Dataflow模型分析

The Dataflow Model 是 Google Research 于2015年发表的一篇流式处理领域的有指导性意义的论文，它对数据集特征和相应的计算方式进行了归纳总结，并针对大规模/无边界/乱序数据集，提出一种可以平衡准确性/延迟/处理成本的数据模型。

逻辑引擎设计

无论是流式计算/微批次或是批处理，它们要处理的问题都可以抽象为以下几个问题:

• What: 需要计算的结果数据是什么
• Where: 计算的上下文环境是什么
• When: 什么时候计算输出结果
• How: 如何修正早期计算结果

针对这些问题，The Dataflow Model 分别提出了:

• windowing model;
• triggering model；
• incremental processing model ；

这些模型并不依赖物理引擎的具体实现，以允许系统设计者结合自己需求灵活集成其中的思想，以及在CLC三者中寻找平衡。

windowing model

• Windowing 策略描述了事件处理的上下文，即Where的问题；
• 该论文在原语上提供了GroupByKey，支持聚合的系统经常会将其重新定义为粒度更细的GroupByByAndWindow；
• 从模型简化的角度上，把所有的窗口策略都当做非对齐窗口，而底层实现来负责把对齐窗口作为一个特例进行优化；
• 窗口操作可以被分隔为assignWindows和mergeWindows两个相关的操作：
  • assignWindows即为事件分配对于的窗口（零个或多个）；
  • mergeWindows即对多个窗口进行合并，通常的使用场景是滑动窗口(校准窗口)间的合并和会话窗口(非校准窗口)间的合并，窗口合并包含以下几步：
    • DropTimestamps： 删除数据上的时间戳，因为窗口合并后，后续的计算只关心窗口；
    • GroupByKey ： 把（值，窗口）二元组按键进行分组；
    • MergeWindows ： 把同一个键的（值，窗口）进行窗口合并。具体的合并方式取决于窗口策略；
    • GroupAlsoByWindow – 对每个键，把值按合并后的窗口进行进一步分组；
    • ExpandToElements – 把已经按键，按窗口分好组的元素扩展成(键，值，事件发生时间，窗口)四元组；

triggering model

触发器决定了什么时候一个窗口被计算和输出为窗格（稳定的计算结果），即When的问题。Trigger为一种受内部或者外信号触发GroupByKeyAndWindow执行并输出执行结果的机制：

• 窗口： 决定哪些事件发生时间段（where）的数据被分组到一起来进行聚合操作；
• 触发： 决定在什么处理时间（when）窗口的聚合结果被处理输出成一个窗格；

触发器还提供了三种不同的模式来控制不同的窗格（计算结果）之间是如何相互关联的：

• 抛弃：窗口触发后，窗口内容被抛弃，而之后窗口计算的结果和之前的结果不存在相关性；
• 累积：触发后，窗口内容被完整保留住持久化的状态中，而后期的计算结果成为对上一次结果的一个修正的版本；
• 累积和撤回：触发后，在进行累积语义的基础上，计算结果的一份复制也被保留到持久化状态中。当窗口将来再次触发时，上一次的结果值先下发做撤回处理，然后新的结果作为正常数据下发；

incremental processing model

Lambda 架构包含三个核心 view: batch view ，real time view 和 query view：

• batch view 存放较早前（一般是数小时以前）的完整数据的离线计算结果；
• real time view 存放的是未进入 batch view 的数据的计算结果，这部分会随着新数据到来而频繁更新；
• query view 负责处理查询，合并 batch view 和 real time view 的结果输出。

参考：

• http://www.whitewood.me/2018/05/07/The-Dataflow-Model-%E8%AE%BA%E6%96%87%E6%80%BB%E7%BB%93/
• https://yq.aliyun.com/articles/64911
• https://www.jianshu.com/p/0faa1c1caa47
• https://www.infoq.cn/article/dataflow-apache-beam