用于大規(guī)模數(shù)據(jù)集并行運(yùn)算的MapReduce誕生之后，谷歌工程師對(duì)其進(jìn)行了大規(guī)模隨機(jī)數(shù)據(jù)的排序測(cè)試。最近，他們向外界披露了過去幾年的測(cè)試數(shù)據(jù)和經(jīng)驗(yàn)總結(jié)，特別是50PB海量數(shù)據(jù)的排序，對(duì)于關(guān)注數(shù)據(jù)處理的技術(shù)人員來說很有借鑒意義。

[[163156]]

為什么谷歌工程師喜歡測(cè)試排序?因?yàn)楹苋菀桩a(chǎn)生任意規(guī)模的數(shù)據(jù)，也很容易驗(yàn)證排序的輸出是否正確。

最初的MapReduce論文就報(bào)道了一個(gè)TeraSort排序的結(jié)果。工程師在一定的規(guī)則基礎(chǔ)上對(duì)1TB或10TB的數(shù)據(jù)進(jìn)行排序測(cè)試，因?yàn)榧?xì)小的錯(cuò)誤更容易在大規(guī)模數(shù)據(jù)運(yùn)行的時(shí)候被發(fā)現(xiàn)。

GraySort是大型排序基準(zhǔn)的選擇。在GraySort基準(zhǔn)下，你必須按照盡快對(duì)至少100TB的數(shù)據(jù)(每100B數(shù)據(jù)用最前面的10B數(shù)據(jù)作為鍵)進(jìn)行字典序排序。Storbenchmark.org這個(gè)網(wǎng)站追蹤報(bào)道了這個(gè)基準(zhǔn)的官方優(yōu)勝者。而谷歌從未正式參加過比賽。

MapReduce是解決這個(gè)問題的不錯(cuò)選擇，因?yàn)樗鼘?shí)現(xiàn)reduce的方法是通過對(duì)鍵進(jìn)行排序。結(jié)合適當(dāng)?shù)?字典)分區(qū)功能，MapReduce的輸出是一組包含了最終排序數(shù)據(jù)的文件序列。

有時(shí)，當(dāng)一個(gè)新的cluster在一個(gè)數(shù)據(jù)中心出現(xiàn)時(shí)(通常被搜索索引團(tuán)隊(duì)所使用)，谷歌MapReduce團(tuán)隊(duì)就得到一個(gè)機(jī)會(huì)在真正的工作到來之前運(yùn)行若干星期。這時(shí)他們有機(jī)會(huì)去“燃燒”這個(gè)cluster，延伸硬件的限制，放棄一些硬盤，而使用一些真正昂貴的設(shè)備，了解系統(tǒng)的性能，并贏得(非正式)排序基準(zhǔn)測(cè)試。

谷歌這次披露了從2007年到2012年的測(cè)試數(shù)據(jù)：

2007

1PB, 12.13小時(shí)，1.37TB/min，2.9MB/s/worker

2007年運(yùn)行了***個(gè)Petasort。在那個(gè)時(shí)候，測(cè)試者***興的是這個(gè)程序最終完成了排序，盡管對(duì)排序的結(jié)果有一些疑問(當(dāng)時(shí)沒有驗(yàn)證排序結(jié)果的正確性)。如果不是測(cè)試者取消了一定要某一個(gè)輸出分區(qū)與備份完全相同的驗(yàn)證機(jī)制，這個(gè)排序便不會(huì)結(jié)束。

測(cè)試者懷疑這是因?yàn)橛脕泶鎯?chǔ)輸入和輸出的文件是GFS格式(谷歌文件系統(tǒng))的緣故。GFS文件沒有足夠校驗(yàn)和保護(hù)，有時(shí)會(huì)返回被污染的數(shù)據(jù)。不幸的是，這個(gè)基準(zhǔn)所使用的文件格式?jīng)]有嵌入任何校驗(yàn)供MapReduce使用(谷歌使用的典型MapReduce的文件是有嵌入校驗(yàn)的)。

2008

1PB, 6.03小時(shí)，2.76TB/min，11.5MB/s/worker

2008年測(cè)試者***次把注意力集中于調(diào)優(yōu)?；ㄙM(fèi)幾天的時(shí)間來調(diào)整分區(qū)數(shù)量、緩沖區(qū)大小、預(yù)讀/預(yù)寫策略、頁(yè)面緩存使用等。最終的瓶頸是寫三路復(fù)制的GFS輸出文件，這是當(dāng)時(shí)在谷歌使用的標(biāo)準(zhǔn)。任何事情的缺失都會(huì)造成數(shù)據(jù)丟失的高風(fēng)險(xiǎn)。

2010

1PB, 2.95小時(shí), 5.65 TB/min, 11.8 MB/s/worker

在這個(gè)測(cè)試中，工程師使用了一種新的不可壓縮數(shù)據(jù)的GraySort基準(zhǔn)版本。在前幾年，當(dāng)我們讀/寫1PB GFS文件時(shí)，實(shí)際上混排的數(shù)據(jù)只有300TB，因?yàn)榍皫啄甑臄?shù)據(jù)是用ASCII格式壓縮好的。

這也是谷歌使用Colossus的一年，新一代的分布式存儲(chǔ)方式取代了GFS。不再有之前遇到過的GFS文件污染的問題。還使用了Reed-Solomon編碼(Colossus新特征)作為輸出，這種編碼允許測(cè)試者減少數(shù)據(jù)的總量，三路復(fù)制數(shù)據(jù)從3字節(jié)減少到了大約1.6字節(jié)。這也是***次，谷歌驗(yàn)證了輸出的結(jié)果是正確的。

為了減少straggler的影響，測(cè)試者采用了一種叫做減少殘余碎片的動(dòng)態(tài)分區(qū)技術(shù)。這也是數(shù)據(jù)流采用全動(dòng)態(tài)分區(qū)的先兆。

2011

1PB, 0.55小時(shí), 30.3 TB/min, 63.1 MB/s/worker

這一年，有了更快的網(wǎng)絡(luò)，并開始更加注重每臺(tái)機(jī)器的效率，特別是I/O的效率。測(cè)試者確保所有的I/O操作都在大于2MB的空間內(nèi)進(jìn)行，而以前有時(shí)候會(huì)小到64kB。

對(duì)于部分?jǐn)?shù)據(jù)，工程師使用固態(tài)硬盤。這是***個(gè)在一小時(shí)之內(nèi)完成Petasort。真的非常接近(兩倍) 給定MapReduce’s體系結(jié)構(gòu)的硬件極限：輸入/輸出分布式存儲(chǔ)，為容錯(cuò)保留中間數(shù)據(jù)(容錯(cuò)是非常重要的，因?yàn)檫@個(gè)試驗(yàn)中一些磁盤甚至整個(gè)機(jī)器都可能會(huì)失敗)。

他們還運(yùn)行了更大的數(shù)據(jù)，10PB數(shù)據(jù)在6小時(shí)27分鐘(26TB/min)。

2012

50PB, 23小時(shí), 36.2 TB/min, 50 MB/s/worker

對(duì)于這個(gè)測(cè)試，工程師將注意力轉(zhuǎn)移到更大規(guī)模的數(shù)據(jù)。在測(cè)試團(tuán)隊(duì)控制的***cluster之下，運(yùn)行了其認(rèn)為是***MapReduce工作。不幸的是，這個(gè)cluster沒有足夠的磁盤空間來排序100PB的數(shù)據(jù)，因而限制測(cè)試的排序“只有”50PB。

這個(gè)測(cè)試只運(yùn)行了一次，并沒有進(jìn)行專門的調(diào)整，只是使用了之前10PB實(shí)驗(yàn)時(shí)候的設(shè)置。這次實(shí)驗(yàn)在23小時(shí)5分鐘之后運(yùn)行結(jié)束。

需要注意的是，這次排序的規(guī)模是GraySort大規(guī)模的要求的500倍，計(jì)算速率是2015年GraySort官方優(yōu)勝者的兩倍。

經(jīng)驗(yàn)總結(jié)

這些實(shí)驗(yàn)教會(huì)了谷歌工程師很多關(guān)于運(yùn)行超過10000臺(tái)機(jī)器的挑戰(zhàn)，以及如何調(diào)整使得運(yùn)行速度接近于硬件的極限。

雖然這些排序?qū)嶒?yàn)很有趣，但還是有幾個(gè)缺點(diǎn)：

• 沒有人真的想要一個(gè)巨大的全局范圍內(nèi)的排序輸出，測(cè)試者還沒有找到這個(gè)問題的需求用例。
• 這些實(shí)驗(yàn)顯示這個(gè)系統(tǒng)是可以良好運(yùn)行的，但是需要強(qiáng)調(diào)的是谷歌花費(fèi)了很多努力。
• MapReduce需要大量的調(diào)試確保它順利運(yùn)行。如果看到很多MapReduce運(yùn)行很差，其原因可能是設(shè)置不當(dāng)。

最近，谷歌工程師已經(jīng)把注意力集中在構(gòu)建系統(tǒng)上，目的是使得大部分調(diào)優(yōu)都不再必要。例如，采用數(shù)據(jù)流自動(dòng)計(jì)算出分區(qū)的數(shù)量(必要時(shí)采用動(dòng)態(tài)再分區(qū))，而不是人為的經(jīng)驗(yàn)性分區(qū)。