大数据-flink常见面试题

1. flink checkpoint了解吗？

Flink Checkpoint 是一种容错恢复机制。这种机制保证了实时程序运行时，即使突然遇到异常或者机器问题时也能够进行自我恢复。Flink Checkpoint 对于用户层面来说，是透明的，用户会感觉实时任务一直在运行。

Flink Checkpoint 是 Flink 自身的系统行为，用户无法对其进行交互，用户可以在程序启动之前，设置好实时任务 Checkpoint 相关的参数，当任务启动之后，剩下的就全交给 Flink 自行管理。

flink checkpoint 提供了三种可用的状态后端：MemoryStateBackend,FsStateBackend和RocksDBStateBackend。

• MemoryStateBackend

内存级的状态后端，会将键控状态作为内存中的对象进行管理，将它们存储在 TaskManager 的 JVM 堆上；而将 checkpoint 存储在 JobManager 的内存中。

• FsStateBackend

将 checkpoint 存到远程的持久化文件系统（FileSystem）上。而对于本地状态，跟 MemoryStateBackend 一样，也会存在 TaskManager 的 JVM 堆上。

• RocksDBStateBackend

将所有状态序列化后，存入本地的 RocksDB 中存储。

2. flink反压了解吗？如何处理反压？

整个Flink 的反压是从下游往上游传播的，一直传播到Source Task，Source Task 有压力后，会降低从外部组件中读取数据的速率，例如：Source Task 会降低从Kafka 中读取数据的速率，来降低整个Flink Job 中缓存的数据，从而降低负载。

https://segmentfault.com/a/1190000038561714

3. flink水印说说？

waterMark是一种衡量Event Tiem进展机制。Watermark是用于处理乱序事件的，而正确的处理乱序事件，通常用Watermark机制结合window来实现。 数据流中的Watermark用于表示timestamp小于Watermark的数据，都已经到达了，因此，window的执行也是由Watermark触发的。 Watermark可以理解成一个延迟触发机制，我们可以设置Watermark的延时时长t，每次系统会校验已经到达的数据中最大的maxEventTime，然后认定eventTime小于maxEventTime - t的所有数据都已经到达，如果有窗口的停止时间等于maxEventTime – t，那么这个窗口被触发执行。

当Flink接收到数据时，会按照一定的规则去生成Watermark，这条Watermark就等于当前所有到达数据中的maxEventTime - 延迟时长，也就是说，Watermark是由数据携带的，一旦数据携带的Watermark比当前未触发的窗口的停止时间要晚，那么就会触发相应窗口的执行。由于Watermark是由数据携带的，因此，如果运行过程中无法获取新的数据，那么没有被触发的窗口将永远都不被触发。

AssignerWithPeriodicWatermarks
AssignerWithPunctuatedWatermarks

迟到事件处理：

• 重新激活已经关闭的窗口并重新计算以修正结果。
• 将迟到事件收集起来另外处理。
• 将迟到事件视为错误消息并丢弃。

https://zhuanlan.zhihu.com/p/364013202

4. flink重启策略。默认有什么问题？

Flink支持不同的重启策略，可以控制在发生故障时如何重启新启动作业。

默认重启策略是通过Flink的配置文件设置的flink-conf.yaml。配置参数restart-strategy定义采用的策略。

如果未启用检查点，则使用“无重启”策略。如果激活了检查点并且尚未配置重启策略，则固定延迟策略将用于 Integer.MAX_VALUE重启尝试。

重启策略分为：固定延迟重启策略、故障率重启策略、无重启策略、后备重启策略。

1.固定延迟重启策略

固定延迟重启策略是尝试给定次数重新启动作业。如果超过最大尝试次数，则作业失败。在两次连续重启尝试之间，会有一个固定的延迟等待时间。

通过在flink-conf.yaml中配置参数：

# fixed-delay:固定延迟策略

restart-strategy: fixed-delay

# 尝试5次，默认Integer.MAX_VALUE

restart-strategy.fixed-delay.attempts: 5

# 设置延迟时间10s，默认为 akka.ask.timeout时间

restart-strategy.fixed-delay.delay: 10s

2.故障率重启策略

故障率重启策略在故障后重新作业，当设置的故障率（failure rate）超过每个时间间隔的故障时，作业最终失败。在两次连续重启尝试之间，重启策略延迟等待一段时间。

在flink-conf.yaml文件配置

# 设置重启策略为failure-rate

restart-strategy: failure-rate

# 失败作业之前的给定时间间隔内的最大重启次数，默认1

restart-strategy.failure-rate.max-failures-per-interval: 3

# 测量故障率的时间间隔。默认1min

restart-strategy.failure-rate.failure-rate-interval: 5min

# 两次连续重启尝试之间的延迟，默认akka.ask.timeout时间

restart-strategy.failure-rate.delay: 10s

在代码中设置：

ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment();

// 3为最大失败次数；5min为测量的故障时间；10s为2次间的延迟时间

env.setRestartStrategy(RestartStrategies.failureRateRestart(3,Time.of(5, TimeUnit.MINUTES),Time.of(10, TimeUnit.SECONDS)));

3.无重启策略

作业直接失败，不尝试重启。

在flink-conf.yaml中配置：

restart-strategy: none

在代码中实现：

ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment();

env.setRestartStrategy(RestartStrategies.noRestart());

4.后备重启策略

使用群集定义的重新启动策略。这对于启用检查点的流式传输程序很有帮助。默认情况下，如果没有定义其他重启策略，则选择固定延迟重启策略。

5. flink 部署模式有哪些？

flink 部署模式主要分为3种

• flink session cluster
• flink job cluster
• flink application cluster

1. flink session cluster 任务提交在同一个集群上，适合小规模数据集测试
2. flink job cluster 也称 pre-job模式，每次启动一个任务，都创建一个单独的集群，目前我们公司采用的就是这个模式，它有着量好的资源隔离性和资源利用率，集群的生命周期也是和任务一样的，适合大规模数据集
3. flink application cluster 该模式下，一个Application动态创建一个属于自己专有的集群，Application内的所有任务共享该集群，很显然这是一种介于Session Cluster和Job Cluster之间的模式：不同Application之间是完全隔离的，类似Job Cluster；但一个Application内的任务是不隔离的，类似于Session Cluster。

https://niyanchun.com/flink-quick-learning-deployment-mode.html#comments

6. flink的监控页面，有了解吗，主要关注那些指标？

flink 主要关注的有

flink 任务运行状态；

flink checkpoint 状态统计

taskmamger的状态，内存使用情况以及垃圾回收情况

Flink 的 metrics 是 Flink 公开的一个度量系统，metrics 也可以暴露给外部系统，通过在 Flink 配置文件 conf/flink-conf.yaml 配置即可，Flink原生已经支持了很多reporter，如 JMX、InfluxDB、Prometheus 等等。

我们也可以自定义指标通过 metric 收集，实际开发时经常需要查看当前程序的运行状况，flink 提供了 UI 界面，有比较详细的统计信息。

7. flink集群规模， 数据量

按照实际情况回答，比如 32台服务器，每台 128 G，数据量大概10亿

8. flink作业，flink参数配配置

#!/bin/bash

env -i FLINK_CONF_DIR = ./conf ./bin/flink run -m yarn-cluster -yn 4 -ytm 2g -ys 4 -yqn dev1 -ynm test xxx.jar --queueName test

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hiKn8c2A-1631032575279)(大数据-flink.assets/1630931126156.png)]

9. flink 并行度 、slot区别

flink 并行度： 一个特定算子的子任务（subtask） 的个数称之为并行度。可以在flink-conf.yml中配置，也可以在环境变量中设置，还可以在每个算子上设置

slot ：在Flink架构角色中我们提到，TaskManager是实际负责执行计算的Worker，TaskManager 是一个 JVM 进程，并会以独立的线程来执行一个 task 或多个 subtask。为了控制一个TaskManager 能接受多少个 task，Flink 提出了 Task Slot 的概念。简单的说，TaskManager会将自己节点上管理的资源分为不同的 Slot：固定大小的资源子集。这样就避免了不同 Job的 Task 互相竞争内存资源，但是需要主要的是，Slot 只会做内存的隔离。没有做 CPU 的隔离。

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

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

10 . flink state状态

按照数据的划分和扩张方式，Flink中大致分为2类：

Keyed States：记录每个Key对应的状态值一个Task上可能包含多个Key不同Task上不会出现相同的Key ，常用的 MapState, ValueState

Operator States：记录每个Task对应的状态值数据类型

1. ListState：并发度在改变的时候，会将并发上的每个List都取出，然后把这些List合并到一个新的List,然后根据元素的个数在均匀分配给新的Task;
2. UnionListState：相比于ListState更加灵活，把划分的方式交给用户去做，当改变并发的时候，会将原来的List拼接起来。然后不做划分，直接交给用户；
3. BroadcastState：如大表和小表做Join时，小表可以直接广播给大表的分区，在每个并发上的数据都是完全一致的。做的更新也相同，当改变并发的时候，把这些数据COPY到新的Task即可

11. flink 状态后端分类，增量checkpoint

state 存储在 State Backend 中，State Backend 一共有三种：

• MemoryStateBackend
• FsStateBackend
• RocksDBStateBackend。

增量 checkpoint 仅包含上次 checkpoint 和本次 checkpoint 之间状态的差异（也就是“增量”）。对于状态非常大的作业，增量 checkpoint 对性能的提升非常明显。**有生产用户反馈对于 TB 级别的作业，使用增量 checkpoint 后能将 checkpoint 的整体时间从 3 分钟降到 30 秒。**这些时间节省主要归功于不需要在每次 checkpoint 都将所有状态写到持久化存储系统。Flink 的增量 checkpoint 以 RocksDB 的 checkpoint 为基础。RocksDB 是一个 LSM 结构的 KV 数据库，把所有的修改保存在内存的可变缓存中（称为 memtable），所有对 memtable 中 key 的修改，会覆盖之前的 value，当前 memtable 满了之后，RocksDB 会将所有数据以有序的写到磁盘。当 RocksDB 将 memtable 写到磁盘后，整个文件就不再可变，称为有序字符串表（sstable）。

RocksDB 的后台压缩线程会将 sstable 进行合并，就重复的键进行合并，合并后的 sstable 包含所有的键值对，RocksDB 会删除合并前的 sstable。

在这个基础上，Flink 会记录上次 checkpoint 之后所有新生成和删除的 sstable，另外因为 sstable 是不可变的，Flink 用 sstable 来记录状态的变化。为此，Flink 调用 RocksDB 的 flush，强制将 memtable 的数据全部写到 sstable，并硬链到一个临时目录中。这个步骤是在同步阶段完成，其他剩下的部分都在异步阶段完成，不会阻塞正常的数据处理。

Flink 将所有新生成的 sstable 备份到持久化存储（比如 HDFS，S3），并在新的 checkpoint 中引用。Flink 并不备份前一个 checkpoint 中已经存在的 sstable，而是引用他们。Flink 还能够保证所有的 checkpoint 都不会引用已经删除的文件，因为 RocksDB 中文件删除是由压缩完成的，压缩后会将原来的内容合并写成一个新的 sstable。因此，Flink 增量 checkpoint 能够切断 checkpoint 历史。

为了追踪 checkpoint 间的差距，备份合并后的 sstable 是一个相对冗余的操作。但是 Flink 会增量的处理，增加的开销通常很小，并且可以保持一个更短的 checkpoint 历史，恢复时从更少的 checkpoint 进行读取文件，因此我们认为这是值得的。

https://cloud.tencent.com/developer/article/1506196

12. flink sql

Flink SQL 是 Flink 实时计算为简化计算模型，降低用户使用实时计算门槛而设计的一套符合标准 SQL 语义的开发语言。它的优点就是简化开发，能够使用类sql的语法来计算数据，缺点就是不够灵活，无法计算复杂的数据处理逻辑或不太好实现

13. flink 双流join 分类，可能导致问题

Flink DataStream API 为用户提供了3个算子来实现双流 join，分别是：

• join()
• coGroup()
• intervalJoin()

join() 算子提供的语义为"Window join"，即按照指定字段和（滚动/滑动/会话）窗口进行 inner join，支持处理时间和事件时间两种时间特征。

coGroup() 算子。它的调用方式类似于 join() 算子，也需要开窗，但是 CoGroupFunction 比 JoinFunction 更加灵活，可以按照用户指定的逻辑匹配左流和/或右流的数据并输出。

intervalJoin() 按照指定字段以及右流相对左流偏移的时间区间进行关联

14. savepoint 和 checkpoint 区别 ，checkpoint执行时间，及问题

1. checkpoint的侧重点是“容错”，即Flink作业意外失败并重启之后，能够直接从早先打下的checkpoint恢复运行，且不影响作业逻辑的准确性。而savepoint的侧重点是“维护”，即Flink作业需要在人工干预下手动重启、升级、迁移或A/B测试时，先将状态整体写入可靠存储，维护完毕之后再从savepoint恢复现场。

2. savepoint是“通过checkpoint机制”创建的，所以savepoint本质上是特殊的checkpoint。

3. checkpoint面向Flink Runtime本身，由Flink的各个TaskManager定时触发快照并自动清理，一般不需要用户干预；savepoint面向用户，完全根据用户的需要触发与清理。

4. checkpoint的频率往往比较高（因为需要尽可能保证作业恢复的准确度），所以checkpoint的存储格式非常轻量级，但作为trade-off牺牲了一切可移植（portable）的东西，比如不保证改变并行度和升级的兼容性。savepoint则以二进制形式存储所有状态数据和元数据，执行起来比较慢而且“贵”，但是能够保证portability，如并行度改变或代码升级之后，仍然能正常恢复。

5. checkpoint是支持增量的（通过RocksDB），特别是对于超大状态的作业而言可以降低写入成本。savepoint并不会连续自动触发，所以savepoint没有必要支持增量。

   原文链接：https://blog.csdn.net/nazeniwaresakini/article/details/104649508

15. flink 窗口

flink窗口分为 keyed window 和 Non-Keyed Window 表示窗口是按照key进行分组还是不安照key分组计算；

flink 窗口有两个必要的操作：

• 使用窗口分配器（WindowAssigner）将数据流中的元素分配到对应的窗口中
• 当窗口满足触发条件时，对窗口中数据使用窗口处理函数（Window Function）进行处理

窗口分配器主要分为两种：一种基于事件（Time-based Window）,一种是基于数量的（Count-based Window）

再细分 有滚动窗口- 窗口之间不叠加，且窗口长度是固定的；滑动窗口以一个步长（Slide）不断向前滑动，窗口的长度固定；

会话窗口根据Session gap切分不同的窗口，当一个窗口在大于Session gap的时间内没有接收到新数据时，窗口将关闭。在这种模式下，窗口的长度是可变的，每个窗口的开始和结束时间并不是确定的。

16. flink窗口，基于事件时间数据，若没有数据来如何触发窗口？

flink如果基于事件事件来创建窗口，若没有数据到来或者是水印未到达窗口的触发条件，是无法触发窗口计算的，此时如何触发窗口

两种方法：1. 在数据源定时触发一条无意义数据，对数据计算没有影响，但带了事件事件戳，则窗口自然触发

2. 自定义一个触发器，自定义触发条件

参考：https://www.cnblogs.com/YuanWeiBlogger/p/12072782.html