如何调试我的 Dataflow 作业卡住的原因？

Question

我有一个 Dataflow 工作没有取得进展 - 或者进展非常缓慢，我不知道为什么。我如何开始调查工作缓慢/卡住的原因？

Answer 1

您应该检查的第一个资源是 Dataflow 文档。检查这些应该很有用：

• 对管道进行故障排除
• 常见错误指导

如果这些资源没有帮助，我将尝试总结一些为什么您的工作可能会卡住的原因，以及您可以如何调试它。我将根据系统的哪个部分引起问题来区分这些问题。你的工作可能是：

作业卡在启动时

作业可能会被 Dataflow 服务接收或启动新的 Dataflow 工作器卡住。一些风险因素是：

• 您是否添加了自定义setup.py文件？
• 您是否有任何需要在 worker 启动时进行特殊设置的依赖项？
• 你在操纵工作容器吗？

为了调试这类问题，我通常打开 StackDriver 日志记录，并查找worker-startup日志（见下图）。这些日志是由工作人员在使用您的代码和依赖项启动 docker 容器时写入的。如果您在此处看到任何问题，则表明您的setup.py、您的作业提交、暂存工件等存在问题。

您可以做的另一件事是保持相同的设置，并运行一个非常小的管道来暂存所有内容：

with beam.Pipeline(...) as p:
  (p 
   | beam.Create(['test element']) 
   | beam.Map(lambda x: logging.info(x)))

如果您没有在 StackDriver 中看到您的日志，那么您可以继续调试您的设置。如果您确实在 StackDriver 中看到了日志，那么您的工作可能会卡在其他地方。

工作似乎卡在用户代码中

可能发生的其他事情是您的工作正在执行一些卡住或缓慢的用户代码操作。一些风险因素是：

• 您的工作是否正在执行需要您等待的操作？（例如将数据加载到外部服务，等待承诺/未来）
  • 请注意，Beam 的一些内置转换就是这样做的（例如，BigQueryIO、FileIO 等 Beam IO）。
• 您的工作是否将非常大的侧输入加载到内存中？如果您使用View.AsList的是侧面输入，则可能会发生这种情况。
• 您的作业是否在GroupByKey操作后加载了非常大的迭代？

此类问题的一个症状可能是管道的吞吐量低于您的预期。另一个症状是在日志中看到以下行：

Processing stuck in step <STEP_NAME>/<...>/<...> for at least <TIME> without outputting or completing in state <STATE>
    .... <a stacktrace> ....

在这种情况下，查看管道中哪个步骤消耗最多时间是有意义的，并检查该步骤的代码，看看可能是什么问题。

一些技巧：

• 非常大的侧输入可能会很麻烦，因此如果您的管道依赖于访问非常大的侧输入，您可能需要重新设计它以避免出现瓶颈。

• 可以对外部服务进行异步请求，但我建议您提交/完成工作startBundle和finishBundle调用。

• 如果您的管道的吞吐量不是您通常所期望的，那可能是因为您没有足够的并行度。这可以通过 a 来解决Reshuffle，或者通过将您现有的键分片成子键（Beam 经常处理每个键，因此如果您的键太少，您的并行度会很低） - 或者使用 aCombiner代替GroupByKey+ ParDo。

• 您的吞吐量低的另一个原因可能是您的工作在外部调用上等待的时间太长。您可以尝试通过尝试批处理策略或异步 IO 来解决此问题。

一般来说，没有灵丹妙药可以提高管道的吞吐量，您需要进行实验。

数据新鲜度或系统滞后增加

首先，我建议您查看有关水印的演示文稿。

对于流媒体，水印的推进是推动管道取得进展的动力，因此，重要的是要注意可能导致水印被阻止并在下游停止管道的事情。水印卡住的一些原因：

• 一种可能性是您的管道遇到了无法解决的错误情况。当包处理失败时，您的管道将继续尝试无限期地执行该包，这将阻止水印。
  • 发生这种情况时，您会在 Dataflow 控制台中看到错误，并且在重试捆绑包时计数会不断攀升。看：

• 将时间戳与数据相关联时，您可能会遇到错误。确保时间戳数据的分辨率是正确的！
• 尽管不太可能，但您可能遇到了 Dataflow 中的错误。如果其他提示都没有帮助，请打开支持票。