为什么groupBy瓶颈我的管道？

我有一个用python apache-beam编写的管道。它将800,000个带时间戳的数据分成2秒钟的窗口，每1秒重叠一次。我的元素可能有不同的键。为什么groupBy瓶颈我的管道？

当它做了GROUPBY，则需要3个小时才能完成。我使用10名员工部署在云数据流中。当我增加工人数量时，处理速度没有显着提高。为什么这种变革瓶颈我的管道？

2016-09-22 agsolid

我不熟悉，在这个问题上的特定标签，但为了开展“GROUPBY”操作（在非索引字段），那么无论做分组必须将整个数据集于一体排序地点。没有这个操作，你可能有容易并行的数据。这是一个字吗？ –

是否有显示问题的特定工作ID？正如Kenny Ostrom所说，gorupby不仅需要在一个地方对数据进行排序，还需要在工作人员之间传递数据，以便处理单个密钥的工作人员具有所有相关的值。元素有多大（这应该显示在每个步骤的Dataflow UI中）？ –

除非元素很大，否则在每个800,000个元素上执行groupby应该非常快。最有可能的事情是瓶颈 - 你在做每件元素或每把钥匙都非常昂贵的东西吗？有多少个不同的钥匙？（一个按键是按顺序处理的，所以如果只有很少的按键，那么无论您指定了多少工人，都会限制可达到的最大并行度）的确如此，很难说出没有工作编号的情况下会发生什么。 – jkff

总结从JKFF和别人的答案：

管道似乎是由一个非常大的键瓶颈。您可以使用常规的Java日志和工作人员的日志看（如测量processElement（您DOFN的处理时间）与记录它，如果它是大于阈值），但不幸的是，我们还没有进行调试“热键”提供了更高级的工具的问题。

您也可以打开autoscaling，使该服务可以，至少，关闭未使用的工人，这样你就不会产生对他们收费。

来源

2017-05-04 17:48:12

为什么groupBy瓶颈我的管道？

回答

相关问题