Dataflow 作业“成功”后，临时文件仍保留在 GCS 中

Question

我的团队每小时/每天运行几个 Dataflow 作业，这些作业主要从 GCS 读取和写入（也就是说，我们有几十个定期运行的 Dataflow 作业计划在一天内运行）。 一些作业从 GCS 读取先前作业产生的数据。 每周大约有一次或两次，我们会遇到以下问题：

• 作业 A 成功运行，并将其输出写入位于 gs://A/output/ 的 GCS。

• （我们确定的工作 A 和工作 B 之间发生的主要问题将在下一段中描述）。

• 作业 B 从 gs://A/output 读取以处理一些数据，但由于在作业运行时删除了临时文件或由于临时文件导致数据中的键不存在而引发异常更长的唯一性（例如，如果作业 B 创建了上述数据的 MapView，则会发生这种情况）。

所以，就我们能够调试而言，原因如下：

• 到作业 A 完成时（根据其管道状态，例如），gs://A/output/ 下的所有“临时”文件都应重命名为由工作。

• 然而，其中一些临时文件会在作业 A 完成后持续存在几分钟 - 有时，我们甚至会在作业 A 完成几小时后看到这些临时文件，因此我们经常不得不删除它们手动。

• 例如，在目录中的约 7,500 个文件中，我们只看到一两个临时文件徘徊，它们通常会在一个小时内消失，但有时会保留几个小时。

我们想知道以下几点：

• 我们的理解是否正确，即 GCS 输出目录中的所有“临时”文件都应在作业 A“完成”之前重命名（例如，在监控 UI 上它说它成功，并且它已经停止了工作池等）？换句话说，作业的完成是否表明临时文件已经消失？

  • 如果是，我们在作业完成后很长时间才能看到临时文件，这是一个错误吗？

  • 如果不是，我们（用户）如何知道作业“真正”完成了，因为它的输出目录不包含临时文件？ （我们应该用我们自己的文件模式匹配脚本或类似的东西来检查它吗？）

我使用 GCS 和 Dataflow 作为关键字进行了一些搜索，但没有找到与我们遇到的问题相近的内容 - 但我可能遗漏了一些东西，因此非常感谢任何帮助！

Answer 1

很抱歉给您带来麻烦。这是TextIO.Write中的一个bug，是因为删除临时文件时遇到GCS eventual consistency，无法找到并全部删除。

幸运的是，在将临时文件复制到最终位置时，它仍然会查看所有正确的文件，因此不会丢失数据。

我们会考虑提供修复。

请注意，再次由于 GCS 最终一致性，作业 B 也可能无法读取 A 生成的某些输出 - 即使有潜在的修复，这仍将保持不变，并且 Dataflow 没有简单的解决方法现在这个。但是，随着您增加完成 A 和开始 B 之间的间隔，这种可能性会降低。

如果可能，我建议将 A 和 B 连接到单个管道中，将此数据表示为中间 PCollection。如果您需要将此数据物化为 GCS 上的文本以用于其他目的（例如，手动检查、服务、由不同工具处理等），您仍然可以通过此联合管道执行此操作，只是不要使用 GCS 传递一个管道和另一个管道之间的数据。