我的团队每小时/每天运行几个Dataflow作业，这些作业主要是读写GCS（也就是说，我们有几十个定期在一天内运行的重复数据流作业）。 有些工作从GCS读取数据，这是由以前的工作产生的。 一周大约一到两次，我们面临以下问题：
作业A成功运行，并以gs：// A / output /将其输出写入GCS。
（我们确定的工作A和工作B之间发生的主要问题将在下一段中介绍。）
作业B从gs：// A / output读取以处理某些数据，但是因为临时文件在作业运行时被删除，或者由于临时文件而导致数据中的键为no，因此会引发异常更长的唯一（例如，如果作业B创建上述数据的MapView，则会发生这种情况）。
因此，我们能够调试的原因如下：
当作业A完成时（根据其管道状态，例如），所有＆＃39; temp＆＃39; gs：// A / output /下的文件应该已重命名为作业指定的文件名。
然而，在Job A完成后，其中一些临时文件徘徊了几分钟 - 有时，我们甚至在Job A完成后几个小时看到那些临时文件，所以我们经常要删除它们手动
例如，我们只看到一个或两个临时文件在目录中的约7,500个文件中挥之不去，它们通常会在一小时内消失，但有时会停留几个小时。
我们想知道以下事项：
我们的理解是否正确所有＆＃34; temp＆＃34;在作业A＆＃34;完成＆＃34;之前，应重命名GCS输出目录中的文件。 （例如，在监控UI上，它说它成功了，它已经停止了工作池等）？换句话说，完成作业是指示临时文件消失了吗？
如果是，那么在作业完成后我们会看到临时文件的错误吗？
如果不是，我们（用户）怎么知道这份工作是＆＃34;真的＆＃34;在输出目录不包含临时文件的意义上完成？ （我们应该使用我们自己的文件模式匹配脚本或类似的东西来检查吗？）
我使用GCS和Dataflow作为关键字进行了一些搜索，但没有发现我们遇到的问题 - 但我可能错过了一些内容，所以任何帮助都会非常感激！
答案 0 :(得分：3)
对不起，不好意思。这是TextIO.Write中的一个错误，原因在于，删除临时文件时，它会遇到GCS eventual consistency，无法找到并删除所有文件。
遗憾的是，在将临时文件复制到最终位置时，它仍会查看所有正确的文件，因此不会丢失数据。
我们将研究提供修复。
请注意，由于GCS最终的一致性，作业B也可能无法读取 A产生的某些输出 - 即使有潜在的修复，这也将保持正确，并且Dataflow没有简单的寻址方式现在这个。但是，当你增加完成A和开始B之间的间隔时，这种减少的几率会降低。
如果可能，我建议将A和B连接到一个管道中，将此数据表示为中间PCollection。如果您需要将此数据在GCS上作为文本实现用于其他目的（例如手动检查，服务，通过其他工具处理等），您仍然可以从此联合管道执行此操作，只是不要使用GCS进行传递一个管道与另一个管道之间的数据。