etl - Pipeline从GCS输入80亿行并做了GroupByKey以防止融合，group step运行非常慢

Question

我从GCS读取了80亿行，对每一行进行处理，然后输出。我的处理步骤可能需要一点时间，以避免 worker 租约到期并出现以下错误；我对 80 亿进行了 GroupByKey 并按 id 分组到 prevent fusion .

A work item was attempted 4 times without success. Each time the worker eventually lost contact with the service. The work item was attempted on:

问题是，即使在 1000 个 high-mem-2 节点上，GroupByKey 步骤也需要永远完成 80 亿行。

我调查了处理缓慢的可能原因； GroupByKey 为每个键生成的每个值的大小很大。我认为这是不可能的，因为在 80 亿个输入中，一个输入 id 不能在该集合中出现超过 30 次。很明显，HotKeys 的问题不在这里，而是有其他问题发生。

任何有关如何优化此问题的想法都将受到赞赏。谢谢。

Answer 1

我确实设法解决了这个问题。我对dataflow wall times有很多错误的假设。 。我正在查看我的管道和墙壁时间最长的步骤；我认为这是几天的瓶颈。但在 Apache Beam 中，一个步骤通常与管道下游的步骤融合在一起，并且只会与管道下游的步骤运行得一样快。因此，显着的挂起时间不足以得出此步骤是管道中的瓶颈的结论。上述问题的真正解决方案来自this thread 。我减少了管道运行的节点数量。并将节点类型从 high-mem-2 更改为 high-mem-4。我希望有一种简单的方法来获取数据流管道的内存使用指标。我必须通过 ssh 进入虚拟机并执行 JMAP。