Apache Flink BATCH执行模式内部机制相关技术问询

我们近期基于Apache Flink的BATCH执行模式搭建了处理有界数据集的ETL任务，运行效果良好，但作为初学者，希望澄清对Flink的理解并了解遗漏的细节。

部署架构 #

作业逻辑为：FileSource -> map() -> AssignTimestamps() -> filter() -> keyBy -> TumblingWindow -> FileSink，运行在AWS KDA的Flink 1.20版本上，采用DataStream API。

现有底层理解与疑问 #

我们自定义了FileSource的FileEnumerator，从预计算清单文件生成FileSourceSplits；KDA集群内的单例JobManager启动时调用该自定义FileEnumerator生成分片，存入队列后通过默认FileAssigner按FIFO分发给各TaskManager的SourceReaders，SourceReaders通过元数据路径获取实际数据。

我们了解到批处理模式不使用checkpoint、背压，无需RocksDB，按键排序串行处理，任务等待上游生成中间结果，但仍有以下疑问：

1. 中间结果存储在磁盘还是其他位置？
2. 观察到首个任务完成后结果并非一次性传输至下一个算子，而是流式传输，这是否是Flink批处理基于有界数据集的流式实现？
3. 无法理解批处理为何无需RocksDB，希望得到相关解释与指引。

解答 #

1. 中间结果的存储位置 #

Flink批处理模式下，中间结果默认存储在TaskManager本地磁盘的临时目录中（可通过taskmanager.tmp.dirs配置指定）。当算子间需要shuffle数据时（比如keyBy操作），上游算子会将数据按key分区后写入本地磁盘文件，下游算子再从这些文件中读取对应分区的数据。如果作业配置了分布式缓存或外部存储，部分场景下也可能利用这些存储，但默认是本地磁盘。

2. 批处理的流式传输现象 #

没错，Flink的批处理确实是基于有界数据集的流式实现，也就是流批一体架构的体现。虽然是批处理模式，但Flink不会等上游所有任务完全结束才开始下游处理，而是采用流水线式执行：上游算子处理完一部分数据后，就会将这部分数据发送给下游算子，无需等待全量数据处理完毕。这种设计既能保证批处理的正确性（因为数据集有界，最终能处理完所有数据），又能提升资源利用率和执行效率。

3. 批处理无需RocksDB的原因 #

RocksDB在Flink中主要用于状态的持久化和增量存储，核心服务于流处理场景：

• 流处理中数据是无界的，需要持续维护状态（比如窗口聚合的中间结果），且状态可能持续增长，RocksDB可以将部分状态写入磁盘，缓解内存压力。
• 批处理模式下，数据集是有界的，所有状态（比如窗口聚合的中间结果）可以完全存放在TaskManager的内存中——因为数据总量已知且有限，不会出现状态无限增长的情况。即使数据量较大，Flink会通过本地磁盘临时文件暂存中间shuffle数据，但这和RocksDB的状态持久化不是一回事。另外，批处理不需要checkpoint（作业失败后可从头重新执行），自然也不需要RocksDB来存储checkpoint状态。

内容的提问来源于stack exchange，提问作者JackatWaterloo