Spark内容分享(二十九)：京东 Spark 自研 Remote Shuffle Service 在大促中的应用实践

目录

前言

ESS问题及现状

RSS目标与挑战

RSS架构和实现

Shuffle Write

Shuffle Read

RSS性能表现

RSS在京东大促期间优化案例

总结与展望

---

前言

本文讨论了京东Spark计算引擎研发团队关于自主研发并落地Remote Shuffle Service，助力京东大促场景的探索和实践。近年来，大数据技术在各行各业的应用越来越广泛，Spark自UCBerkeley的AMP实验室诞生到如今3.0版本的发布，已有十年之久，俨然已经成为大数据计算领域名副其实的老将。虽经过不断的迭代和优化，Spark功能日趋成熟与完善，但在性能及稳定性方面，仍然还有很多可以提升的地方。Shuffle过程作为MapReduce编程模型的性能瓶颈，就是其中重点之一。我们希望在京东超大规模数据体量及复杂业务场景的背景下，通过自研并落地Remote Shuffle Service服务，解决External Shuffle Service中存在的现有问题，打造稳定高效的JDSpark计算引擎，助力京东大促过程中的一些应用实践，能够给大家提供一些思路和启发，同时也欢迎大家多多交流，给我们提出宝贵建议。

ESS问题及现状

在此之前，相当一部分公司在使用Spark计算引擎时，对于Shuffle Service的支持采用了社区的External Shuffle Service解决方案，京东原来的架构也不例外。该方案需要在所有Executor计算节点所在的NodeManager上部署一个External Shuffle Service服务，当Executor针对Shuffle过程进行相关数据处理时，Shuffle Write阶段会先将Shuffle数据写到本地存储介质，Shuffle Read阶段读取Shuffle数据文件时不再需要直接请求Executor，转而请求与Executor位于同一节点上的External Shuffle Service服务，获取Shuffle数据文件，完成Shuffle过程的数据传递。这样就可以解决由于Executor意外终止造成的数据丢失问题，继而实现对Spark做动态资源功能的支持。但该方案在架构及使用上存在一些限制与不足：

1. 架构不清晰：External Shuffle Service必须与Executor计算节点所绑定，两者位于同一个NodeManager上，这就造成了架构不清晰、系统健壮性不高的问题，同时不利于K8s等容器级别框架方案的部署与使用。

2. 资源利用低：Executor的内存使用会根据任务的具体情况而进行调节，目的是为了避免Spill过程造成的Overhead，但在一些场景下可能会存在内存资源较早的先于CPU资源而耗尽的情况，容易造成集群资源利用率低的问题。

3. 缺乏整体性：不同Executor的Shuffle数据分散在不同的Node上，数据文件的存储及管理较为分散，缺乏整体性，比如：不利于针对同一个Stage的Ta