一、引言在 Spark、Flink、MapReduce 等大数据计算引擎中Shuffle 往往是作业稳定性和性能的关键瓶颈。随着云原生、弹性伸缩、存算分离和混部调度成为主流传统依赖本地磁盘和 Executor 生命周期的 Shuffle 模式逐渐暴露出资源利用率低、失败恢复成本高、扩缩容受限等问题。Celeborn 的思路是把 Shuffle 数据交给一个独立服务管理。计算引擎的任务不再把 Shuffle 数据只写在本地 Executor 磁盘上而是推送到 Celeborn Worker由 Worker 负责存储、合并、复制和服务下游读取。二、Celeborn介绍Apache Celeborn 是 Apache 顶级项目定位为面向大数据计算引擎的中间数据服务当前重点解决 Shuffle 数据管理问题。它通过 Remote Shuffle Service 的方式将 Shuffle 数据从计算节点生命周期中解耦出来提供独立的 Master、Worker、Client 架构并支持 Spark、Flink Batch、MapReduce 等引擎接入其核心特性包括存算分离、push-based shuffle write、merged shuffle read、高可用和高容错。从工程视角看Celeborn 不是替代 Spark、Flink 或 Hadoop 的计算框架而是位于计算引擎和存储资源之间的 Shuffle 数据服务层。它接管的是中间数据的写入、读取、合并、复制、清理和资源分配让计算引擎可以更专注于任务调度和算子执行。Celeborn 的架构可以分为三个核心组件Master、Worker、Client。Master 负责资源管理并基于 Raft 同步共享状态Worker 处理读写请求并为每个 Reducer 合并数据LifecycleManager 维护每个 Shuffle 的元数据并运行在 Spark Driver 中。Master 更像 Celeborn 集群的“大脑”。它管理 Worker 注册、资源分配、Slot 分配、健康状态和集群元数据在高可用部署中Master 支持基于 Raft 的 HA 模式。Worker 是真正处理数据读写的组件。Map 端任务通过 Client 将 Shuffle 数据推送到 WorkerWorker 负责接收、缓存、刷盘、复制、合并和最终提供给 Reduce 端读取Celeborn 支持本地磁盘也支持 HDFS、S3、OSS 等后端。Client 是计算引擎侧的接入层。Spark 通过配置spark.shuffle.managerorg.apache.spark.shuffle.celeborn.SparkShuffleManager 接入 CelebornFlink 通过shuffle-service-factory.class 或 Hybrid Shuffle 外部 Tier 接入MapReduce 则通过 MapOutputCollector 和 Reduce Shuffle Consumer 插件接入。三、Shuffle 流程Celeborn 的 Shuffle 流程可以理解为“先注册再分配再推送再提交最后读取”。Mapper 懒加载请求 LifecycleManager 注册 ShuffleLifecycleManager 向 Master 请求 SlotsWorker 预留 Slots 并创建文件Mapper 获取 Worker 位置后推送数据Worker 合并并复制数据周期性刷盘Map 任务完成后触发提交Reducer 再请求文件位置并读取数据。这个流程背后的核心收益是把 Shuffle 文件从“散落在 Executor 本地磁盘上的临时副产物”变成“由独立服务管理的中间数据”。当计算资源需要扩缩容时Shuffle 数据不再天然依附于 Executor 存活状态当 Worker 压力较高或磁盘异常时Master 也有机会基于资源状态做更集中化的分配和规避。四、核心特性与优势存算解耦Celeborn 可与 Spark、Flink、MapReduce 等引擎集成使这些引擎向 Celeborn 写入和读取 Shuffle 数据。高可用和容错Master 支持 Raft-based HAWorker 侧支持数据复制、失败重试、磁盘监控、内存水位控制、优雅关闭等机制。多引擎支持Celeborn 支持 Spark 3.0 到 4.2、Flink 1.18 到 2.3、Hadoop MapReduce 3并列出了不同 Java 和 Scala 版本下的兼容矩阵另外Flink引擎当前仅支持批作业。多存储后端Celeborn 可用本地 HDD/SSD也可配置 HDFS、S3、OSS。Celeborn 的优势并不只是“把 Shuffle 放到远端”。它真正解决的是大规模计算集群里 Shuffle 数据的生命周期管理问题。维度传统本地 ShuffleCeleborn Remote Shuffle数据生命周期绑定 Executor 或 Task 本地目录由 Celeborn Worker 独立管理弹性伸缩Executor 释放可能影响 Shuffle 数据更适合动态资源分配和弹性计算容错恢复Executor 丢失可能触发上游重算可通过复制、重试、集中管理降低失败影响资源治理分散在计算节点本地磁盘独立 Shuffle 集群便于容量和健康管理引入成本引擎默认能力架构简单需要部署 Master/Worker并维护服务稳定性性能边界本地读写路径短但易受 Executor 资源竞争影响网络多一跳但可通过合并、复制、集中 I/O 优化收益实际选型时不应简单地认为“Remote Shuffle 一定更快”。它更适合 Shuffle 数据大、任务多、Executor 生命周期不稳定、需要动态资源分配或集群资源混部的场景。如果你的作业规模小、Shuffle 很轻、本地磁盘充足且失败代价低引入独立 Shuffle 服务可能会增加系统复杂度。五、适用场景Celeborn 适合第一类场景大规模 Spark SQL、ETL、Join、聚合、排序等 Shuffle 密集型任务。尤其是存在大宽表 Join、倾斜 Join、超大聚合、长链路 DAG 的场景Shuffle 数据量常常远超单个 Executor 的稳定承载能力。第二类场景是需要动态资源分配或云原生弹性的集群。Spark 自身也长期围绕 Shuffle Tracking、External Shuffle Service、Dynamic Allocation 做演进而 Celeborn 的价值在于让 Shuffle 数据独立于计算容器生命周期。第三类场景是存算分离或混部集群。Celeborn 为异构环境中的在线和离线服务混部提供了基础条件并帮助提升在线服务和大数据集群的联合调度与利用率。第四类场景是希望集中治理 Shuffle 资源的组织。比如为 Shuffle 单独规划 SSD、本地盘、HDFS 或对象存储后端统一监控 Worker 磁盘健康、网络吞吐、复制失败、应用 Shuffle 占用等指标而不是让每个 Spark Executor 各自处理本地临时数据。六、部署使用Celeborn 最小部署由 Master 和 Worker 组成。最小化部署流程 1. 下载并解压 apache-celeborn-VERSION-bin.tgz 2. 配置存储目录 celeborn.worker.storage.dirs$CELEBORN_HOME/shuffle 3. 启动 Master ./sbin/start-master.sh 4. 启动 Worker ./sbin/start-worker.sh celeborn://Master IP:Master Port 5. 接入计算引擎 Spark / Flink / MapReduce client jar engine config生产部署一般不建议只部署单 Master建议配置多个 Master endpoint并启用celeborn.master.ha.enabled true同时为每个 Master 配置唯一节点 ID、RPC 端口、Ratis 端口和 Raft 存储目录。Spark 接入时需要把对应 Spark 大版本的 Celeborn client jar 放入$SPARK_HOME/jars/ 并设置spark.shuffle.manager org.apache.spark.shuffle.celeborn.SparkShuffleManager 、spark.serializer org.apache.spark.serializer.KryoSerializer 、spark.celeborn.master.endpoints 等配置建议启用 AQE并在使用 Celeborn 时将spark.sql.adaptive.localShuffleReader.enabled 设置为false 以获得更好的 Celeborn 性能表现。一个典型 Spark 配置片段如下spark.shuffle.manager org.apache.spark.shuffle.celeborn.SparkShuffleManager spark.serializer org.apache.spark.serializer.KryoSerializer spark.celeborn.master.endpoints clb-1:9097,clb-2:9097,clb-3:9097 spark.shuffle.service.enabled false spark.celeborn.client.push.replicate.enabled true spark.sql.adaptive.enabled true spark.sql.adaptive.skewJoin.enabled true spark.sql.adaptive.localShuffleReader.enabled falseFlink 接入时要先确认你的作业类型Celeborn 当前只支持 Flink batch jobs对于 Flink 1.16 及以上可用 Remote Shuffle Service 方式设置shuffle-service-factory.class: org.apache.celeborn.plugin.flink.RemoteShuffleServiceFactory 和execution.batch-shuffle-mode: ALL_EXCHANGES_BLOCKING 对于 Flink 1.20 及以上也可通过 Hybrid Shuffle 外部 remote tier 集成 Celeborn。MapReduce 接入则需要把 Celeborn MR client jar 加入 MapReduce 和 YARN classpath并配置mapreduce.job.map.output.collector.class 为org.apache.hadoop.mapred.CelebornMapOutputCollector 配置mapreduce.job.reduce.shuffle.consumer.plugin.class 为org.apache.hadoop.mapreduce.task.reduce.CelebornShuffleConsumer 。七、选型建议如果你已经在大规模使用 Spark SQL 或离线 ETL并且经常遇到 Shuffle 文件丢失、Executor 退出导致重算、动态资源分配困难、磁盘 I/O 抖动或大作业长尾问题Celeborn 值得进入技术验证范围。它的价值在于把 Shuffle 从“每个作业自己处理的临时文件问题”提升为“集群级中间数据服务问题”。但如果你的集群规模不大Shuffle 数据量有限任务失败成本低或者团队尚未建立稳定的监控、容量规划和独立服务运维能力直接引入 Celeborn 可能会增加复杂度。Celeborn 自身也需要高可用部署、磁盘规划、网络规划、版本兼容治理和故障排查机制。一个务实的落地路径是先选择几类 Shuffle 重、失败代价高、运行频率稳定的 Spark Batch 作业做灰度验证。验证指标可以包括作业耗时、失败率、Executor 重算次数、Shuffle fetch 失败、Worker 磁盘利用率、网络吞吐、Celeborn Master/Worker 稳定性和升级恢复表现。八、与Uniffle的异同两者都是 Apache 体系下的 Remote Shuffle Service目标都是把 Shuffle 从计算节点本地磁盘中解耦出来。Celeborn 更像“Master Worker 引擎侧 Client”的远程 Shuffle 集群。Master 负责资源管理和共享状态同步Worker 负责读写、合并、复制、刷盘Spark 场景中的 LifecycleManager 运行在 Driver 内并维护 Shuffle 元数据。Uniffle 更强调“Coordinator Shuffle Server 可选远端存储”的分配模型。Coordinator 收集 Shuffle Server 心跳和状态决定作业使用哪些 Shuffle ServerShuffle Server 接收 Shuffle 数据、合并并写入本地或远端存储。Celeborn Spark / Flink / MR Client | v ---------------- | Master | 资源管理、slot 分配、HA 状态同步 ---------------- | v ---------------- | Worker | push / fetch / merge / replicate / persist ---------------- | v Local Disk / HDFS / S3 / OSS Uniffle Spark / MR / Tez Client | v ---------------- | Coordinator | 收集 Shuffle Server 状态、分配节点、下发动态配置 ---------------- | v ---------------- | Shuffle Server | receive / merge / write / serve ---------------- | v Memory / LocalFile / HDFS 等你的场景更建议优先评估 Spark 3.x/4.x 为主并且希望跟进较新的 Spark 版本CelebornFlink Batch 是重要场景CelebornHadoop MapReduce Tez 是重要场景Uniffle希望 Remote Shuffle 服务兼顾 Spark、Flink Batch、MapReduceCeleborn希望强化 Coordinator 动态客户端配置、远端存储路径分配、访问控制候选列表Uniffle希望使用 Raft-based Master HA并以 Master/Worker 模型统一管理 Shuffle 资源Celeborn已经有较多 HDFS 混合存储、Memory Local Remote Storage 经验Uniffle选 Celeborn Spark/Flink Batch/MapReduce 通用性更重要想要较新的 Spark/Flink 版本覆盖偏向 Master/Worker Raft HA 的架构。选 Uniffle Spark MapReduce/Tez 更重要偏向 Coordinator 分配模型、Memory/Local/Remote 混合存储、动态客户端配置和远端 Merge。不要只看“谁更快” 两者性能都依赖网络、磁盘、存储后端、分区规模、数据倾斜和客户端参数必须用真实作业压测后再定。