降本增效利器！趣头条Spark Remote Shuffle Service最佳实践

1. 业务场景与现状

趣头条是一家依赖大数据的科技公司，在2018-2019年经历了业务的高速发展，主App和其他创新App的日活增加了10倍以上，相应的大数据系统也从最初的100台机器增加到了1000台以上规模。多个业务线依赖于大数据平台展开业务，大数据系统的高效和稳定成了公司业务发展的基石，在大数据的架构上我们使用了业界成熟的方案，存储构建在HDFS上、计算资源调度依赖Yarn、表元数据使用Hive管理、用Spark进行计算，具体如图1所示：

图1 趣头条离线大数据平台架构图

其中Yarn集群使用了单一大集群的方案，HDFS使用了联邦的方案，同时基于成本因素，HDFS和Yarn服务在ECS上进行了DataNode和NodeManager的混部。
在趣头条每天有6W+的Spark任务跑在Yarn集群上，每天新增的Spark任务稳定在100左右，公司的迅速发展要求需求快速实现，积累了很多治理欠债，种种问题表现出来集群稳定性需要提升，其中Shuffle的稳定性越来越成为集群的桎梏，亟需解决。

2. 当前大数据平台的挑战与思考

近半年大数据平台主要的业务指标是降本增效，一方面业务方希望离线平台每天能够承载更多的作业，另一方面我们自身有降本的需求，如何在降本的前提下支撑更多地业务量对于每个技术人都是非常大地挑战。熟悉Spark的同学应该非常清楚，在大规模集群场景下，Spark Shuffle在实现上有比较大的缺陷，体现在以下的几个方面：

• Spark Shuffle Fetch过程存在大量的网络小包，现有的External Shuffle Service设计并没有非常细致的处理这些RPC请求，大规模场景下会有很多connection reset发生，导致FetchFailed，从而导致stage重算。
• Spark Shuffle Fetch过程存在大量的随机读，大规模高负载集群条件下，磁盘IO负载高、CPU满载时常发生，极容易发生FetchFailed，从而导致stage重算。
• 重算过程会放大集群的繁忙程度，抢占机器资源，导致恶性循环严重，SLA完不成，需要运维人员手动将作业跑在空闲的Label集群。
• 计算和Shuffle过程架构不能拆开，不能把Shuffle限定在指定的集群内，不能利用部分SSD机器。
• M*N次的shuffle过程：对于10K mapper，5K reducer级别的作业，基本跑不完。
• NodeManager和Spark Shuffle Service是同一进程，Shuffle过程太重，经常导致NodeManager重启，从而影响Yarn调度稳定性。

以上的这些问题对于Spark研发同学是非常痛苦的，好多作业每天运行时长方差会非常大，而且总有一些无法完成的作业，要么业务进行拆分，要么跑到独有的Yarn集群中。除了现有面临的挑战之外，我们也在积极构建下一代基础架构设施，随着云原生Kubernetes概念越来越火，Spark社区也提供了Spark on Kubernetes版本，相比较于Yarn来说，Kubernetes能够更好的利用云原生的弹性，提供更加丰富的运维、部署、隔离等特性。但是Spark on Kubernetes目前还存在很多问题没有解决，包括容器内的Shuffle方式、动态资源调度、调度性能有限等等。我们针对Kubernetes在趣头条