谷歌的海量数据排序实验史

原文:History of massive-scale sorting experiments at Google 作者:Marian Dvorsky 译者:孙薇 责编:钱曙光,关注架构和算法领域

自从相关工具创建以来,我们一直通过对海量的随机数据执行排序来测试MapReduce。这种方式很受欢迎,因为生成任意数量的数据非常简单,想要验证输出结果是否正确也很简单。

尽管最开始的MapReduce论文报告的是TeraSort的结果。工程师们将定期对1TB或10TB数据执行排序当作回归测试来做,因为测试时使用的数据量越大,那些不显眼的bug就越容易被发现。然而,当我们进一步扩大数据规模后,真正的乐趣才刚开始。本文将会讨论几年前我们所做的一些PB规模的排序实验,包括在我们看来最大的一次MapReduce任务:对50PB的数据执行排序。

如今,GraySort已是海量数据排序基准之选,测试者必须以最快速度按字典顺序对至少100TB的数据执行排序。网站sortbenchmark.org跟踪记录了这项基准测试的官方优胜者,但谷歌从未参加过官方竞赛。

由于实现Reduce的过程就是对键值排序,MapReduce刚好适合解决这个问题。通过合适的(词典)分片功能,MapReduce就能输出一系列的文件,其中包含最终排序后的数据集。

有时在数据中心有新集群出现时(一般是为了搜索索引团队的使用),我们这些MapReduce团队的人员就有机会歇口气,在实际工作量压过来之前休闲几周。这些时候,我们才有机会试试看:让集群“超负荷”、探究硬件的极限、搞挂一些硬盘、测试一些非常昂贵的设备,并学到很多系统性能相关的东西,同时(在非官方的)排序基准测试获得胜利。

图一:谷歌的Petasort记录

2007

(1PB,12.13小时,1.37TB/分钟,2.9 MB/秒/worker)

我们在2007年首次运行Petasort。那时候,我们主要是开心能把这个测试完成,尽管对输出结果的正确性还有些疑问(由于未作验证而无法确认)。当时,若不是我们关闭了检查map分片与备份的输出结果是否一致的机制,这项任务是无法完成的。我们怀疑,这是用作输入和输出结果存储的谷歌档案系统(GFS)所造成的限制。GFS的校验和保护不足,有时会返回损坏的数据。不幸的是,该基准测试所使用的文件格式并不包含任何内嵌的校验和,无法让MapReduce发送通知(在谷歌,通常使用MapReduce的方式就是使用内嵌校验和的文件格式)。

2008

(1PB,6.03小时,2.76TB/分钟,11.5 MB/秒/worker)

2008年,我们首次专注于优化调整,花了几天时间调整分片数量、不同缓冲区的大小、预读/预写策略、页面缓存使用等,并在博客中记录了结果。最终,通过将输出结果三路复制到GFS,我们解决掉了瓶颈,这也成了我们那时在谷歌的标准用法,少一路都会有很高的风险损失掉数据。

2010

(1PB,2.95小时,5.65TB/分钟,11.8 MB/秒/worker)

在这个测试中,我们使用了新版本的GraySort基准,这个版本使用到了不可压缩的数据。在前几年中,我们从GFS读取或者向其写入1PB数据时,实际shuffle的数据量仅有大约300TB左右,因为那时所使用的ASCII格式都是压缩过的。

在这一年中,谷歌将GFS更新为下一代分布式存储系统Colossus。之前使用GFS时所遇到的数据损坏问题不再出现了,我们还在输出结果中使用了RS编码(Colossus的新功能),从而将写入的总数据量从3PB(三路复制)减少到大约1.6PB。这时我们也首次证实了输出结果的正确性。

为了减少离散数据的影响,我们运用了动态分片技术(也就是减少子分片),后来演变为了在Dataflow中使用完全动态分片技术。

2011

(1PB,0.55小时,30.3TB/分钟,63.1 MB/秒/worker)

这一年我们的网络速度更快,也开始关注每台服务器的效率,特别是输入/输出(I/O)方面的问题。我们要确保所有的硬盘I/O操作都是在2MB大小的块区内进行的,解决有时会缩小到64kB块区的问题。我们使用了固态硬盘(SSD)来记录部分数据,这使得Petasort测试首次在一小时之内完成,准确来讲是33分钟,可以参考这里的记录。最终,在分布式存储中输入/输出以及将中间数据保存在硬盘中以支持容错(由于在实验中,某些硬盘甚至整台服务器都会宕掉,而且这种情况会频繁出现,因此容错非常重要)的问题上,性能达到了指定MapReduce架构的硬件极限性能的将近两倍。同时也获得了更高的扩展:我们在6小时27分钟之内运行了10PB的数据(26TB/分钟)。

2012

(50PB,23小时,36.2TB/分钟,50 MB/秒/worker)

在这个测试中,我们将注意力转向更大规模的数据排序,通过调用我们在谷歌所能控制的最大规模集群,将shuffle的数据量提到最大,然后运行相应的MapReduce任务。不幸的是,这个集群的空间不够让100PB的数据排序,因此我们将要排序的数据限制在50PB。这个测试仅运行了一次,也没有做专门的优化调整,而且设置还是取自之前做10PB实验时所用的那一套,完成时间为23小时5分钟。

注意,这个排序的规模是GraySort的500倍,在吞吐量上是2015年GraySort官方优胜者的两倍。

学到的经验

这些实验让我们获益良多:包括在运行万台规模的服务器上执行排序时遇到了什么挑战,以及如何优化调整以接近硬件性能的速度极限。

尽管这些排序实验非常有趣,但仍有一些缺点:

  1. 真正海量的全局排序输出是没有人需要的,我们还没有找到如上所述实验的任何一个真实用例。
  2. 这些实验证实了系统能够良好地运行,不过回避了所需努力程度的问题。MapReduce需要很多的调整才能良好运行,事实上,我们发现在生产中有很多的MapReduce任务就是由于配置不当而导致表现不佳。

近来,我们已经转向对系统自身构建的注重,让大多部分不再需要优化调整。例如:Dataflow可以自动找出分片的数量(以及自动按需重新分片),以代替人工摸索着手动执行这一任务。不过这些话题还有达成的结果,我们会在以后的博客中再来描述。

原文发布于微信公众号 - CSDN技术头条(CSDN_Tech)

原文发表时间:2016-04-11

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏鸿的学习笔记

《design data-intensive application》阅读笔记之一

于2017年末得知了一本神书《design data-intensive application》,读完即可惜,如果早拿到这本书,就不会纠结于很多分布式系统...

792
来自专栏数据小魔方

当PowerBI遇到R语言

PowerBI作为微软系最新的商务智能办公系统,自去年发布以来,一直都备受瞩目。 他的更新频次相当之高,功能更新迭代非常迅速。 大概对可视化领域稍有涉猎的朋友们...

5194
来自专栏大数据文摘

后Hadoop时代的大数据架构

2525
来自专栏SeanCheney的专栏

《Python分布式计算》第1章 并行和分布式计算介绍 (Distributed Computing with Python)并行计算分布式计算共享式内存vs分布式内存阿姆达尔定律混合范式总结

本书示例代码适用于Python 3.5及以上。 ---- 当代第一台数字计算机诞生于上世纪30年代末40年代初(Konrad Zuse 1936年的Z1存在争议...

4278
来自专栏杨建荣的学习笔记

运维平台元数据稽核小结

数据库运维中的元数据建设都是重中之重,如果元数据不具有参考的价值,那么后续的操作都会受到影响,但是元数据的建设也应该是分成几个步子来走,首先得能够收集到元数...

1474
来自专栏海天一树

结构化、半结构化和非结构化数据

结构化的数据是指可以使用关系型数据库表示和存储,表现为二维形式的数据。一般特点是:数据以行为单位,一行数据表示一个实体的信息,每一行数据的属性是相同的。举一个例...

9762
来自专栏马哥教育

想学Python?这里有一个最全面的职位分析

Python从2015年开始,一直处于火爆的趋势,目前Python工程师超越Java、Web前端等岗位,起薪在15K左右,目前不管是小公司还是知名大公司都在热招...

5035
来自专栏程序员的知识天地

Python爬虫入门,8个常用爬虫技巧盘点

编程对于任何一个新手来说都不是一件容易的事情,Python对于任何一个想学习的编程的人来说的确是一个福音,阅读Python代码像是在阅读文章,源于Python语...

1621
来自专栏PPV课数据科学社区

【聚焦】后Hadoop时代的大数据架构

提到大数据分析平台,不得不说Hadoop系统,Hadoop到现在也超过10年的历史了,很多东西发生了变化,版本也从0.x进化到目前的2.6版本。我把2012年后...

2954
来自专栏一个会写诗的程序员的博客

20+个很棒的Android开源项目

20+个很棒的Android开源项目 本文摘自文章: 20+ Awesome Open-Source Android Apps To Boost Your D...

1372

扫码关注云+社区

领取腾讯云代金券