Spark+Celeborn：更快，更稳，更弹性

摘要：本文整理自阿里云 EMR Spark 团队的周克勇（一锤），在 Spark&DS Meetup 的分享。本篇内容主要分为三个部分：

1. 传统 Shuffle 的问题
2. Apache Celeborn （Incubating）简介
3. Celeborn 在性能、稳定性、弹性上的设计

一、传统 Shuffle 的问题

Apache Spark 是广为流行的大数据处理引擎，它有很多使用场景: Spark SQL、批处理、流处理、MLLIB、GraphX 等。在所有组件下是统一的 RDD 抽象，RDD 血缘通过两种依赖关系描述，窄依赖和宽依赖。其中宽依赖是支撑复杂算子（Join, Agg 等）的关键，而宽依赖实现机制就是 Shuffle。

传统的 Shuffle 实现如上图中间部分所示，每个 Mapper 对 Shuffle Output 的数据，根据 Partition ID 做排序，然后把排序好的数据和索引写入本地盘。Shuffle Read 阶段，Reducer 从所有 Mapper 的 Shuffle 文件里读取属于自己的 Partition 数据。但这种实现有如下几个缺陷：

• 第一，依赖大容量的本地盘或云盘存储 Shuffle 数据，数据需要驻留直至消费完成。这就限制了存算分离，因为存算分离架构下，计算节点通常不希望有大容量的本地盘，希望计算结束就可以释放节点。
• 第二，Mapper 做排序会占用较大内存，甚至触发堆外排序，引入额外的磁盘 IO。
• 第三，Shuffle Read 有大量的网络连接，逻辑连接数是 m×n。
• 第四，存在大量的随机读盘。假设一个 Mapper 的 Shuffle 数据是 128M，Reducer 的并发是 2000，那么每个文件将会被读 2000 次，每次只随机读 64k，这就很容易达到磁盘 IOPS 的瓶颈。
• 第五，数据单副本，容错性不高。

以上五点缺陷最终导致不够高效、不够稳定以及不够弹性。

二、Apache Celeborn (Incubating)

Apache Celeborn （Incubating）是我们团队早期为了解决上述问题开发的 Remote Shuffle Service，已经于2022 年 10 月捐赠给了 Apache 基金会。Celeborn 的定位是大数据引擎统一中间数据服务，它是引擎无关的，并且除了支持 Shuffle，未来还会支持 Spilled data，这样计算节点就能真正解除对大容量本地盘的依赖。

在正式介绍 Celeborn 设计之前，简单介绍一些历史。Celeborn 最早诞生于 2020 年，当时的名字是 Remote Shuffle Service，主要为了满足客户需求，2021 年 12 月正式对外开源。开源之后我们吸引了来自小米、Shopee、网易等开发者共建，其中很多人已经成为了核心贡献者。

2022 年 10 月正式进入 Apache 孵化器，截至目前我们积累了 600+的 commits， 32 个 contributor，330+的 star，也希望更多感兴趣的开发者参与共建。

三、Celeborn 的性能、稳定性、弹性

Celeborn 针对性能提升的设计，主要包括核心设计、如何对接 Spa