Python Apache Beam数据流管道-具有高壁时间的简单DoFn

我正在查看最近部署的管道的作业图，我注意到一个看似非常简单的DoFn似乎比其他任务占用了大量的处理时间

管道获取流式会话数据消息，这些消息同时具有

project\u id

和

user\u id

标识符，并生成在项目级别聚合的每小时汇总，并将其保存到BigQuery。管道每秒处理约1k条JSON消息，并在10台

n2标准机器上运行。这些步骤的简要总结：

从PubSub阅读
窗口-5天固定窗口，具有3小时重复触发和
累积模式。累积
按用户聚合+一组其他字段（即使我们最终进行项目级汇总，但必须首先执行此步骤以避免对某些字段进行过多计算）
从旧的
（键）、值
映射到新的
（键）、值
（从键列表中删除用户id，以便我们现在在项目级别聚合）
计算每小时的项目级汇总
保存到BQ
从图中可以看出，对于刚从一组关键点映射到另一组关键点的DoFn，墙时间（在步骤上花费的时间）似乎非常高。我在这里犯了一些卑鄙的梁/数据流罪吗？这只是数据流UI的一个工件吗？我对Beam和Dataflow都是新手，如果您有任何建议，我将不胜感激

您可以使用上的选项获取个人资料，并计算出您在特定DOFN中的时间花费。
您好，我认为这是正常的。在“折叠到项目”操作中可能有一个“分组方式”操作，它会触发机器之间的洗牌。这意味着网络流量在时间上是昂贵的，这会增加步骤的挂墙时间。hi@jszule感谢您的响应！在这个问题上我应该更清楚，但在项目运作的崩溃中没有“分组”操作发生。“CollapseKeys（））

@user3637516我看到您已将工人数量设置为10。但是，您的流程CollapseKeys（）似乎需要10个以上的工作人员。您是否考虑过将自动调用与设置一起使用，而不是在整个过程中使用10个工人？如果这确实是您的DoFn，这是令人惊讶的。（出现这种情况的一个地方是，如果您的DoFn在GroupByKey之后迭代（可能很大）一组值，这会导致实际的GBK读取，但您在这里似乎没有这样做……）

class CollapseKeys(beam.DoFn):
    """
    Re-map data to the hour/org/project/release/env level (remove distinct_id key)
    """
    def process(self, elem, window=beam.DoFn.WindowParam):
        (timestamp, org_id, project_id, release, env, sdk, distinct_id), vals = elem
        yield (timestamp, org_id, project_id, release, env, sdk), vals