谷歌的海量數據排序實驗史

自從相關工具創建以來，我們一直通過對海量的隨機數據執行排序來測試MapReduce。這種方式很受歡迎，因為生成任意數量的數據非常簡單，想要驗證輸出結果是否正確也很簡單。

盡管最開始的MapReduce論文報告的是TeraSort的結果。工程師們將定期對1TB或10TB數據執行排序當作回歸測試來做，因為測試時使用的數據量越大，那些不顯眼的bug就越容易被發現。然而，當我們進一步擴大數據規模后，真正的樂趣才剛開始。本文將會討論幾年前我們所做的一些PB規模的排序實驗，包括在我們看來最大的一次MapReduce任務：對50PB的數據執行排序。

如今，GraySort已是海量數據排序基準之選，測試者必須以最快速度按字典順序對至少100TB的數據執行排序。網站sortbenchmark.org跟蹤記錄了這項基準測試的官方優勝者，但谷歌從未參加過官方競賽。

由于實現Reduce的過程就是對鍵值排序，MapReduce剛好適合解決這個問題。通過合適的(詞典)分片功能，MapReduce就能輸出一系列的文件，其中包含最終排序后的數據集。

有時在數據中心有新集群出現時(一般是為了搜索索引團隊的使用)，我們這些MapReduce團隊的人員就有機會歇口氣，在實際工作量壓過來之前休閑幾周。這些時候，我們才有機會試試看：讓集群“超負荷”、探究硬件的極限、搞掛一些硬盤、測試一些非常昂貴的設備，并學到很多系統性能相關的東西，同時(在非官方的)排序基準測試獲得勝利。

圖一：谷歌的Petasort記錄

2007

(1PB，12.13小時，1.37TB/分鐘，2.9 MB/秒/worker)

我們在2007年首次運行Petasort。那時候，我們主要是開心能把這個測試完成，盡管對輸出結果的正確性還有些疑問(由于未作驗證而無法確認)。當時，若不是我們關閉了檢查map分片與備份的輸出結果是否一致的機制，這項任務是無法完成的。我們懷疑，這是用作輸入和輸出結果存儲的谷歌檔案系統(GFS)所造成的限制。GFS的校驗和保護不足，有時會返回損壞的數據。不幸的是，該基準測試所使用的文件格式并不包含任何內嵌的校驗和，無法讓MapReduce發送通知(在谷歌，通常使用MapReduce的方式就是使用內嵌校驗和的文件格式)。

2008

(1PB，6.03小時，2.76TB/分鐘，11.5 MB/秒/worker)

2008年，我們首次專注于優化調整，花了幾天時間調整分片數量、不同緩沖區的大小、預讀/預寫策略、頁面緩存使用等，并在博客中記錄了結果。最終，通過將輸出結果三路復制到GFS，我們解決掉了瓶頸，這也成了我們那時在谷歌的標準用法，少一路都會有很高的風險損失掉數據。

2010

(1PB，2.95小時，5.65TB/分鐘，11.8 MB/秒/worker)

在這個測試中，我們使用了新版本的GraySort基準，這個版本使用到了不可壓縮的數據。在前幾年中，我們從GFS讀取或者向其寫入1PB數據時，實際shuffle的數據量僅有大約300TB左右，因為那時所使用的ASCII格式都是壓縮過的。

在這一年中，谷歌將GFS更新為下一代分布式存儲系統Colossus。之前使用GFS時所遇到的數據損壞問題不再出現了，我們還在輸出結果中使用了RS編碼(Colossus的新功能)，從而將寫入的總數據量從3PB(三路復制)減少到大約1.6PB。這時我們也首次證實了輸出結果的正確性。

為了減少離散數據的影響，我們運用了動態分片技術(也就是減少子分片)，后來演變為了在Dataflow中使用完全動態分片技術。

2011

(1PB，0.55小時，30.3TB/分鐘，63.1 MB/秒/worker)

這一年我們的網絡速度更快，也開始關注每臺服務器的效率，特別是輸入/輸出(I/O)方面的問題。我們要確保所有的硬盤I/O操作都是在2MB大小的塊區內進行的，解決有時會縮小到64kB塊區的問題。我們使用了固態硬盤(SSD)來記錄部分數據，這使得Petasort測試首次在一小時之內完成，準確來講是33分鐘，可以參考這里的記錄。最終，在分布式存儲中輸入/輸出以及將中間數據保存在硬盤中以支持容錯(由于在實驗中，某些硬盤甚至整臺服務器都會宕掉，而且這種情況會頻繁出現，因此容錯非常重要)的問題上，性能達到了指定MapReduce架構的硬件極限性能的將近兩倍。同時也獲得了更高的擴展：我們在6小時27分鐘之內運行了10PB的數據(26TB/分鐘)。

2012

(50PB，23小時，36.2TB/分鐘，50 MB/秒/worker)

在這個測試中，我們將注意力轉向更大規模的數據排序，通過調用我們在谷歌所能控制的最大規模集群，將shuffle的數據量提到最大，然后運行相應的MapReduce任務。不幸的是，這個集群的空間不夠讓100PB的數據排序，因此我們將要排序的數據限制在50PB。這個測試僅運行了一次，也沒有做專門的優化調整，而且設置還是取自之前做10PB實驗時所用的那一套，完成時間為23小時5分鐘。

注意，這個排序的規模是GraySort的500倍，在吞吐量上是2015年GraySort官方優勝者的兩倍。

學到的經驗

這些實驗讓我們獲益良多：包括在運行萬臺規模的服務器上執行排序時遇到了什么挑戰，以及如何優化調整以接近硬件性能的速度極限。

盡管這些排序實驗非常有趣，但仍有一些缺點：

1. 真正海量的全局排序輸出是沒有人需要的，我們還沒有找到如上所述實驗的任何一個真實用例。
2. 這些實驗證實了系統能夠良好地運行，不過回避了所需努力程度的問題。MapReduce需要很多的調整才能良好運行，事實上，我們發現在生產中有很多的MapReduce任務就是由于配置不當而導致表現不佳。
3. 近來，我們已經轉向對系統自身構建的注重，讓大多部分不再需要優化調整。例如：Dataflow可以自動找出分片的數量(以及自動按需重新分片)，以代替人工摸索著手動執行這一任務。不過這些話題還有達成的結果，我們會在以后的博客中再來描述。