大數(shù)據(jù)那些事(2)：三駕馬車之永垂不朽的GFS
但凡是要開始講大數(shù)據(jù)的，都繞不開最初的Google三駕馬車：Google File System(GFS)， MapReduce，BigTable。如果我們拉長時間軸到20年為一個周期來看呢，這三駕馬車到今天的影響力其實已然不同。
MapReduce作為一個有很多優(yōu)點又有很多缺點的東西來說，很大程度上影響力已經(jīng)釋微了。BigTable以及以此為代表的各種KeyValue Store還有著它的市場，但是在Google內(nèi)部Spanner作為下一代的產(chǎn)品，也在很大程度上開始取代各種各樣的的BigTable的應(yīng)用。而作為這一切的基礎(chǔ)的Google File System，不但沒有任何倒臺的跡象，還在不斷的演化，事實上支撐著Google這個龐大的互聯(lián)網(wǎng)公司的一切計算。
作為開源最為成功的Hadoop Ecosystem來說，這么多年來風(fēng)起云涌，很多東西都在變。但是HDFS的地位卻始終很牢固。盡管各大云計算廠商都基于了自己的存儲系統(tǒng)實現(xiàn)了HDFS的接口，但是這個文件系統(tǒng)的基本理念至今并無太多改變。
那么GFS到底是什么呢?簡單一點來說它是一個文件系統(tǒng)，類似我們的NTFS或者EXT3，只是這個文件系統(tǒng)是建立在一堆的計算機(jī)的集群之上，用來存儲海量數(shù)據(jù)的。一般來說，對文件系統(tǒng)的操作無非是讀或者寫，而寫通常又被細(xì)分成update和append。Update是對已有數(shù)據(jù)的更新，而append則是在文件的末尾增加新的數(shù)據(jù)。
Google File System的論文發(fā)表于2003年，那個時候Google已經(jīng)可以讓這個文件系統(tǒng)穩(wěn)定的運行在幾千臺機(jī)器上，那么今天在我看來穩(wěn)定的運行在幾萬臺機(jī)器上并非是什么問題。這是非常了不起的成就，也是Hadoop的文件系統(tǒng)至今無非達(dá)到的高度。
GFS的設(shè)計理念上做了兩個非常重要的假設(shè)，其一是這個文件系統(tǒng)只處理大文件，一般來說要以TB或者PB作為級別去處理。其二是這個文件系統(tǒng)不支持update只支持append。在這兩個假設(shè)的基礎(chǔ)上，文件系統(tǒng)進(jìn)一步假設(shè)可以把大文件切成若干個chunk，本文上面的圖大致上給了GFS的一個基本體系框架的解釋。
Chunk server是GFS的主體，它們存在的目的是為了保存各種各樣的chunk。這些chunk代表了不同文件的不同部分。為了保證文件的完整性不受到機(jī)器下崗的影響，通常來說這些chunk都有冗余，這個冗余標(biāo)準(zhǔn)的來說是3份。有過各種分析證明這個三份是多么的安全。
在我曾經(jīng)工作的微軟的文件系統(tǒng)實現(xiàn)里面也用過三份這樣的冗余。結(jié)果有一次data center的電源出問題，導(dǎo)致一個集裝箱的機(jī)器整個的失聯(lián)(微軟的數(shù)據(jù)中心采用了非常獨特的集裝箱設(shè)計)。有一些文件的兩個或者三個拷貝都在那個集裝箱對應(yīng)的機(jī)器上，可以想象，這也同樣導(dǎo)致了整個系統(tǒng)的不可用。所以對于這三個拷貝要放哪里怎么去放其實是GFS里比較有意思的一個問題。我相信Google一定是經(jīng)過了很多的研究。
除了保存實際數(shù)據(jù)的chunk server以外，我們還需要metadata manager，在GFS里面這個東西就是master了。按照最初的論文來說，master是一個GFS里面唯一的。當(dāng)然后續(xù)有些資料里有提到GFS V2的相關(guān)信息表明這個single point bottleneck 在Google的系統(tǒng)演進(jìn)中得到了解決。Master說白了就是記錄了各個文件的不同chunk以及它們的各自拷貝在不同chunk server上的區(qū)別。
Master的重要性不言而喻。沒有了metadata的文件系統(tǒng)就是一團(tuán)亂麻。Google的實現(xiàn)實際上用了一個Paxos協(xié)議，倘若我的理解是正確的話。Paxos是Lamport提出來的用來解決在不穩(wěn)定網(wǎng)絡(luò)里面的consensus的一個協(xié)議。協(xié)議本身并不難懂，但是論文的證明需要有些耐心。
當(dāng)然最重要的，我自己從來沒有實現(xiàn)過這個協(xié)議。但是就我能看到的周圍實現(xiàn)過的人來說，這個東西很坑爹。Paxos干的事情是在2N+1臺機(jī)器里保持N的冗余。簡單一點說，掛掉N臺機(jī)器這個metadata service依然可以使用。
協(xié)議會選出一個master服務(wù)，而其他的則作為shadow server存在。一旦master掛了大家會重新投票。這個協(xié)議很好的解決了High Availability的問題。很不幸的是，抄襲的Hadoop 文件系統(tǒng)使用的是一個完全不同的方案。這個我們在講到Hadoop的時候再說。
對GFS的訪問通過client，讀的操作里，client會從master那邊拿回相應(yīng)的chunk server，數(shù)據(jù)的傳輸則通過chunk server和client之間進(jìn)行。不會因此影響了master的性能。而寫的操作則需要確保所有的primary以及secondary都寫完以后才返回client。如果寫失敗，則會有一系列的retry，實在不行則這些chunk會被標(biāo)注成garbage，然后被garbage collection。
Master和chunk server之間會保持通信，master保持著每個chunk的三個copy的實際位置。當(dāng)有的機(jī)器掉線之后，master如果有必要也會在其他的機(jī)器上觸發(fā)額外的copy活動以確保冗余，保證文件系統(tǒng)的安全。
GFS的設(shè)計非常的值得學(xué)習(xí)。系統(tǒng)支持的目標(biāo)文件以及文件的操作非常的明確而簡單。對待大規(guī)模不穩(wěn)定的PC機(jī)構(gòu)成的data center上怎么樣建立一個穩(wěn)定的系統(tǒng)，對data使用了復(fù)制，而對metadata則用了Paxos這樣的算法的實現(xiàn)。這個文件系統(tǒng)體現(xiàn)了相當(dāng)高水準(zhǔn)的系統(tǒng)設(shè)計里對方方面面trade off的選擇。有些東西只有自己做過或者就近看人做過才能真正感受到這系統(tǒng)設(shè)計的博大精深。故而對我個人而言，我對GFS的論文一直是非常的推崇，我覺得這篇論文值得每個做系統(tǒng)的人反復(fù)的讀。
同系列之：
