關(guān)于谷歌的一些數(shù)據(jù)排序?qū)嶒?/h1>

大?。?/span>0.5 MB 人氣： 2017-10-11 需要積分：1

推薦 + 挑錯 + 收藏(0) + 用戶評論（0）

前往下載地址

分享到:

分享此文章到新浪微博 分享此文章到開心網(wǎng) 分享此文章到人人網(wǎng) 分享此文章到豆瓣網(wǎng) 分享此文章到騰訊微博

標(biāo)簽：數(shù)據(jù)排序(1426)

自從相關(guān)工具創(chuàng)建以來，我們一直通過對海量的隨機(jī)數(shù)據(jù)執(zhí)行排序來測試MapReduce。這種方式很受歡迎，因為生成任意數(shù)量的數(shù)據(jù)非常簡單，想要驗證輸出結(jié)果是否正確也很簡單。
　　盡管最開始的MapReduce論文報告的是TeraSort的結(jié)果。工程師們將定期對1TB或10TB數(shù)據(jù)執(zhí)行排序當(dāng)作回歸測試來做，因為測試時使用的數(shù)據(jù)量越大，那些不顯眼的bug就越容易被發(fā)現(xiàn)。然而，當(dāng)我們進(jìn)一步擴(kuò)大數(shù)據(jù)規(guī)模后，真正的樂趣才剛開始。本文將會討論幾年前我們所做的一些PB規(guī)模的排序?qū)嶒?，包括在我們看來最大的一次MapReduce任務(wù)：對50PB的數(shù)據(jù)執(zhí)行排序。
　　如今，GraySort已是海量數(shù)據(jù)排序基準(zhǔn)之選，測試者必須以最快速度按字典順序?qū)χ辽?00TB的數(shù)據(jù)執(zhí)行排序。網(wǎng)站sortbenchmark.org跟蹤記錄了這項基準(zhǔn)測試的官方優(yōu)勝者，但谷歌從未參加過官方競賽。
　　由于實現(xiàn)Reduce的過程就是對鍵值排序，MapReduce剛好適合解決這個問題。通過合適的（詞典）分片功能，MapReduce就能輸出一系列的文件，其中包含最終排序后的數(shù)據(jù)集。
　　有時在數(shù)據(jù)中心有新集群出現(xiàn)時（一般是為了搜索索引團(tuán)隊的使用），我們這些MapReduce團(tuán)隊的人員就有機(jī)會歇口氣，在實際工作量壓過來之前休閑幾周。這些時候，我們才有機(jī)會試試看：讓集群“超負(fù)荷”、探究硬件的極限、搞掛一些硬盤、測試一些非常昂貴的設(shè)備，并學(xué)到很多系統(tǒng)性能相關(guān)的東西，同時（在非官方的）排序基準(zhǔn)測試獲得勝利。
　　圖一：谷歌的Petasort記錄
　　
　　2007
　　（1PB，12.13小時，1.37TB/分鐘，2.9 MB/秒/worker）
　　我們在2007年首次運行Petasort。那時候，我們主要是開心能把這個測試完成，盡管對輸出結(jié)果的正確性還有些疑問（由于未作驗證而無法確認(rèn)）。當(dāng)時，若不是我們關(guān)閉了檢查map分片與備份的輸出結(jié)果是否一致的機(jī)制，這項任務(wù)是無法完成的。我們懷疑，這是用作輸入和輸出結(jié)果存儲的谷歌檔案系統(tǒng)（GFS）所造成的限制。GFS的校驗和保護(hù)不足，有時會返回?fù)p壞的數(shù)據(jù)。不幸的是，該基準(zhǔn)測試所使用的文件格式并不包含任何內(nèi)嵌的校驗和，無法讓MapReduce發(fā)送通知（在谷歌，通常使用MapReduce的方式就是使用內(nèi)嵌校驗和的文件格式）。
　　2008
　?。?PB，6.03小時，2.76TB/分鐘，11.5 MB/秒/worker）
　　2008年，我們首次專注于優(yōu)化調(diào)整，花了幾天時間調(diào)整分片數(shù)量、不同緩沖區(qū)的大小、預(yù)讀/預(yù)寫策略、頁面緩存使用等，并在博客中記錄了結(jié)果。最終，通過將輸出結(jié)果三路復(fù)制到GFS，我們解決掉了瓶頸，這也成了我們那時在谷歌的標(biāo)準(zhǔn)用法，少一路都會有很高的風(fēng)險損失掉數(shù)據(jù)。
　　2010
　?。?PB，2.95小時，5.65TB/分鐘，11.8 MB/秒/worker）
　　在這個測試中，我們使用了新版本的GraySort基準(zhǔn)，這個版本使用到了不可壓縮的數(shù)據(jù)。在前幾年中，我們從GFS讀取或者向其寫入1PB數(shù)據(jù)時，實際shuffle的數(shù)據(jù)量僅有大約300TB左右，因為那時所使用的ASCII格式都是壓縮過的。
　　在這一年中，谷歌將GFS更新為下一代分布式存儲系統(tǒng)Colossus。之前使用GFS時所遇到的數(shù)據(jù)損壞問題不再出現(xiàn)了，我們還在輸出結(jié)果中使用了RS編碼（Colossus的新功能），從而將寫入的總數(shù)據(jù)量從3PB（三路復(fù)制）減少到大約1.6PB。這時我們也首次證實了輸出結(jié)果的正確性。
　　為了減少離散數(shù)據(jù)的影響，我們運用了動態(tài)分片技術(shù)（也就是減少子分片），后來演變?yōu)榱嗽贒ataflow中使用完全動態(tài)分片技術(shù)。
　　2011
　?。?PB，0.55小時，30.3TB/分鐘，63.1 MB/秒/worker）
　　這一年我們的網(wǎng)絡(luò)速度更快，也開始關(guān)注每臺服務(wù)器的效率，特別是輸入/輸出（I/O）方面的問題。我們要確保所有的硬盤I/O操作都是在2MB大小的塊區(qū)內(nèi)進(jìn)行的，解決有時會縮小到64kB塊區(qū)的問題。我們使用了固態(tài)硬盤（SSD）來記錄部分?jǐn)?shù)據(jù)，這使得Petasort測試首次在一小時之內(nèi)完成，準(zhǔn)確來講是33分鐘，可以參考這里的記錄。最終，在分布式存儲中輸入/輸出以及將中間數(shù)據(jù)保存在硬盤中以支持容錯（由于在實驗中，某些硬盤甚至整臺服務(wù)器都會宕掉，而且這種情況會頻繁出現(xiàn)，因此容錯非常重要）的問題上，性能達(dá)到了指定MapReduce架構(gòu)的硬件極限性能的將近兩倍。同時也獲得了更高的擴(kuò)展：我們在6小時27分鐘之內(nèi)運行了10PB的數(shù)據(jù)（26TB/分鐘）。
　　2012
　　（50PB，23小時，36.2TB/分鐘，50 MB/秒/worker）
　　在這個測試中，我們將注意力轉(zhuǎn)向更大規(guī)模的數(shù)據(jù)排序，通過調(diào)用我們在谷歌所能控制的最大規(guī)模集群，將shuffle的數(shù)據(jù)量提到最大，然后運行相應(yīng)的MapReduce任務(wù)。不幸的是，這個集群的空間不夠讓100PB的數(shù)據(jù)排序，因此我們將要排序的數(shù)據(jù)限制在50PB。這個測試僅運行了一次，也沒有做專門的優(yōu)化調(diào)整，而且設(shè)置還是取自之前做10PB實驗時所用的那一套，完成時間為23小時5分鐘。
　　注意，這個排序的規(guī)模是GraySort的500倍，在吞吐量上是2015年GraySort官方優(yōu)勝者的兩倍。
　　學(xué)到的經(jīng)驗
　　這些實驗讓我們獲益良多：包括在運行萬臺規(guī)模的服務(wù)器上執(zhí)行排序時遇到了什么挑戰(zhàn)，以及如何優(yōu)化調(diào)整以接近硬件性能的速度極限。
　　盡管這些排序?qū)嶒灧浅Ｓ腥?，但仍有一些缺點：
　　真正海量的全局排序輸出是沒有人需要的，我們還沒有找到如上所述實驗的任何一個真實用例。
　　這些實驗證實了系統(tǒng)能夠良好地運行，不過回避了所需努力程度的問題。MapReduce需要很多的調(diào)整才能良好運行，事實上，我們發(fā)現(xiàn)在生產(chǎn)中有很多的MapReduce任務(wù)就是由于配置不當(dāng)而導(dǎo)致表現(xiàn)不佳。
　　近來，我們已經(jīng)轉(zhuǎn)向?qū)ο到y(tǒng)自身構(gòu)建的注重，讓大多部分不再需要優(yōu)化調(diào)整。例如：Dataflow可以自動找出分片的數(shù)量（以及自動按需重新分片），以代替人工摸索著手動執(zhí)行這一任務(wù)。不過這些話題還有達(dá)成的結(jié)果，我們會在以后的博客中再來描述。
?

下載地址