The Dataflow Model论文学习笔记

因为是被誉为流计算基石的论文，所以决定花时间学习一下。

这篇论文在开篇总结了流计算的应用场景 主要是说现在对数据处理的语义越来越复杂， 对延时性的要求越来越苛刻。。

在这里对Spark Streaming的微批次流处理模型进行了批评，在流计算的时候应该遵从的理念是我们不知道数据何何时流何时被终结，何时数据会完整，唯一确信的是新的数据会源源不断的进来，老的数据会被撤销或者更新。基于这个思路来设计一个流计算编程模型。该论文的主要贡献在于

1、提出了一个统一的模型能够对无边界并且无序的数据源按照数据自身的特征进行窗口计算，然后在正确性、延时性和处理成本之间做一个调整。

2、在四个相关维度上分解管道实现，提供清晰度，可组合性和灵活性，也就是对流计算框架的设计提出了4个问题，对于这4个问题先贴出前大哥的演讲文稿中描述Flink怎么回答的这4个问题答案。

What results are being computed(定义DAG图)

Where in event time they are being computed.(定义各类窗口（固定窗口、滑动窗口和Session窗口）

When in processing time they are materialized.支持灵活定义计算触发时间

How earlier results relate to later refifinements.支持丰富的Function定义数据更新模式

论文给出了三种窗口机制(fix slide session)的设计思路（参考Flink的实现理解会比较清楚， 论文其实讲的不是很清楚感觉).

接下来基于这个图讲解了watermark和event time、processingtime之间的关联。直线代表了event time = processtime的关系，此时Event Time Skew(就是事件发生到数据处理管道的延迟） = 0， 而watermark是来说明小于某个时间点的数据已经被处理完了的标记。   watermark机制对窗口计算数据的准确性是有影响的。  设置的过短会导致在watermark水位以后还有数据到达从而影响了数据计算的准确性，设置的过长则会造成触发窗口计算结果的延时。 参考lambda架构提供了低延时的近似结果计算和最终一致性正确的结果计算。 那怎么来解决这个问题呢？ 就是通过Trigger来实现。Trigger可以选择在何时触发指定窗口的输出结果。 提出了一种概念叫基于窗口的完成度估计的预定义触发器(这个没有仔细说明 不太理解)

然后提出了三种模式 这个的话我在学FlinkSQL的时候有看到相关联的知识也就是以下三种

①Discarding:窗口触发后，窗口内容被丢弃，之后窗口计算的结果和之前的结果不存在相关性。这样保持了计算结果之间的独立。

②Accumulating:窗口触发后，窗口内容还持久化进行保存，后期的计算结果会成为对上一次结果的修正。

③Accumulating & Retracting: 这个相比Accumulating的应用场景不一样， 窗口再次触发时会因为上次的计算结果而导致这次的计算结果失败。 具体案例还是可以参照FlinkSQL。