永利开户送38元体验金 1

本文由 伯乐在线 –
sunshinebuel
翻译,艾凌风
校稿。未经许可,禁止转载!
英文出处:Marian
Dvorsky。欢迎加入翻译组。

自从相关工具创建以来,我们一直通过对海量的随机数据执行排序来测试MapReduce。这种方式很受欢迎,因为生成任意数量的数据非常简单,想要验证输出结果是否正确也很简单。尽管最开始的MapReduce论文报告的是TeraSort的结果。工程师们将定期对1TB或10TB数据执行排序当作回归测试来做,因为测试时使用的数据量越大,那些不显眼的bug就越容易被发现。然而,当我们进一步扩大数据规模后,真正的乐趣才刚开始。本文将会讨论几年前我们所做的一些PB规模的排序实验,包括在我们看来最大的一次MapReduce任务:对50PB的数据执行排序。如今,GraySort已是海量数据排序基准之选,测试者必须以最快速度按字典顺序对至少100TB的数据执行排序。网站sortbenchmark.org跟踪记录了这项基准测试的官方优胜者,但谷歌从未参加过官方竞赛。由于实现Reduce的过程就是对键值排序,MapReduce刚好适合解决这个问题。通过合适的分片功能,MapReduce就能输出一系列的文件,其中包含最终排序后的数据集。有时在数据中心有新集群出现时,我们这些MapReduce团队的人员就有机会歇口气,在实际工作量压过来之前休闲几周。这些时候,我们才有机会试试看:让集群“超负荷”、探究硬件的极限、搞挂一些硬盘、测试一些非常昂贵的设备,并学到很多系统性能相关的东西,同时排序基准测试获得胜利。图一:谷歌的Petasort记录

自从创造 MapReduce
以来,我们就通过对海量随机数据进行排序来测试它。我们喜欢排序,因为很容易生成任意数量的数据,检查输出是否正确同样简单。

尽管最初的 MapReduce 论文提交了一个 TeraSort 结果。工程师定期通过对 1TB
或者 10TB 的数据排序来做回归测试。因为数据量越大,那些不易察觉的 bug
越容易显现。然而,当我们进一步扩大规模后,乐趣开始显现。本文会回顾前几年我们做的一些
PB 量级测试的经历。这其中包括 MapReduce
迄今为止做过的最大量级的测试:50PB 数据的排序。

如今,GraySort 已经是海量数据排序的基准。使用
GraySort,以最快的速度按照字典顺序对至少 100TB
的数据进行排序(100字节的记录,开头10个字节作为关键字)。网站
sortbenchmark.org
记录了基于此基准的官方获胜者。但谷歌从未参加官方竞赛。

由于 MapReduce
就是通过对键排序来缩减规模,因而它很适合解决这个问题。通过合适的(词典)分片功能,MapReduce输出一系列包含最终排序后数据集的文件。

有时在数据中心有新集群出现时(一般是搜索索引团队使用), 我们 MapReduce
组员就可以在动手干活前玩上几下。我们有机会试试让集群超负荷,测试硬件的极限范围,搞挂掉一些硬盘,测试一些非常昂贵的设备,学到很多关于系统性能的东
西,同时获得排序基准竞赛的胜(非官方)。

永利开户送38元体验金 2

图一:谷歌的Petasort记录

2007年

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

我们在 2007 年进行了首次 Petasort
测试。那时我们很开心能够完成整个测试,尽管对输出结果的正确性有些质疑(我们并没有验证正确性)。要不是我们关闭了验证
map
分片输出结果与备份是否一致的机制,就无法完成这项工作。我们怀疑这是用来对输入输出数据排序的谷歌档案系统(GFS)所造成的限制。GFS没
有足够的校验和保护机制,有时会返回坏值。糟糕的是,该基准所采用的文本格式并没有自带的校验和,来让
MapReduce 发送通知(在谷歌,MapReduce
的使用方式一般都是采用内嵌校验和的文件格式)。

2008年

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

2008
年开始,我们开始着眼于优化调整。我们花了几天时间来调整分片数量、各个缓存区的大小、预读/预写机制、页缓存机制等等。我们在这篇博客中公布了结果
。通过向 GFS
三路复制输出结果我们解决了瓶颈,这也是我们那时在谷歌的标准用法。少任何一路都会带来很高的风险。

2010年

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

在测试中,我们使用了新版本的GraySort基准,它采用不可压缩的数据。在早些年,我们从
GFS 读取或写入 1 PB的数据时,实际传输的数据只有 300
TB,因为那时所使用的ASCII格式易于压缩。

这也是 Colossus 诞生的一年(谷歌下一代分布式存储系统,GFS
的继任者)。我们不会再遇到先前使用 GFS
时碰到的崩溃问题。我们还对输出结果进行RS编码(Colossus的新功能),从而将总写入据量从
3 PB(三路复制)减少到大约1.6PB。我们也首次验证了输出结果的正确性。

为了减少掉队数据的影响,我们采用动态分片技术(也被称作 reduce
subsharding)。这也是后来在 Dataflow 所采用的全动态切片技术的先驱。

2011年

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


一年我们的网络速度更快,也开始更多地关注每台服务器的效率,特别是输入/输出(I/O)方面的问题。我们确保了所有的磁盘读写操作都是在
2 MB 的区块中进行,而不会落到 64 KB
的小区块中。我们使用固态硬盘来存储部分数据。这使得 Petasort
测试首次在一小时时间内完成––确切讲是 33
分钟––我们在此做了介绍。最终,在分布式存储中输入/输出以及坚持将中间数据保存在硬盘中以支持容错(由于在这种规模的测试中,某些硬盘甚至整台服务器都很容易宕掉,因此容错非常重要)的问题上,性能几乎达到了在指定
MapReduce 架构条件下的硬件极限性能的两倍。

同时也获得了更高的扩展:我们在 6 小时 27 分钟之内运行了 10 PB 的数据(26
TB/分钟)。

2012年

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

在这个测试中,我们将注意力转移到更大规模的测试中。通过调用我们在谷歌所能获取到的最大规模集群,我们进行了最大规模的
MapReduce
测试(就分片数据量而言)。不幸的是,该集群没有足够的硬盘空间来对 1000 PB
的数据进行排序,因而我们将排序的数据量限定在 50
PB。我们只测试了一次,也没有做专门的优化,参数设置还沿用了之前 10 PB
测试的那套。完成时间为 23 小时 5 分钟。

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

永利开户送38元体验金,经验教训

这些实验让我们受益匪浅:包括在 1000
台机器上测试所遇到的挑战以及如何调整优化来逼近硬件所能承受的极限速度。

尽管这些排序实验很有趣,但还是有些缺点:

没人需要这种海量的全局排序输出。我们还没有发现如上述实验那样的针对具体问题的应用实例。

这些实验证实了系统可以很好的运行,却回避了达到这个效果所要付出的努力。MapReduce
需要很多的优化调整才能很好地运行。我们确实在生产中间发现很多由于错误的参数配置导致
MapReduce表现不佳的案例。

最近,我们已经将注意力转向对系统自身构建,对许多不必要的部分进行优化调整。例如:Dataflow可以自动找出分片的数量(以及自动按需重新分片),以代替人工摸索着手动执行这一任务。不过我们将把这些话题以及取得的结果,留到以后的博客中再来描述。

打赏支持我翻译更多好文章,谢谢!

打赏译者

打赏支持我翻译更多好文章,谢谢!

任选一种支付方式

永利开户送38元体验金 3
永利开户送38元体验金 4

2 赞 6 收藏
评论

关于作者:sunshinebuel

永利开户送38元体验金 5

新世纪的好青年,写得了代码,下得了厨房,玩得了乐器,过得了六级!

个人主页 ·
我的文章 ·
12 ·
  

相关文章