Flink常见⾯试题整理
1.什么是Apache Flink（为什么使⽤ Flink 替代 Spark？）
2.Flink 的核⼼概念
Flink 的核⼼概念主要有四个：Event Streams、State、Time 和 Snapshots。
Event Streams：即事件流，事件流可以是实时的也可以是历史的。Flink 是基于流的，但它不⽌能处理流，也能处理批，⽽流和批的输⼊都是事件流，差别在于实时与批量。
State：Flink 擅长处理有状态的计算。通常的复杂业务逻辑都是有状态的，它不仅要处理单⼀的事件，⽽且需要记录⼀系列历史的信息，然后进⾏计算或者判断。
Time：最主要处理的问题是数据乱序的时候，⼀致性如何保证。
Snapshots：实现了数据的快照、故障的恢复，保证数据⼀致性和作业的升级迁移等。
任务管理器在哪
3.作业在很多情况下有可能会失败。失败之后重新去运⾏时，我们如何保证数据的⼀致性？
Flink 基于 Chandy-Lamport 算法，会把分布式的每⼀个节点的状态保存到分布式⽂件系统⾥⾯作为 Checkpoint（检查点），过程⼤致如下。⾸先，从数据源端开始注⼊ Checkpoint Barrier，它是⼀种⽐较特殊的消息。
然后它会跟普通的事件⼀样随着数据流去流动，当 Barrier 到达算⼦之后，这个算⼦会把它当前的本地状态进⾏快照保存，当 Barrier 流动到 Sink，所有的状态都保存完整了之后，它就形成⼀个全局的快照。
这样当作业失败之后，就可以通过远程⽂件系统⾥⾯保存的 Checkpoint 来进⾏回滚：先把 Source 回滚到 Checkpoint 记录的offset，然后把有状态节点当时的状态回滚到对应的时间点，进⾏重新计算。这样既可以不⽤从头开始计算，⼜能保证数据语义的⼀致性。
4.Flink的时间语义
Event Time：事件创建的时间
Ingestion Time：数据进⼊Flink的时间
Processing Time：执⾏操作算⼦的本地系统时间，与机器相关
5.Flink的API可分为哪⼏层？
SQL & Table API 同时适⽤于批处理和流处理，这意味着你可以对有界数据流和⽆界数据流以相同的语义进⾏查询，并产⽣相同的结果。除了基本查询外， 它还⽀持⾃定义的标量函数，聚合函数以及表值函数，可以满⾜多样化的查询需求。
DataStream & DataSet API 是 Flink 数据处理的核⼼ API，⽀持使⽤ Java 语⾔或 Scala 语⾔进⾏调⽤，提供了数据读取，数据转换和数据输出等⼀系列常⽤操作的封装。
Stateful Stream Processing 是最低级别的抽象，它通过 Process Function 函数内嵌到 DataStream API 中。 Process
1) 作业管理器（JobManager）
1. 控制⼀个应⽤程序执⾏的主进程，也就是说，每个应⽤程序都会被⼀个不同的Jobmanager所控制执⾏
2. Jobmanager会先接收到要执⾏的应⽤程序，这个应⽤程序会包括：作业图（ Job Graph）、逻辑数据流图（ ogical dataflow
graph）和打包了所有的类、库和其它资源的JAR包。
3. Jobmanager会把Jobgraph转换成⼀个物理层⾯的数据流图，这个图被叫做“执⾏图”(Executiongraph)，包含了所有可以并发执
⾏的任务。Job Manager会向资源管理器(Resourcemanager)请求执⾏任务必要的资源，也就是任务管理器(Taskmanager)上的插槽slot。⼀旦它获取到了⾜够的资源，就会将执⾏图分发到真正运⾏它们的 Taskmanager上。⽽在运⾏过程中Jobmanagera会负责所有需要中央协调的操作，⽐如说检查点(checkpoints)的协调。
2) 任务管理器（TaskManager）
1. Flink中的⼯作进程。通常在 Flink中会有多个Taskmanager运⾏，每个Taskmanager都包含了⼀定数量的插槽(slots)。插槽的数量
限制了Taskmanager能够执⾏的任务数量。
2. 启动之后，Taskmanager会向资源管理器注册它的插槽；收到资源管理器的指令后， Taskmanager就会将⼀个或者多个插槽提供给
Jobmanager调⽤。Jobmanager就可以向插槽分配任务(tasks)来执⾏了。
3. 在执⾏过程中，⼀个Taskmanager可以跟其它运⾏同⼀应⽤程序的Taskmanager交换数据。
3) 资源管理器（ResourceManager)
1. 主要负责管理任务管理器(TaskManager)的插槽(slot)Taskmanger插槽是Flink中定义的处理资源单元。
2. Flink为不同的环境和资源管理⼯具提供了不同资源管理器，⽐如YARN、K8s，以及 standalone部署。
3. 当Jobmanager申请插槽资源时，Resourcemanager会将有空闲插槽的Taskmanager分配给Jobmanager。如果
Resourcemanager没有⾜够的插槽来满⾜ Jobmanager的请求，它还可以向资源提供平台发起会话，以提供启动 Taskmanager进程的容器。
4) 分发器（Dispatcher）
1. 可以跨作业运⾏，它为应⽤提交提供了REST接⼝。
2. 当⼀个应⽤被提交执⾏时，分发器就会启动并将应⽤移交给Jobmanage。
3. Dispatcher他会启动⼀个WebUi，⽤来⽅便地展⽰和监控作业执⾏的信息。
7.Flink任务提交流程
8.任务提交流程（YARN）
1. Flink任务提交后，Client向HDFS上传Flink的Jar包和配置
2. 随后向Yarn ResourceManager提交任务，ResourceManager分配Container资源并通知对应的NodeManager启动
3. ApplicationMaster，ApplicationMaster启动后加载Flink的Jar包和配置构建环境
4. 然后启动JobManager，之后ApplicationMaster向ResourceManager申请资源启动 TaskManager
5. ResourceManager分配Container资源后，由ApplicationMaster通知资源所在节点的NodeManager启动TaskManager
6. NodeManager加载Flink的Jar包和配置构建环境并启动TaskManager
7. TaskManager启动后向JobManager发送⼼跳包，并等待JobManager向其分配任务。
9.Flink的执⾏图
Flink中的执⾏图可以分成四层： Streamgraph -> Jobgraph -> Executiongraph -> 物理执⾏图
1. Streamgraph：是根据⽤户通过 Stream API编写的代码⽣成的最初的图。⽤来表⽰程序的拓扑结构。
2. Jobgraph：Streamgraph经过优化后⽣成了 Jobgraph，提交给 Jobmanager的数据结构。主要的优化为，将多个符合条件的节点
chain在⼀起作为⼀个节点。
3. Execution Graph：Jobmanager根据 Jobgraph⽣成，是 Jobgraph的并⾏化版本，是调度层最核⼼的数据结构。
4. 物理执⾏图：Jobmanager根据 Executiongraph对Job进⾏调度后，在各个Taskmanager上部署Task后形成的“图”，并不是⼀个
具体的数据结构。
10.Flink的分区策略
11.Flink 的状态分为哪两类
作为对状态⽀持⽐较好的系统，Flink内部提供了可以使⽤的很多种可选的状态原语。从⼤的⾓度看， 所有状态原语可以分为KeyedState和OperatorState 两类。
12.KeyedState都有哪⼏类
Keyed State 可以进⼀步划分为下⾯的 5 类，它们分别是
13.Flink中watermark的概念
watermark是⼀种衡量Event Time进展的机制，它是数据本⾝的⼀个隐藏属性。通常基于Event Time的数据，⾃⾝都包含⼀个timestamp.watermark是⽤于处理乱序事件的，⽽正确的处理乱序事件，通常⽤watermark机制结合window来实现。
流处理从事件产⽣，到流经source，再到operator，中间是有⼀个过程和时间的。虽然⼤部分情况下，流到operator的数据都是按照事件产⽣的时间顺序来的，但是也不排除由于⽹络、背压等原因，导致乱序的产⽣（out-of-order或者说late element）。
但是对于late element，我们⼜不能⽆限期的等下去，必须要有个机制来保证⼀个特定的时间后，必须触发window去进⾏计算了。这个特别的机制，就是watermark。
14.什么是Flink的全局快照
全局快照⾸先是⼀个分布式应⽤，它有多个进程分布在多个服务器上；其次，它在应⽤内部有⾃⼰的处理逻辑和状态；第三，应⽤间是可以互相通信的；第四，在这种分布式的应⽤，有内部状态，硬件可以通信的情况下，某⼀时刻的全局状态，就叫做全局的快照。
15.为什么需要全局快照
第⼀，⽤它来做检查点，可以定期对全局状态做备份，当应⽤程序故障时，就可以拿来恢复；
第⼆，做死锁检测，进⾏快照后当前的程序继续运⾏，然后可以对快照进⾏分 析，看应⽤程序是不是存在死锁状态，如果是就可以进⾏相应的处理。
16.Flink的容错机制
Exactly once，是指每条 event 会且只会对 state 产⽣⼀次影响，这⾥的“⼀次”并⾮端到端的严格⼀次，⽽是指在 Flink 内部只处理⼀次，不包括 source和 sink 的处理。
At least once，是指每条 event 会对 state 产⽣最少⼀次影响，也就是存在重复处理的可能。
At most once，是指每条 event 会对 state 产⽣最多⼀次影响，就是状态可能会在出错时丢失。
17.Flink是如何实现End-To-End Exactly-once的？
Flink通过状态和两次提交协议来保证了端到端的exactly-once语义
Source：⽀持数据的replay，如Kafka的offset。
Transformation：借助于checkpoint
Sink：Checkpoint + 两阶段事务提交
18.解释下两阶段提交？
⼀旦Flink开始做checkpoint操作，就会进⼊pre-commit “预提交”阶段，同时JobManager的Coordinator会将Barrier注⼊数据流中。
当所有的barrier在算⼦中成功进⾏⼀遍传递（就是Checkpoint完成），并完成快照后，“预提交”阶段完成。
等所有的算⼦完成“预提交”，就会发起⼀个commit “提交”动作，但是任何⼀个“预提交” 失败都会导致Flink回滚到最近的checkpoint。
19.两阶段提交API
发布评论