分布式文件存儲(chǔ)系統(tǒng)調(diào)研方案

1、分布式文件存儲(chǔ)系統(tǒng)調(diào)研方案1.需求分析41.1.大數(shù)據(jù)時(shí)代41.2.調(diào)研范圍41.3.名詞解釋52.Google GFS62.1.系統(tǒng)架構(gòu)72.2.相關(guān)技術(shù)82.2.1.租賃機(jī)制82.2.2.一致性模型82.2.3.追加流程92.2.4.容錯(cuò)機(jī)制102.2.5.Master內(nèi)存占用112.2.6.負(fù)載均衡112.2.7.垃圾回收122.2.8.快照122.2.9.ChunkServer122.3.GFS學(xué)習(xí)總結(jié)133.開(kāi)源的分布式文件存儲(chǔ)系統(tǒng)133.1.前言133.2.Hadoop HDFS143.2.1.介紹143.2.2.特點(diǎn)143.2.3.性能143.3.KFS143.4.流行的開(kāi)源文件

2、存儲(chǔ)系統(tǒng)比較153.5.開(kāi)源分布式文件存儲(chǔ)學(xué)習(xí)總結(jié)184.參考資料181. 需求分析1.1. 大數(shù)據(jù)時(shí)代我們?cè)缫烟幵跀?shù)字時(shí)代。而今，我們迎來(lái)了數(shù)據(jù)爆炸的時(shí)代，這就是所謂的大數(shù)據(jù)時(shí)代。2013年，大數(shù)據(jù)元年。大數(shù)據(jù)的四個(gè)特征：Ø 數(shù)據(jù)量大第一個(gè)特征是數(shù)據(jù)量大。大數(shù)據(jù)的起始計(jì)量單位至少是P（1000個(gè)T）、E（100萬(wàn)個(gè)T）或Z（10億個(gè)T）。Ø 類(lèi)型繁多第二個(gè)特征是數(shù)據(jù)類(lèi)型繁多。包括網(wǎng)絡(luò)日志、音頻、視頻、圖片、地理位置信息等等，多類(lèi)型的數(shù)據(jù)對(duì)數(shù)據(jù)的處理能力提出了更高的要求。Ø 價(jià)值密度低第三個(gè)特征是數(shù)據(jù)價(jià)值密度相對(duì)較低。如隨著物聯(lián)網(wǎng)的廣泛應(yīng)用，信息感知無(wú)處不在，信息

3、海量，但價(jià)值密度較低，如何通過(guò)強(qiáng)大的機(jī)器算法更迅速地完成數(shù)據(jù)的價(jià)值“提純”，是大數(shù)據(jù)時(shí)代亟待解決的難題。Ø 速度快時(shí)效高第四個(gè)特征是處理速度快，時(shí)效性要求高。這是大數(shù)據(jù)區(qū)分于傳統(tǒng)數(shù)據(jù)挖掘最顯著的特征。既有的技術(shù)架構(gòu)和路線(xiàn)，已經(jīng)無(wú)法高效處理如此海量的數(shù)據(jù)，而對(duì)于相關(guān)組織來(lái)說(shuō)，如果投入巨大采集的信息無(wú)法通過(guò)及時(shí)處理反饋有效信息，那將是得不償失的?？梢哉f(shuō)，大數(shù)據(jù)時(shí)代對(duì)人類(lèi)的數(shù)據(jù)駕馭能力提出了新的挑戰(zhàn)，也為人們獲得更為深刻、全面的洞察能力提供了前所未有的空間與潛力。當(dāng)前，分布式文件存儲(chǔ)系統(tǒng)是解決大數(shù)據(jù)時(shí)代的利器。1.2. 調(diào)研范圍為了應(yīng)對(duì)大數(shù)據(jù)的到來(lái)，不同背景的企業(yè)有不同的解決方案。傳統(tǒng)的關(guān)

4、系型數(shù)據(jù)庫(kù)（OldSQL）、新型的列存儲(chǔ)-關(guān)系型數(shù)據(jù)庫(kù)（NewSQL）和基于NoSQL的云存儲(chǔ)，都針對(duì)云存儲(chǔ)提出了相應(yīng)的解決方案。這是一個(gè)多元化的時(shí)代，三個(gè)解決方案各有優(yōu)缺點(diǎn)，互為補(bǔ)充更加適合大數(shù)據(jù)的需要。相比之下，OldSQL已經(jīng)比較成熟，NewSQL技術(shù)比較封閉比較商業(yè)化，都不是此次的研究對(duì)象。此次技術(shù)調(diào)研，主要涉及基于NoSQL的分布式文件存儲(chǔ)系統(tǒng)。NoSQL領(lǐng)域技術(shù)繁多，各種概念層出不窮，雖涉足不深但已經(jīng)常感覺(jué)頭暈?zāi)垦?。為了便于調(diào)研，我將NoSQL涉及的各個(gè)組件、產(chǎn)品分為三部分：Ø 分布式文件存儲(chǔ)系統(tǒng)Ø NoSQL數(shù)據(jù)庫(kù)Ø 云計(jì)算應(yīng)用分布式文件存儲(chǔ)是另外兩

5、個(gè)部分的基礎(chǔ)，此篇文章將聚焦于分布式文件存儲(chǔ)系統(tǒng)。1.3. 名詞解釋Ø 大數(shù)據(jù)：指的是所涉及的資料量規(guī)模巨大到無(wú)法透過(guò)目前主流軟件工具，在合理時(shí)間內(nèi)達(dá)到擷取、管理、處理、并整理成為幫助企業(yè)經(jīng)營(yíng)決策更積極目的的資訊。簡(jiǎn)單的說(shuō)，至少要達(dá)到TB級(jí)別的數(shù)據(jù)。Ø 云存儲(chǔ)：云存儲(chǔ)是與云計(jì)算同時(shí)興起的一個(gè)概念。云存儲(chǔ)一般包含兩個(gè)含義：n 云存儲(chǔ)是云計(jì)算的存儲(chǔ)部分，即虛擬化的、易于擴(kuò)展的存儲(chǔ)資源池。用戶(hù)通過(guò)云計(jì)算使用存儲(chǔ)資源池，但不是所有的云計(jì)算的存儲(chǔ)部分都是可以分離的。n 云存儲(chǔ)意味著存儲(chǔ)可以作為一種服務(wù)，通過(guò)網(wǎng)絡(luò)提供給用戶(hù)。用戶(hù)可以通過(guò)若干種方式來(lái)使用存儲(chǔ)，并按使用（時(shí)間、空間或兩者結(jié)

6、合）付費(fèi)。Ø NoSQL：Not Only SQL，泛指這樣一類(lèi)數(shù)據(jù)庫(kù)和數(shù)據(jù)存儲(chǔ)，它們不遵循經(jīng)典關(guān)系型數(shù)據(jù)庫(kù)原理，且常與Web規(guī)模的大型數(shù)據(jù)集有關(guān)。Ø NewSQL：新型的關(guān)系型數(shù)據(jù)庫(kù)；不同于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)，NewSQL陣營(yíng)普遍采用了列存儲(chǔ)技術(shù)，是介于傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)和NoSQL之間的產(chǎn)品。這類(lèi)產(chǎn)品有可能代表未來(lái)的發(fā)展方向，但是目前尚不普及。Ø DFS：分布式文件系統(tǒng)（Distributed File System），指文件系統(tǒng)管理的物理存儲(chǔ)資源不一定直接連接在本地節(jié)點(diǎn)上，而是通過(guò)計(jì)算機(jī)網(wǎng)絡(luò)與節(jié)點(diǎn)相連。Ø HDFS：Hadoop分布式文件系統(tǒng)（Had

7、oop Distributed File System），是一個(gè)高度容錯(cuò)性的系統(tǒng)，適合部署在廉價(jià)的機(jī)器上。Ø KFS：Kosmos distributed file system，是一個(gè)專(zhuān)門(mén)為數(shù)據(jù)密集型應(yīng)用（搜索引擎，數(shù)據(jù)挖掘等）而設(shè)計(jì)的存儲(chǔ)系統(tǒng)，類(lèi)似于Google的GFS和Hadoop的HDFS分布式文件系統(tǒng)。 KFS使用C+實(shí)現(xiàn)，支持的客戶(hù)端包括C+，Java和Python。KFS系統(tǒng)由三部分組成，分別是metaserver、chunkserver和client library。Ø 流式數(shù)據(jù)訪(fǎng)問(wèn)： 流式讀取最小化了硬盤(pán)的尋址開(kāi)銷(xiāo)，只需要尋址一次，然后就一直讀啊讀。硬盤(pán)的

8、物理構(gòu)造導(dǎo)致尋址開(kāi)銷(xiāo)的優(yōu)化跟不上讀取開(kāi)銷(xiāo)。所以流式讀取更加適合硬盤(pán)的本身特性。當(dāng)然大文件的特點(diǎn)也更適合流式讀取。Ø 隨機(jī)數(shù)據(jù)訪(fǎng)問(wèn)： 要求定位、查詢(xún)或修改數(shù)據(jù)的延遲較小，比較適合于創(chuàng)建數(shù)據(jù)后再多次讀寫(xiě)的情況，傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)很符合這一點(diǎn)。Ø POSIX：可移植操作系統(tǒng)接口（Portable Operating System Interface），最初開(kāi)發(fā) POSIX 標(biāo)準(zhǔn)，是為了提高 UNIX 環(huán)境下應(yīng)用程序的可移植性。然而，POSIX 并不局限于 UNIX，許多系統(tǒng)都支持。由于分布式文件存儲(chǔ)系統(tǒng)很多是用C/C+開(kāi)發(fā)的，支持POSIX也就意味著它的文件操作在大部分UNIX和L

9、inux操作系統(tǒng)之間是可移植的。對(duì)于Java開(kāi)發(fā)的文件存儲(chǔ)系統(tǒng)則不需要關(guān)心。Ø FUSE：用戶(hù)態(tài)文件系統(tǒng)（Filesystem in Userspace），是操作系統(tǒng)中的概念，指完全在用戶(hù)態(tài)實(shí)現(xiàn)的文件系統(tǒng)。目前Linux通過(guò)內(nèi)核模塊對(duì)此進(jìn)行支持。傳統(tǒng)上操作系統(tǒng)在內(nèi)核層面上對(duì)文件系統(tǒng)提供支持。而通常內(nèi)核態(tài)的代碼難以調(diào)試，生產(chǎn)率較低。在用戶(hù)空間實(shí)現(xiàn)文件系統(tǒng)能夠大幅提高生產(chǎn)率，簡(jiǎn)化了為操作系統(tǒng)提供新的文件系統(tǒng)的工作量，特別適用于各種虛擬文件系統(tǒng)和網(wǎng)絡(luò)文件系統(tǒng)。上述ZFS和glusterfs都屬于網(wǎng)絡(luò)文件系統(tǒng)。但是，在用戶(hù)態(tài)實(shí)現(xiàn)文件系統(tǒng)必然會(huì)引入額外的內(nèi)核態(tài)/用戶(hù)態(tài)切換帶來(lái)的開(kāi)銷(xiāo)，對(duì)性能會(huì)產(chǎn)

10、生一定影響。（針對(duì)C/C+，Java系統(tǒng)則不需要關(guān)心）2. Google GFS提起分布式文件存儲(chǔ)系統(tǒng)，最有名的莫過(guò)于谷歌技術(shù)“三寶”之一：Google文件系統(tǒng)GFS。Google文件系統(tǒng)（Google File System，GFS）是構(gòu)建在廉價(jià)的服務(wù)器之上的大型分布式系統(tǒng)。它將服務(wù)器故障視為正?，F(xiàn)象，通過(guò)軟件的方式自動(dòng)容錯(cuò)，在保證系統(tǒng)可靠性和可用性的同時(shí)，大大減少了系統(tǒng)的成本。GFS是Google云存儲(chǔ)的基石，其它存儲(chǔ)系統(tǒng)，如Google Bigtable，Google Megastore，Google Percolator均直接或者間接地構(gòu)建在GFS之上。另外，Google大規(guī)模批處理系

11、統(tǒng)MapReduce也需要利用GFS作為海量數(shù)據(jù)的輸入輸出。2.1. 系統(tǒng)架構(gòu)GFS將整個(gè)系統(tǒng)的節(jié)點(diǎn)分為三種角色：GFS Master（總控服務(wù)器），GFS Chunkserver（數(shù)據(jù)塊服務(wù)器，簡(jiǎn)稱(chēng)CS）以及GFS Client（客戶(hù)端）。GFS文件被劃分為固定大小的數(shù)據(jù)塊（Chunk），由Master在創(chuàng)建時(shí)分配一個(gè)64位全局唯一的Chunk句柄。CS以普通的Linux文件的形式將Chunk存儲(chǔ)在磁盤(pán)中。為了保證可靠性，Chunk在不同的機(jī)器中復(fù)制多份，默認(rèn)為三份。Master中維護(hù)了系統(tǒng)的元數(shù)據(jù)，包括文件及Chunk名字空間，GFS文件到Chunk之間的映射，Chunk位置信息。它也負(fù)責(zé)

12、整個(gè)系統(tǒng)的全局控制，如Chunk租約管理，垃圾回收無(wú)用Chunk，Chunk復(fù)制，等等。Master會(huì)定期與CS通過(guò)心跳的方式交換信息。Client是GFS提供給應(yīng)用程序的訪(fǎng)問(wèn)接口，它是一組專(zhuān)用接口，不遵守POSIX規(guī)范，以庫(kù)文件的形式提供。Client訪(fǎng)問(wèn)GFS時(shí)，首先訪(fǎng)問(wèn)Master節(jié)點(diǎn)，獲取與之進(jìn)行交互的CS信息，然后直接訪(fǎng)問(wèn)這些CS，完成數(shù)據(jù)存取工作。需要注意的是，GFS中的客戶(hù)端不緩存文件數(shù)據(jù)，只緩存Master中獲取的元數(shù)據(jù)，這是由GFS的應(yīng)用特點(diǎn)決定的。GFS最主要的應(yīng)用有兩個(gè)：MapReduce與Bigtable。對(duì)于MapReduce，GFS客戶(hù)端使用方式為順序讀寫(xiě)，沒(méi)有緩存

13、文件數(shù)據(jù)的必要；而B(niǎo)igtable作為云表格系統(tǒng)，內(nèi)部實(shí)現(xiàn)了一套緩存機(jī)制。另外，如何維護(hù)客戶(hù)端緩存與實(shí)際數(shù)據(jù)之間的一致性是一個(gè)極其復(fù)雜的問(wèn)題。下面討論GFS架構(gòu)中的幾個(gè)關(guān)鍵技術(shù)。2.2. 相關(guān)技術(shù)2.2.1. 租賃機(jī)制GFS數(shù)據(jù)追加以記錄為單位，每個(gè)記錄的大小為幾十KB到幾MB，如果每次記錄追加都需要請(qǐng)求Master，那么Master顯然會(huì)成為系統(tǒng)的性能瓶頸，因此，GFS系統(tǒng)中通過(guò)Lease機(jī)制將chunk寫(xiě)操作授權(quán)給Chunk Server。獲取Lease授權(quán)的Chunk Server稱(chēng)為Primary Chunk Server，其它副本所在的Chunk Server稱(chēng)為Secondary

14、Chunk Server。Lease授權(quán)針對(duì)單個(gè)chunk，在Lease有效期內(nèi)，對(duì)該chunk的寫(xiě)操作都有Primary Chunk Server負(fù)責(zé)，從而減少M(fèi)aster的負(fù)擔(dān)。一般來(lái)說(shuō)，Lease的有效期比較長(zhǎng)，比如60秒，只要沒(méi)有出現(xiàn)異常，Primary Chunk Server可以不斷向Master請(qǐng)求延長(zhǎng)Lease的有效期直到整個(gè)chunk寫(xiě)滿(mǎn)。假設(shè)有Chunk A在GFS中保存了三個(gè)副本A1，A2，A3，其中，A1是Primary。如果副本A2所在Chunk Server下線(xiàn)后又重新上線(xiàn)，并且在A(yíng)2下線(xiàn)的過(guò)程中，副本A1和A3有新的更新，那么，A2需要被Master當(dāng)成垃圾回收掉

15、。GFS通過(guò)對(duì)每個(gè)chunk維護(hù)一個(gè)版本號(hào)來(lái)解決，每次給Chunk進(jìn)行Lease授權(quán)或者Primary Chunk Server重新延長(zhǎng)Lease有效期時(shí)，Master會(huì)將Chunk的版本號(hào)加1。A2下線(xiàn)的過(guò)程中，副本A1和A3有新的更新，說(shuō)明Primary Chunk Server向Master重新申請(qǐng)Lease并增加了A1和A3的版本號(hào)，等到A2重新上線(xiàn)后，Master能夠發(fā)現(xiàn)A2的版本號(hào)太低，從而將A2標(biāo)記為可刪除的chunk，Master的垃圾回收任務(wù)會(huì)定時(shí)檢查，并通知Chunk Server將A2回收掉。總結(jié)：GFS通過(guò)租賃機(jī)制來(lái)緩解Master的性能瓶頸。2.2.2. 一致性模型G

16、FS主要是為了追加（Append）而不是改寫(xiě)（Overwrite）而設(shè)計(jì)的。一方面是因?yàn)槭歉膶?xiě)的需求比較少，或者可以通過(guò)追加來(lái)實(shí)現(xiàn)，比如可以只使用GFS的追加功能構(gòu)建分布式表格系統(tǒng)Bigtable；另一方面是因?yàn)樽芳拥囊恢滦阅Ｐ拖啾雀膶?xiě)要更加簡(jiǎn)單有效。考慮Chunk A的三個(gè)副本A1，A2，A3，有一個(gè)改寫(xiě)操作修改了A1，A2但沒(méi)有修改A3，這樣，落到副本A3的讀操作可能讀到不正確的數(shù)據(jù)；相應(yīng)地，如果有一個(gè)追加操作往A1，A2上追加了一個(gè)記錄但是追加A3失敗，那么即使讀操作落到副本A3也只是讀到過(guò)期而不是不正確的數(shù)據(jù)。我們只討論追加的一致性。如果不發(fā)生異常，追加成功的記錄在GFS的各個(gè)副本中是

17、確定并且嚴(yán)格一致的；但是如果出現(xiàn)了異常，可能出現(xiàn)某些副本追加成功而某些副本沒(méi)有成功的情況，失敗的副本可能會(huì)出現(xiàn)一些可識(shí)別的填充(padding)記錄。GFS客戶(hù)端追加失敗將重試，只要返回用戶(hù)追加成功，說(shuō)明在所有副本中都至少追加成功了一次。當(dāng)然，可能出現(xiàn)記錄在某些chunk副本中被追加了多次，即重復(fù)記錄；也可能出現(xiàn)一些可識(shí)別的填充記錄，應(yīng)用層需要能夠處理這些問(wèn)題。另外，由于GFS支持多個(gè)客戶(hù)端并發(fā)追加，那么多個(gè)客戶(hù)端之間的順序是無(wú)法保證的，同一個(gè)客戶(hù)端連續(xù)追加成功的多個(gè)記錄也可能被打斷，比如客戶(hù)端先后追加成功記錄R1和R2，由于追加R1和R2這兩條記錄的過(guò)程不是原子的，中途可能被其它客戶(hù)端打斷，

18、那么GFS的chunk中記錄的R1和R2可能不連續(xù)，中間夾雜著其它客戶(hù)端追加的數(shù)據(jù)。GFS的這種一致性模型是追求性能導(dǎo)致的，這也增加了應(yīng)用程序開(kāi)發(fā)的難度。對(duì)于MapReduce應(yīng)用，由于其批處理特性，可以先將數(shù)據(jù)追加到一個(gè)臨時(shí)文件，在臨時(shí)文件中維護(hù)索引記錄每個(gè)追加成功的記錄的偏移，等到文件關(guān)閉時(shí)一次性將臨時(shí)文件改名為最終文件?？偨Y(jié)：GFS倡導(dǎo)一次寫(xiě)入多次讀取，對(duì)改寫(xiě)的一致性處理性能不高。對(duì)于追加，它采用的是一種寬松的一致性模型，追加過(guò)程可能會(huì)導(dǎo)致少量的重復(fù)記錄，也可能出現(xiàn)一些可識(shí)別的填充記錄。2.2.3. 追加流程追加流程是GFS系統(tǒng)中最為復(fù)雜的地方，而且，高效支持記錄追加對(duì)于基于GFS實(shí)現(xiàn)B

19、igtable是至關(guān)重要的。追加流程大致如下：客戶(hù)端向Master請(qǐng)求chunk每個(gè)副本所在的Chunk Server，其中Primary Chunk Server持有修改Lease。如果沒(méi)有Chunk Server持有Lease，說(shuō)明該chunk最近沒(méi)有寫(xiě)操作，Master會(huì)發(fā)起一個(gè)任務(wù)，按照一定的策略將chunk的Lease授權(quán)給其中一臺(tái)chunk Server。Master返回客戶(hù)端Primary和其它Chunk Server的位置信息，客戶(hù)端將緩存這些信息供以后使用。如果不出現(xiàn)故障，客戶(hù)端以后讀寫(xiě)該chunk都不需要再次請(qǐng)求Master。客戶(hù)端將要追加的記錄發(fā)送到每一個(gè)副本。每一個(gè)Ch

20、unk Server會(huì)在內(nèi)部的LRU結(jié)構(gòu)中緩存這些數(shù)據(jù)。GFS中采用數(shù)據(jù)流和控制流分離的方法，從而能夠基于網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)更好地調(diào)度數(shù)據(jù)流的傳輸。當(dāng)所有副本都確認(rèn)收到了數(shù)據(jù)，客戶(hù)端發(fā)起一個(gè)寫(xiě)請(qǐng)求控制命令給Primary。由于Primary可能收到多個(gè)客戶(hù)端對(duì)同一個(gè)chunk的并發(fā)追加操作，Primary將確定這些操作的順序并寫(xiě)入本地；Primary把寫(xiě)請(qǐng)求提交給所有的Secondary副本。每一個(gè)Secondary會(huì)根據(jù)Primary確定的順序執(zhí)行寫(xiě)操作；Secondary副本成功完成后應(yīng)答Primary；Primary應(yīng)答客戶(hù)端，如果有副本發(fā)生錯(cuò)誤，將出現(xiàn)Primary寫(xiě)成功但是某些Second

21、ary不成功的情況，客戶(hù)端將重試。GFS追加流程有兩個(gè)特色：流水線(xiàn)及分離數(shù)據(jù)流與控制流。流水線(xiàn)操作用來(lái)減少延時(shí)。當(dāng)一個(gè)ChunkServer接收到一些數(shù)據(jù)，它就立即開(kāi)始轉(zhuǎn)發(fā)。由于采用全雙工網(wǎng)絡(luò)，立即發(fā)送數(shù)據(jù)并不會(huì)降低接收數(shù)據(jù)的速率。拋開(kāi)網(wǎng)絡(luò)阻塞，傳輸B個(gè)字節(jié)到R個(gè)副本的理想時(shí)間是B/T + RL，其中T是網(wǎng)絡(luò)吞吐量，L是亮點(diǎn)之間的延時(shí)。假設(shè)采用千兆網(wǎng)絡(luò)，L通常小于1ms，傳輸1MB數(shù)據(jù)到多個(gè)副本的時(shí)間小于80ms。分離數(shù)據(jù)流與控制流主要是為了優(yōu)化數(shù)據(jù)傳輸，每一個(gè)機(jī)器都是把數(shù)據(jù)發(fā)送給網(wǎng)絡(luò)拓?fù)鋱D上”最近”的尚未收到數(shù)據(jù)的數(shù)據(jù)。舉個(gè)例子，假設(shè)有三臺(tái)ChunkServer S1，S2和S3，S1與S3

22、在同一個(gè)機(jī)架上，S2在另外一個(gè)機(jī)架，客戶(hù)端部署在機(jī)器S1上。如果數(shù)據(jù)先從S1轉(zhuǎn)發(fā)到S2，再?gòu)腟2轉(zhuǎn)發(fā)到S3，需要經(jīng)歷兩次跨機(jī)架數(shù)據(jù)傳輸；相對(duì)地，按照GFS中的策略，數(shù)據(jù)先發(fā)送到S1，接著從S1轉(zhuǎn)發(fā)到S3，最后轉(zhuǎn)發(fā)到S2，只需要一次跨機(jī)架數(shù)據(jù)傳輸?？偨Y(jié)：GFS的追加流程非常精致：控制與數(shù)據(jù)分離，利用流水線(xiàn)（pipe line）方式進(jìn)行數(shù)據(jù)傳輸，傳輸?shù)耐負(fù)浣Y(jié)構(gòu)精心設(shè)計(jì)。這一系列措施都是盡最大可能減少系統(tǒng)瓶頸，加快網(wǎng)絡(luò)傳輸速度，以提高整體性能。2.2.4. 容錯(cuò)機(jī)制Master的容錯(cuò)與傳統(tǒng)的方法類(lèi)似，通過(guò)操作日志加checkpoint的方式進(jìn)行，并且有一臺(tái)稱(chēng)為”Shadow Master”的實(shí)時(shí)熱備

23、。Master上保存了三種元數(shù)據(jù)信息：(1) 命名空間（Name Space），也就是整個(gè)文件系統(tǒng)的目錄結(jié)構(gòu)以及chunk基本信息；(2) 文件到chunk之間的映射；(3) Chunk副本的位置信息，每個(gè)Chunk通常有三個(gè)副本；GFS Master的修改操作總是先記錄操作日志，然后再修改內(nèi)存，當(dāng)Master發(fā)生故障重啟時(shí)，可以通過(guò)磁盤(pán)中的操作日志恢復(fù)內(nèi)存數(shù)據(jù)結(jié)構(gòu)；另外，為了減少M(fèi)aster宕機(jī)恢復(fù)時(shí)間，Master會(huì)定期將內(nèi)存中的數(shù)據(jù)以checkpoint文件的形式轉(zhuǎn)儲(chǔ)到磁盤(pán)中，從而減少回放的日志量。為了進(jìn)一步提高M(jìn)aster的可靠性和可用性，GFS中還會(huì)執(zhí)行實(shí)時(shí)熱備，所有的元數(shù)據(jù)修改操作

24、都必須保證發(fā)送到實(shí)時(shí)熱備才算成功。遠(yuǎn)程的實(shí)時(shí)熱備將實(shí)時(shí)接收Master發(fā)送的操作日志并在內(nèi)存中回放這些元數(shù)據(jù)操作。如果Master宕機(jī)，還可以秒級(jí)切換到實(shí)時(shí)備機(jī)繼續(xù)提供服務(wù)。為了保證同一時(shí)刻只有一個(gè)Master，GFS依賴(lài)Google內(nèi)部的Chubby服務(wù)進(jìn)行選主操作。Master需要持久化前兩種元數(shù)據(jù)，即命令空間及文件到chunk之間的映射關(guān)系；對(duì)于第三種元數(shù)據(jù)，即Chunk副本的位置信息，Master可以選擇不進(jìn)行持久化，這是因?yàn)镃hunkServer維護(hù)了這些信息，即使Master發(fā)生故障，也可以在重啟時(shí)通過(guò)ChunkServer匯報(bào)來(lái)獲取。GFS采用復(fù)制多個(gè)副本的方式實(shí)現(xiàn)Chunk S

25、erver的容錯(cuò)，每一個(gè)Chunk有多個(gè)存儲(chǔ)副本，分別存儲(chǔ)在不同的Chunk Server上。對(duì)于每一個(gè)Chunk，必須將所有的副本全部寫(xiě)入成功，才視為成功寫(xiě)入。如果相關(guān)的副本出現(xiàn)丟失或不可恢復(fù)的情況，Master自動(dòng)將給副本復(fù)制到其它Chunk Server，從而確保副本保持一定的個(gè)數(shù)。另外，Chunk Server會(huì)對(duì)存儲(chǔ)的數(shù)據(jù)維持校驗(yàn)和。GFS以64MB為Chunk大小來(lái)劃分文件，每一個(gè)Chunk又以Block為單位進(jìn)行劃分，大小為64KB，每一個(gè)Block對(duì)應(yīng)一個(gè)32位的校驗(yàn)和。當(dāng)讀取一個(gè)Chunk副本時(shí)，Chunk Server會(huì)將讀取的數(shù)據(jù)和校驗(yàn)和進(jìn)行比較，如果不匹配，就會(huì)返回錯(cuò)誤

26、，客戶(hù)端將選擇其它Chunk Server上的副本?？偨Y(jié)：Master Server和Chunk Server都提供了相應(yīng)的容錯(cuò)機(jī)制，能實(shí)現(xiàn)完全自動(dòng)的容錯(cuò)處理和切換，響應(yīng)切換速度為秒級(jí)。2.2.5. Master內(nèi)存占用Master維護(hù)了系統(tǒng)中的元數(shù)據(jù)，包括文件及chunk名字空間，文件到chunk的映射，chunk副本的位置信息。其中前兩種元數(shù)據(jù)需要持久化到磁盤(pán)，chunk副本的位置信息不需要持久化，可以通過(guò)Chunk Server匯報(bào)獲取。內(nèi)存是Master的稀有資源，下面估算Master的內(nèi)存使用量。Chunk的元信息包括全局唯一的ID，版本號(hào)，每個(gè)副本所在的Chunk Server編號(hào)

27、，引用計(jì)數(shù)等。GFS系統(tǒng)中每個(gè)chunk大小為64MB，默認(rèn)存儲(chǔ)3份，每個(gè)chunk的元數(shù)據(jù)小于64字節(jié)。那么1PB數(shù)據(jù)的chunk元信息大小不超過(guò)1PB * 3 / 64MB * 64 = 3GB。另外，Master對(duì)命名空間進(jìn)行了壓縮存儲(chǔ)，例如有兩個(gè)文件foo1和foo2都存放在目錄/home/very_long_directory_name/中，那么目錄名在內(nèi)存中只需要存放一次。壓縮存儲(chǔ)后，每個(gè)文件在文件名字空間的元數(shù)據(jù)也不超過(guò)64字節(jié)，由于GFS中的文件一般都是大文件，因此，文件名字空間占用內(nèi)存不多。這也就說(shuō)明了Master內(nèi)存容量不會(huì)成為GFS的系統(tǒng)瓶頸。總結(jié)：為了提高性能，Mast

28、er Server需要將部分元數(shù)據(jù)緩存到內(nèi)存，因此需要較大的內(nèi)存。Chunk Server則不需要進(jìn)行數(shù)據(jù)緩存。2.2.6. 負(fù)載均衡GFS中副本的分布策略需要考慮多種因素，如網(wǎng)絡(luò)的拓?fù)?，機(jī)架的分布，磁盤(pán)的利用率等等。為了提高系統(tǒng)的可用性，GFS會(huì)避免同一個(gè)chunk的所有副本都存放在同一個(gè)機(jī)架的情況。系統(tǒng)中有三種需要?jiǎng)?chuàng)建chunk副本的情況：chunk創(chuàng)建，chunk重新復(fù)制（re-replication）以及重新平衡（rebalancing）。當(dāng)Master創(chuàng)建了一個(gè)chunk，它會(huì)根據(jù)如下因素來(lái)選擇chunk副本的初始位置：(1) 新副本所在的Chunk Server的磁盤(pán)利用率低于平均

29、水平；(2) 限制每個(gè)Chunk Server”最近”創(chuàng)建的數(shù)量。（3）每個(gè)chunk的所有副本不能在同一個(gè)機(jī)架。第二點(diǎn)容易忽略但卻很重要，因?yàn)閯?chuàng)建完chunk以后通常需要馬上寫(xiě)入數(shù)據(jù)，如果不限制”最近”創(chuàng)建的數(shù)量，當(dāng)一臺(tái)空的Chunk Server上線(xiàn)時(shí)，由于磁盤(pán)利用率低，可能導(dǎo)致大量的chunk瞬間遷移到這臺(tái)機(jī)器從而將它壓垮。當(dāng)Chunk的副本數(shù)量小于一定的數(shù)量后，Master會(huì)嘗試重新復(fù)制一個(gè)chunk副本。可能的原因包括Chunk Server宕機(jī)或者Chunk Server報(bào)告自己的副本損壞，或者它的某個(gè)磁盤(pán)故障，或者用戶(hù)動(dòng)態(tài)增加了Chunk的副本數(shù)，等等。每一個(gè)chunk復(fù)制任務(wù)都

30、有一個(gè)優(yōu)先級(jí)，按照優(yōu)先級(jí)從高到低在Master排隊(duì)等待執(zhí)行。例如，只有一個(gè)副本的chunk需要優(yōu)先復(fù)制，又如，有效文件的chunk復(fù)制優(yōu)先級(jí)比最近刪除的文件的chunk高，最后，GFS會(huì)提高所有阻塞客戶(hù)端操作的chunk復(fù)制任務(wù)的優(yōu)先級(jí)，例如客戶(hù)端正在往一個(gè)只有一個(gè)副本的chunk追加數(shù)據(jù)，如果限制至少需要追加成功兩個(gè)副本，那么這個(gè)chunk復(fù)制任務(wù)會(huì)阻塞客戶(hù)端寫(xiě)操作，需要提高優(yōu)先級(jí)。最后，Master會(huì)定期掃描當(dāng)前副本的分布情況，如果發(fā)現(xiàn)磁盤(pán)使用量或者機(jī)器負(fù)載不均衡，將執(zhí)行重新平衡操作。無(wú)論是chunk創(chuàng)建，chunk重新復(fù)制，還是重新平衡，它們選擇chunk副本位置的策略都是相同的，并且需

31、要限制重新復(fù)制和重新平衡任務(wù)的拷貝速度，否則可能影響系統(tǒng)正常的讀寫(xiě)服務(wù)?？偨Y(jié)：GFS的負(fù)載均衡策略十分完備，已被眾多開(kāi)源實(shí)現(xiàn)所模仿。2.2.7. 垃圾回收GFS采用延遲刪除的機(jī)制，也就是說(shuō)，當(dāng)文件被刪除后，GFS并不要求立即歸還可用的物理存儲(chǔ)，而是在元數(shù)據(jù)中將文件改名為一個(gè)隱藏的名字，并且包含一個(gè)刪除時(shí)間戳。Master定時(shí)檢查，如果發(fā)現(xiàn)文件刪除超過(guò)一段時(shí)間（默認(rèn)為3天，可配置），那么它會(huì)把文件從內(nèi)存元數(shù)據(jù)中刪除，以后Chunk Server和Master的心跳消息中，每一個(gè)Chunk Server都將報(bào)告自己的chunk集合，Master會(huì)回復(fù)在Master元數(shù)據(jù)中已經(jīng)不存在的chunk信息

32、，這時(shí)，Chunk Server會(huì)釋放這些Chunk副本。為了減輕系統(tǒng)的負(fù)載，垃圾回收一般在服務(wù)低峰期執(zhí)行，比如每天晚上凌晨1:00開(kāi)始。另外，Chunk副本可能會(huì)因?yàn)镃hunk Server失效期間丟失了對(duì)Chunk的修改操作而導(dǎo)致過(guò)期。系統(tǒng)對(duì)每個(gè)Chunk都維護(hù)了版本號(hào)，過(guò)期的Chunk可以通過(guò)版本號(hào)檢測(cè)出來(lái)。Master仍然通過(guò)正常的垃圾回收機(jī)制來(lái)刪除過(guò)期的副本?？偨Y(jié)：GFS的垃圾回收機(jī)制被眾多開(kāi)源實(shí)現(xiàn)所模仿。2.2.8. 快照快照（Snapshot）操作是對(duì)源文件/目錄進(jìn)行一個(gè)”快照”操作，生成該時(shí)刻源文件/目錄的一個(gè)瞬間狀態(tài)存放與目標(biāo)文件/目錄中。GFS中使用標(biāo)準(zhǔn)的copy-on-w

33、rite機(jī)制生成快照，也就是說(shuō)，”快照”只是增加GFS中chunk的引用計(jì)數(shù)，表示這個(gè)chunk被快照文件引用了，等到客戶(hù)端修改這個(gè)chunk時(shí)，才需要在Chunk Server中拷貝chunk的數(shù)據(jù)生成新的chunk，后續(xù)的修改操作落到新生成的chunk上。為了對(duì)某個(gè)文件做Snapshot，首先需要停止這個(gè)文件的寫(xiě)服務(wù)，接著增加這個(gè)文件的所有chunk的引用計(jì)數(shù)，以后修改這些chunk時(shí)會(huì)拷貝生成新的chunk。對(duì)某個(gè)文件執(zhí)行Snapshot的大致步驟如下：1, 通過(guò)Lease機(jī)制收回對(duì)文件每一個(gè)chunk寫(xiě)權(quán)限，停止對(duì)文件的寫(xiě)服務(wù)；2, Master拷貝文件名等元數(shù)據(jù)生成一個(gè)新的Snaps

34、hot文件；3, 對(duì)執(zhí)行Snapshot的文件的所有chunk增加引用計(jì)數(shù)；例如，對(duì)文件foo執(zhí)行快照操作生成foo_backup，foo在GFS中有三個(gè)chunk C1，C2和C3。Master首先需要收回C1，C2和C3的寫(xiě)Lease，從而保證文件foo處于一致的狀態(tài)，接著Master復(fù)制foo文件的元數(shù)據(jù)生成foo_backup，foo_backup同樣指向C1，C2和C3?？煺涨埃珻1，C2和C3只被一個(gè)文件foo引用，因此引用計(jì)數(shù)為1；執(zhí)行快照操作后，這些chunk的引用計(jì)數(shù)增加為2。以后客戶(hù)端再次往C3追加數(shù)據(jù)時(shí)，Master發(fā)現(xiàn)C3的引用計(jì)數(shù)大于1，通知C3所在的Chunk Se

35、rver本次拷貝C3生成C3，客戶(hù)端的追加操作也相應(yīng)地轉(zhuǎn)向C3?？偨Y(jié)：GFS采用快照技術(shù)來(lái)實(shí)現(xiàn)數(shù)據(jù)的回滾。2.2.9. ChunkServerChunkServer管理大小均為64MB的chunk，存儲(chǔ)的時(shí)候需要保證chunk盡可能均勻地分布在不同的磁盤(pán)之中，可能考慮的因素包括磁盤(pán)空間，最近新建chunk數(shù)，等。另外，Linux文件系統(tǒng)刪除64MB大文件消耗的時(shí)間太長(zhǎng)，且沒(méi)有必要，刪除Chunk可以只將對(duì)應(yīng)的chunk文件移動(dòng)到每個(gè)磁盤(pán)中的回收站，以后新建chunk的時(shí)候可以重用。ChunkServer是一個(gè)磁盤(pán)和網(wǎng)絡(luò)IO密集型應(yīng)用，為了最大限度地發(fā)揮機(jī)器性能，需要能夠做到將磁盤(pán)和網(wǎng)絡(luò)操作異步

36、化，這會(huì)增加代碼實(shí)現(xiàn)的難度。總結(jié)：Ø GFS并不是直接保存源文件，而是將文件分塊存儲(chǔ)。對(duì)于基于大文件的應(yīng)用，普遍都采用類(lèi)似技術(shù)進(jìn)行存儲(chǔ)。對(duì)于小文件，則實(shí)現(xiàn)方案不一。Ø ChunkServer的磁盤(pán)IO是瓶頸之一，采用追加方式，避免隨機(jī)寫(xiě)是比較普遍的解決方案。2.3. GFS學(xué)習(xí)總結(jié)Google的GFS論文詳細(xì)介紹了google分布式文件系統(tǒng)的各個(gè)實(shí)現(xiàn)方案和動(dòng)機(jī)，以上僅是個(gè)人選擇認(rèn)為比較重要的幾點(diǎn)加以描述，詳細(xì)的描述只能是去拜讀第一手資料了。通過(guò)近期的學(xué)習(xí)，對(duì)于分布式文件系統(tǒng)，有了那么一些粗淺的體會(huì)。Ø 傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)是單機(jī)應(yīng)用的產(chǎn)物，分布式文件系統(tǒng)是當(dāng)前大數(shù)據(jù)

37、應(yīng)用的主流。Ø 容錯(cuò)機(jī)制、負(fù)載均衡、垃圾回收、數(shù)據(jù)一致性是云存儲(chǔ)的基本要求。沒(méi)有這些機(jī)制的系統(tǒng)不是云存儲(chǔ)系統(tǒng)。Ø 對(duì)于云存儲(chǔ)系統(tǒng)，一般都有類(lèi)似MasterServer這樣的元數(shù)據(jù)管理Server，對(duì)它的訪(fǎng)問(wèn)是否優(yōu)化，直接影響到系統(tǒng)的性能。大部分系統(tǒng)都有MasterServer的冗余備份，有的是主備機(jī)制，有的是平行機(jī)制。主備機(jī)制的，有的支持故障服務(wù)的自動(dòng)切換，有的則需要人工干預(yù)。Ø 有的系統(tǒng)提供類(lèi)似快照的回滾機(jī)制，有的則不具備。Ø 多數(shù)系統(tǒng)采用類(lèi)似ChunkServer這樣的分塊存儲(chǔ)，也有直接保存原文件的。Ø 分布式文件系統(tǒng)的語(yǔ)言實(shí)現(xiàn)多種多樣，但

38、以Java和C的居多。Java的移植性好，C的性能卓越。對(duì)于基于C實(shí)現(xiàn)的系統(tǒng)，就要檢查它在文件操作上是否支持POSIX或者FUSE，這直接決定了它在各操作系統(tǒng)之間的移植性問(wèn)題。很不幸，出于性能的考慮，不少產(chǎn)品沒(méi)有實(shí)現(xiàn)POSIX或者FUSE，因而安裝上往往很不方便。性能和易用，就看哪個(gè)產(chǎn)品解決得好了。3. 開(kāi)源的分布式文件存儲(chǔ)系統(tǒng)3.1. 前言開(kāi)源的分布式文件存儲(chǔ)系統(tǒng)非常多，也多有各自的用戶(hù)群體。這么短的調(diào)研時(shí)間不足以將所有的產(chǎn)品挖掘出來(lái)，只能重點(diǎn)列舉幾個(gè)，再重點(diǎn)的橫向比較一些。本文優(yōu)先介紹那些流行的產(chǎn)品，但是我在調(diào)研過(guò)程深深感到，這個(gè)互聯(lián)網(wǎng)領(lǐng)域火熱的應(yīng)用發(fā)展實(shí)在太快了，相對(duì)來(lái)說(shuō)也太紛亂了些，今

39、天總結(jié)的成果也許過(guò)段時(shí)間就變了，有更好的產(chǎn)品出現(xiàn)了。3.2. Hadoop HDFS3.2.1. 介紹編程語(yǔ)言：JavaHadoop是當(dāng)前互聯(lián)網(wǎng)上最流行的海量數(shù)據(jù)分布式處理的軟件框架。Hadoop包括很多模塊，其中HDFS是它的分布式文件存儲(chǔ)系統(tǒng)。HDFS是模仿Google GFS實(shí)現(xiàn)的兩個(gè)產(chǎn)品之一，另一個(gè)是KFS。HDFS的設(shè)計(jì)理念和GFS是高度一致的，因此，理解了GFS的架構(gòu)，你就能理解HDFS的架構(gòu)。3.2.2. 特點(diǎn)Ø 流行，幾乎所有流行的分布式系統(tǒng)都可以和HDFS進(jìn)行對(duì)接；強(qiáng)大的社區(qū)支持，資料完備齊全。Ø 流式數(shù)據(jù)訪(fǎng)問(wèn)，設(shè)計(jì)中更多的考慮了數(shù)據(jù)批處理，而不是用戶(hù)交互

40、處理。更多的考慮高吞吐量，而不是數(shù)據(jù)訪(fǎng)問(wèn)的低延遲。Ø 更適合上G甚至上T的大文件。Ø 一次寫(xiě)入多次讀取，文件在經(jīng)過(guò)創(chuàng)建、寫(xiě)入和關(guān)閉后就不需要改變，簡(jiǎn)化了數(shù)據(jù)一致性問(wèn)題。Ø 采用master/slave架構(gòu)。當(dāng)前的穩(wěn)定版本1.0.4存在master單獨(dú)故障問(wèn)題，需要人工切換。不過(guò)HDFS版本繁多，有的版本則具備快速自動(dòng)切換功能。Ø 通信協(xié)議：基于TCP/IP長(zhǎng)鏈接。Ø 健壯性：n 支持：數(shù)據(jù)安全（容錯(cuò)機(jī)制）；集群均衡；數(shù)據(jù)完整性檢查和恢復(fù)；橫向擴(kuò)展n 不支持：Master節(jié)點(diǎn)自動(dòng)恢復(fù)；快照3.2.3. 性能HDFS作為一個(gè)Java語(yǔ)言開(kāi)發(fā)的產(chǎn)品，

41、有著鮮明的優(yōu)缺點(diǎn)。Ø 開(kāi)源合作更容易，更流行。Ø 資源占用率高，系統(tǒng)的內(nèi)存緩存量很大幾乎等于全部?jī)?nèi)存，iowait 也很高，這點(diǎn)和C+產(chǎn)品沒(méi)法比。3.3. KFS開(kāi)發(fā)語(yǔ)言： C+，可用C+、Java和Python訪(fǎng)問(wèn)客戶(hù)端。與HDFS相似，KFS也是以Google GFS理論為基礎(chǔ)的實(shí)現(xiàn)。因此和HDFS有這相同的架構(gòu)和特點(diǎn)。區(qū)別：Ø KFS本身的性能優(yōu)于HDFS，但若集成到hadoop中，性能卻未必出色。Ø 站在開(kāi)源角度，不及HDFS活躍。3.4. 流行的開(kāi)源文件存儲(chǔ)系統(tǒng)比較比較表一：HDFSKFSMooseFSMogileFSFastDFSTFSCep

42、hGlusterFS開(kāi)發(fā)語(yǔ)言JavaC+CPerlCC+C+C支持的Client語(yǔ)言C/C+、Java、Python支持thriftC+、Java、PythonC、Java、PerlPerl、Java、Ruby、PHP、PythonC、Java、PHPC+、Java文件系統(tǒng)操作放寬了POSIX約束（懷疑涉及本地實(shí)現(xiàn)）支持FUSE，可以直接使用mount命令掛載（懷疑涉及本地實(shí)現(xiàn)）支持FUSE，可以直接使用mount命令掛載支持POSIX支持FUSE，可以直接使用mount命令掛載支持軟鏈接和硬鏈接支持FUSE不支持POSIX、FUSE、不能mount使用可以在做了RAID的服務(wù)器上運(yùn)轉(zhuǎn)，但是認(rèn)為沒(méi)有必要不支持POSIX支持POSIX支持FUSE，可以直接使用mount命令掛載支持軟鏈接和硬鏈接支持POSIX支持FUSE，可以直接使用mount命令掛載磁盤(pán)上保存client上傳的原文件容錯(cuò)機(jī)制支持支持支持支持支持支持支持支持集群/負(fù)載均衡支持支持支持支持支持支持支持支持?jǐn)U容能力支持動(dòng)態(tài)的增減支持動(dòng)態(tài)的增減支持動(dòng)態(tài)的增減支持動(dòng)態(tài)的增減支持動(dòng)態(tài)的增減支持動(dòng)態(tài)的增減支持動(dòng)態(tài)的增減高可用存在Namenode單點(diǎn)故障，需人工干預(yù)不能確定