一、Apache Flink 的定义、架构及原理

1. Flink Application

了解 Flink 应用开发需要先理解 Flink 的 Streams、State、Time 等基础处理语义以及 Flink 兼顾灵活性和方便性的多层次 API。

Streams：流，分为有限资料流与无限资料流，unbounded stream 是有始无终的资料流，即无限资料流；而 bounded stream 是限定大小的有始有终的资料集合，即有限资料流，二者的区别在于无限资料流的资料会随时间的推演而持续增加，计算持续进行且不存在结束的状态，相对的有限资料流资料大小固定，计算最终会完成并处于结束的状态。State，状态是计算过程中的资料资讯，在容错恢复和 Checkpoint 中有重要的作用，流计算在本质上是 Incremental Processing，因此需要不断查询保持状态；另外，为了确保 Exactly- once 语义，需要资料能够写入到状态中；而持久化储存，能够保证在整个分散式系统执行失败或者挂掉的情况下做到 Exactly- once，这是状态的另外一个价值。Time，分为 Event time、Ingestion time、Processing time，Flink 的无限资料流是一个持续的过程，时间是我们判断业务状态是否滞后，资料处理是否及时的重要依据。API，API 通常分为三层，由上而下可分为 SQL / Table API、DataStream API、ProcessFunction 三层，API 的表达能力及业务抽象能力都非常强大，但越接近 SQL 层，表达能力会逐步减弱，抽象能力会增强，反之，ProcessFunction 层 API 的表达能力非常强，可以进行多种灵活方便的操作，但抽象能力也相对越小。2.Flink Architecture

在架构部分，主要分为以下四点：

第一， Flink 具备统一的框架处理有界和无界两种资料流的能力

第二， 部署灵活，Flink 底层支援多种资源排程器，包括 Yarn、Kubernetes 等。Flink 自身带的 Standalone 的排程器，在部署上也十分灵活。

第三， 极高的可伸缩性，可伸缩性对于分散式系统十分重要，阿里巴巴双 11 大屏采用 Flink 处理海量资料，使用过程中测得 Flink 峰值可达 17 亿 / 秒。

第四， 极致的流式处理效能。Flink 相对于 Storm 最大的特点是将状态语义完全抽象到框架中，支援本地状态读取，避免了大量网络 IO，可以极大提升状态存取的效能。

3.Flink Operation

后面会有专门课程讲解，此处简单分享 Flink 关于运维及业务监控的内容：

Flink 具备 7 X 24 小时高可用的 SOA（面向服务架构），原因是在实现上 Flink 提供了一致性的 Checkpoint。Checkpoint 是 Flink 实现容错机制的核心，它周期性的记录计算过程中 Operator 的状态，并生成快照持久化储存。当 Flink 作业发生故障崩溃时，可以有选择的从 Checkpoint 中恢复，保证了计算的一致性。Flink 本身提供监控、运维等功能或界面，并有内建的 WebUI，对执行的作业提供 DAG 图以及各种 Metric 等，协助使用者管理作业状态。4.Flink 的应用场景

4.1 Flink 的应用场景：Data Pipeline

Data Pipeline 的核心场景类似于资料搬运并在搬运的过程中进行部分资料清洗或者处理，而整个业务架构图的左边是 Periodic ETL，它提供了流式 ETL 或者实时 ETL，能够订阅讯息伫列的讯息并进行处理，清洗完成后实时写入到下游的 Database 或 File system 中。场景举例：

实时数仓当下游要构建实时数仓时，上游则可能需要实时的 Stream ETL。这个过程会进行实时清洗或扩充套件资料，清洗完成后写入到下游的实时数仓的整个链路中，可保证资料查询的时效性，形成实时资料采集、实时资料处理以及下游的实时 Query。

搜索引擎推荐搜索引擎这块以淘宝为例，当卖家上线新商品时，后台会实时产生讯息流，该讯息流经过 Flink 系统时会进行资料的处理、扩充套件。然后将处理及扩充套件后的资料生成实时索引，写入到搜索引擎中。这样当淘宝卖家上线新商品时，能在秒级或者分钟级实现搜索引擎的搜寻。

4.2 Flink 应用场景：Data Analytics

Data Analytics，如图，左边是 Batch Analytics，右边是 Streaming Analytics。Batch Analysis 就是传统意义上使用类似于 Map Reduce、Hive、Spark Batch 等，对作业进行分析、处理、生成离线报表，Streaming Analytics 使用流式分析引擎如 Storm，Flink 实时处理分析资料，应用较多的场景如实时大屏、实时报表。

4.3 Flink 应用场景：Data Driven

从某种程度上来说，所有的实时的资料处理或者是流式资料处理都是属于 Data Driven，流计算本质上是 Data Driven 计算。应用较多的如风控系统，当风控系统需要处理各种各样复杂的规则时，Data Driven 就会把处理的规则和逻辑写入到 Datastream 的 API 或者是 ProcessFunction 的 API 中，然后将逻辑抽象到整个 Flink 引擎中，当外面的资料流或者是事件进入就会触发相应的规则，这就是 Data Driven 的原理。在触发某些规则后，Data Driven 会进行处理或者是进行预警，这些预警会发到下游产生业务通知，这是 Data Driven 的应用场景，Data Driven 在应用上更多应用于复杂事件的处理。

二、“有状态的流式处理”概念解析

传统批处理方法是持续收取资料，以时间作为划分多个批次的依据，再周期性地执行批次运算。但假设需要计算每小时出现事件转换的次数，如果事件转换跨越了所定义的时间划分，传统批处理会将中介运算结果带到下一个批次进行计算；除此之外，当出现接收到的事件顺序颠倒情况下，传统批处理仍会将中介状态带到下一批次的运算结果中，这种处理方式也不尽如人意。

2. 理想方法

第一点，要有理想方法，这个理想方法是引擎必须要有能力可以累积状态和维护状态，累积状态代表着过去历史中接收过的所有事件，会影响到输出。

第二点，时间，时间意味着引擎对于资料完整性有机制可以操控，当所有资料都完全接受到后，输出计算结果。

第三点，理想方法模型需要实时产生结果，但更重要的是采用新的持续性资料处理模型来处理实时资料，这样才最符合 continuous data 的特性。

3. 流式处理

流式处理简单来讲即有一个无穷无尽的资料来源在持续收取资料，以程式码作为资料处理的基础逻辑，资料来源的资料经过程式码处理后产生出结果，然后输出，这就是流式处理的基本原理。

4. 分散式流式处理

假设 Input Streams 有很多个使用者，每个使用者都有自己的 ID，如果计算每个使用者出现的次数，我们需要让同一个使用者的出现事件流到同一运算程式码，这跟其他批次需要做 group by 是同样的概念，所以跟 Stream 一样需要做分割槽，设定相应的 key，然后让同样的 key 流到同一个 computation instance 做同样的运算。

5. 有状态分散式流式处理

如图，上述程式码中定义了变数 X，X 在资料处理过程中会进行读和写，在最后输出结果时，可以依据变数 X 决定输出的内容，即状态 X 会影响最终的输出结果。这个过程中，第一个重点是先进行了状态 co-partitioned key by，同样的 key 都会流到 computation instance，与使用者出现次数的原理相同，次数即所谓的状态，这个状态一定会跟同一个 key 的事件累积在同一个 computation instance。

相当于根据输入流的 key 重新分割槽的 状态，当分割槽进入 stream 之后，这个 stream 会累积起来的状态也变成 copartiton 了。第二个重点是 embeded local state backend。有状态分散式流式处理的引擎，状态可能会累积到非常大，当 key 非常多时，状态可能就会超出单一节点的 memory 的负荷量，这时候状态必须有状态后端去维护它；在这个状态后端在正常状况下，用 in-memory 维护即可。

三、Apache Flink 的优势

当我们考虑状态容错时难免会想到精确一次的状态容错，应用在运算时累积的状态，每笔输入的事件反映到状态，更改状态都是精确一次，如果修改超过一次的话也意味着资料引擎产生的结果是不可靠的。

如何确保状态拥有精确一次（Exactly-once guarantee）的容错保证？如何在分散式场景下替多个拥有本地状态的运算子产生一个全域一致的快照（Global consistent snapshot）？更重要的是，如何在不中断运算的前提下产生快照？1.1 简单场景的精确一次容错方法

还是以使用者出现次数来看，如果某个使用者出现的次数计算不准确，不是精确一次，那么产生的结果是无法作为参考的。在考虑精确的容错保证前，我们先考虑最简单的使用场景，如无限流的资料进入，后面单一的 Process 进行运算，每处理完一笔计算即会累积一次状态，这种情况下如果要确保 Process 产生精确一次的状态容错，每处理完一笔资料，更改完状态后进行一次快照，快照包含在伫列中并与相应的状态进行对比，完成一致的快照，就能确保精确一次。

1.2 分散式状态容错

Flink 作为分散式的处理引擎，在分散式的场景下，进行多个本地状态的运算，只产生一个全域一致的快照，如需要在不中断运算值的前提下产生全域一致的快照，就涉及到分散式状态容错。

Global consistent snapshot

关于 Global consistent snapshot，当 Operator 在分散式的环境中，在各个节点做运算，首先产生 Global consistent snapshot 的方式就是处理每一笔资料的快照点是连续的，这笔运算流过所有的运算值，更改完所有的运算值后，能够看到每一个运算值的状态与该笔运算的位置，即可称为 consistent snapshot，当然，Global consistent snapshot 也是简易场景的延伸。

容错恢复

首先了解一下 Checkpoint，上面提到连续性快照每个 Operator 运算值本地的状态后端都要维护状态，也就是每次将产生检查点时会将它们传入共享的 DFS 中。当任何一个 Process 挂掉后，可以直接从三个完整的 Checkpoint 将所有的运算值的状态恢复，重新设定到相应位置。Checkpoint 的存在使整个 Process 能够实现分散式环境中的 Exactly-once。

1.3 分散式快照（Distributed Snapshots）方法

关于 Flink 如何在不中断运算的状况下持续产生 Global consistent snapshot，其方式是基于用 simple lamport 演算法机制下延伸的。已知的一个点 Checkpoint barrier， Flink 在某个 Datastream 中会一直安插 Checkpoint barrier，Checkpoint barrier 也会 N — 1 等等，Checkpoint barrier N 代表着所有在这个范围里面的资料都是 Checkpoint barrier N。

举例：假设现在需要产生 Checkpoint barrier N，但实际上在 Flink 中是由 job manager 触发 Checkpoint，Checkpoint 被触发后开始从资料来源产生 Checkpoint barrier。当 job 开始做 Checkpoint barrier N 的时候，可以理解为 Checkpoint barrier N 需要逐步填充左下角的表格。

如图，当部分事件标为红色，Checkpoint barrier N 也是红色时，代表着这些资料或事件都由 Checkpoint barrier N 负责。Checkpoint barrier N 后面白色部分的资料或事件则不属于 Checkpoint barrier N。

在以上的基础上，当资料来源收到 Checkpoint barrier N 之后会先将自己的状态储存，以读取 Kafka 资料为例，资料来源的状态就是目前它在 Kafka 分割槽的位置，这个状态也会写入到上面提到的表格中。下游的 Operator 1 会开始运算属于 Checkpoint barrier N 的资料，当 Checkpoint barrier N 跟着这些资料流动到 Operator 1 之后,Operator 1 也将属于 Checkpoint barrier N 的所有资料都反映在状态中，当收到 Checkpoint barrier N 时也会直接对 Checkpoint 去做快照。

当快照完成后继续往下游走，Operator 2 也会接收到所有资料，然后搜寻 Checkpoint barrier N 的资料并直接反映到状态，当状态收到 Checkpoint barrier N 之后也会直接写入到 Checkpoint N 中。以上过程到此可以看到 Checkpoint barrier N 已经完成了一个完整的表格，这个表格叫做 Distributed Snapshots，即分散式快照。分散式快照可以用来做状态容错，任何一个节点挂掉的时候可以在之前的 Checkpoint 中将其恢复。继续以上 Process，当多个 Checkpoint 同时进行，Checkpoint barrier N 已经流到 job manager 2，Flink job manager 可以触发其他的 Checkpoint，比如 Checkpoint N + 1，Checkpoint N + 2 等等也同步进行，利用这种机制，可以在不阻挡运算的状况下持续地产生 Checkpoint。

2. 状态维护

状态维护即用一段程式码在本地维护状态值，当状态值非常大时需要本地的状态后端来支援。

如图，在 Flink 程式中，可以采用 getRuntimeContext().getState(desc); 这组 API 去注册状态。Flink 有多种状态后端，采用 API 注册状态后，读取状态时都是通过状态后端来读取的。Flink 有两种不同的状态值，也有两种不同的状态后端：

JVM Heap 状态后端，适合数量较小的状态，当状态量不大时就可以采用 JVM Heap 的状态后端。JVM Heap 状态后端会在每一次运算值需要读取状态时，用 Java object read / writes 进行读或写，不会产生较大代价，但当 Checkpoint 需要将每一个运算值的本地状态放入 Distributed Snapshots 的时候，就需要进行序列化了。

RocksDB 状态后端，它是一种 out of core 的状态后端。在 Runtime 的本地状态后端让使用者去读取状态的时候会经过磁盘，相当于将状态维护在磁盘里，与之对应的代价可能就是每次读取状态时，都需要经过序列化和反序列化的过程。当需要进行快照时只将应用序列化即可，序列化后的资料直接传输到中央的共享 DFS 中。Flink 目前支援以上两种状态后端，一种是纯 memory 的状态后端，另一种是有资源磁盘的状态后端，在维护状态时可以根据状态的数量选择相应的状态后端。

3.Event - Time

3.1 不同时间种类

在 Flink 及其他进阶的流式处理引擎出现之前，大资料处理引擎一直只支援 Processing-time 的处理。假设定义一个运算 windows 的视窗，windows 运算设定每小时进行结算。以 Processing-time 进行运算时可以发现数据引擎将 3 点至 4 点间收到的资料做结算。实际上在做报表或者分析结果时是想了解真实世界中 3 点至 4 点之间实际产生资料的输出结果，了解实际资料的输出结果就必须采用 Event – Time 了。

如图，Event - Time 相当于事件，它在资料最源头产生时带有时间戳，后面都需要用时间戳来进行运算。用图来表示，最开始的伫列收到资料，每小时对资料划分一个批次，这就是 Event - Time Process 在做的事情。

3.2 Event-Time 处理

Event-Time 是用事件真实产生的时间戳去做 Re-bucketing，把对应时间 3 点到 4 点的资料放在 3 点到 4 点的 Bucket，然后 Bucket 产生结果。所以 Event - Time 跟 Processing - time 的概念是这样对比的存在。

Event - Time 的重要性在于记录引擎输出运算结果的时间。简单来说，流式引擎连续 24 小时在执行、搜集资料，假设 Pipeline 里有一个 windows Operator 正在做运算，每小时能产生结果，何时输出 windows 的运算值，这个时间点就是 Event - Time 处理的精髓，用来表示该收的资料已经收到。

3.3 Watermarks

Flink 实际上是用 watermarks 来实现 Event - Time 的功能。Watermarks 在 Flink 中也属于特殊事件，其精髓在于当某个运算值收到带有时间戳“ T ”的 watermarks 时就意味着它不会接收到新的资料了。使用 watermarks 的好处在于可以准确预估收到资料的截止时间。举例，假设预期收到资料时间与输出结果时间的时间差延迟 5 分钟，那么 Flink 中所有的 windows Operator 搜寻 3 点至 4 点的资料，但因为存在延迟需要再多等 5 分钟直至收集完 4：05 分的资料，此时方能判定 4 点钟的资料收集完成了，然后才会产出 3 点至 4 点的资料结果。这个时间段的结果对应的就是 watermarks 的部分。

4. 状态储存与迁移

流式处理应用无时无刻不在执行，运维上有几个重要考量：

更改应用逻辑 / 修 bug 等，如何将前一执行的状态迁移到新的执行？如何重新定义执行的平行化程度？如何升级运算丛集的版本号？Checkpoint 完美符合以上需求，不过 Flink 中还有另外一个名词储存点（Savepoint），当手动产生一个 Checkpoint 的时候，就叫做一个 Savepoint。Savepoint 跟 Checkpoint 的差别在于检查点是 Flink 对于一个有状态应用在执行中利用分散式快照持续周期性的产生 Checkpoint，而 Savepoint 则是手动产生的 Checkpoint，Savepoint 记录着流式应用中所有算子的状态。

如图，Savepoint A 和 Savepoint B，无论是变更底层程式码逻辑、修 bug 或是升级 Flink 版本，重新定义应用、计算的平行化程度等，最先需要做的事情就是产生 Savepoint。

Savepoint 产生的原理是在 Checkpoint barrier 流动到所有的 Pipeline 中手动插入从而产生分散式快照，这些分散式快照点即 Savepoint。Savepoint 可以放在任何位置储存，当完成变更时，可以直接从 Savepoint 恢复、执行。

从 Savepoint 的恢复执行需要注意，在变更应用的过程中时间在持续，如 Kafka 在持续收集资料，当从 Savepoint 恢复时，Savepoint 储存着 Checkpoint 产生的时间以及 Kafka 的相应位置，因此它需要恢复到最新的资料。无论是任何运算，Event - Time 都可以确保产生的结果完全一致。

假设恢复后的重新运算用 Process Event - Time，将 windows 视窗设为 1 小时，重新运算能够在 10 分钟内将所有的运算结果都包含到单一的 windows 中。而如果使用 Event – Time，则类似于做 Bucketing。在 Bucketing 的状况下，无论重新运算的数量多大，最终重新运算的时间以及 windows 产生的结果都一定能保证完全一致。

四、总结

本文首先从 Apache Flink 的定义、架构、基本原理入手，对大资料流计算相关的基本概念进行辨析，在此基础上简单回顾了大资料处理方式的历史演进以及有状态的流式资料处理的原理，最后从目前有状态的流式处理面临的挑战分析 Apache Flink 作为业界公认为最好的流计算引擎之一所具备的天然优势。希望有助于大家厘清大资料流式处理引擎涉及的基本概念，能够更加得心应手地使用 Flink。