用于大规模数据集并行运算的MapReduce诞生之后，谷歌工程师对其进行了大规模随机数据的排序测试。最近，他们向外界披露了过去几年的测试数据和经验总结，特别是50PB海量数据的排序，对于关注数据处理的技术人员来说很有借鉴意义。
为什么谷歌工程师喜欢测试排序?因为很容易产生任意规模的数据，也很容易验证排序的输出是否正确。
最初的MapReduce论文就报道了一个TeraSort排序的结果。工程师在一定的规则基础上对1TB或10TB的数据进行排序测试，因为细小的错误更容易在大规模数据运行的时候被发现。
GraySort是大型排序基准的选择。在GraySort基准下，你必须按照尽快对至少100TB的数据(每100B数据用最前面的10B数据作为键)进行字典序排序。Storbenchmark.org这个网站追踪报道了这个基准的官方优胜者。而谷歌从未正式参加过比赛。
MapReduce是解决这个问题的不错选择，因为它实现reduce的方法是通过对键进行排序。结合适当的(字典)分区功能，MapReduce的输出是一组包含了最终排序数据的文件序列。
有时，当一个新的cluster在一个数据中心出现时(通常被搜索索引团队所使用)，谷歌MapReduce团队就得到一个机会在真正的工作到来之前运行若干星期。这时他们有机会去“燃烧”这个cluster，延伸硬件的限制，放弃一些硬盘，而使用一些真正昂贵的设备，了解系统的性能，并赢得(非正式)排序基准测试。
谷歌这次披露了从2007年到2012年的测试数据：
2007
1PB, 12.13小时，1.37TB/min，2.9MB/s/worker
2007年运行了***个Petasort。在那个时候，测试者***兴的是这个程序最终完成了排序，尽管对排序的结果有一些疑问(当时没有验证排序结果的正确性)。如果不是测试者取消了一定要某一个输出分区与备份完全相同的验证机制，这个排序便不会结束。
测试者怀疑这是因为用来存储输入和输出的文件是GFS格式(谷歌文件系统)的缘故。GFS文件没有足够校验和保护，有时会返回被污染的数据。不幸的是，这个基准所使用的文件格式没有嵌入任何校验供MapReduce使用(谷歌使用的典型MapReduce的文件是有嵌入校验的)。
2008
1PB, 6.03小时，2.76TB/min，11.5MB/s/worker
2008年测试者***次把注意力集中于调优。花费几天的时间来调整分区数量、缓冲区大小、预读/预写策略、页面缓存使用等。最终的瓶颈是写三路复制的GFS输出文件，这是当时在谷歌使用的标准。任何事情的缺失都会造成数据丢失的高风险。
2010
1PB, 2.95小时, 5.65 TB/min, 11.8 MB/s/worker
在这个测试中，工程师使用了一种新的不可压缩数据的GraySort基准版本。在前几年，当我们读/写1PB GFS文件时，实际上混排的数据只有300TB，因为前几年的数据是用ASCII格式压缩好的。
这也是谷歌使用Colossus的一年，新一代的分布式存储方式取代了GFS。不再有之前遇到过的GFS文件污染的问题。还使用了Reed-Solomon编码(Colossus新特征)作为输出，这种编码允许测试者减少数据的总量，三路复制数据从3字节减少到了大约1.6字节。这也是***次，谷歌验证了输出的结果是正确的。
为了减少straggler的影响，测试者采用了一种叫做减少残余碎片的动态分区技术。这也是数据流采用全动态分区的先兆。
2011
1PB, 0.55小时, 30.3 TB/min, 63.1 MB/s/worker
这一年，有了更快的网络，并开始更加注重每台机器的效率，特别是I/O的效率。测试者确保所有的I/O操作都在大于2MB的空间内进行，而以前有时候会小到64kB。
对于部分数据，工程师使用固态硬盘。这是***个在一小时之内完成Petasort。真的非常接近(两倍) 给定MapReduce’s体系结构的硬件极限：输入/输出分布式存储，为容错保留中间数据(容错是非常重要的，因为这个试验中一些磁盘甚至整个机器都可能会失败)。
他们还运行了更大的数据，10PB数据在6小时27分钟(26TB/min)。
2012
50PB, 23小时, 36.2 TB/min, 50 MB/s/worker
对于这个测试，工程师将注意力转移到更大规模的数据。在测试团队控制的***cluster之下，运行了其认为是***MapReduce工作。不幸的是，这个cluster没有足够的磁盘空间来排序100PB的数据，因而限制测试的排序“只有”50PB。
这个测试只运行了一次，并没有进行专门的调整，只是使用了之前10PB实验时候的设置。这次实验在23小时5分钟之后运行结束。
需要注意的是，这次排序的规模是GraySort大规模的要求的500倍，计算速率是2015年GraySort官方优胜者的两倍。
经验总结
这些实验教会了谷歌工程师很多关于运行超过10000台机器的挑战，以及如何调整使得运行速度接近于硬件的极限。
虽然这些排序实验很有趣，但还是有几个缺点：
- 没有人真的想要一个巨大的全局范围内的排序输出，测试者还没有找到这个问题的需求用例。
- 这些实验显示这个系统是可以良好运行的，但是需要强调的是谷歌花费了很多努力。
- MapReduce需要大量的调试确保它顺利运行。如果看到很多MapReduce运行很差，其原因可能是设置不当。
最近，谷歌工程师已经把注意力集中在构建系统上，目的是使得大部分调优都不再必要。例如，采用数据流自动计算出分区的数量(必要时采用动态再分区)，而不是人为的经验性分区。
