大數據那些事（2）：三駕馬車之永垂不朽的GFS

01-27

微信公眾號：飛總的IT世界面面觀。

但凡是要開始講大數據的，都繞不開最初的Google三駕馬車：Google File System（GFS）， MapReduce，BigTable。如果我們拉長時間軸到20年為一個周期來看呢，這三駕馬車到今天的影響力其實已然不同。MapReduce作為一個有很多優點又有很多缺點的東西來說，很大程度上影響力已經釋微了。BigTable以及以此為代表的各種KeyValue Store還有著它的市場，但是在Google內部Spanner作為下一代的產品，也在很大程度上開始取代各種各樣的的BigTable的應用。而作為這一切的基礎的Google File System，不但沒有任何倒台的跡象，還在不斷的演化，事實上支撐著Google這個龐大的互聯網公司的一切計算。

作為開源最為成功的Hadoop Ecosystem來說，這麼多年來風起雲湧，很多東西都在變。但是HDFS的地位卻始終很牢固。儘管各大雲計算廠商都基於了自己的存儲系統實現了HDFS的介面，但是這個文件系統的基本理念至今並無太多改變。

那麼GFS到底是什麼呢？簡單一點來說它是一個文件系統，類似我們的NTFS或者EXT3，只是這個文件系統是建立在一堆的計算機的集群之上，用來存儲海量數據的。一般來說，對文件系統的操作無非是讀或者寫，而寫通常又被細分成update和append。Update是對已有數據的更新，而append則是在文件的末尾增加新的數據。Google File System的論文發表於2003年，那個時候Google已經可以讓這個文件系統穩定的運行在幾千台機器上，那麼今天在我看來穩定的運行在幾萬台機器上並非是什麼問題。這是非常了不起的成就，也是Hadoop的文件系統至今無非達到的高度。

GFS的設計理念上做了兩個非常重要的假設，其一是這個文件系統只處理大文件，一般來說要以TB或者PB作為級別去處理。其二是這個文件系統不支持update只支持append。在這兩個假設的基礎上，文件系統進一步假設可以把大文件切成若干個chunk，本文上面的圖大致上給了GFS的一個基本體系框架的解釋。

Chunk server是GFS的主體，它們存在的目的是為了保存各種各樣的chunk。這些chunk代表了不同文件的不同部分。為了保證文件的完整性不受到機器下崗的影響，通常來說這些chunk都有冗餘，這個冗餘標準的來說是3份。有過各種分析證明這個三份是多門的安全。在我曾經工作的微軟的文件系統實現裡面也用過三份這樣的冗餘。結果有一次data center的電源出問題，導致一個集裝箱的機器整個的失聯（微軟的數據中心採用了非常獨特的集裝箱設計）。有一些文件的兩個或者三個拷貝都在那個集裝箱對應的機器上，可以想像，這也同樣導致了整個系統的不可用。所以對於這三個拷貝要放哪裡怎麼去放其實是GFS里比較有意思的一個問題。我相信Google一定是經過了很多的研究。

除了保存實際數據的chunk server以外，我們還需要metadata manager，在GFS裡面這個東西就是master了。按照最初的論文來說，master是一個GFS裡面唯一的。當然後續有些資料里有提到GFS V2的相關信息表明這個single point bottleneck 在Google的系統演進中得到了解決。Master說白了就是記錄了各個文件的不同chunk以及它們的各自拷貝在不同chunk server上的區別。

Master的重要性不言而喻。沒有了metadata的文件系統就是一團亂麻。Google的實現實際上用了一個Paxos協議，倘若我的理解是正確的話。Paxos是Lamport提出來的用來解決在不穩定網路裡面的consensus的一個協議。協議本身並不難懂，但是論文的證明需要有些耐心。當然最重要的，我自己從來沒有實現過這個協議。但是就我能看到的周圍實現過的人來說，這個東西很坑爹。Paxos乾的事情是在2N+1台機器里保持N的冗餘。簡單一點說，掛掉N台機器這個metadata service依然可以使用。協議會選出一個master服務，而其他的則作為shadow server存在。一旦master掛了大家會重新投票。這個協議很好的解決了High Availability的問題。很不幸的是，抄襲的Hadoop 文件系統使用的是一個完全不同的方案。這個我們在講到Hadoop的時候再說。

對GFS的訪問通過client，讀的操作里，client會從master那邊拿回相應的chunk server，數據的傳輸則通過chunk server和client之間進行。不會因此影響了master的性能。而寫的操作則需要確保所有的primary以及secondary都寫完以後才返回client。如果寫失敗，則會有一系列的retry，實在不行則這些chunk會被標註成garbage，然後被garbage collection。

Master和chunk server之間會保持通信，master保持著每個chunk的三個copy的實際位置。當有的機器掉線之後，master如果有必要也會在其他的機器上觸發額外的copy活動以確保冗餘，保證文件系統的安全。

GFS的設計非常的值得學習。系統支持的目標文件以及文件的操作非常的明確而簡單。對待大規模不穩定的PC機構成的data center上怎麼樣建立一個穩定的系統，對data使用了複製，而對metadata則用了Paxos這樣的演算法的實現。這個文件系統體現了相當高水準的系統設計里對方方面面trade off的選擇。有些東西只有自己做過或者就近看人做過才能真正感受到這系統設計的博大精深。故而對我個人而言，我對GFS的論文一直是非常的推崇，我覺得這篇論文值得每個做系統的人反覆的讀。