groupBy 后吞吐量缓慢答案

【问题标题】：Slow throughput after a groupBygroupBy 后吞吐量缓慢
【发布时间】：2015-01-13 12:25:15
【问题描述】：

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

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

谢谢， G

【问题讨论】：

【解决方案1】：

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

通常吞吐量（记录数/秒）取决于几个因素，例如

一般而言，GroupByKey 构造一个更大的记录，其中包含一个键和具有该键的所有值；即输入是 KV 的集合，输出是 KV>

的集合

因此，通常我希望 GroupByKey 输出的记录比输入记录大得多。由于记录较大，因此处理时间较长，因此记录/秒会趋于减少。

在 Dataflow 的 Alpha 版本中，CPU 使用率低并非意料之外。目前，Dataflow 并未充分利用所有 VM 内核来处理工作。为了改善这一点，我们将进行多项性能改进。

Dataflow 目前提供了两个旋钮，用于通过标志调整并行度

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

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

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

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

目前，Dataflow 仅提供这些非常粗略的旋钮来控制全局级别（而不是每个阶段级别）的并行度。这在未来可能会改变。但是，总的来说，我们的目标是自动为您调整并行度，因此您不必这样做。

【讨论】：

【解决方案2】：

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

Here 是 Google 关于热键及其处理方法的官方文档。根据我的经验，使用Combine.PerKeyWithHotKeyFanout 选择性地应用扇出因子会产生良好的效果。

【讨论】：