一、Flink概述

Flink起源于Stratosphere项目，Stratosphere是德国科学基金会（DFG）赞助的一个研究项目，目标是建立下一代大数据分析引擎。2010年，从Stratosphere项目上生出一个新的分支，就是Flink。Flink项目于2014年3月被交给Apache孵化，同年4月16日成为Apache的孵化项目，12月变成Apache顶级项目。

为什么Flink能够在短短的几年时间里迅速占领分布式流数据处理市场，得到众多企业采用，成为主流实时数据处理框架呢？这与以下两个原因密切相关：

• Flink及时吸收和采用了Google开源论文提到的DataFlow/Beam编程思想，这使其成为当时功能最强大的开源流系统。
• 并且此后不久Flink又完成了一个轻量且高效的分布式异步快照算法实现（原型是Chandy-Lamport算法），为端到端的数据一致性提供了强大保证。

在当时的开源数据处理框架中，只有Flink能够同时保证低延时、高吞吐以及ExactlyOnce数据一致性。

二、DataFlow设计思想

在当时的背景下，传统的批处理系统无法满足实时性要求，而流处理系统在大规模数据场景下缺乏准确性、容错性、时间语义的表达。Lambda架构能够满足上述大部分要求，但是其系统过于复杂，用户必须构建和维护离线及在线两套系统。因此，Google提出了DataFlow编程模型，旨在提供一种统一批处理和流处理的系统，DataFlow可以称得上是现代流式计算的基石（Google YYDS!）

DataFlow能够对无界、无序的数据源按数据本身的特征进行窗口计算，得到基于事件发生时间的有序结果，并能在准确性、延迟程度和处理成本之间取得平衡，它主要具备以下重要思想：

无界、有界与流处理、批处理

在描述无限和有限数据集时，DataFlow使用无界和有界这样的描述，而不是流处理数据和批处理数据，这是因为流处理和批处理意味着使用特定的执行引擎。实际上，无界数据集可以通过批处理系统反复调度来处理，而设计良好的流处理系统也可以完美地处理有界数据集。从这个角度来看，区分流处理和批处理的实际意义不大，这也为后来Flink流批一体架构提供了理论基础。

有界流与无界流

窗口计算

窗口计算支持把一个数据集切分为有限的数据片，以便于聚合处理。对于无界的数据，有些操作需要窗口，以定义大多数聚合操作需要的边界；另一些则不需要窗口（如过滤、映射、内链接等）。对于有界的数据，窗口是可选的，不过很多情况下仍然是一种有效的语义概念。如下图所示，DataFlow提供了3种窗口计算类型：

• 固定窗口（fixed）：按固定窗口大小定义，如小时窗口或天窗口。固定窗口一般都是对齐窗口，也就是说，每个窗口包含对应时间范围内的所有数据。有时为了把窗口计算的负荷均匀分摊到整个时间范围内，会在窗口边界时间加上一个随机数，这样窗口就变成了不对齐窗口。
• 滑动窗口（sliding）：按窗口大小和滑动周期定义，如小时窗口、每五分钟滑动一次。滑动周期通常小于窗口，也就是窗口有相互重合之处。滑动窗口一般也是对齐的。固定窗口可以看作滑动窗口的一个特例。
• 会话窗口（session）：会话窗口是在数据集上捕捉一段时间内的活动。一般来说，会话窗口按超时时间定义，任何发生在超时时间以内的事件都被认为属于同一个会话。会话窗口是非对齐窗口，在下图中，Key3的窗口1与窗口4，两次活动之间的间隔超过了超时时间，因此系统需要重新定义一个会话窗口。

窗口分类

时间语义与Watermark

DataFlow将时间域分为两种类型，即Event Time和Processing Time。而Flink在此之外还引入了Ingestion Time，如下图所示：

时间语义

• Event Time：是事件创建的时间，通常由事件中的时间戳描述，例如采集的日志数据中，每一条日志都会记录自己的生成时间
• Ingestion Time：是数据进入Flink的时间
• Processing Time：是每一个执行基于时间操作的算子的本地系统时间，与机器相关

绝大部分的业务都会使用Event Time，一般只在Event Time无法使用时，才会被迫使用Processing Time或者Ingestion Time。在实际生产中，因为系统本身受到一些现实影响（通信延迟、调度算法、处理时长、管道中间数据序列化等），这几个时间概念存在差值且动态波动。在时间语义的基础上，Flink引入了Watermark（水位线）机制来处理乱序事件，以保证数据处理结果的准确性。

Watermark是一种衡量Event Time进展的机制，通常用结合窗口计算来处理乱序事件。Watermark可以理解成延迟触发窗口计算，我们可以设置Watermark的延时时长t，每次系统会校验已经到达的数据中最大的事件时间maxEventTime，然后认定eventTime小于 maxEventTime - t的所有数据都已经到达，如果有窗口的停止时间等于maxEventTime – t，那么这个窗口被触发执行。

例如，以下两张图分别代表理想的有序数据流与实际的无序数据流。我们假设固定窗口为5，Watermark的延时时长为2，那么乱序流中当eventTime为7的数据到达时，系统会认为所有eventTime小于5的数据已经到达，因此会触发1-5窗口计算；同理，eventTime为12的数据到达时，会触发6-10的窗口计算。

有序数据

乱序数据

三、分布式异步快照算法

基于DataFlow模型实现的计算框架虽然能够进行大规模无界乱序数据处理并平衡好准确性、延迟程度和处理成本三者之间的关系，但在数据处理过程中，保障数据一致性同样重要。

在Flink中，通过checkpoint机制可以保证数据的一致性。开启checkpoint为Exactly-Once模式时，能够保证数据严格执行一次、不重复也不丢失。Flink中的checkpoint机制源于Chandy和Lamport两位科学家提出的分布式异步快照算法：Chandy-Lamport算法（Lamport就是分布式系统领域无人不晓一致性算法Paxos的作者），而后Flink在此基础上加以改进为异步屏障快照（ABS）算法。

问题定义

分布式异步快照算法应用到流式系统中就是定期产生一个全局快照（global snapshot），当系统出现错误时，将各个节点根据上一次的全局快照恢复整个系统。这里的全局快照我们也可以理解为全局状态（global state）。全局状态在系统进行故障恢复（failure recovery）的时候非常有用，它也是分布式计算系统中容错处理的理论基础。对于分布式系统来讲，想要获取全局状态，需要面临如下问题与挑战：

• 进程节点只能记录各自的状态，即本地状态信息，需要通过网络传递信息，形成各个进程之间的全局状态。
• 所有的进程不可能在同一时间立即精确记录各自的状态，除非它们能够获取相同的时钟，但显然各节点时钟不可能完全一致。
• 同时做到全局状态过程中持续数据计算，对于STW（Stop The World，暂停当前所有运行的线程）的做法是没有意义的。

Chandy-Lamport算法

那么Chandy-Lamport算法是如何解决上述问题的呢？为了定义分布式系统的全局状态，首先将分布式系统简化成有限个进程与进程的组合，也就是有向无环图，其中节点是进程，边是channel，并且这些进程运行在不同的物理机器上。分布式系统的全局状态由进程的状态和channel中的信息（message）组成，而这些信息也是分布式异步快照算法需要记录的。下图为Chandy-Lamport算法示意图，从中可以看出，整个分布式系统的全局状态包括如下3个过程。

Chandy-Lamport算法

1. 系统中的任意一个进程发起创建快照操作
   1.1 进程P1发起快照操作，记录进程P1的状态，同时生产一个标识信息marker。注意这里的marker和进程之间通信的信息不同。
   1.2 将marker信息通过output channel发送给系统的其他进程，上图中是进程P2。
   1.3 P1开始记录所有input channel接收到的信息并写入M1存储。
2. 系统中其他进程开始逐个创建snapshot操作
   2.1 进程P2通过input channel C12接收P1发送的marker信息。
   2.2 如果P2没有记录自己的进程状态，则记录当前进程状态（上图中用深色框表示），同时将channel C12置为空，并向output channel发送marker信息；否则，记录其他channel在收到marker之前从input channel收到的所有信息。
3. 终止并完成当前的快照操作
   在所有进程都收到marker信息并记录自己的状态和channel消息后，终止整个snapshot过程。此时分布式系统本次的snapshot操作结束，等待下一次触发和执行。

异步屏障快照（ABS）算法

可以看出，Chandy-Lamport算法的思想还是比较straightforward。它虽然能够实现全局状态一致，但或多或少牺牲了程序的性能，不太适合在工程上实现。2015年，Flink官方发布了一篇名为《Lightweight Asynchronous Snapshotsfor Distributed Dataflows》的论文，旨在改进Chandy-Lamport分布式异步快照算法。该论文主要对Chandy-Lamport算法进行了以下两个方面的改进：

• 在Chandy- Lamport算法中，为了实现全局状态一致，需要停止流处理程序，直到快照完成，这会对系统性能有非常大的影响。
• 每次快照的内容包含传输过程中所有的内容，导致每次快照的数据量过大，进而影响系统的整体性能。

异步屏障快照算法对其进行了改造，并应用在Flink项目中，其核心思想是在input source节点插入barrier事件，替代Chandy-Lamport算法中的marker，通过控制barrier事件同步实现快照备份，最终实现Exactly-Once语义。

Flink的论文分别针对有向无环（DAG）和有向有环两种计算拓扑图提出了不同的算法，后者是在前者基础上进行的修改。在实际应用，尤其是在Flink系统中，大多数数据流拓扑都是有向无环图。下图所示为DAG的ABS算法执行流程。

ABS算法

1. barrier事件被周期性地注入所有source节点（数据读取节点），source节点接收到barrier后会立即对自己的状态进行快照操作，然后将barrier事件发送到下游的节点。
2. 下游的Transformation Operator从上游某个input channel接收到barrier事件后，会立刻阻塞通道，直到接收到所有上游算子对应的input channel发送的barrier事件。这实际上是barrier事件的对齐过程，operator节点完成barrier对齐操作后，会对当前算子的状态进行快照操作，并向所有下游的节点广播barrier事件。
3. Sink节点（数据输出节点）接收到barrier事件后，也会进行barrier对齐操作。在所有input channel中的barrier事件全部到达Sink节点后，Sink节点会对自己的状态进行快照操作。Sink节点完成快照操作标志着完成一次系统全局快照，即完成本次checkpoint操作。

小结

ABS算法对Flink中的checkpoint操作进行了系统性的描述，且在Flink项目中已经有成熟的落地实现。Chandy-Lamport算法相对比较理想化，未考虑在落地时全局状态获取过程中的性能问题，而ABS算法实际上是对Chandy-Lamport算法在生产项目中落地实现的补充和优化。可以看出，Flink系统融合了很多的设计思想和理念，这些设计理念都具有一定的前瞻性。正是由于对这些思想的应用，Flink才得以从众多大数据框架中脱颖而出。

参考资料

• 《Flink设计与实现 核心原理与源码解析》--张利兵
• 现代流式计算的基石：Google DataFlow
• 分布式快照算法: Chandy-Lamport 算法