groupBy 后吞吐量缓慢

Question

我注意到在我的作业中，吞吐量（报告的 records/sec 数量）在 "group by" 步骤后显着减慢。当该工作流步骤执行时，我看到一些实例的 CPU 利用率约为 30%，而有些实例似乎处于空闲状态。

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

谢谢， G

Answer 1

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

一般吞吐量（records/sec 的数量）取决于几个因素，例如

记录的大小。
ParDo 执行的处理量

一般来说，GroupByKey 会构造一个更大的记录，该记录由一个键和具有该键的所有值组成；即输入是 KV 的集合，输出是 KV>

的集合

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

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

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

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

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

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

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

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

Answer 2

低吞吐量也可能是 "hot-keys," 或非常频繁出现的键的结果。这将导致一些非常大的集合由单个 worker 上的单个核心处理。

Here is Google's official documentation regarding hot keys and how to deal with them. In my experience, selectively applying a fanout factor using Combine.PerKeyWithHotKeyFanout取得了不错的成绩

groupBy 后吞吐量缓慢

Slow throughput after a groupBy

google-cloud-dataflow