推文

@Zen_with_AI · 2026-10-16 03:37

小路带你看大厂架构｜LinkedIn 用 Celeborn 重做 Shuffle 层 LinkedIn 每天跑 30 万多个 Spark 作业，吃掉约 200 PB-hours 算力，占集群利用率 98% 以上。这个量级下，shuffle 是最耗资源、最容易失败的环节：网络流量、磁盘 I/O、作业运行时长都由它主导。 LinkedIn 的 shuffle 演进过三代：原生 Spark（map 输出写本地盘，reduce 去各台机器拉，M×R 个小块）；自研 Magnet（push-based，Spark 3.2 上游贡献，把同 reduce 分区的小块合并成大文件）；现在是 Celeborn，把 shuffle 彻底从计算节点上拆出来。 拆出来的好处有三点。第一，shuffle 数据不再绑在算出它的机器上，节点挂了、维护了，数据还在，副本直接顶上。第二，shuffle 有了独立资源边界，不再和 NodeManager 抢 CPU、内存、磁盘，noisy neighbor 消失。第三，shuffle 容量可以独立于计算扩缩容，用存储优化硬件。 生产化加了不少料：5 节点 Raft 控制平面跨可用区部署，状态用 Apache Ratis 复制；network-aware replication 按网络拓扑和故障域放副本，同一时间只允许一个可用区下线；disruption-aware slot selection 避开即将维护的机器；存储从 HDD 换成 NVMe。 效果：任务失败数较 Magnet 基线降 20 倍，shuffle 总时长降 40%。同一套平台同时服务 Spark 和 Flink，靠 ShuffleManager 扩展点接入，应用不用改代码。 https://www.linkedin.com/blog/engineering/infrastructure/scaling-spark-and-flink-shuffle-at-linkedin-with-apache-celeborn

曝光 29 · 评论 0 · 点赞 1 · 书签 0