在2014 Sort Benchmark国际大赛上，百度成功夺冠，其幕后英雄无疑卓越的Shuffle机制，在孙垚光的分享中，我们对Shuffle的发展、细节和未来有了一次深度的接触。
Shuffle简介
孙垚光表示，简单来说，Shuffle就是按照一定的分组和规则Map一个数据，然后传入Reduce端。不管对于MapReduce还是Spark，Shuffle都是一个非常重要的阶段。然而，虽然Shuffle解决的问题相同，但是在Spark和MapReduce中，Shuffle流程（具体时间和细节）仍然存在一定的差别：
Baidu Shuffle发展历程
通过孙垚光了解到，Shuffle在百度的发展主要包括两个阶段：跟随社区和独立发展。从2008年百度的MapReduce/Hadoop起步开始，百度就开始跟随社区，使用社区版本，期间的主要工作包含Bug修复和性能优化两个方面（增加内存池、减少JVMGC，传输Server由Jetty换Netty，及批量传输、聚合数据等方面）。
分离了shuffle和Map/Reduce
在2012年开始，Baidu Shuffle开启独立发展阶段，主要源于下一代离线计算系统的开发，Shuffle被抽离为独立的ShuffleService服务，从而提高了集群资源的利用率。
截止此时，不管是社区版本（MapReduce/Spark），还是百度研发的ShuffleService，它们都是基于磁盘的PULL模式。基于磁盘，所有Map的数据都会放到磁盘，虽然Spark号称内存计算，但是涉及到Shuffle时还是会写磁盘。基于PULL，所有数据在放到Map端的磁盘之后，Reduce在使用时还需要主动的拉出来，因此会受到两个问题影响：首先，业务数据存储在Map端的服务器上，机器宕机时会不可避免丢失数据，这一点在大规模分布式集群中非常致命；其次，更重要的是，Shuffle阶段会产生大量的磁盘寻道（随机读）和数据重算（中间数据存在本地磁盘），举个例子，某任务有1百万个Map，1万个Reduce，如果一次磁盘寻道的时间是10毫秒，那么集群总共的磁盘寻道时间= 1000000 ×10000 ×0.01 = 1亿秒。
New Shuffle
基于这些问题，百度设计了基于内存的PUSH模式。新模式下，Map输出的数据将不落磁盘，并在内存中及时地Push给远端的Shuffle模块，从而将获得以下提升：
New Shuffle的优势
New Shuffle架构
如图所示，蓝色部分为New Shuffle部分，主要包含两个部分：数据写入和读取的API，Map端会使用这个接口来读取数据，Reduce会使用这个接口来读取数据；其次，最终重要的是，服务器端使用了典型的主从架构，用多个shuffle工作者节点来shuffle数据。同时，在系统设计中，Master非常有利于横向扩展，让shuffle不会成为整个分布式系统的瓶颈。
让New Shuffle模块专注于shuffle，不依赖于外部计算模块，从而计算模块可以专注于计算，同时还避免了磁盘IO。然而New Shuffle带来的问题也随之暴漏，其中影响比较重要的两个就是：慢节点和数据重复。
慢节点。以shuffle写入过程中出现慢节点为例，通常包含两个情况。首先，Shuffle自身慢节点，对比社区版本中只会影响到一个task，New Shuffle中常常会影响到一片集群。在这里，百度为每个Shuffle节点都配置了一个从节点，当Map检测到一个慢节点时，系统会自动切换到从节点。其次，DFS出现慢节点，这个情况下，Shuffle的从节点只能起到缓解作用。这种情况下，首先DFS系统会自动检测出慢节点，并进行替换。比如，传统的HDFS会以pipeline的形式进行写入，而DFS则转换为分发写。
在此之外，New Shuffle还需要解决更多问题，比如资源共享和隔离等。同时，基于New Shuffle的机制，New Shuffle还面临一些其他挑战，比如Reduce全启动、数据过于分散、对DFS压力过大、连接数等等。
数据重复。如上图所示，这些问题主要因为New Shuffle对上层组件缺少感知，这个问题的解决主要使用task id和block id进行去重。
New Shuffle展望
孙垚光表示，New Shuffle使用了通用的Writer和Reader接口，当下已经支持百度MR和DCE（DAG、C++），同时即将对开源Spark提供支持。在未来，New Shuffle无疑将成为更通用的组件，支持更多的计算模型。
