Google 怎麼樣做 50 PB 資料排序的？

自從創造 MapReduce 以來，我們就通過對海量隨機資料進行排序來測試它。我們喜歡排序，因為很容易生成任意數量的資料，檢查輸出是否正確同樣簡單。

儘管最初的 MapReduce 論文提交了一個 TeraSort 結果。工程師定期通過對 1TB 或者 10TB 的資料排序來做迴歸測試。因為資料量越大，那些不易察覺的 bug 越容易顯現。然而，當我們進一步擴大規模後，樂趣開始顯現。本文會回顧前幾年我們做的一些 PB 量級測試的經歷。這其中包括 MapReduce 迄今為止做過的最大量級的測試：50PB 資料的排序。

如今，GraySort 已經是海量資料排序的基準。使用 GraySort，以最快的速度按照字典順序對至少 100TB 的資料進行排序（100位元組的記錄，開頭10個位元組作為關鍵字）。網站 sortbenchmark.org 記錄了基於此基準的官方獲勝者。但谷歌從未參加官方競賽。

由於 MapReduce 就是通過對鍵排序來縮減規模，因而它很適合解決這個問題。通過合適的（詞典）分片功能，MapReduce輸出一系列包含最終排序後資料集的檔案。

有時在資料中心有新叢集出現時（一般是搜尋索引團隊使用）， 我們 MapReduce 組員就可以在動手幹活前玩上幾下。我們有機會試試讓叢集超負荷，測試硬體的極限範圍，搞掛掉一些硬碟，測試一些非常昂貴的裝置，學到很多關於系統效能的東 西，同時獲得排序基準競賽的勝（非官方）。

圖一：谷歌的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官方優勝者的兩倍。

經驗教訓

這些實驗讓我們受益匪淺：包括在 1000 臺機器上測試所遇到的挑戰以及如何調整優化來逼近硬體所能承受的極限速度。

儘管這些排序實驗很有趣，但還是有些缺點：

沒人需要這種海量的全域性排序輸出。我們還沒有發現如上述實驗那樣的針對具體問題的應用例項。

這些實驗證實了系統可以很好的執行，卻迴避了達到這個效果所要付出的努力。MapReduce 需要很多的優化調整才能很好地執行。我們確實在生產中間發現很多由於錯誤的引數配置導致 MapReduce表現不佳的案例。

最近，我們已經將注意力轉向對系統自身構建，對許多不必要的部分進行優化調整。例如：Dataflow可以自動找出分片的數量（以及自動按需重新分片），以代替人工摸索著手動執行這一任務。不過我們將把這些話題以及取得的結果，留到以後的部落格中再來描述。

打賞支援我翻譯更多好文章，謝謝！

打賞譯者