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