Flink

Flink 一、Flink 是什么？

Flink是一个框架和分布式处理引擎，用于在无边界和有边界的数据流上进行有状态的计算

无界流：有定义流的开始 但是没有定义流的结束，会无休无止的产生数据。无界流必须持续处理，即数据被摄取后立刻处理

有界流：有定义流的开始也有定义流的结束。有界流可以在摄取所有数据后再进行计算。

二、Flink的状态：

Flink分为Operator State算子状态和Keyed State

Operator State

分为三种数据结构：

1. 列表状态：状态表示一组数据的列表
2. 联合列表状态：在发生故障时或从保存点（savePoint）启动应用程序时如何恢复
3. 广播状态：如果一个算子有多项任务，而它的每项任务状态都相同，这种情况适合用广播状态

Keyed State

1. 只能在keyed Stream (keyby)算子处理后
2. 一般keyBy进行hashcode 重分区户基于它自己独享的内存空间就会针对每一个不同的key
3. 分别保存一份独立的存储状态，而且接下来来了一个新的数据只能访问自己的状态，不能访问其他的key的，Flink会为每一个key维护一个状态

有状态计算：在程序计算中 Flink程序内部存储计算产生结果并提供给后续的Function活算子计算结果使用。

三、Time语义

• processing Time：处理时间
• Event Time：事件时间
• Ingestion Time：进入Flink系统的时间

四、Window

window：将一个无限的stream 拆分成有限个bucket

TimeWindow

滚动窗口

• 依据固定的窗口长度对数据进行分片
• 特点：时间对齐，窗口长度固定无重叠，如下图

 

滑动窗口

• 由固定窗口长度和滑动间隔组成
• 特点：时间对齐，窗口长度固定有重叠，如下图：

 

 会话窗口

• 根据session gap切分不同的窗口，当一个窗口在大于session gap的时间内没有接收到新数据时，窗口关闭。在这种模式下窗口长度是可变的，每个窗口的开始和结束时间并不是确定的。我们可以设置定长的session gap，也可以使用 SessionWindowTimeGapExtractor动态的确定 Session gap的长度
• 特点：时间 无对齐

countWindow

按照指定的数据条数生成一个window，与时间无关，根据窗口中的相同key元素数量来触发执行，执行时只计算元素数量达到窗口大小的key对应结果

• 滚动窗口：默认为指定窗口，只需指定窗口大小
• 滑动窗口：需要指定两个参数：windowSize和slidingSize，假设windowSize=5，slidingSize=2 每个相同key的数据计算一次，每一次计算window满足5个元素

五、windowFunction

• 增量聚合：ReducingFunction  AggregateFunction
• 全量聚合：processWindowFunction

六、水位线

watermark 是一种衡量EventTime进展机制，可以设定延迟触发，到了时间窗口不应立刻触发窗口计算，而是等待一段时间

七、基本架构

提交任务流程

client 与JobManager构建AKKA连接，将任务提交到JobManager上，JonManager根据已注册在JobManager中的TaskManager的资源（TaskSolt）情况，将任务分配给有资源的Taskmanager，并命令taskManager 启动任务，taskManager使用slot资源启动task

TaskManager和Task Slot的关系

• 每个Task Slot 是TaskManager一部分，若一个taskManager有三个solt，则这个三个solt会均分TaskManager的资源（仅内存，不包括CPU），有多个solt 意味着同一个jvm 会有多个子任务，会共享jvm的tcp链接和心跳信息
• slot的个数是不是subtask个数，一个solt可以有多个subtask，在默认情况下同一个job子任务是可共享一个slot。
• 任务提交阶段的任务并行度的最大值和集群的slot总数有关系

八、检查点 一致性

• at-most-once：至多一次，故障发生后计算结果可能丢失
• at-least-once：至少一次，计算结果可能大于正确值
• Exactly-once：精确一次

checkPoint

• Flink快照是基于“轻量级异步快照”，在计算过程中保存中间状态和数据流对应位置，这些保存信息相当于系统的checkpoint。
• Flink 做分布式快照过程中核心一个元素 Barries的使用，这些Barries 是在数据接入到Flink之初就注入到数据流中，并随着数据流向每个算子，需要说明的有两点:
• 算子对Barries是免疫的，即Barries 是不参与计算的
• Barries 和数据的相对位置是保持不变的，而且Barries之间是线性递增的

如下图所示，Barriers将将数据流分成了一个个数据集。值得提醒的是，当barriers流经算子时，会触发与checkpoint相关的行为，保存的barriers的位置和状态（中间计算结果）

对齐机制

接收不止一个数据输入的operator需要基于屏障对齐输入数据流。详述如下：

• 当operator接收到快照的屏障n 后不能直接处理之后的数据，而是需要等待其他数据快照的屏障n，否则的话会将快照n的数据和快照n+1的数据混在一起，如下图所示：operator 即将要收到数据流1（图中的6,5,4,3,2,1），下面的当成输数据流2好了，当1,2,3在屏障n之后到达operator，这个时候如果数据流1继续流里，那么operator就会包含n屏障之后的数据(1,2,3)，但是operator中此刻在接收和处理数据流2，数据（a,b,c）就会和数据流中的（1,2,3）混合

 

• 快照n的数据流会被暂时放到一边。从这些数据流中获取到的数据不会被处理，而是存储到一个缓冲中。图中第一个所示，因为数据流2的屏障n还没到，所以operator持续接收1，2，3然而并不做任何处理。但是需要将1，2，3存入到buffer中。此时第二个数据流接到a，b，则直接发送，接到c发送c

• 一旦最后一个数据流收到了快照n，opertor就会将发出所有阻塞的数据，并发出自己的屏障。如图中第三个所示，operator最后收到了另一个数据流的屏障n，然后再发出a,b,c(图中operator中的c,b,a)以后，发出自己的屏障，这个时候buffer中又增加了一个4，变成（4，3，2，1）。

• 之后operator会重新开始处理所有的输入数据流，先处理buffer中的数据，处理完之后再处理输入数据流的数据。如图第四个所示，先将buffer中的1，2，3，4先处理完，在接收并处理这两个数据源的数据。

九、Flink调优

• 看是否产生背压：数据的序列化和反序列化造成性能性能影响，一些数据结构使用keyBy影响性能，是否频繁的gc
• 看延迟的指标和吞吐：checkPoint时间过长能在一定程度上影响job的吞吐
• 提高资源使用率
• 是否发生数据倾斜
• 源头和数据源并发度是否保持一致
• 非堆内存调优