flink知识点总结

介绍
flink 数据处理流程：

flink 摒弃了spark 拥有两个算子的思想（transfor、action）,其数据流程包括了

关于并行度和算子之间的运算流程为：

其在分布式上运行流程为：

具体执行步骤为
1、当 Flink 集群启动后，首先会启动一个 JobManger 和一个或多个的 TaskManager。由 Client 提交任务给 JobManager， JobManager 再调度任务到各个 TaskManager 去执行，然后 TaskManager 将心跳和统计信息汇报给 JobManager。 TaskManager 之间以流的形式进行数据的传输。上述三者均为独立的 JVM 进程。
2、Client 为提交 Job 的客户端，可以是运行在任何机器上（与 JobManager 环境连通即可）。提交 Job 后，Client 可以结束进程 （Streaming的任务），也可以不结束并等待结果返回。JobManager 主要负责调度 Job 并协调 Task 做 checkpoint（分布式快照）。从 Client 处接收到 Job 和 JAR 包 等资源后，会生成优化后的执行计划，并以 Task 的单元调度到各个 TaskManager 去执行。
3、Client 为提交 Job 的客户端，可以是运行在任何机器上（与 JobManager 环境连通即可）。提交 Job 后，Client 可以结束进程 （Streaming的任务），也可以不结束并等待结果返回。
JobManager 主要负责调度 Job 并协调 Task 做 checkpoint（分布式快照）。从 Client 处接收到 Job 和 JAR 包 等资源后，会生成优化后的执行计划，并以 Task 的单元调度到各个 TaskManager 去执行。

各个组件作用：
JobManager：
JobManager是Flink系统的协调者，它负责接收Flink Job，调度组成Job的多个Task的执行。同时，JobManager还负责收集Job 的状态信息，并管理Flink集群中从节点TaskManager。JobManager所负责的各项管理功能，它接收到并处理的事件主要包括：
（1）RegisterTaskManager
在Flink集群启动的时候，TaskManager会向JobManager注册，如果注册成功，则JobManager会向TaskManager回复消息 AcknowledgeRegistration。
（2）SubmitJob
Flink程序内部通过Client向JobManager提交Flink Job，其中在消息SubmitJob中以JobGraph形式描述了Job的基本信息。
（3）CancelJob
请求取消一个Flink Job的执行，CancelJob消息中包含了Job的ID，如果成功则返回消息CancellationSuccess，失败则返回消息 CancellationFailure。
（4）UpdateTaskExecutionState
TaskManager会向JobManager请求更新ExecutionGraph中的ExecutionVertex的状态信息，更新成功则返回true。
（5）RequestNextInputSplit
运行在TaskManager上面的Task，请求获取下一个要处理的输入Split，成功则返回NextInputSplit。
（6）JobStatusChanged
ExecutionGraph向JobManager发送该消息，用来表示Flink Job的状态发生的变化，例如：RUNNING、CANCELING、 FINISHED等。
TaskManager：
TaskManager也是一个Actor，它是实际负责执行计算的Worker，在其上执行Flink Job的一组Task。每个TaskManager负责管理 其所在节点上的资源信息，如内存、磁盘、网络，在启动的时候将资源的状态向JobManager汇报。TaskManager端可以分成两个阶段：
（1）注册阶段
TaskManager会向JobManager注册，发送RegisterTaskManager消息，等待JobManager返回AcknowledgeRegistration，然 后TaskManager就可以进行初始化过程。
（2）可操作阶段
该阶段TaskManager可以接收并处理与Task有关的消息，如SubmitTask、CancelTask、FailTask。如果TaskManager无法连接 到JobManager，这是TaskManager就失去了与JobManager的联系，会自动进入“注册阶段”，只有完成注册才能继续处理Task 相关的消息。

Client：
当用户提交一个Flink程序时，会首先创建一个Client，该Client首先会对用户提交的Flink程序进行预处理，并提交到Flink集群中处 理，所以Client需要从用户提交的Flink程序配置中获取JobManager的地址，并建立到JobManager的连接，将Flink Job提交给 JobManager。Client会将用户提交的Flink程序组装一个JobGraph， 并且是以JobGraph的形式提交的。一个JobGraph是一个 Flink Dataflow，它由多个JobVertex组成的DAG。其中，一个JobGraph包含了一个Flink程序的如下信息：JobID、Job名称、配 置信息、一组JobVertex等。

flink task 的切分
与Spark不同的地方在于Spark是通过RDD的依赖关系实现Stage的划分⽽而Flink是通过 OperatorChain 的概念实现Task的拆分。所谓的OperatorChain 指的是Flink在做job编织的时候，尝试将多个操作符算子进行串联到一个Task中，以减少数据的线程到线程传输的开销，目前Flink常见的Operatorchain的方式有两种：forward、hash|rebalance.

flink的状态管理：
你可以把状态当成一个 Task 可以访问的内存中的变量，当 Task 执行的时候，可以直接访问和更新状态，其中可以认为包含两种状态（1）. Operator State （2）. Keyed State

1、operator state: 是 task 级别的状态 说白了就是每个 task 对应着一个状态 State

2、Keyed State
Keyed State 记录的是每一个 key 的状态，key的状态类型一般可以归结为5种

为了预防状态的丢失flink支持状态的备份机制一般包含三种

1. MemoryStateBackend （默认情况下，状态信息是存储在 TaskManager 的堆内存中的 checkpoint 的时候将状态保存到 JobManager 的堆内存中）2. FSStateBackend （状态信息存储在 TaskManager 的堆内存中的 checkpoint 的时候将状态保存到指定的文件中 (HDFS 等文件系统) State）3. RocksDBStateBackend(状态信息存储在 RocksDB 数据库 (key-value 的数据存储服务)， 最终保存在本地文件中 checkpoint 的时候将状态保存到指定的文件中 (HDFS 等文件系统))

flink的checkpoint 机制（先状态备份完成 然后进行状态传输）
flink 窗口函数
Time Window：窗口可以是时间驱动的（Time Window，例如：每30秒钟），
Count Window：也可以是数据驱动的（Count Window，例如：每一百个元素）
Session Window：在这种用户交互事件流中，我们首先想到的是将事件聚合到会话窗口中（一段用户持续活跃的周期），由非活跃的间隙分隔开。如上图所示，就是需要计算每个用户在活跃期间总共购买的商品数量，如果用户30秒没有活动则视为会话断开

flink的三种时间类型
处理时间
Flink程序执行对应操作的系统时间。所有基于时间的操作（例如：时间窗口）都将使用运行相应operator的系统时间。例如：每个小时的处理时间窗口包括在系统时间范围内所有operator接收到的记录。例如：如果应用程序在09:15开始运行，则第一个滚动时间窗口将包括：09:15 – 10:00 之间的处理事件，下一个窗口包括上午10:00 – 11:00之间的处理事件
这种处理时间方式实时性是最好的，但数据未必准确
事件时间
每个事件发生的时间。这个时间一般是在进入到Flink之前就包含在事件中针对Eventtime，事件被处理的时间以来与事件本身Eventtime必须要指定如何生成Eventtime Watermark（水印）理想情况，不管事件何时到达或者顺序如何，事件时间处理能够得到完整一致地结果。
事件处理在等待乱序事件时，会产生一些延迟。这样会对Eventtime的应用性能有一定的影响
摄入时间
摄入时间是事件进入Flink的时间在source operator中，每个记录以时间戳的形式获取源的当前时间它在概念是处于事件时间和处理时间中间摄入时间不能处理乱序问题或者延迟数据，摄入时间可以由流式系统自动生成水印

flink 水印技术（水位线）
是一种度量 event time 进度的机制，watermarks 作为数据流中的一部分在 Stream 中流动， 并且携带一个 timestamp 一个 watermark(t) 表明在流中处理的 event time 已经到达了 t，那么在流中不会 event time 小于 t 的事 件产生了。（说白了就是为了防止事件晚到的一种机制，相当窗口的事件长度变大了多了水位线时间）。