摘要:本文整理自阿里云 EMR Spark 团队的周克勇(一锤),在 Spark&DS Meetup 的分享。本篇内容主要分为三个部分:
- 传统 Shuffle 的问题
- Apache Celeborn (Incubating)简介
- 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