知乎基于Celeborn优化Spark Shuffle的实践

文章预览

1 背景 知乎Hadoop集群上每天运行着大量的Spark作业，包括调度平台提交的例行作业、Kyuubi提交的Spark SQL作业，每天Spark作业的Shuffle量达到3PB以上，单个Spark作业Shuffle量最大接近100TB，单个Stage 50TB。同时Hadoop集群上每天有1PB左右的MR作业Shuffle，以及DataNode的磁盘IO。 Spark ESS Shuffle在大作业稳定性上更有优势，在Executor意外退出或者GC严重时，已经完成的Map端的Shuffle数据，可以继续被下游读取，不受影响，所以知乎使用的是ESS(External Shuffle Service)作为Spark的Shuffle服务。 但是ESS也有自己的局限性，ESS Shuffle过程中，每个Reducer Task需要去每个上游Mapper Task的输出文件中读取属于自己的Block，从而产生大量的网络连接以及随机IO，大量的随机IO会导致容易达到磁盘的IOPS瓶颈，作业性能和稳定性都会明显下降 [1][2]。在知乎，经常遇到IO负载高的节点导致个别Spark作业S ………………………………