Firestorm - 腾讯自研Remote Shuffle Service在Spark云原生场景的实践

图片来源：pexels

背景

Shuffle是分布式计算框架用来衔接上下游任务的数据重分布过程，在分布式计算中所有涉及到数据上下游衔接的过程都可以理解为shuffle。针对不同的分布式框架，shuffle有几种实现形态：

1. 基于文件的pull based shuffle，如MapReduce、Spark。这种shuffle方式多用于类MR的框架，比如MapReduce、Spark，它的特点是具有较高的容错性，适合较大规模的批处理作业。由于实现的是基于文件的shuffle方案，因此失败重跑时只须重跑失败的task、stage，而无须重跑整个job。
2. 基于管道的push based shuffle，比如Flink、Storm等。基于管道的push based shuffle的实现方式多用于Flink、Storm等流式框架，或是一些MPP框架，如Presto、Greenplum等，它的特点是具有较低的延迟和较高的性能，但是比较大的问题是由于没有将shuffle数据持久化下来，因此任务的失败会导致整个作业的重跑。

Shuffle是分布式框架里面最为重要的一个环节，shuffle的性能和稳定性直接影响到了整个框架的性能和稳定性，因此改进shuffle框架是非常有必要的。

业务痛点

Spark在云原生场景下的挑战

基于本地磁盘的shuffle方式，使得Spark在云原生、存储计算分离、在离线环境中有极大的使用限制：

1. 在云原生环境中，serverless化是服务部署的一个目标，但是由于弹性或是抢占情况的发生，节点或是容器被抢占导致executor被kill是一种常态，现有的shuffle无法使计算做到serverless，在节点/容器被抢占时往往需要重新计算shuffle数据，有很高的代价。
2. 在线集群通常只有少量的本地磁盘和大量的CPU core，因此其计算和IO是不平衡的，在这样的集群中根据算力去调度作业时非常容易将磁盘写满。
3. 现在越来越多的数据中心架构采用了存储计算分离的部署方式，在这样的部署方式下基于本地磁盘的shuffle方式首先会遇到的问题是由于本地磁盘的不足导致无法存放shuffle数据；其次，虽然可以通过块存储（RBD）的方式来解决本地存储，但是对于shuffle这样的IO使用模式，使用块存储会带来极大的网络开销和性能问题。

Spark在生产环境的挑战

当前分布式计算平台上大多数的批处理作业是Spark作业，少量是MR作业，相比于MR作业，Spark作业的稳定性较差，而稳定性的问题中至少有一半是由于shuffle的失败造成的。

Shuffle失败导致的任务陷入重试，严重拖慢作业。shuffle fetch失败会导致map任务重跑重新生成shuffle数据，然后再重跑reduce任务，如果reduce任务反复失败会导致map任务需要反复重跑，在集群压力较高的情况下重跑的代价很高，会严重影响作业。

邵铮在SPARK-1529中就有相应的评论，地址如下：

https://issues.apache.org/jira/browse/SPARK-1529

对于超大规模的shuffle数据（T级别以上的shuffle量）的作业，非常难以顺利跑过，这里面的问题有：

1. shuffle数据非常容易将磁盘写满。只有通过反复调整和重试使executor尽量分布到多的节点(anti-affinity)上避免这个问题。
2. 海量的shuffle partition导致非常多的shuffle连接，使得shuffle框架极容易发生超时问题，以及非常高的随机访问IO所导致的问题。

基于本地磁盘的shuffle方式有较为严重的写放大问题和随机IO问题，当任务数量达到10K乃至100K以上时，随机IO的问题非常严重，严重影响了集群的性能和稳定性。

因此实现一个更好的、能解决上述业务痛点的shuffle框架显得尤为重要。

业界趋势

业界在shuffle[1]上也有了多年的探索，围绕各自的业务场景构建了相应的能力，