我从GCS读取了80亿行，在每行上进行处理，然后输出。我的处理步骤可能需要一些时间，以避免工人租约到期并低于错误;我对80亿进行了$app->singleton('filesystem', function ($app) {
return $app->loadComponent('filesystems', 'Illuminate\Filesystem\FilesystemServiceProvider', 'filesystem');
});
，并按ID分组到prevent fusion。
尝试了4次工作项而没有成功。每一次 工人最终失去了与服务的联系。工作项目是 试图：
问题是即使在1000个高mem-2节点上，GroupByKey步骤也将永远完成80亿行。
我研究了处理缓慢的可能原因; GroupByKey为每个键生成的每个值的大小。我不认为这是可能的，因为在80亿输入中，一个输入id不能超过30次。显然，HotKeys的问题不在这里，还有其他事情正在发生。
有关如何优化此功能的任何想法都表示赞赏。感谢。
答案 0 :(得分：0)
我确实设法解决了这个问题。关于dataflow wall times，我在这里有一些不正确的假设。我正在看着我的管道和最长的墙壁时间;这是几天，我认为是瓶颈。但是在Apache梁中，一个步骤通常与管道中下游的步骤融合在一起，并且只能在管道运行的下降步骤中运行。因此，重要的隔夜时间不足以得出结论，这一步骤是管道中的瓶颈。上述问题的真正解决方案来自this thread。我减少了管道运行的节点数量。并将节点类型从high-mem-2更改为high-mem-4。我希望有一种简单的方法来获取数据流管道的内存使用指标。我不得不进入虚拟机并进行JMAP。