大数据计算引擎常用的 Pull-Based Sort Shuffle 方案实现机制存在缺陷,在大规模生产环境下经常因为 Shuffle 问题影响作业稳定性。在此背景下,字节跳动自研了 Cloud Shuffle Service,提供比原生方案稳定性更好、性能更高、更弹性的数据 Shuffle 能力,同时也为存算分离/在离线混部等场景提供了 Remote Shuffle 解决方案。
Cloud Shuffle Service(以下简称CSS) 是字节自研的通用 Remote Shuffle Service 框架,支持 Spark/FlinkBatch/MapReduce 等计算引擎,提供了相比原生方案稳定性更好、性能更高、更弹性的数据 Shuffle 能力,同时也为存算分离/在离线混部等场景提供了 Remote Shuffle 解决方案。
开源背景
在大数据计算引擎中,Pull-Based Sort Shuffle 是一种常见的 Shuffle 方案,比如 Spark/MapReduce/FlinkBatch (高于1.15版本)等都将 Sort Shuffle 作为引擎默认方案,但是 Sort Shuffle 实现机制有一定的缺陷,在大规模生产环境下经常因为 Shuffle 问题影响作业稳定性。
以 Spark 的 Sort Shuffle 为例:
-
将多个 Spill 文件合并成一个文件,会额外消耗读写 IO;
-
假设有 m 个 MapTask & n 个 ReduceTask,会产生 m*n 个网络链接,当数量特别多时:
-
大量的网络请求会导致 Shuffle Service 容易形成积压;
-
Shuffle Service 会产生大量的随机读取,容易导致 IO 瓶颈,特别是 HDD 集群;
-
-
Shuffle Service 无法做到 Application 的资源隔离,当有一个异常作业时,可能会影响同一个 Shuffle Service 节点上其它所有作业,问题容易放大;
-
MapTask 生成的 Shuffle Data File 只存储一份到本地,当磁盘坏了也会导致数据丢失,同样引起 FetchFailed 问题;
-
Shuffle Data File 写到本地磁盘的方式,依赖计算节点上的磁盘,无法做到存算分离
-
受限 HDD 磁盘 IO 能力/磁盘坏等情况,导致大量的 Shuffle FetchFailed 引起的作业慢/失败/Stage 重算等问题,影响稳定性&资源利用率
-
External Shuffle Service (以下简称ESS) 存算无法分离,遇到磁盘容量低的机器经常出现磁盘打满影响作业运行
Cloud Shuffle Service 介绍
CSS 架构
-
CSS Worker
-
CSS Master
-
ZooKeeper
CSS 特性
-
多引擎支持
-
PartitionGroup 支持
-
高效统一的内存管理
-
容错处理
Push 失败:当触发 Spill 进行 Push PartitionGroup 数据时,每次 Push 的数据大小为 4MB(一个Batch),当某次 Push batch 失败时,并不影响之前已经 Push 成功的数据,只需要重新分配节点(Reallocate)继续 Push 当前失败的数据以及后续还未 Push 的数据,后续 ReduceTask 会从新老节点读取完整的 Partition 数据;
多副本存储:ReduceTask 从 CSS Worker 读取某个 Partition 数据是按照 Batch 粒度进行拉取的,当 CSS Worker 异常(如网络问题/磁盘坏等)导致无法获取该 Batch 数据,可以继续选择另外一个副本节点继续读取该 Batch 以及后续 Batch 的数据;
数据去重:当作业开启 Speculative 推测执行会有多个 AttempTask 并发跑,需要在读取的时候进行去重。在 Push Batch 的时候,会给 Batch 数据加上 Header 信息,Header 信息中包含 MapId + AttempId + BatchId 等信息,ReduceTask 读取时可以根据这些 ID 信息进行去重。
-
Adaptive Query Execution(AQE) 适配
CSS 性能测试
未来规划
-
支持 MapReduce/FlinkBatch 引擎;
-
CSS 集群增加 ClusterManager 服务角色,管理 CSS Worker 的状态&负载信息,同时将当前 CSS Master 分配 CSS Worker 的功能提到 ClusterManager;
-
基于异构机器(如磁盘能力不同)/负载 等维度的 CSS Worker 分配策略。