痛点在LinkedIn公司主要采用了Spark自带的基于Yarn的External sorted shuffle实现，主要遇到痛点:
All-To-All Connectionsmap 和 reduce task之间需要维护all-to-all 的链接，以M个Map端task，R和Reducer端task为例，理论上就会建立M * R 个connection 。在实际实现中，一个executor上的reducer可以共享一个和ess的tcp链接 。因此实际上的链接数是和executor个数 E 和ess节点数 S相关 。但是在生产集群中 E 和 S 可能都会达到上千，这时链接数就会非常的客观，很容易带来稳定性的问题，如果建立链接失败可能会导致相关stage进行重跑，失败代价很高 。
Random IO从上面的读取流程我们可以看到因为多个reduce task数据在同一个文件中，很容易产生随机读取的问题，并且从linkedin公司观察到的这些block通常都比较小，平均只有10KB 。而LinkedIn shuffle集群主要使用的HDD磁盘，这个问题就会更大 。并且随机读取以及大量的网络小包会带来性能的损失 。
也许我们会想到说是否可以有办法来通过调参来让Shuffle Block 变大而减轻随机小IO的问题呢？比如把reduce task端的并发调小，这样每个task的数据量必然就变大了 。论文中也对此做了阐述，
