groupBy之后的吞吐量很慢

Question

我注意到在我的工作中，吞吐量（报告的记录数/秒）在“分组依据”步骤后显着减慢。 当执行该工作流程步骤时，我发现某些实例的CPU利用率约为30％，而有些实例似乎处于空闲状态。

是数据流问题还是应该以某种方式指示工作流程增加此步骤的并行性？

谢谢， ģ

Answer 1

如果不了解管道正在做什么的更多细节，很难确定发生了什么。

一般来说，吞吐量（记录数/秒）取决于几个因素，例如

• 记录大小。
• ParDo的处理量

通常，GroupByKey构造一个更大的记录，该记录由一个键和包含该键的所有值组成;即，输入是KV＆lt; K，V＆gt;的集合。并且输出是KV＆lt; K，Iterable＆lt; V＆gt;＆gt;

的集合

因此，一般来说，我希望GroupByKey输出的记录比输入记录大得多。由于记录较大，因此处理时间较长，因此记录/秒会降低。

数据流的Alpha版本中CPU使用率低并不意外。目前，Dataflow尚未充分利用所有VM核心来处理工作。许多性能改进正在改善这一点。

Dataflow目前提供两个旋钮，用于通过标志

调整并行度

--numWorkers=<integer>
--workerMachineType=<Name of GCE VM Machine Type>

- numWorkers允许您增加或减少用于并行处理数据的工作人员数量。通常，增加工作者数量可以并行处理更多数据。

使用--workerMachineType，您可以选择具有更多或更少CPU或RAM的计算机。

如果您发现VM的CPU未得到充分利用，您可以选择CPU较少的计算机（默认情况下，Dataflow每个VM使用4个CPU）。如果减少每台计算机的CPU数量但增加numWorkers以使CPU总数大致相同，则可以增加并行度，而不会增加工作成本。

现在Dataflow只提供这些非常粗糙的旋钮来控制全局级别的并行度（而不是每级级别）。这可能在将来发生变化。但是，一般来说，我们的目标是为您自动调整并行度，因此您不必这样做。

Answer 2

低吞吐量也可能是“热键”或非常频繁出现的键的结果。这将导致一些极大的集合由单个工作者的单个核心处理。

Here是Google关于热键以及如何处理热键的官方文档。根据我的经验，使用Combine.PerKeyWithHotKeyFanout选择性地应用扇出因子已经取得了很好的效果。