每个subtask都提交一份快照到hdfs，会把10个小的快照合并成一个大的吗？谁来合并？
直接给你结论，大白话讲透
核心答案
不会自动把 10 个 Subtask 的小快照，合并成一个大文件 10 个并行度，就是 HDFS 上 10 份独立快照目录 / 文件 ，永远保持分开，不合并。
一、谁都不会去合并
- JobManager 不合并
- TaskManager 不合并
- Flink 框架本身不做全局合并
为什么不合并？Flink 设计原则：快照、恢复、故障迁移、扩容缩容，全部以 Subtask 为最小独立单元一旦把 10 个子任务快照合成一个大文件：
- 单个 Subtask 挂了，没法只恢复自己那一小块
- 必须加载整个大文件，浪费 IO、内存
- 版本管理、增量快照、并发 CK 全乱套
👉 所以架构上刻意不合并 ，永远保持每个 Subtask 快照独立存放。
二、HDFS 上实际长什么样
并行度 = 10 → 一次 Checkpoint 在 HDFS 里：
plaintext
/flink/checkpoints/jobid/ck-123/
/subtask-0/
/subtask-1/
/subtask-2/
...
/subtask-9/10 个独立子目录，各存各的状态文件，互不合并、互不干扰。
三、那恢复的时候怎么凑齐整个作业状态？
很简单：恢复时，10 个 Subtask 各自读取自己对应的那一份快照
- Subtask0 读 subtask-0 目录
- Subtask1 读 subtask-1 目录......各自加载、各自恢复，拼起来就是完整作业状态。
是 "分头加载、逻辑拼成整体"，不是 "物理合并成一个大文件"。
四、唯独一个例外：RocksDB 增量快照
增量快照也不合并多个 Subtask，只是：单个 Subtask 内部：
- 全量快照 + 后续只存增量变更减少单个 subtask 自己的存储体积，不跨 subtask 合并。
五、回到你最关心的 BroadcastState
并行度 10 → BroadcastState 本来 10 份内容一模一样
- 照常 10 个子任务各自上传一份快照到 HDFS
- 默认还是 10 份重复文件，不合并
- Flink1.15+ 快照复用：物理只存 1 份，其他 9 个做引用 逻辑上还是 10 个 subtask 目录，物理文件只一份，逻辑不分、物理省空间，但也不合并成一个大快照。
六、面试背诵版
每个 Subtask 各自独立提交快照到 HDFS，框架不会把多个子任务快照合并成一个大文件； Flink 以 Subtask 为最小快照和恢复单元，保持各自独立存储，故障重启、扩容缩容只加载对应子任务快照； 恢复时各子任务分别读取自己的快照，逻辑拼接成完整作业状态，而非物理合并。
RocksDB 增量快照时，首次全量快照是每个subtask分开的吗？后续增量状态也是每个subtask分开的？
100% 正确、最终答案
是的！完全正确！ RocksDB 增量快照，不管是第一次全量，还是后面 N 次增量，全部都是：每个 subtask 自己一份、完全独立、互不合并、互不共享！
我给你用最清晰、最肯定的方式讲死👇
1. 第一次全量快照
每个 subtask 独立上传自己的全量状态
- 并行度 = 10
- → HDFS 上 10 份独立全量快照
- 互不干扰、不合并、不共享
即使是 BroadcastState（10 份内容一样）→ 也会存 10 份独立全量（除非开了 Flink 1.15+ 快照复用）
2. 后续增量快照
依然是每个 subtask 自己上传自己的增量
- 每个 subtask 只记录自己的：
- 新产生的 SST 文件
- 删了哪些旧文件
- 每个 subtask 增量 独立、分开、不共享
并行度 10 → 10 份独立增量链
3. 最关键结论（面试必背）
RocksDB 增量快照 = 单个 subtask 自己的增量， 不是全局增量， 不是跨 subtask 共享， 不是合并成一个大增量。
4. 一句话总结（你可以直接背）
RocksDB 增量快照，第一次全量是每个 subtask 独立一份； 后续所有增量快照，也依然是每个 subtask 独立一份、独立上传、独立存储； 所有 subtask 之间完全隔离，不合并、不共享、不交叉。