如何设计一个良好的流系统？（下）

概念

在Streaming 101中，作者引入了窗口和时间的概念，在本文中，作者为了解决流处理系统无法精确的处理结果的问题，提出了下面三个概念：

• Watermarks：为了解决处理结果的完整性，也就是说，保证流处理系统确确实实把某个窗口的输入数据全部处理了，从而提出Watermarks表示与事件时间相关联的输入完整性的概念，对于事件时间为X的Watermark是指：已经观察到事件时间小于X的所有输入数据。
• Triggers：引入外部信号触发机制，用于表示什么样的信号会真正地触发窗口中的数据被计算。（例如：某人在断网时记录各种动作及其事件时间，然后在重新联网后，上传这些事件进行处理。）
• Accumulation：指定在同一窗口中观察到的多个运算结果之间的关系。这是为了解决early data和late data。

问题

作者认为流系统中，有四个核心问题要解决（what,where,when,how）：

1. What results are calculated?：也就是说，如何进行计算结果。简单的答案：使用transform操作
2. Where in event time are results calculated?：也就是说，计算什么时间范围的数据。简单的答案：在pipeline中用EventTime来窗口化数据
3. When in processing time are results materialized?：也就是说，何时将计算结果输出？简单的答案：使用watermark和trigger配合触发计算。
4. How do refinements of results relate?：也就是说，后续数据的处理结果如何影响之前的处理结果？简单的答案：Accumulation：丢弃（结果之间是独立且不同的），累积（后来的结果建立在先前的结果上）或累积并撤回（其中累积值加上先前触发的值的撤回）

本文的核心也是在于如何使用时间、窗口、水印（watermark），触发器（trigger）和累积（accumulation）五个概念去解决上面的四个问题。

What: transformations

Transform操作可以是对元素一个一个操作，也可以是聚集（agg）操作，或者可以与其他的数据集相互组合。单纯的transform操作类似于批处理，只有接收到所有的input值才会开始处理，但是对于无穷的数据集，transform就需要考虑等待时间了，所以需要引入了窗口概念，合理的切分数据集处理。

Where: windowing

窗口化是沿着时间边界分割数据源的过程。常见的窗口划分策略包括固定窗口，滑动窗口和会话窗口。但是简单的窗口划分会出现一个问题，那就是如何保证窗口确实把数据完整的切分了。

When: watermarks

Watermark是在Event-Time域上的时间概念，用来刻画输入完整性。是系统以Event-Time为尺度来衡量事件流中Record处理进度/完整性。Watermark分为两种：

• 完美Watermark：如果我们对所有输入数据十分了解，就有可能构建一个完美的Watermark。这种情况下，输入源不存在数据迟来的问题，所有数据只会提前或者准时到达。但是完美Watermark太慢了，当watermark因为知道有数据还没到来被正当地推迟了，这种延迟会直接影响了系统最终输出的时间。
• 启发式Watermark：启发式Watermark会使用一切可用的信息（包括分区，分区内排序，文件增长速度等）来尽量准确地推断输入的进度。但是启发式的watermark算法不能正确地标识数据。某些Event-Time小于watermark的数据会迟到地到达，产生了late data，从而漏计算了这些数据，产出了不正确的结果。

因此，仅仅依靠watermark的系统是不能同时获得低延迟和正确性的，解决这些问题的关键是引入触发器（Trigger）的概念。

When: triggers

触发器表示一个窗口的计算结果在哪个处理时间被输出？在窗口内的每次特定输出都被称为窗口的窗格（pane）。触发器有以下的类型：

• Watermark的进度（如：事件时间的值）：当watermark线到达窗口终点时触发输出。
• 处理时间的进度：用来提供定期更新数据，因为处理时间（不像事件时间）总是大致均匀地移动，而不会出现延迟。
• 到达元素的数量：窗口中观察到一些有限数量的元素之后进行触发
• 特殊的标记：在Record的一些记录或特征值（例如，EOF元素或刷新事件）指示应该生成输出。 除了触发器标志外，还有对触发器进行组合：
• 重复触发（Repetitions）：类似于提供定时更新操作。
• 联合触发（Conjunctions） ：(逻辑 AND)，只有所有子Trigger触发才会触发。
• 各自触发（Disjunctions）： (逻辑 OR)，只要有一个子触发器触发，就会触发 。
• 按顺序触发（Sequences）：以预定义的顺序触发子触发器。（后一个子触发器必须等待前一个触发器触发）

有了触发器使得可以优雅的处理late data，不至于长时间等待late data，也不会漏过late data。但是会产生一个问题，何时关闭窗口，当late data迟迟没有到来的时候。

When: allowed lateness （垃圾回收，何时关闭Window）

在系统内可以定义一个允许数据迟到的视界（horizon，理解成时间范围），理想状态下，需要保存每一个窗口的状态，等待late data数据，但在现实中无限期地保持窗口状态（包括元数据），最终会耗尽磁盘空间。

一旦划定允许数据能多晚到达，就准确地确定窗口状态需要保持的最长时间，这段时间就是watermark线到达窗口终点线之后再继续等待的时间。此外还给予系统尽快丢弃超过horizon的数据的自由，这意味着不要在无关紧要的数据上浪费任何资源。

How: accumulation

最后一个问题，late data的处理结果应该如何影响之前的处理结果呢？作者给出了三个方案：

• 丢弃（Discarding）：每当有窗格（pane）输出，过去的状态就会被丢弃，这意味着后续的窗格与之前的无关。
• 累计（Accumulating）：每一个窗格（pane）输出时，过去状态被保留，和未来的输入一起累加形成新的当前状态。
• 累计并更正（Accumulating&retracting）:与累计模式类似，但是当产生新的窗格（pane）时，它会再单独产生一个被更正/回撤的值。

结论

上面便就是Dataflow模型对于流系统的解决方案，用五个概念回答了流系统为了保证正确性结果提出的四个问题，在工程上给出准确性、延迟和代价的如何进行权衡。

参考链接:

https://www.oreilly.com.cn/ideas/?p=18

http://limuzhi.com/2017/04/09/%E6%B5%81%E5%BC%8F%E8%B6%85%E8%B6%8A%E6%89%B9%E9%87%8F-Streaming%20102%E7%BF%BB%E8%AF%91/