在spark新版本中，引入了 consolidation 机制，也就是说提出了ShuffleGroup的概念。一个 ShuffleMapTask 将数据写入 ResultTask 数量的本地文本，这个不会变。但是，当下一个 ShuffleMapTask 运行的时候，可以直接将数据写入之前的 ShuffleMapTask 的本地文件。相当于是，对多个 ShuffleMapTask 输出做了合并，从而大大减少了本地磁盘的数量。
假设一台机器上有两个 cpu ，也就是说，4个 ShuffleMapTask，有2个ShuffleMapTask是可以并行执行的。并行执行的 ShuffleMapTask ，写入的文件，一定是不同的。当一批并行执行的 ShuffleMapTask 运行完之后，那么新的一批 ShuffleMapTask 启动起来并执行的时候，优化机制就开始发挥作用了（consolidation机制）。这个东西，就可以称作为一组 ShuffleGroup。那么每个文件中，都存储了多个 ShuffleMapTask 的数据，每个 ShuffleMapTask 的数据 ，叫做一个 segment，此外，会通过一些索引，来标记每个 ShuffleMapTask 的输出在 ShuffleBlockFlie 中的索引，以及偏移量等，来进行不同 ShuffleMapTask 的数据的区分。
开启了 consolidation 机制之后的 shuffle write 操作，它的优化点在哪里？效果在哪里？
开启了 consolidation 机制之后，那么每个节点上的磁盘文件，数量是不是变成了 cpu core 数量* ResultTask数量，比如每个节点有2个 cpu，有100个 ResultTask，那么每个节点上总共才200 个磁盘文件呀！但是按照普通的 shuffle 操作来说，那么第一个节点上面，比如每个节点有2个 cpu，有100个 ShuffleMapTask，那么此时就会产生100*100个磁盘文件，就是1000个。
优化之后的 shuffle 操作，主要通过在 SparkConf 中设置一个参数即可。