<p> </p>    <p>自从相关工具创建以来，我们一直通过对海量的随机数据执行排序来测试MapReduce。这种方式很受欢迎，因为生成任意数量的数据非常简单，想要验证输出结果是否正确也很简单。</p>    <p>尽管 <a href="/misc/goto?guid=4959652819495159873" rel="nofollow,noindex">最开始的MapReduce论文</a> 报告的是TeraSort的结果。工程师们将定期对1TB或10TB数据执行排序当作回归测试来做，因为测试时使用的数据量越大，那些不显眼的bug就越容易被发现。然而，当我们进一步扩大数据规模后，真正的乐趣才刚开始。本文将会讨论几年前我们所做的一些PB规模的排序实验，包括在我们看来最大的一次MapReduce任务：对50PB的数据执行排序。</p>    <p>如今，GraySort已是海量数据排序基准之选，测试者必须以最快速度按字典顺序对至少100TB的数据执行排序。网站 <a href="/misc/goto?guid=4958970292741855453" rel="nofollow,noindex">sortbenchmark.org</a> 跟踪记录了这项基准测试的官方优胜者，但谷歌从未参加过官方竞赛。</p>    <p>由于实现Reduce的过程就是对键值排序，MapReduce刚好适合解决这个问题。通过合适的（词典）分片功能，MapReduce就能输出一系列的文件，其中包含最终排序后的数据集。</p>    <p>有时在数据中心有新集群出现时（一般是为了搜索索引团队的使用），我们这些MapReduce团队的人员就有机会歇口气，在实际工作量压过来之前休闲几周。这些时候，我们才有机会试试看：让集群“超负荷”、探究硬件的极限、搞挂一些硬盘、测试一些非常昂贵的设备，并学到很多系统性能相关的东西，同时（在非官方的）排序基准测试获得胜利。</p>    <p>图一：谷歌的Petasort记录</p>    <p><img src="https://simg.open-open.com/show/be2c816d5726b25ae85d530415df7cac.png"></p>    <p><strong>2007</strong></p>    <p>（1PB，12.13小时，1.37TB/分钟，2.9 MB/秒/worker）</p>    <p>我们在2007年首次运行Petasort。那时候，我们主要是开心能把这个测试完成，尽管对输出结果的正确性还有些疑问（由于未作验证而无法确认）。当时，若不是我们关闭了检查map分片与备份的输出结果是否一致的机制，这项任务是无法完成的。我们怀疑，这是用作输入和输出结果存储的谷歌档案系统（GFS）所造成的限制。GFS的校验和保护不足，有时会返回损坏的数据。不幸的是，该基准测试所使用的文件格式并不包含任何内嵌的校验和，无法让MapReduce发送通知（在谷歌，通常使用MapReduce的方式就是使用内嵌校验和的文件格式）。</p>    <p><strong>2008</strong></p>    <p>（1PB，6.03小时，2.76TB/分钟，11.5 MB/秒/worker）</p>    <p>2008年，我们首次专注于优化调整，花了几天时间调整分片数量、不同缓冲区的大小、预读/预写策略、页面缓存使用等，并在 <a href="/misc/goto?guid=4959670173953444065" rel="nofollow,noindex">博客中记录了结果</a> 。最终，通过将输出结果三路复制到GFS，我们解决掉了瓶颈，这也成了我们那时在谷歌的标准用法，少一路都会有很高的风险损失掉数据。</p>    <p><strong>2010</strong></p>    <p>（1PB，2.95小时，5.65TB/分钟，11.8 MB/秒/worker）</p>    <p>在这个测试中，我们使用了新版本的GraySort基准，这个版本使用到了不可压缩的数据。在前几年中，我们从GFS读取或者向其写入1PB数据时，实际shuffle的数据量仅有大约300TB左右，因为那时所使用的ASCII格式都是压缩过的。</p>    <p>在这一年中，谷歌将GFS更新为下一代分布式存储系统Colossus。之前使用GFS时所遇到的数据损坏问题不再出现了，我们还在输出结果中使用了RS编码（Colossus的新功能），从而将写入的总数据量从3PB（三路复制）减少到大约1.6PB。这时我们也首次证实了输出结果的正确性。</p>    <p>为了减少离散数据的影响，我们运用了动态分片技术（也就是减少子分片），后来演变为了在Dataflow中使用完全动态分片技术。</p>    <p><strong>2011</strong></p>    <p>（1PB，0.55小时，30.3TB/分钟，63.1 MB/秒/worker）</p>    <p>这一年我们的网络速度更快，也开始关注每台服务器的效率，特别是输入/输出（I/O）方面的问题。我们要确保所有的硬盘I/O操作都是在2MB大小的块区内进行的，解决有时会缩小到64kB块区的问题。我们使用了固态硬盘（SSD）来记录部分数据，这使得Petasort测试首次在一小时之内完成，准确来讲是33分钟，可以参考这里的记录。最终，在分布式存储中输入/输出以及将中间数据保存在硬盘中以支持容错（由于在实验中，某些硬盘甚至整台服务器都会宕掉，而且这种情况会频繁出现，因此容错非常重要）的问题上，性能达到了指定MapReduce架构的硬件极限性能的将近两倍。同时也获得了更高的扩展：我们在6小时27分钟之内运行了10PB的数据（26TB/分钟）。</p>    <p><strong>2012</strong></p>    <p>（50PB，23小时，36.2TB/分钟，50 MB/秒/worker）</p>    <p>在这个测试中，我们将注意力转向更大规模的数据排序，通过调用我们在谷歌所能控制的最大规模集群，将shuffle的数据量提到最大，然后运行相应的MapReduce任务。不幸的是，这个集群的空间不够让100PB的数据排序，因此我们将要排序的数据限制在50PB。这个测试仅运行了一次，也没有做专门的优化调整，而且设置还是取自之前做10PB实验时所用的那一套，完成时间为23小时5分钟。</p>    <p>注意，这个排序的规模是GraySort的500倍，在吞吐量上是2015年GraySort官方优胜者的两倍。</p>    <p><strong>学到的经验</strong></p>    <p>这些实验让我们获益良多：包括在运行万台规模的服务器上执行排序时遇到了什么挑战，以及如何优化调整以接近硬件性能的速度极限。</p>    <p>尽管这些排序实验非常有趣，但仍有一些缺点：</p>    <ul>     <li>真正海量的全局排序输出是没有人需要的，我们还没有找到如上所述实验的任何一个真实用例。</li>     <li>这些实验证实了系统能够良好地运行，不过回避了所需努力程度的问题。MapReduce需要很多的调整才能良好运行，事实上，我们发现在生产中有很多的MapReduce任务就是由于配置不当而导致表现不佳。</li>    </ul>    <p>近来，我们已经转向对系统自身构建的注重，让大多部分不再需要优化调整。例如：Dataflow可以自动找出分片的数量（以及自动按需重新分片），以代替人工摸索着手动执行这一任务。不过这些话题还有达成的结果，我们会在以后的博客中再来描述。</p>    <p>原文： <a href="/misc/goto?guid=4959670174043571721" rel="nofollow,noindex">History of massive-scale sorting experiments at Google</a></p>    <p>作者：Marian Dvorsky</p>    <p>译者：孙薇</p>    <p>责编：钱曙光，关注架构和算法领域，寻求报道或者投稿请发邮件qianshg@csdn.net，另有「CSDN 高级架构师群」，内有诸多知名互联网公司的大牛架构师，欢迎架构师加微信qshuguang2008申请入群，备注姓名+公司+职位。</p>    <p>来自： <a href="/misc/goto?guid=4959670174124435473" rel="nofollow">http://www.iteye.com/news/31490</a></p>