工作在启动时卡住了

数据流服务可能会卡住作业，或者启动新的数据流工作器。某些危险因素是：

要调试此类问题，我通常打开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调用中落实/完成工作。
如果管道的吞吐量不是通常所期望的，则可能是因为您没有足够的并行性。这可以通过Reshuffle来解决，也可以通过将现有密钥分片为子密钥来解决（Beam通常会处理每个密钥，因此，如果密钥太少，则并行度会很低）-或使用{{ 1}}，而不是Combiner + GroupByKey。
吞吐量低的另一个原因可能是您的工作在外部呼叫上等待的时间太长。您可以尝试使用批处理策略或异步IO来解决此问题。

通常，没有什么灵丹妙药可以提高管道的吞吐量，并且需要进行实验。

对于流而言，水印的前进是驱动管道取得进展的动力，因此，请务必注意可能导致水印受阻并使管道向下游停顿的事情，这一点很重要。水印可能卡住的一些原因：

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