一、Flink 基础与架构（1~15）
1. Flink 为什么适合实时计算？
标准答案
Flink 是真正的流式计算引擎：
- event-by-event
- 非微批
- 毫秒级延迟
- 高吞吐
- 支持状态管理
相比 Spark Streaming：
Spark Streaming：
Micro BatchFlink：
Native Streaming因此：
- 延迟更低
- 更适合实时风控
- 实时指标
- 实时推荐
2. Flink 的核心组件有哪些？
标准答案
JobManager
负责：
- 作业调度
- checkpoint协调
- failover
TaskManager
负责：
- 执行 task
- 管理 slot
- state计算
Dispatcher
提交 job。
ResourceManager
资源管理。
3. Flink 的 slot 是什么？
标准答案
slot 是 TaskManager 中的资源执行单元。
例如：
1 TaskManager
= 4 slotsslot 共享：
不同 operator chain 可共享 slot。
4. 什么是 Operator Chain？
标准答案
多个 operator 合并到同一个线程执行。
例如：
source -> map -> filter可能 chain 在一起。
好处
- 减少线程切换
- 减少序列化
- 提升性能
5. Flink 的并行度如何决定？
标准答案
并行度来源：
1）env level
env.setParallelism(4)2）operator level
map.setParallelism(2)3）slot 数量限制
6. Flink 的数据流模型是什么？
标准答案
Flink 本质：
DAG数据流图。
operator：
- source
- transform
- sink
组成 pipeline。
7. Flink 为什么性能高？
标准答案
主要：
1）流式模型
2）Operator Chain
3）内存管理优秀
4）异步 checkpoint
5）本地状态管理
8. Flink 支持哪些时间语义？
标准答案
1）Processing Time
机器时间。
2）Event Time
事件产生时间。
生产最常用。
3）Ingestion Time
进入 Flink 时间。
现在较少使用。
9. 为什么 Event Time 更重要？
标准答案
因为：
生产环境存在：
- 网络延迟
- 数据乱序
- 重放
Event Time 更符合业务真实时间。
10. Flink 如何处理乱序数据？
标准答案
通过：
Watermark控制事件时间推进。
11. Watermark 本质是什么？
高频。
标准答案
Watermark：
"当前认为某时间之前的数据已经基本到齐"
例如：
watermark = 10:00说明：
10:00 之前窗口可关闭。
12. Watermark 为什么会导致延迟？
标准答案
因为需要等待：
allowed lateness等待迟到数据。
Watermark 越保守：
- 准确率越高
- 延迟越大
13. 什么是 Late Data？
标准答案
事件时间：
小于 watermark 的数据。
例如：
watermark=10:00
数据=09:58属于迟到数据。
14. 如何处理迟到数据？
标准答案
allowedLateness
允许窗口再次更新。
side output
输出到旁路流。
15. Flink 为什么适合状态计算？
标准答案
Flink：
- 原生 state 管理
- checkpoint
- exactly-once
- 本地 state
非常适合：
- 实时统计
- CEP
- 实时画像
二、Checkpoint 与 Exactly Once（16~35）
16. Flink Checkpoint 是什么？
标准答案
Checkpoint：
分布式一致性快照
用于：
- 故障恢复
- exactly-once
17. Checkpoint 原理是什么？
超高频。
标准答案
基于：
Chandy-Lamport
分布式快照算法。
通过：
Barrier在数据流传播。
18. Barrier 是什么？
标准答案
Barrier：
特殊标记。
表示：
checkpoint 边界19. Barrier Alignment 是什么？
标准答案
多输入流：
需要等所有 barrier 到齐。
例如：
stream1 barrier 到了
stream2 没到需要等待。
20. 为什么会发生 Barrier 对齐等待？
标准答案
因为：
不同流速不同。
导致：
慢流阻塞21. Unaligned Checkpoint 是什么？
标准答案
避免 barrier alignment。
直接：
channel buffer 一起checkpoint适合：
- backpressure严重
22. Exactly Once 如何实现？
超高频。
标准答案
核心：
checkpoint + state + source offset同时保存。
恢复时：
一起恢复。
23. At Least Once 和 Exactly Once 区别？
标准答案
At Least Once
可能重复。
Exactly Once
不重复不丢失。
24. 两阶段提交如何实现 Exactly Once？
标准答案
Sink：
pre-commit
checkpoint 前预提交。
commit
checkpoint 成功后真正提交。
25. Kafka Sink 如何实现 Exactly Once？
标准答案
通过：
transactional.idKafka transaction。
26. Checkpoint 为什么失败？
高频场景题。
标准答案
1）state 太大
2）网络问题
3）backpressure
4）sink阻塞
5）checkpoint timeout
27. 如何优化 Checkpoint？
标准答案
增量 checkpoint
RocksDB
checkpoint interval 调整
state TTL
28. savepoint 和 checkpoint 区别？
超高频。
标准答案
checkpoint
自动。
用于恢复。
savepoint
人工触发。
用于：
- 升级
- 迁移
29. savepoint 能否跨作业恢复？
标准答案
可以。
但：
- operator uid 不能变
- state schema兼容
30. 什么是增量 Checkpoint？
标准答案
只保存：
变化部分state减少：
- 网络IO
- checkpoint时间
三、State 状态管理（36~55）
31. Flink State 有哪些类型？
标准答案
Keyed State
keyBy 后使用。
Operator State
operator 级别。
32. Keyed State 有哪些？
标准答案
ValueState
ListState
MapState
ReducingState
AggregatingState
33. Keyed State 为什么必须 keyBy？
标准答案
因为：
state 按 key 分区。
34. Operator State 用于什么？
标准答案
适合：
- source offset
- broadcast state
35. Broadcast State 使用场景？
超高频。
标准答案
适合：
- 配置动态下发
- 实时规则
- 小维表
36. Flink 为什么需要 State Backend？
标准答案
管理：
- state存储
- checkpoint
37. 常见 State Backend 有哪些？
标准答案
HashMapStateBackend
EmbeddedRocksDBStateBackend
生产主流。
38. RocksDB 为什么适合大状态？
超高频。
标准答案
因为：
state 存本地磁盘。
避免 JVM heap 过大。
39. RocksDB 缺点是什么？
标准答案
序列化开销
延迟高于 Heap
40. State TTL 是什么？
标准答案
状态过期机制。
避免：
state 无限增长41. State 为什么会爆炸？
标准答案
key无限增长
没有TTL
热key
42. 什么是热 Key？
标准答案
某个 key 数据量远超其他 key。
导致：
- 数据倾斜
- task负载不均
43. 如何解决热 Key？
标准答案
key打散
局部聚合
增加并行度
四、Window（56~70）
44. Flink Window 有哪些？
标准答案
Tumbling Window
滚动窗口。
Sliding Window
滑动窗口。
Session Window
会话窗口。
45. Tumbling 和 Sliding 区别？
标准答案
Tumbling
不重叠。
Sliding
可重叠。
46. Session Window 使用场景？
标准答案
用户行为分析。
例如：
30分钟无操作
session结束47. Window 为什么占用大量 state？
标准答案
窗口内数据需要缓存。
48. Window Join 为什么容易 OOM？
标准答案
因为：
双流窗口数据都要缓存。
49. 如何优化 Window？
标准答案
reduce/aggr 提前聚合
缩短窗口
state ttl
50. Window 什么时候触发？
标准答案
主要：
- watermark
- trigger
五、Kafka + Flink（71~85）
51. Flink Kafka Source 如何保证 Exactly Once？
标准答案
checkpoint 时：
offset 一起保存恢复时：
offset 回滚。
52. Kafka Rebalance 为什么影响稳定性？
标准答案
会导致：
- 消费暂停
- 重复消费
- 延迟升高
53. Kafka 消息积压如何处理？
标准答案
增加 partition
增加 consumer
提升 sink性能
54. Kafka 为什么不能无限增加 partition？
标准答案
因为：
- controller压力
- 文件句柄
- 网络开销
55. Flink 消费 Kafka 延迟高如何排查？
标准答案
看lag
看backpressure
看GC
看下游sink
六、生产问题（86~100）
56. Flink Backpressure 是什么？
标准答案
下游处理不过来。
导致：
数据反向阻塞57. 如何定位 Backpressure？
标准答案
Flink UI：
- 红色严重
- 黑色正常
58. Backpressure 常见原因？
标准答案
sink慢
网络
数据倾斜
GC
59. Flink OOM 原因？
标准答案
state太大
window缓存
RocksDB内存
JVM参数不合理
60. 如何优化 Flink 性能？
标准答案
operator chain
并行度
RocksDB调优
async io
批量sink
61. 为什么会数据倾斜？
标准答案
key分布不均
热点数据
62. 如何做实时维表 Join？
标准答案
broadcast
async io
temporal join
63. Async IO 为什么重要？
标准答案
避免同步阻塞。
提升吞吐。
64. Flink CDC 原理？
北京现在极高频。
标准答案
snapshot阶段
全量读取。
binlog阶段
增量同步。
65. CDC 为什么会导致抖动？
标准答案
snapshot 阶段压力大。
66. 实时数仓为什么需要去重？
标准答案
Kafka：
- 重复消费
- 重试
都会导致重复。
67. 如何做实时去重？
标准答案
state
Redis
bitmap
68. 什么是流批一体？
标准答案
同一套：
- 存储
- 元数据
- SQL
同时支持：
- batch
- streaming
69. 为什么 Iceberg/Hudi/Paimon 很重要？
标准答案
支持：
- ACID
- schema evolution
- streaming read/write
70. Flink SQL 为什么越来越重要？
标准答案
降低开发门槛。
适合：
- 实时ETL
- 指标计算
七、高级架构题（加分）
71. 如何设计实时数仓？
72. 如何设计统一实时平台？
73. 如何做多租户隔离？
74. 如何做实时数据质量监控？
75. 如何做实时血缘？
76. 如何设计实时指标体系？
77. 如何支持千级 Flink Job？
78. 如何设计动态规则引擎？
79. 如何实现实时画像？
80. 如何做 AI 实时特征平台？
八、北京大厂现在特别爱问的"灵魂题"
81. Flink 最大的坑是什么？
建议回答：
- state膨胀
- checkpoint抖动
- backpressure传导
82. 你线上最难的问题是什么？
一定准备：
- 排查过程
- 指标
- root cause
- 优化结果
83. 为什么不用 Spark Streaming？
84. 为什么不用 Kafka Streams？
85. 实时和离线口径不一致怎么办？
86. 你如何保证数据一致性？
87. 如何做 SLA？
88. 如何做实时监控？
89. 如何做任务自动恢复？
90. 如何做灰度发布？
九、Leader / 架构师级别
91. 如何做流量治理？
92. 如何做成本优化？
93. 如何做资源隔离？
94. 如何做平台化？
95. 如何做低代码实时开发？
96. 如何做统一元数据？
97. 如何做统一权限？
98. 如何做多机房容灾？
99. 如何做 AI Agent 数据总线？
100. 未来实时计算的发展方向？
建议回答：
- 流批一体
- AI Native Data Platform
- 实时 Feature Store
- Vector Streaming
- Agent Event Streaming
最后：北京面试真正的重点
现在北京的大厂/独角兽：
真正想招的是：
懂生产问题的人而不是：
只会写API的人所以你准备时：
一定重点准备：
1. 原理
- checkpoint
- barrier
- watermark
- state
2. 线上问题
- OOM
- backpressure
- 延迟
- 倾斜
3. 架构
- 实时数仓
- CDC
- 流批一体
4. AI + 实时数据
这个会越来越重要。