【概述｜基础】flink系列01：flink概述：flink能做些什么、flink的特点有那些、适合哪些场景、flink的技术的基石是来自哪篇论文

基于flink 1.12.5对flink做一些系统的总结

一. Flink的核心特性

序号	特性	描述
1	统一的数据处理组件栈	可以处理例如流、批、机器学习，图等不同类型的数据需求
2	时间概念和窗口操作	支持event time、 ingestion time、processing time 等时间概念 支持高度灵活的窗口操作，实现不同场景下的聚合。
3	分布式快照实现容错	通过生成分布式快照（checkpoint、savepoint）能够实现数据的精准一次。
4	有状态计算	基于hdfs、内存、rocksDB的持久化支持，在计算框架内通过kv格式进行状态的持久化。
5	带反压的流模型	天然的反压模型，类似于BlockingQueue，如果下游处理能力不足，则会反馈给上游算子。
6	基于JVM实现了Flink独立的内存管理

 

二. Flink基石dataflow模型

1. 模型讨论的范围

• dataflow模型处理的是大规模的、无界的、乱序的数据
• 处理数据时，需要兼顾正确性、时间延迟和资源消耗

首先解释一下提到的几个名词：

1. 无界数据代表一直有产出且流动的数据；
2. 乱序数据是指处理数据时，因为网络等原因导致一些较早产生的数据而晚到了，这就是乱序；
3. 事件时间就是数据产生一瞬间的时间戳，比如调用某接口时的时间戳；
4. 处理时间就是数据进入流式处理程序的时间戳。

如上图展示了我们在实际生产中不可避免的一个场景：在一个不断处理数据的流式程序中，有些数据因为网络等原因导致数据晚到，造成了数据的乱序。

 

2. Dataflow模型解决的问题

分解为3个子问题来解决上述提到的现实问题：

1. 在哪里计算无界数据 [Where in event time they are being computed]；
2. 什么时间将计算出结果 [When in processing time they are materialized]；
3. 迟到的数据如何修正之前的结果 [How earlier results relate to later refinements]。

解决方案：

1. 窗口模型（windowing model），支持基于乱序的事件时间的窗口操作，用于解决Where问题；
2. 触发模型（triggering model），能够将数据结果与事件的时间特性绑定，解决When问题；
3. 增量更新模型（incremental processing model），能够将后到的数据融合到窗口和触发模型中，解决How问题。
    

3.Dataflow三大模型

3.1. 窗口模型

通过窗口就可以将无界数据时域地划分为一个个的有限数据集，进而能在其上做分组、聚合、连接等比较高级的操作。下图示出乱序事件时间的一种窗口。

Note that, to support event-time windowing natively, instead of passing (key, value) pairs through the system, we now pass (key, value, event time, window) 4-tuples. Elements are provided to the system with event-time timestamps

为了支持窗口计算，Dataflow通过窗口模型将传统流处理中的(key, value)二元组改进为(key, value, event_time, window)四元组。实际上，事件时间规定了window的边界，即触发窗口内数据计算并输出的时机。

常见的开窗方式有三种：固定（fixed/tumbling）、滑动（sliding）、会话（session）窗口。

3.2. 触发模型与水印

按照处理时间处理数据时，不存在迟到的问题，因为程序处理的时间就是处理时间。但一旦用事件时间，由于数据会迟到，所以无法判断窗口中的数据是否都到了。

因此，这里需要引入水印（watermark）的概念，用于确定允许数据迟到多长时间，一旦超过这个时间便触发结果物化。水印本质上是个时间戳，对一个无界数据源而言，假设水印=T，那么它表示已经接收到所有t <= T的数据，其他t > T的数据都将被视为迟到，当T到达窗口时间时，则出发结果物化。

如下图，红色箭头表达了实际数据到达的时间，也就是有迟到的数据，所以水印考虑了迟到的时间。

水印的设定大多是启发式（heuristic）的，亦即根据历史指标尽量保证窗口内数据的完整性，但不能确保100%可靠，太快和太慢都不行。

3.3. 增量更新模型

既然启发式水印不能确保100%可靠，那么就必须用迟到数据修正之前窗口的正确性，亦即增量更新，也叫做回填（backfill）。
Dataflow原生定义了以下三种回填策略：

策略	描述
丢弃（discarding）	一旦窗口已经触发过了，就不再保留窗口的数据，所有超过水印的数据也都不算数（后面的窗口也不会获取这个数据）
累积（accumulating）	窗口触发过之后，保留窗口数据一段时间，超过水印的数据在该时间内仍然会进入窗口。保留的时间就是允许迟到时间（allowed lateness）
累积与回撤（accumulating & retracting）	在累积的基础上，先撤回对上一次窗口操作的结果的修改，再输出新的结果。比如聚合操作，如果不回撤结果就不对了

 

4. 示例

如图程序从12:05分开始处理数据，而数据实际上已经在12:00就已经出现了。
理想水印线如浅色线（即事件时间和处理时间同步），实际水印是深色线，说明有迟到数据。

下图是采用与Spark Streaming类似的微批次（micro-batch）手段进行处理的流程图，可见是根据processing time进行处理，与event time并没有关系。

下图则是与Flink类似的固定窗口+流式处理机制。

根据事件时间每两分钟出发一个窗口，从深色线可以看出每个窗口下水印策略是不同的，比如数据9在水印触发时实际上还没有到，也就是水印太快了。而数据7要到8触发水印时才会输出，也就是水印太慢了。

参考
https://time.geekbang.org/course/detail/100058801-278256
dataflow模型论文