Flink高频面试题( 精简 )

本文隶属于专栏《董工的1000个大数据技术体系》摘要，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！

前言

作为大数据领域炙手可热的大数据组件，Flink作为大数据行业跳槽必问的组件，整理一些Flink相关的面试题供大家参考，有些题言简意赅即可，大多数的博客冗余一堆的知识点，看完要好久，我想帮大家提炼总结出核心的点，以帮助大家临阵磨枪，短时间掌握，当你把知识提炼出来，你会发现你的知识进步了，当你把简单提炼的知识再用自己的语言详细的说出来，那你就成为很厉害的人了，希望帮助大家收获到自己满意的offer。

一、SparkStreaming和Flink的区别是什么？

1、Flink 是实时处理引擎，基于事件驱动。而 Spark Streaming 是微批（Micro-Batch）的模型。（根本区别，一定要说出来）

2、时间机制:Spark Streaming只支持处理时间。 Flink支持处理时间、事件时间、注入时间。同时也支持watermark来处理滞后数据。

3、容错机制:Spark Streaming 通过checkpoint实现数据不丢失，但无法做到恰好一次处理语义。Flink 则使用两阶段提交协议和checkpoint实现精准一次处理，容错性好

区别相对比较多，具体不一一介绍，只要说出来其代表性的即可

二、Flink的编程模型?

1. Source数据源输入
2. Tranformation数据转换
3. Sink数据输出

三、Flink中集群有哪些角色?各个角色有什么作用？

jobmanager: 管理集群master的角色，负责资源调度和资源管理，管理taskManager，协调checkpoint，故障恢复

taskManager: 实际执行计算，与TaskManager状态传递

client(客户端): 负责与jobManager进行交互把任务提交到集群

四、Flink如何设置并行度

系统层面（flink客户端的配置yml文件中设置）

客户端层面（提交flink run -p的时候设置）

执行环境层面（构建Flink环境时getExecutionEnvironment.setParallelism(1)设置）

算子层面（算子.setParallelism(3),实际算子时设置）

优先级设置: 算子层面>执行环境层面>客户端层面>系统层面

（实际业务中通常设置和kafka分区数一样或者kafka分区倍数的并行度）

五、Flink中有没有重启策略?

故障延迟重启策略

故障率重启策略

没有重启策略

Fallback重启策略

如果没有启用 checkpointing，则使用无重启 (no restart) 策略。如果启用了 checkpointing，但没有配置重启策略，则使用固定间隔 (fixed-delay) 策略
重启策略可以在flink-conf.yaml中配置，表示全局的配置。也可以在应用代码中动态指定，会覆盖全局配置

六、Flink的广播变量，使用的时候需要注意什么？

我们知道Flink的任务是并行的，计算过程可能不在一个slot中进行，那么就只有一种情况即：当我们访问同一份数据的时候，Flink中广播变量就是了解这种情况

我们可以把广播变量当一个公共的共享变量，我们可以把一个dataset数据集广播出去，然后通过不同的task节点获取到，这个数据在每个节点上只会存在一份。

七、Flink的状态储存

存在状态后端

1.13版本之前

MemoryStateBackend 开发时使用
FsStateBackend 生产时使用，常用
RocksDBStateBackend 生产时使用，非常大的状态时用

1.13版本之后

HashMapStateBackend（即MemoryStateBackend和FsStateBackend，根据api不同）

EmbeddedRocksDBStateBackend 生产时使用，非常大的状态时用

八、Flink的分区策略

GlobalPartitioner （数据发到下游算子的第一个实例）

ShufflePartitioner（ 数据随机分发到下游算子）

dataStream.shuffle();

RebalancePartitioner （数据循环发送到下游的实例）

dataStream.rebalance()

RescalePartitioner （根据上下游算子的并行度，循环输出到下游算子）

dataStream.rescale();

BroadcastPartitioner （输出到下游算子的每个实例中）

dataStream.broadcast();

ForwardPartitioner （上下游算子并行度一样）

KeyGroupStreamPartitioner (按 Key 的 Hash 值输出到下游算子)

KeyedStream根据keyGroup索引编号进行分区，会将数据按 Key 的 Hash 值输出到下游算子实例中。该分区器不是提供给用户来用的。CustomPartitionerWrapper (用户自定义分区器)

CustomPartitionerWrapper（用户自定义分区器。需要用户自己实现Partitioner接口，来定义自己的分区逻辑）

九、Flink时间有那几类？

事件时间(event time)：数据本身真正产生时间（大多数都用这个）
摄取时间(ingestion time)： Flink 读取数据时的时间
处理时间(processing time)： Flink中算子处理数据的时间

十、你们公司怎么提交FLink任务

也就是说flink提交的几种模式

yarn-session提交

application提交

per-job提交（大多数公司都用这个，无论是监控还是提交都很方便，一个yarn分配一次）

十一、Flink中watermark

wateramrk是flink用来处理乱序时间的机制，基于事件时间，通常用来触发窗口的计算

水位线计算公式：Watermark=进入Flink的最大的事件时间(Event Time)-指定的延迟时间(t)

触发窗口计算的时机：窗口的停止时间<=当前的WaterMark

（假如窗口是12点到12点05，最大延迟时间1min，
假如来了条数据是12点07，，那水印就是12点07-1min为12点06 > 12点05，就可以出发上面的窗口进行计算了）

十二、Flink如何容错

通过checkpoint（基于ABS算法）实现容错

ABG全程异步屏障快照（Asynchronous Barrier Snapshotting）,是对Chandy-Lamport算法(分布式快照算法)在工业项目中落地实现的补充和优化

具体过程
1、JobManager定期向source发送Checkpoint的请求（由代码中的Checkpoint配置决定），向下游发送CheckpointBarrier
2、每个计算算子收到CheckpointBarrier，进行Barrier对齐，对齐后存储Checkpoint到状态后端，
3、sink节点Barrier对齐后，多个sink确认下Checkpoint是否正常，如果正常JobManager确定本次Checkpoint结束
4、中途失败只需要拿取前面的Checkpoint重新计算，进行恢复

十三、Flink运行中必须依赖Hadoop组件吗？

Flink在运行当中完全可以独立于Hadoop，不依赖于Hadoop运行，但是作为大数据基础设施，Hadoop体系是任何大数据都绕不过去的问题，Flink可以集成Hadoop中的许多组件，例如：hdfs，hbase，yarn 比如：Flink通过yarn来做资源的调度，HDFS的读写，或者用HDFS做检查点

十四、Flink的Slot和parallelism有什么区别？

slot是指taskmanager的并发执行能力，假设我们将 taskmanager.numberOfTaskSlots 配置为3 那么每一个 taskmanager 中分配3个 TaskSlot, 3个 taskmanager 一共有9个TaskSlot。

parallelism是指taskmanager实际使用的并发能力。假设我们把 parallelism.default 设置为1，那么9个 TaskSlot 只能用1个，有8个空闲。

十五、Flink的状态

Flink中的状态分为两个

1.KeyedState（键控状态）

2.OperatorState（算子状态）

（实际生产中通常使用Keyed State中的ValueState、MapState）

十六、Flink的资源调度

TaskManager中最细粒度的资源是Task slot，代表了一个固定大小的资源子集，每个TaskManager会将其所占有的资源平分给它的slot。
通过调整 task slot 的数量，用户可以定义task之间是如何相互隔离的。每个 TaskManager 有一个slot，也就意味着每个task运行在独立的 JVM 中。每个 TaskManager 有多个slot的话，也就是说多个task运行在同一个JVM中。
而在同一个JVM进程中的task，可以共享TCP连接（基于多路复用）和心跳消息，可以减少数据的网络传输，也能共享一些数据结构，一定程度上减少了每个task的消耗。 每个slot可以接受单个task，也可以接受多个连续task组成的pipeline，如下图所示，FlatMap函数占用一个taskslot，而key Agg函数和sink函数共用一个taskslot：

十七、Flink SQL的实现原理

Flink的SQL解析是基于Apache Calcite框架的

一套完整的解析过程如下：

1.用户使用对外提供Stream SQL的语法开发业务应用

2.用calcite对StreamSQL进行语法检验，语法检验通过后，转换成calcite的逻辑树节点；最终形成calcite的逻辑计划

3.采用Flink自定义的优化规则和calcite火山模型、启发式模型共同对逻辑树进行优化，生成最优的Flink物理计划

4.对物理计划采用janino codegen生成代码，生成用低阶API DataStream 描述的流应用，提交到Flink平台执行