首頁 > 網路科技 > Google大規模排序實驗史

Google大規模排序實驗史

笨笨包說明:

這篇文章翻譯是由大陸的伯樂在線網站翻譯發布,翻譯後的標題為:Google 怎麼樣做50 PB 資料排序的?

但是笨笨包轉貼前看了一下內容後,決定修改一些大陸用語,以及少許翻譯不順暢或錯誤修正。這篇文章對於程式設計師關於大資料的查詢排序非常有參考價值!

英文原文:https://cloud.google.com/blog/big-data/2016/02/history-of-massive-scale-sorting-experiments-at-google


自從建立 MapReduce 工具以來,我們就通過對大量隨機資料進行排序來測試它。我們喜歡排序,因為很容易生成任意數量的資料,很容易驗證輸出是否正確。

儘管最初的 MapReduce 論文報告了一個 TeraSort 結果。工程師定期通過對 1TB 或者 10TB 的資料排序來做回歸測試。因為資料量越大,那些不易察覺的 bug 越容易顯現。然而,當我們進一步擴大規模後,真正有趣的事情開始了。在這篇文章中我將談談前幾年我們做的一些PB 量級測試的經歷。這其中包括MapReduce 迄今為止做過的最大量級的測試:50PB 資料的排序。

如今,GraySort已經是大量資料排序的選擇基準。使用GraySort,以最快的速度按照字典順序對至少100TB的資料進行排序(100字節的記錄,開頭10個字節作為關鍵字)。sortbenchmark.org 網站追蹤記錄了這種測試基準的官方獲勝者。但Google從未參加官方競賽。

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

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

圖一:Google的Petasort根據時間推移的記錄

2007年

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

我們在2007 年進行了首次Petasort 測試。那時我們很開心能夠完成整個測試,儘管對輸出結果的正確性有些質疑(我們並沒有驗證正確性)。要不是我們關閉了驗證map 拆分輸出結果與備份是否一致的機制,就無法完成這項工作。我們懷疑這是用來對輸入輸出資料排序的Google檔案系統(GFS)所造成的限制。GFS沒有足夠的校驗和保護機制,有時會返回損壞的值。糟糕的是,該基準所採用的文字格式並沒有自帶的校驗和,來讓MapReduce 傳送通知(在Google,MapReduce 的使用方式一般都是採用嵌入校驗和的檔案格式)。

2008年

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

2008年開始,我們開始著眼於優化調整。我們花了幾天時間來調整拆分數量、各個暫存區的大小、預讀/預寫機制、頁暫存機制等等。我們在這篇部落格中公佈了結果。通過向GFS三路複製輸出結果我們解決了瓶頸,這也是我們那時在Google的標準用法。少任何一路都會帶來很高的風險。

2010年

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

在測試中,我們使用了新版本的GraySort基準,它採用不可壓縮的資料。在早些年,我們從GFS 讀取或寫入1 PB的資料時,實際傳輸的資料只有300 TB,因為那時所使用的ASCII格式易於壓縮。

這也是Colossus 誕生的一年(Google下一代分佈式存儲系統,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)

在這個測試中,我們將注意力轉移到更大規模的測試中。通過調用我們在Google所能獲取到的最大規模集群,我們進行了最大規模的MapReduce 測試(就拆分資料量而言)。不幸的是,該集群沒有足夠的硬碟空間來對1000 PB 的資料進行排序,因而我們將排序的資料量限定在50 PB。我們只測試了一次,也沒有做專門的優化,參數設置還沿用了之前10 PB 測試的那套。完成時間為23 小時5 分鐘。

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

經驗教訓

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

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

 

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

 

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

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

作者:Google Cloud Platform 軟體工程師 Marian Dvorsky

發表留言

您的電子郵件地址將不會被公開標記為必填欄位 *

*

這個網站採用 Akismet 服務減少垃圾留言。進一步瞭解 Akismet 如何處理網站訪客的留言資料