数据流融合+窗口/触发器

Question

我知道 Dataflow 可以通过Fusion Optimization 修改管道的执行图。

窗口/触发器是否会影响融合优化？

流式传输管道和/或无限源 (Pub/Sub) 是否会影响该行为？

Answer 1

Beam 编程模型的所有复杂操作，包括对窗口/触发等的评估，最终都被转换为（可能是有状态的）ParDo 和 GroupByKey 操作（又名 Map 和 Reduce）的低级图:) )。

例如

• 您可以将分配窗口 (Window.into()) 视为一个 ParDo，它接受一个元素并返回元素时间戳映射到的所有窗口的对（元素、窗口）列表
• 原始管道中的GroupByKey（或Combine）通过组合键(user key, window) 转换为GroupByKey
• 触发器的评估发生在有状态的ParDo 之后立即插入任何GroupByKey 并通过缓冲新值并根据触发器决定它是否已经对到达给定键/窗口的新值做出反应是否发出累积值的时间。

这不是一个精确的对应关系（windows 的语义比这复杂一点），只是为了给你一个想法。

Fusion 在ParDo 和GroupByKey 的这个低级图上运行，将ParDo 的一些链折叠成一个ParDo。 Fusion 不在乎某些 ParDos 是否扮演与窗口相关的角色，或者 GroupByKey 是否按复合键分组等。

我相信在 Dataflow Streaming 运行器中，融合在实践中比在批处理运行器中更具侵略性（它总是折叠 ParDos 的链）（仅在根据数据大小估计似乎有益的情况下折叠，基于FlumeJava paper)，但随着我们对两个跑步者的改进，这可能会改变。