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 的结果输出。
参考：
