数据流作业后临时文件保留在 GCS 中 "succeeded"
temp files remain in GCS after a Dataflow job "succeeded"
我的团队 运行 有几个 hourly/daily 数据流作业，主要是从 GCS 读取和写入（也就是说，我们有几十个定期的数据流作业计划 运行 在一个日）。
一些作业从 GCS 读取由先前作业生成的数据。
大约一周一次或两次，我们面临以下问题：
作业 A 成功 运行s，并将其输出写入 GCS 的 gs://A/output/.
（发生在作业 A 和作业 B 之间的主要问题在下一段中描述）。
作业 B 从 gs://A/output 读取以处理一些数据，但抛出异常，因为在作业 运行ning 或到期时删除了临时文件对于临时文件，数据中的键不再是唯一的（例如，如果作业 B 创建上述数据的 MapView，就会发生这种情况）。
因此，据我们能够调试的原因如下：
当作业 A 完成时（例如，根据其管道状态），gs://A/output/ 下的所有 'temp' 文件应该已重命名为该文件作业指定的名称。
然而，其中一些临时文件会在作业 A 完成后徘徊几分钟——有时，我们甚至会在作业 A 完成后几个小时看到这些临时文件，因此我们经常必须手动删除它们。
例如，我们只看到目录中约 7,500 个文件中的一两个临时文件徘徊，它们通常在一个小时内消失，但有时它们会停留几个小时。
我们想知道以下问题：
我们的理解是否正确，GCS 输出目录中的所有 "temp" 文件应该在作业 A "finishes" 之前重命名（例如，在监控 UI 上它说它成功了，它已经停止了工作池等）？换句话说，作业完成表明临时文件已消失？
如果是，是不是我们在作业完成后看到临时文件的错误？
如果不是，我们（用户）如何知道作业 "really" 已完成，因为它的输出目录不包含临时文件？ （我们应该用我们自己的文件模式匹配脚本或类似的东西来检查它吗？）
我用 GCS 和 Dataflow 作为关键字进行了一些搜索，但没有找到与我们遇到的问题相近的东西——但我可能遗漏了一些东西，所以我们将不胜感激！
抱歉给您带来麻烦。这是TextIO.Write中的一个错误，是由于删除临时文件时遇到GCS eventual consistency，无法找到并删除所有临时文件造成的。
幸运的是，在将临时文件复制到它们的最终位置时它仍然会查看所有正确的文件，因此没有数据丢失。
我们将考虑提供修复。
再次注意，由于 GCS 的最终一致性，作业 B 也可能无法读取 A 产生的一些输出——即使有潜在的修复，这也将保持真实，并且 Dataflow 已经现在没有简单的方法来解决这个问题。但是，随着您增加完成 A 和开始 B 之间的间隔，出现这种情况的可能性会降低。
如果可能，我建议将 A 和 B 连接到一个管道中，将此数据表示为中间 PCollection。如果您需要将此数据具体化为 GCS 上的文本用于其他目的（例如手动检查、服务、使用不同工具处理等），您仍然可以从这个联合管道中执行此操作，只是不要使用 GCS 传递一个管道和另一个管道之间的数据。
我的团队 运行 有几个 hourly/daily 数据流作业，主要是从 GCS 读取和写入（也就是说，我们有几十个定期的数据流作业计划 运行 在一个日）。 一些作业从 GCS 读取由先前作业生成的数据。 大约一周一次或两次，我们面临以下问题：
作业 A 成功 运行s，并将其输出写入 GCS 的 gs://A/output/.
（发生在作业 A 和作业 B 之间的主要问题在下一段中描述）。
作业 B 从 gs://A/output 读取以处理一些数据，但抛出异常，因为在作业 运行ning 或到期时删除了临时文件对于临时文件，数据中的键不再是唯一的（例如，如果作业 B 创建上述数据的 MapView，就会发生这种情况）。
因此，据我们能够调试的原因如下：
当作业 A 完成时（例如，根据其管道状态），gs://A/output/ 下的所有 'temp' 文件应该已重命名为该文件作业指定的名称。
然而，其中一些临时文件会在作业 A 完成后徘徊几分钟——有时，我们甚至会在作业 A 完成后几个小时看到这些临时文件，因此我们经常必须手动删除它们。
例如，我们只看到目录中约 7,500 个文件中的一两个临时文件徘徊，它们通常在一个小时内消失，但有时它们会停留几个小时。
我们想知道以下问题：
我们的理解是否正确，GCS 输出目录中的所有 "temp" 文件应该在作业 A "finishes" 之前重命名（例如，在监控 UI 上它说它成功了，它已经停止了工作池等）？换句话说，作业完成表明临时文件已消失？
如果是，是不是我们在作业完成后看到临时文件的错误？
如果不是，我们（用户）如何知道作业 "really" 已完成，因为它的输出目录不包含临时文件？ （我们应该用我们自己的文件模式匹配脚本或类似的东西来检查它吗？）
我用 GCS 和 Dataflow 作为关键字进行了一些搜索，但没有找到与我们遇到的问题相近的东西——但我可能遗漏了一些东西，所以我们将不胜感激！
抱歉给您带来麻烦。这是TextIO.Write中的一个错误，是由于删除临时文件时遇到GCS eventual consistency，无法找到并删除所有临时文件造成的。
幸运的是，在将临时文件复制到它们的最终位置时它仍然会查看所有正确的文件，因此没有数据丢失。
我们将考虑提供修复。
再次注意，由于 GCS 的最终一致性，作业 B 也可能无法读取 A 产生的一些输出——即使有潜在的修复，这也将保持真实，并且 Dataflow 已经现在没有简单的方法来解决这个问题。但是，随着您增加完成 A 和开始 B 之间的间隔，出现这种情况的可能性会降低。
如果可能，我建议将 A 和 B 连接到一个管道中，将此数据表示为中间 PCollection。如果您需要将此数据具体化为 GCS 上的文本用于其他目的（例如手动检查、服务、使用不同工具处理等），您仍然可以从这个联合管道中执行此操作，只是不要使用 GCS 传递一个管道和另一个管道之间的数据。