Google Dataflow 工作人员完成度达 99%

Question

我被这个问题困扰了一个多星期了。当我运行以下管道时，我的工作人员会翻阅我的数据 - 直到 99% 标记，他们会无限期地挂在这个标记上。我想不出一个不涉及大量工程的简单解决方案来解决这个问题。我也无法知道原因，因为我的应用程序日志显示传递给落后工作人员的最后一个输入已成功转换（因此它没有挂在地图中间）。

如果我有办法为整个作业添加超时，我就可以杀死那些挂起的工人并用我所拥有的完成管道。不幸的是，python 的超时库非常脆弱（不能使用信号，func_timeout 仅在未嵌套时有效，不能 fork 另一个进程等）。

落后工人：

管道阶段：

对受影响管道阶段的影响： - 请注意，当吞吐量下降时，我的工作应该结束，因为它实际上已完成 99.9%。然而，我是按工人纺纱的时间付费的。

请注意，“训练”阶段正在处理多一个数量级的数据。

尝试修复

• 为我的处理函数添加超时
  • 提高了我的吞吐量，但问题仍然存在

我相信原因是 Dataflow 末端的一些雷击错误杀死了我的管道（可能是由于任何原因 - 资源匮乏、工作窃取期间的死锁、网络下降等）。因此，我更感兴趣的是弄清楚如何使我的管道能够应对这些问题，而不是必须预测/预防所有这些问题。

管道代码

（复制3次 -

Train

/

Val

/

Test

）

"ReadFromText" >> beam.io.ReadFromText(file_pattern=data_path)
| "Shuffle0" >> beam.Reshuffle()
| "Convert" >> beam.FlatMap(map_fn)
| "Shuffle1" >> beam.Reshuffle()
| "Write" >> beam.io.WriteToTFRecord(
    output_path,
    coder=beam.coders.ProtoCoder(tf.train.Example)))

Answer 1

我认为问题可能正在酝酿之中。

中的转换步骤使用了 2 天的挂壁时间，而其他两条管道则需要几个小时。该管道有什么不同？无论出于何种原因，转换步骤都很慢。一种可能是内存问题。查看作业的内存和 CPU 图表。如果您看到“峰值”模式（不断上升和下降），这可能是内存问题的一个指标（通过检查工作日志来确认）。

如果您遇到内存问题，我会尝试使用Dataflow Prime（存在内存问题时垂直自动缩放），或者可能是具有 highmem 工作线程的常规 Dataflow 作业（但 Dataflow Prime 可能会在正确匹配所需资源方面做得更好每一步）。

但是您的转换步骤可能很慢。如果实现可以并行处理数据，那么应该没问题，并且不需要垂直可扩展性。但根据正在执行的步骤，可能无法以可并行的方式实现。