Flink 高频面试题

6 大主题，36 个 Flink 高频面试题：

1. ⭐ 状态原理
2. ⭐ 时间窗口
3. ⭐ 编程技巧
4. ⭐ 实战经验
5. ⭐ 实时数仓
6. ⭐ 前沿探索

1.状态原理

1.1.状态、状态后端、Checkpoint 三者之间的区别及关系？

• 状态：本质来说就是数据，在 Flink 中，其实就是 Flink 提供给用户的状态编程接口。比如 flink 中的 MapState，ValueState，ListState。
• 状态后端：Flink 提供的用于管理状态的组件，状态后端决定了以什么样数据结构，什么样的存储方式去存储和管理我们的状态。Flink 目前官方提供了 memory、filesystem，rocksdb 三种状态后端来存储我们的状态。
• Checkpoint（状态管理）：Flink 提供的用于定时将状态后端中存储的状态同步到远程的存储系统的组件或者能力。为了防止 long run 的 Flink 任务挂了导致状态丢失，产生数据质量问题，Flink 提供了状态管理（Checkpoint，Savepoint）的能力把我们使用的状态给管理起来，定时的保存到远程。然后可以在 Flink 任务 failover 时，从远程把状态数据恢复到 Flink 任务中，保障数据质量。

1.2 把状态后端从 FileSystem 变为 RocksDB 后，Flink 任务状态存储会发生那些变化？

结论：是否使用 RocksDB 只会影响 Flink 任务中 keyed-state 存储的方式和地方，Flink 任务中的 operator-state 不会受到影响。

首先我们来看看，Flink 中的状态只会分为两类：

• keyed-state：键值状态，如其名字，此类状态是以 k-v 的形式存储，状态值和 key 绑定。Flink 中的 keyby 之后紧跟的算子的 state 就是键值状态；
• operator-state：算子状态，非 keyed-state 的 state 都是算子状态，非 k-v 结构，状态值和算子绑定，不和 key 绑定。Flink 中的 kafka source 算子中用于存储 kafka offset 的 state 就是算子状态。

如下图所示是 3 种状态后端和 2 种 State 的对应存储关系：

1. 横向（行）来看，即 Flink 的状态分类。分为 Operator state-backend、Keyed state-backend；
2. 纵向（列）来看，即 Flink 的状态后端分类。用户可以配置 memory，filesystem，rocksdb 3 中状态后端，在 Flink 任务中生成 MemoryStateBackend，FsStateBackend，RocksdbStateBackend，其声明了整个任务的状态管理后端类型；
3. 每个格子中的内容就是用户在配置 xx 状态后端（列）时，给用户使用的状态（行）生成的状态后端实例，生成的这个实例就是在 Flink 中实际用于管理用户使用的状态的组件。

因此对应的结论就是：

1. Flink 任务中的 operator-state。无论用户配置哪种状态后端（无论是 memory，filesystem，rocksdb），都是使用 DefaultOperatorStateBackend 来管理的，状态数据都存储在内存中，做 Checkpoint 时同步到远程文件存储中（比如 HDFS）。
2. Flink 任务中的 keyed-state。用户在配置 rocksdb 时，会使用 RocksdbKeyedStateBackend 去管理状态；用户在配置 memory，filesystem 时，会使用 HeapKeyedStateBackend 去管理状态。因此就有了这个问题的结论，配置 rocksdb 只会影响 keyed-state 存储的方式和地方，operator-state 不会受到影响。

1.3什么样的业务场景你会选择 filesystem，什么样的业务场景你会选 rocksdb 状态后端？

先看看每种状态后端的特性：

(1) MemoryStateBackend

原理：运行时所需的 State 数据全部保存在 TaskManager JVM 堆上内存中，执行 Checkpoint 的时候，会把 State 的快照数据保存到 JobManager 进程 的内存中。执行 Savepoint 时，可以把 State 存储到文件系统中。

适用场景：
a. 基于内存的 StateBackend 在生产环境下不建议使用，因为 State 大小超过 JobManager 内存就 OOM 了，此种状态后端适合在本地开发调试测试，生产环境基本不用。
b. State 存储在 JobManager 的内存中。受限于 JobManager 的内存大小。
c. 每个 State 默认 5MB,可通过 MemoryStateBackend 构造函数调整。
d. 每个 Stale 不能超过 Akka Frame 大小。

(2) FSStateBackend

原理：运行时所需的 State 数据全部保存在 TaskManager 的内存中，执行 Checkpoint 的时候，会把 State 的快照数据保存到配置的文件系统中。TM 是异步将 State 数据写入外部存储。

适用场景：
a.适用于处理小状态、短窗口、或者小键值状态的有状态处理任务，不建议在大状态的任务下使用 FSStateBackend。比如 ETL 任务，小时间间隔的 TUMBLE 窗口 b.State 大小不能超过 TM 内存。

(3) RocksDBStateBackend

原理：使用嵌入式的本地数据库 RocksDB 将流计算数据状态存储在本地磁盘中。在执行 Checkpoint 的时候，会将整个 RocksDB 中保存的 State 数据全量或者增量持久化到配置的文件系统中。

适用场景：
a. 最适合用于处理大状态、长窗口，或大键值状态的有状态处理任务。
b. RocksDBStateBackend 是目前唯一支持增量检查点的后端。
c. 增量检查点非常适用于超大状态的场景。比如计算 DAU 这种大数据量去重，大状态的任务都建议直接使用 RocksDB
状态后端。

到生产环境中：

• 如果状态很大，使用 Rocksdb；如果状态不大，使用 Filesystem。
• Rocksdb 使用磁盘存储 State，所以会涉及到访问 State 磁盘序列化、反序列化，性能会收到影响，而 Filesystem 直接访问内存，单纯从访问状态的性能来说 Filesystem 远远好于 Rocksdb。生产环境中实测，相同任务使用 Filesystem 性能为 Rocksdb 的 n 倍，因此需要根据具体场景评估选择。

1.4 operator-state 和 keyed-state 两者的区别？最大并行度又和它们有什么关系？举个生产环境中经常出现的案例，当用户停止任务、更新代码逻辑并且改变任务并发度时，两种 state 都是怎样进行恢复的？

1. operator-state：
   

• 状态适用算子：所有算子都可以使用 operator-state，没有限制。
• 状态的创建方式：如果需要使用 operator-state，需要实现 CheckpointedFunction 或 ListCheckpointed 接口
• DataStream API 中，operator-state 提供了 ListState、BroadcastState、UnionListState 3 种用户接口
• 状态的存储粒度：以单算子单并行度粒度访问、更新状态
• 并行度变化时：

a. ListState：均匀划分到算子的每个 sub-task 上，比如 Flink Kafka Source 中就使用了 ListState 存储消费 Kafka 的 offset，其 rescale 如下图

b. BroadcastState：每个 sub-task 的广播状态都一样 c. UnionListState：将原来所有元素合并，合并后的数据每个算子都有一份全量状态数据

2. keyed-state
   

• 状态适用算子：keyed-stream 后的算子使用。注意这里很多同学会犯一个错误，就是大家会认为 keyby 后面跟的所有算子都使用的是 keyed-state，但这是错误的 ❌，比如有 keyby.process.flatmap，其中 flatmap 中使用状态的话是 operator-state
• 状态的创建方式：从 context 接口获取具体的 keyed-state
• DataStream API 中，keyed-state 提供了 ValueState、MapState、ListState 等用户接口，其中最常用 ValueState、MapState
• 状态的存储粒度：以单 key 粒度访问、更新状态。举例，当我们使用 keyby.process，在 process 中处理逻辑时，其实每一次 process 的处理 context 都会对应到一个 key，所以在 process 中的处理都是以 key 为粒度的。这里很多同学会犯一个错 ❌，比如想在 open 方法中访问、更新 state，这是不行的，因为 open 方法在执行时，还没有到正式的数据处理环节，上下文中是没有 key 的。
• 并行度变化时：keyed-state 的重新划分是随着 key-group 进行的。其中 key-group 的个数就是最大并发度的个数。其中一个 key-group 处理一段区间 key 的数据，不同 key-group 处理的 key 是完全不同的。当任务并行度变化时，会将 key-group 重新划分到算子不同的 sub-task 上，任务启动后，任务数据在做 keyby 进行数据 shuffle 时，依然能够按照当前数据的 key 发到下游能够处理这个 key 的 key-group 中进行处理，如下图所示。注意：最大并行度和 key-group 的个数绑定，所以如果想恢复任务 state，最大并行度是不能修改的。大家需要提前预估最大并行度个数。
  

1.5 ValueState 和 MapState 各自适合的应用场景？

• ValueState
  应用场景：简单的一个变量存储，比如 Long\String 等。如果状态后端为 RocksDB，极其不建议在 ValueState 中存储一个大 Map，这种场景下序列化和反序列化的成本非常高，这种常见适合使用 MapState。其实这种场景也是很多小伙伴一开始使用 State 的误用之痛，一定要避免。
  TTL：针对整个 Value 起作用

• MapState
  应用场景：和 Map 使用方式一样一样的
  TTL：针对 Map 的 key 生效，每个 key 一个 TTL

1.6 Flink 配置 State TTL 时都有哪些配置项？每种配置项的作用？

• 支持 TTL 更新类型：更新 TTL 的时机
• 访问到已过期数据的时的数据可见性
• 过期时间语义：目前只支持处理时间
• 具体过期实现：lazy，后台线程
  

2.1.watermark 到底是干啥的？应用场景？

大部分同学都只能回答出：watermark 是用于缓解时间时间的乱序问题的。
没错，这个观点是正确的。但是博主认为这只是 watermark 第二重要的作用，其更重要的作用在于可以标识一个 Flink 任务的事件 时间进度。

怎么理解 时间进度？

我们可以现象一下，一个事件时间窗口的任务，如果没有一个 东西 去标识其事件时间的进度，那么这个事件时间的窗口也就是不知道什么时候能够触发了，也就是说这个窗口永远不会触发并且输出结果。

所以要有一个 东西 去标识其事件时间的进度，从而让这个事件时间窗口知道，这个事件时间窗口已经结束了，可以触发计算了。在 Flink 中，这个 东西 就是 watermark。

总结一下，现在认为 watermark 为 Flink 解决了两个问题：

• 标识 Flink 任务的事件时间进度，从而能够推动事件时间窗口的触发、计算。
• 解决事件时间窗口的乱序问题。