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