50PB海量數據排序，谷歌是這么做的
用于大規模數據集并行運算的MapReduce誕生之后，谷歌工程師對其進行了大規模隨機數據的排序測試。最近，他們向外界披露了過去幾年的測試數據和經驗總結，特別是50PB海量數據的排序，對于關注數據處理的技術人員來說很有借鑒意義。
為什么谷歌工程師喜歡測試排序?因為很容易產生任意規模的數據，也很容易驗證排序的輸出是否正確。
最初的MapReduce論文就報道了一個TeraSort排序的結果。工程師在一定的規則基礎上對1TB或10TB的數據進行排序測試，因為細小的錯誤更容易在大規模數據運行的時候被發現。
GraySort是大型排序基準的選擇。在GraySort基準下，你必須按照盡快對至少100TB的數據(每100B數據用最前面的10B數據作為鍵)進行字典序排序。Storbenchmark.org這個網站追蹤報道了這個基準的官方優勝者。而谷歌從未正式參加過比賽。
MapReduce是解決這個問題的不錯選擇，因為它實現reduce的方法是通過對鍵進行排序。結合適當的(字典)分區功能，MapReduce的輸出是一組包含了最終排序數據的文件序列。
有時，當一個新的cluster在一個數據中心出現時(通常被搜索索引團隊所使用)，谷歌MapReduce團隊就得到一個機會在真正的工作到來之前運行若干星期。這時他們有機會去“燃燒”這個cluster，延伸硬件的限制，放棄一些硬盤，而使用一些真正昂貴的設備，了解系統的性能，并贏得(非正式)排序基準測試。
谷歌這次披露了從2007年到2012年的測試數據：
2007
1PB, 12.13小時，1.37TB/min，2.9MB/s/worker
2007年運行了***個Petasort。在那個時候，測試者***興的是這個程序最終完成了排序，盡管對排序的結果有一些疑問(當時沒有驗證排序結果的正確性)。如果不是測試者取消了一定要某一個輸出分區與備份完全相同的驗證機制，這個排序便不會結束。
測試者懷疑這是因為用來存儲輸入和輸出的文件是GFS格式(谷歌文件系統)的緣故。GFS文件沒有足夠校驗和保護，有時會返回被污染的數據。不幸的是，這個基準所使用的文件格式沒有嵌入任何校驗供MapReduce使用(谷歌使用的典型MapReduce的文件是有嵌入校驗的)。
2008
1PB, 6.03小時，2.76TB/min，11.5MB/s/worker
2008年測試者***次把注意力集中于調優。花費幾天的時間來調整分區數量、緩沖區大小、預讀/預寫策略、頁面緩存使用等。最終的瓶頸是寫三路復制的GFS輸出文件，這是當時在谷歌使用的標準。任何事情的缺失都會造成數據丟失的高風險。
2010
1PB, 2.95小時, 5.65 TB/min, 11.8 MB/s/worker
在這個測試中，工程師使用了一種新的不可壓縮數據的GraySort基準版本。在前幾年，當我們讀/寫1PB GFS文件時，實際上混排的數據只有300TB，因為前幾年的數據是用ASCII格式壓縮好的。
這也是谷歌使用Colossus的一年，新一代的分布式存儲方式取代了GFS。不再有之前遇到過的GFS文件污染的問題。還使用了Reed-Solomon編碼(Colossus新特征)作為輸出，這種編碼允許測試者減少數據的總量，三路復制數據從3字節減少到了大約1.6字節。這也是***次，谷歌驗證了輸出的結果是正確的。
為了減少straggler的影響，測試者采用了一種叫做減少殘余碎片的動態分區技術。這也是數據流采用全動態分區的先兆。
2011
1PB, 0.55小時, 30.3 TB/min, 63.1 MB/s/worker
這一年，有了更快的網絡，并開始更加注重每臺機器的效率，特別是I/O的效率。測試者確保所有的I/O操作都在大于2MB的空間內進行，而以前有時候會小到64kB。
對于部分數據，工程師使用固態硬盤。這是***個在一小時之內完成Petasort。真的非常接近(兩倍) 給定MapReduce’s體系結構的硬件極限：輸入/輸出分布式存儲，為容錯保留中間數據(容錯是非常重要的，因為這個試驗中一些磁盤甚至整個機器都可能會失敗)。
他們還運行了更大的數據，10PB數據在6小時27分鐘(26TB/min)。
2012
50PB, 23小時, 36.2 TB/min, 50 MB/s/worker
對于這個測試，工程師將注意力轉移到更大規模的數據。在測試團隊控制的***cluster之下，運行了其認為是***MapReduce工作。不幸的是，這個cluster沒有足夠的磁盤空間來排序100PB的數據，因而限制測試的排序“只有”50PB。
這個測試只運行了一次，并沒有進行專門的調整，只是使用了之前10PB實驗時候的設置。這次實驗在23小時5分鐘之后運行結束。
需要注意的是，這次排序的規模是GraySort大規模的要求的500倍，計算速率是2015年GraySort官方優勝者的兩倍。
經驗總結
這些實驗教會了谷歌工程師很多關于運行超過10000臺機器的挑戰，以及如何調整使得運行速度接近于硬件的極限。
雖然這些排序實驗很有趣，但還是有幾個缺點：
- 沒有人真的想要一個巨大的全局范圍內的排序輸出，測試者還沒有找到這個問題的需求用例。
- 這些實驗顯示這個系統是可以良好運行的，但是需要強調的是谷歌花費了很多努力。
- MapReduce需要大量的調試確保它順利運行。如果看到很多MapReduce運行很差，其原因可能是設置不當。
最近，谷歌工程師已經把注意力集中在構建系統上，目的是使得大部分調優都不再必要。例如，采用數據流自動計算出分區的數量(必要時采用動態再分區)，而不是人為的經驗性分區。
