2024谷歌Bigtable中文系統(tǒng)

GoogleBigtable中文版目錄TOC\o"1-3"\h\u261971 1175822 127988 212833 2130563.1 330973.2 3207523.3 4258814 4177045BigTable 5168106 7252186.1 7142226.2 8249946.3 10143226.4 1117377 11303637.1 11238287.2 12263837.3 12131498 15267278.1 16126348.2 17154849 17201179.1 1834529.2Google 185529.3 19747010 203108411 212136712 22GoogleGoogleBigtable1.0GoogleBigtable務(wù)器上的PB級(jí)的數(shù)據(jù)。Google的很多項(xiàng)目使用Bigtable存儲(chǔ)數(shù)據(jù)，包括Web索引、GoogleEarth、GoogleFinance。這些應(yīng)用對(duì)Bigtable提出的要求差異非常大，無(wú)論是在數(shù)據(jù)量上（URL到網(wǎng)頁(yè)到衛(wèi)星圖像）還是在響應(yīng)速度上（從后本論文描述了Bigtable我們還將描述Bigtable的設(shè)計(jì)和實(shí)現(xiàn)。Google，我們Bigtable。Bigtable的設(shè)計(jì)目的是可靠的處理PB級(jí)別的數(shù)據(jù)，并且能夠部署到上千臺(tái)機(jī)器上。BigtableBigtable60個(gè)GoogleGoogleAnalytics、GoogleFinance、Orkut、PersonalizedSearch、WritelyGoogleEarth。這些產(chǎn)品對(duì)Bigtable提出了迥異的需求，有的需要高吞Bigtable集群的配置也有很大的差異，有的集群只有幾臺(tái)服務(wù)器，而有的則需要上千臺(tái)服務(wù)器、存儲(chǔ)幾百TB的數(shù)據(jù)。在很多方面，Bigtable和數(shù)據(jù)庫(kù)很類(lèi)似：它使用了很多數(shù)據(jù)庫(kù)的實(shí)現(xiàn)策略。并行數(shù)據(jù)庫(kù)【14】和內(nèi)存數(shù)據(jù)庫(kù)【13】已經(jīng)具備可擴(kuò)展性和高性能，但是Bigtable提供了一個(gè)和這些系統(tǒng)完全不同的接口。Bigtable不支3節(jié)描述關(guān)于數(shù)據(jù)模型更多細(xì)節(jié)方面的東西；4節(jié)概要介紹了客戶端API；5節(jié)簡(jiǎn)要介紹了BigTable底層使用的Google的基礎(chǔ)框架；6節(jié)描述了BigTable實(shí)現(xiàn)的關(guān)鍵部分；7BigTable的性能采用的一些精細(xì)的調(diào)優(yōu)方法；8節(jié)提供了BigTable的性能數(shù)據(jù)；9節(jié)講述了幾個(gè)Google內(nèi)部使用BigTable以及時(shí)間戳；Mapvalue都是一個(gè)未經(jīng)解析的Bigtable的系統(tǒng)的種種潛在用途之后，決定使用這個(gè)數(shù)據(jù)模型。我們先舉個(gè)WebtableWebtableURL作為行關(guān)鍵1WebURL。contents列族存放的是網(wǎng)頁(yè)的內(nèi)容，anchor列族存放引用該網(wǎng)頁(yè)的錨鏈接文本7。CNN的主頁(yè)被SportsIllustrator和MY-look的主頁(yè)引用，因此該行包含了名為“anchor:”和t6標(biāo)識(shí)。表中的行關(guān)鍵字可以是任意的字符串（64KB的字符串，但是對(duì)大多數(shù)用戶，10-100個(gè)字BgabeabeabetebabeURLap.goge.condex.hlo.googe.apndex.hl訪問(wèn)控制、磁盤(pán)和內(nèi)存的使用統(tǒng)計(jì)都是在列族層面進(jìn)行的。在我們的Webtable的例子中，上述的控制權(quán)Bigtable中，表的每一個(gè)數(shù)據(jù)項(xiàng)都可以包含同一份數(shù)據(jù)的不同版本；不同版本的數(shù)據(jù)通過(guò)時(shí)間戳來(lái)索n個(gè)版本的數(shù)據(jù)，或者只保存“足夠新”的版本的數(shù)據(jù)（7天的內(nèi)容寫(xiě)入的數(shù)據(jù)。Webtable的舉例里，contents:列存儲(chǔ)的時(shí)間戳信息是網(wǎng)絡(luò)爬蟲(chóng)抓取一個(gè)頁(yè)面的時(shí)間。上面提及的垃圾B(niǎo)igtableAPI函數(shù)。Bigtable////OpentheTable*T=//WriteanewanchoranddeleteanoldanchorRowMutationr1(T,“n.www”);r1.Set(“anchor:\h”,“CNN”);\hOperationApply(&op,2WritingtoBigtableBigtable中的值、從每個(gè)行中查找值、或者遍\hScannerScannerScanStreamstream=scanner.FetchColumnFamily(“anchor”);for(;!stream->Done();stream->Next()){printf(“%s%s%lld%s\n”,3Readingfrom3中的C++代碼使用Scanner抽象對(duì)象遍歷一個(gè)行內(nèi)的所有錨點(diǎn)。客戶程序可以遍歷多個(gè)列族，有幾正則表達(dá)式*.10天的錨點(diǎn)。Bigtable還支持一些其它的特性，利用這些特性，用戶可以對(duì)數(shù)據(jù)進(jìn)行更復(fù)雜的處理。首先，Bigtable支雖然Bigtable提供了一個(gè)允許用戶跨行批量寫(xiě)入數(shù)據(jù)的接口，但是，Bigtable目前還不支持通用的跨行事務(wù)處理。其次，Bigtable允許把數(shù)據(jù)項(xiàng)用做整數(shù)計(jì)數(shù)器。最后，Bigtable允許用戶在服務(wù)器的地址空間內(nèi)執(zhí)行腳本GoogleSawzall【28SawzallAPIBigtable，但是它允許多種形式的數(shù)據(jù)轉(zhuǎn)換、基于任意表達(dá)式的數(shù)據(jù)BigtableMapReduce【12】一起使用，MapReduceGoogle開(kāi)發(fā)的大規(guī)模并行計(jì)算框架。我們已WrapperWrapper類(lèi)，BigtableMapReduce框架的輸入和輸出。BigTable各樣的分布式應(yīng)用程序，BigTable的進(jìn)程經(jīng)常要和其它應(yīng)用的進(jìn)程共享機(jī)器。BigTable依賴(lài)集群管理系統(tǒng)來(lái)MapMap是一個(gè)key-value映射的數(shù)據(jù)結(jié)構(gòu)，keyvalueByteSSTablekeyvaluekeykey-value對(duì)。從內(nèi)SSTable都放在內(nèi)存中，這樣就不必訪問(wèn)硬盤(pán)了。BigTableChubby【8Chubby服務(wù)包括5Master，并且處理請(qǐng)求。只有在大多數(shù)副本都是正常運(yùn)行的，并【9,23】來(lái)保證副本的一致性。Chubby提供了一個(gè)名字空間，里面包括了目錄和小文件。每個(gè)目錄或者文件可以當(dāng)成一個(gè)鎖，讀寫(xiě)文件的操作都是原子的。ChubbyChubby文件的一致性緩存。每個(gè)ChubbyChubby服務(wù)的會(huì)話。如果客戶程序不能在租約到期的時(shí)間內(nèi)重新簽訂會(huì)話的租約，這個(gè)會(huì)話就過(guò)期失效了9。當(dāng)一個(gè)會(huì)話失效時(shí)，它擁有的鎖和打開(kāi)的文件句柄都失效了。Chubby客戶存儲(chǔ)BigTable數(shù)據(jù)的自引導(dǎo)指令的位置（5.1節(jié)查找TabletTablet服務(wù)器失效時(shí)進(jìn)行善后（5.2節(jié)存儲(chǔ)BigTable的模式信息（每張表的列族信息Bigable0.0326%10。BigtableMasterTablet服務(wù)器。針對(duì)系統(tǒng)工作負(fù)載的變化情況，BigTable可以動(dòng)態(tài)的向集群中添加（或者刪除）Tablet服務(wù)器。MasterTabletTabletsTable服務(wù)器、對(duì)TabletGFS上的文件進(jìn)行垃圾收集。除此之外，它還處理對(duì)模TabletSingle-Master類(lèi)型的分布式存儲(chǔ)系統(tǒng)【17.21Master服務(wù)器：TabletBigTableMaster服務(wù)器來(lái)獲取TabletMaster服務(wù)器通信。在實(shí)際應(yīng)用中，Master服缺省情況下，每個(gè)Tablet100MB200MB。我們使用一個(gè)三層的、類(lèi)似Ｂ+樹(shù)[10]的結(jié)構(gòu)存儲(chǔ)Tablet的位置信息(4)第一層是一個(gè)存儲(chǔ)在Chubby中的文件，它包含了RootTablet的位置信息。RootTablet包含了一個(gè)特殊RootTablet實(shí)際上是METADATA表的第一個(gè)TabletRootTablet永遠(yuǎn)不會(huì)被分割—這就保證了Tablet的位置信息存儲(chǔ)結(jié)構(gòu)不會(huì)超過(guò)三層。2^34個(gè)Tablet的地址（Tablet128MB2^61字節(jié)數(shù)據(jù)。TabletTablet的地址信息，或者發(fā)現(xiàn)Tablet位置信息；如果客戶端緩存是數(shù)據(jù)的時(shí)候才能發(fā)現(xiàn)數(shù)據(jù)過(guò)期11TabletGFS文件Tablet的元數(shù)據(jù)的時(shí)候，它都會(huì)多讀取幾個(gè)Tablet的元數(shù)據(jù)。為該Tablet提供服務(wù)。這些信息有助于排查錯(cuò)誤和性能分析。Tablet只能分配給一個(gè)TabletMaster服務(wù)器記錄了當(dāng)前有哪些活躍的Tablet一個(gè)裝載請(qǐng)求，把Tablet分配給這個(gè)服務(wù)器。BigTable使用ChubbyTabletTablet服務(wù)器啟動(dòng)時(shí)，它在Chubby的一個(gè)Master（服務(wù)器目錄MasterTablet服務(wù)器加入了。如果Tablet服務(wù)器丟失了Chubby上的獨(dú)占鎖—比如由于網(wǎng)絡(luò)斷開(kāi)導(dǎo)致Tablet服務(wù)器和Chubby的會(huì)話丟失—它就停止對(duì)Tablet（Chubby提供了一種高效的機(jī)制，利用這種機(jī)制，Tablet服務(wù)器能夠在不增加網(wǎng)絡(luò)負(fù)擔(dān)的情況下知道它是否還持有鎖。只要文件還存在，Tablet服務(wù)器就會(huì)試圖重新獲得對(duì)該文件的獨(dú)占鎖；如果文件不存在了，那么Tablet分配到其它的Tablet服務(wù)器。MasterTabletTablet提供服務(wù)了，并且要盡快重新分配Tablet。MasterTabletTabletTabletTabletMaster服務(wù)器最近幾次嘗試和它通信都沒(méi)有得到響應(yīng)，MasterTabletMaster服務(wù)器成功獲取了獨(dú)占鎖，ChubbyTabletChubbyMaster服務(wù)器就刪除該TabletChubbyTabletTablet服務(wù)器Chubby上的服務(wù)器文件被刪除了，MasterTabletTabletBigtableMasterChubby之間網(wǎng)絡(luò)出現(xiàn)故障的時(shí)候仍然可以使用，Master服務(wù)器在它的Chubby會(huì)話過(guò)期后主動(dòng)退出。但是不管怎樣，如同我們前面所描述的，Master服務(wù)器的故障不Tablet在Tablet服務(wù)器上的分配狀態(tài)。Master服務(wù)器之后，Master服務(wù)器首先要了解當(dāng)前Tablet的分配狀態(tài)，之后才能夠修改分配狀態(tài)。Master服務(wù)器在啟動(dòng)的時(shí)候執(zhí)行以下步驟：Master服務(wù)器從ChubbyMasterMasterMasterTabletTabletTablet的分配信未分配的Tablet集合等待合適的時(shí)機(jī)分配。4Tablet加入到未分配的Tablet集合。這個(gè)附加操作確保了RootTablet會(huì)被分配。由于RootTablet包括了所有Tablet的名字了。保存現(xiàn)有Tablet的集合只有在以下事件發(fā)生時(shí)才會(huì)改變：建立了一個(gè)新表或者刪除了一個(gè)舊表、兩個(gè)Tablet被合并了、或者一個(gè)Tablet被分割成兩個(gè)小的Tablet。Master服務(wù)器可以跟蹤記錄所有這些事件，因?yàn)镸asterTablet并不完整，因此，Tablet服務(wù)器會(huì)重新向Master服務(wù)器發(fā)送通知信息。5所示，TabletGFSREDO日志中14。在這些更新操作中，最近提交的那些存放在一個(gè)排序的緩存中，我們稱(chēng)這個(gè)緩存為memtable；較早的更新存放在一系列含了組成這個(gè)Tablet的SSTable的列表，以及一系列的RedoPoint15，這些RedoPoint指向可能含有該Tabletmemtable。當(dāng)對(duì)Tablet服務(wù)器進(jìn)行寫(xiě)操作時(shí)，Tablet驗(yàn)證（Chubby客戶緩存里。成功的修改操作會(huì)記錄在提交日志里。可以采用批memtable里面。當(dāng)對(duì)Tablet服務(wù)器進(jìn)行讀操作時(shí)，TabletmemtableCompaction過(guò)程有兩個(gè)目的：shrink19Tablet服務(wù)器使用的內(nèi)存，以及在服務(wù)器災(zāi)難恢復(fù)過(guò)程中，減少必須從提交日志里讀取的數(shù)據(jù)量。在Compaction過(guò)程中，正在進(jìn)行的讀寫(xiě)操作仍能繼續(xù)。MinorCompaction都會(huì)創(chuàng)建一個(gè)新的SSTableMinorCompaction過(guò)程不停滯的持續(xù)進(jìn)行下SSTableMergingCompaction過(guò)程合并文件，限制這類(lèi)文件的數(shù)量。MergingCompaction過(guò)程讀取一些SSTablememtable的內(nèi)容，合并成SSTable。只要MergingCompactionSSTablememtable就可以刪除了。SSTableSSTableMergingCompactionMajorCompaction。由非循環(huán)掃描它所有的TabletMajorCompaction。MajorCompactionBigtable回收BigTable能及時(shí)清除已經(jīng)刪除的數(shù)據(jù)21，這對(duì)存放敏感數(shù)據(jù)的服務(wù)是BigtableBigtable到達(dá)用戶要求的高性能、Bigtable實(shí)現(xiàn)的其它部分，為了更好的強(qiáng)調(diào)這些優(yōu)化工作，我們將深入細(xì)客戶程序可以將多個(gè)列族組合成一個(gè)局部性群族。對(duì)TabletSSTableWebtable表中，網(wǎng)頁(yè)的元數(shù)據(jù)（Checksum）可以在一個(gè)局部性群組中，網(wǎng)頁(yè)的內(nèi)容可以在另外一個(gè)群組：特別有用：在BigtableMETADATA表中具有位置相關(guān)性的列族的訪問(wèn)速度。SSTable是否需要壓縮；如果需要壓縮，那么以什么格式來(lái)壓縮。SSTable的塊（塊的大小由局部性群組的優(yōu)化參數(shù)指定）都使用用戶指定的壓縮格式來(lái)壓縮。雖然分塊壓縮浪費(fèi)了少量空間22，但是，我們?cè)谥蛔x取SSTable的一小部分?jǐn)?shù)據(jù)的時(shí)候就不必解壓整個(gè)文件了。很多客戶程序使用了“兩遍”的、可定制的壓縮方式。第一遍采用BentleyandMcIlroy’s方式[6]，這種方式在一個(gè)16KB的小掃描窗口中尋找重復(fù)數(shù)據(jù)。兩個(gè)壓縮的算法都很快，在現(xiàn)在的機(jī)器上，壓縮的速率達(dá)到100-200MB/s，解壓的速率達(dá)400-1000MB/s。壓縮率上的表現(xiàn)也是令人驚嘆。比如，在Webtable的例子里，我們使用這種壓縮方式來(lái)存儲(chǔ)網(wǎng)頁(yè)內(nèi)容。在一存放方式：從同一個(gè)主機(jī)獲取的頁(yè)面都存在臨近的地方。利用這個(gè)特性，Bentley-McIlroy算法可以從來(lái)自同Webtable，其它的很多應(yīng)用程序也通過(guò)選擇合適的行名來(lái)Bigtable中存儲(chǔ)同一份數(shù)據(jù)的多個(gè)版本的時(shí)候，為了提高讀操作的性能，TabletSSTableKey-Value對(duì)；BlockGFSSSTableBloom過(guò)濾器6.3節(jié)所述，一個(gè)讀操作必須讀取構(gòu)成TabletSSTableSSTable不在內(nèi)存SSTableBloom7BloomSSTable是否包含了特定行和列的數(shù)據(jù)。對(duì)于Bloom過(guò)濾器的內(nèi)存的代價(jià)，就換來(lái)了讀操作顯著減少Bloom過(guò)濾器也隱式的達(dá)到了當(dāng)應(yīng)用程序訪問(wèn)不存在的行或列時(shí)，大多數(shù)時(shí)候我們Commit如果我們把對(duì)每個(gè)Tablet的操作的Commit日志文件時(shí)24Seek操作。另外，由于批量提交25中操作的數(shù)目一般比較少，因此，對(duì)每個(gè)TabletTabletCommit日志文件，把修改操作的日志以追加方式寫(xiě)入同一個(gè)日志文件，因此Tablet修改的日志記錄。Tablet服務(wù)器宕機(jī)時(shí)，Tablet修改操作的日志記錄都混合在同一個(gè)日志文件中的。一種方法TabletCommitTablet的相關(guān)修改操作。使100次（每個(gè)服務(wù)器讀取一次。64MBTablet服務(wù)器對(duì)段日志文件恢復(fù)Tablet時(shí)開(kāi)始執(zhí)行。在向GSCot（GSGSSbtabet服務(wù)abetMaster服務(wù)器將一個(gè)Tablet從一個(gè)Tablet服務(wù)器移到另外一個(gè)Tablet服務(wù)器時(shí)，源Tablet服務(wù)器會(huì)對(duì)這個(gè)Tablet做一次MinorCompactionCompaction操作減少了Tablet服務(wù)器的日志文件中沒(méi)有歸并的記MinorCompaction完成以后，TabletTablet服務(wù)器上了，并且不SSTable讀取數(shù)據(jù)的時(shí)候，我們不必對(duì)文件系統(tǒng)訪問(wèn)操作進(jìn)行同步。這樣一來(lái)，就可以非常高效的實(shí)現(xiàn)對(duì)行的并行操作。memtable是唯一一個(gè)能被讀和寫(xiě)操作同時(shí)訪問(wèn)的可變數(shù)據(jù)結(jié)SSTable是不變的，因此，我們可以把永久刪除被標(biāo)記為“刪除”的數(shù)據(jù)的問(wèn)題，轉(zhuǎn)換成對(duì)廢棄的記-SSTableSSTable【25METADATARootSSTableSSTable集合，而是共享原來(lái)的Tablet的SSTableTablet1GB17862IDE）2GZOpteron處理器，配置了足以容納所有進(jìn)程工作數(shù)據(jù)集的物理內(nèi)存，以及一張Gigabit的以太網(wǎng)卡。這些機(jī)器都連入一個(gè)兩層的、樹(shù)狀的交換網(wǎng)絡(luò)里，在1ms。Tablet服務(wù)器、MasterGFS服務(wù)器都運(yùn)行在同一組機(jī)器上。每臺(tái)機(jī)器都運(yùn)行一個(gè)GFSTablet服務(wù)器、要么運(yùn)行客戶程序、要么運(yùn)行在測(cè)試過(guò)程中，使用這組Tablet服務(wù)器讀/1GB左右。0R-110N個(gè)大小相同Hash，HashR取模的方式，這樣就保證了在整個(gè)基準(zhǔn)測(cè)BigTablevalue值的API。減少RPC調(diào)用的次數(shù)。memory因此，讀操作直接從Tablet服務(wù)器的內(nèi)存中讀取數(shù)據(jù)，不需要從GFS讀取數(shù)據(jù)。針對(duì)這個(gè)測(cè)試，我們把每臺(tái)TabletTabletTablet服務(wù)器的性能。隨機(jī)讀的性能比其它操作慢一個(gè)數(shù)量級(jí)或以上27讀操作都要通過(guò)網(wǎng)絡(luò)從GFS64KB的SSTableTablet1000byte的一減小Block8KB。取數(shù)據(jù)，不需要從GFS64KB的Block。Tablet服務(wù)器直接把寫(xiě)入操作的內(nèi)容追加到一個(gè)CommitGFS來(lái)提高性能。隨機(jī)Tablet服務(wù)器的Commit日志文件中。64次讀操作直接從緩存讀取數(shù)據(jù)。Tablet1500臺(tái)，系統(tǒng)的整體吞吐量有了夢(mèng)幻般的增長(zhǎng)，增長(zhǎng)的100。比如，隨著Tablet500300倍。之所以會(huì)有這樣的性能提升，主要是因?yàn)檫@個(gè)基準(zhǔn)測(cè)試的瓶頸是單臺(tái)Tablet服務(wù)器的CPU。Tablet1臺(tái)Tablet的移動(dòng)導(dǎo)致重新負(fù)載均衡能力受限（Tablet1秒內(nèi)—這個(gè)Tablet是不可用的Tablet服務(wù)器數(shù)量增加的提升幅度最?。ㄕw吞吐量100500倍1000-byte64KB大的Block1GB的鏈路，結(jié)果導(dǎo)致隨著我們Google組，我們看到整體的吞吐量超過(guò)了每秒1200000次請(qǐng)求，發(fā)送到系統(tǒng)的RPC請(qǐng)求導(dǎo)致的網(wǎng)絡(luò)負(fù)載達(dá)到了741MB/s，系統(tǒng)發(fā)出的RPC16GB/s。2提供了一些目前正在使用的表的相關(guān)數(shù)據(jù)。一些表存儲(chǔ)的是用戶相關(guān)的數(shù)據(jù)，另外一些存儲(chǔ)的則是的復(fù)雜程度上都有很大的差別。本節(jié)的其余部分，我們將主要描述三個(gè)產(chǎn)品研發(fā)團(tuán)隊(duì)如何使用Bigtable的。Web這個(gè)Javascript程序在頁(yè)面被訪問(wèn)的時(shí)候調(diào)用。它記錄了各種GoogleAnalytics需要使用的信息，比如用戶的標(biāo)識(shí)、獲取的網(wǎng)頁(yè)的相關(guān)信息。GoogleAnalytics匯總這些數(shù)據(jù)，之后提供給Web站點(diǎn)的管理員。我們粗略的描述一下GoogleAnalytics使用的兩個(gè)表。RowClick表（200TB數(shù)據(jù)）的每一行存放對(duì)同一個(gè)Web14%。Summary表（20TB的數(shù)據(jù)）包含了關(guān)于每個(gè)Web站點(diǎn)的、各種類(lèi)型的預(yù)定義匯總信息。一個(gè)周MapReduceRawClickSummaryMapReduce工作進(jìn)程都RawClickGFS的吞吐量。這個(gè)表的能夠壓縮到原有29%。GoogleGoogleWeb的（70TB的數(shù)據(jù)，所以需要從磁盤(pán)讀取數(shù)據(jù)。圖像已經(jīng)被高效壓縮過(guò)了，因此存儲(chǔ)在Bigtable后不需要再壓縮了。Imagery表的每一行都代表了一個(gè)單獨(dú)的地理區(qū)域。行都有名稱(chēng)，以確保毗鄰的區(qū)域存儲(chǔ)在了一起。數(shù)據(jù)預(yù)處理流水線高度依賴(lài)運(yùn)行在BigtableMapReduceMapReduce任務(wù)的時(shí)候，整個(gè)系統(tǒng)中每臺(tái)Tablet1MB/s。500GBTabletin-memory的列族。\hGoogleWeb查詢(xún)、圖像和新聞。用戶可以瀏覽他們查詢(xún)的歷史，重復(fù)他們之前的查詢(xún)和點(diǎn)擊；Google歷史使用習(xí)慣模式的個(gè)性化查詢(xún)結(jié)果。BigtableBigtable為MapReduce任務(wù)生成用戶的數(shù)據(jù)圖表。這些用戶數(shù)據(jù)圖表用來(lái)個(gè)性化當(dāng)前的查詢(xún)結(jié)果。Bigtable的集群上，這樣就增強(qiáng)了數(shù)據(jù)可用性，同時(shí)減少了由客戶端和BigtableBigtableChubbyRPCChecksum。我們?cè)谠O(shè)計(jì)Chubby操作只返回錯(cuò)誤碼集合中的一個(gè)值。API中支持通常方式的事務(wù)處理。但是由于我們還不會(huì)馬上用到Bigtable非常重要（Bigtable自身以詳細(xì)記錄代表了RPC調(diào)用的很多重要操作。這個(gè)特性允許我們檢測(cè)和修正很多的問(wèn)題，比如Tablet數(shù)據(jù)結(jié)大約1000032，abtMsr服Tablet服務(wù)器簽訂租約，TabletKill掉自己的進(jìn)程。不幸的是，這使用Chubby最廣泛使用的特性的協(xié)議。ChunkB-tree存儲(chǔ)。BoxwoodGoogle的某些組件盡管功能類(lèi)似，但是Boxwood的組件提供更底層的服務(wù)。Boxwood項(xiàng)目的目的是提供創(chuàng)建類(lèi)似文件系統(tǒng)、數(shù)據(jù)庫(kù)等高級(jí)服務(wù)Bigtable的目的是直接為客戶程序的數(shù)據(jù)存儲(chǔ)需求提供支持。現(xiàn)在有不少項(xiàng)目已經(jīng)攻克了很多難題，實(shí)現(xiàn)了在廣域網(wǎng)上的分布式數(shù)據(jù)存儲(chǔ)或者高級(jí)服務(wù)，通常是Byzantine災(zāi)難冗余34Bigtable的目的。就提供給應(yīng)用程序開(kāi)發(fā)者的分布式數(shù)據(jù)存儲(chǔ)模型而言，我們相信，分布式B-Tree或者分布式Hash表提有些數(shù)據(jù)庫(kù)廠商已經(jīng)開(kāi)發(fā)出了并行的數(shù)據(jù)庫(kù)系統(tǒng)，能夠存儲(chǔ)海量的數(shù)據(jù)。OracleRAC【27】使用共享GFSChubbyDB2【4Bigtable的、不共享任何東西的架構(gòu)35【33DB2的服務(wù)器都負(fù)責(zé)處理BigtableMonetDB/X100【38ColumnDM存儲(chǔ)層。另外一種在平面文件中提供垂直和水平數(shù)據(jù)分區(qū)、并且提AT&T的Daytona19AilamakiCPUC-StoreBigtableShared-nothing架構(gòu)，都有兩種不同的數(shù)據(jù)結(jié)構(gòu)，一Bigtable對(duì)讀和寫(xiě)密集型應(yīng)用都提供了很好的性能。Bigtable，Google的一個(gè)分布式的結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)系統(tǒng)。Bigtable20054720064月，已經(jīng)有60BigtableBigtable提供的高性能和高可用性很滿意，隨著時(shí)間的推移，Bigtable提供的編程接口并不常見(jiàn)，一個(gè)有趣的問(wèn)題是：我們的用戶適應(yīng)新的接口有多難？新的使Bigtable接口的最佳方法，特別是在他們已經(jīng)習(xí)慣于使用支持通用事務(wù)的關(guān)系型數(shù)據(jù)庫(kù)的接口的情況下。但是，GoogleBigtable的事實(shí)證明了，我們的設(shè)計(jì)在實(shí)踐我們現(xiàn)在正在對(duì)BigtableMasterBigtableBigtable部署為服務(wù)供其它的產(chǎn)品團(tuán)隊(duì)使用，這樣不同BigtableBigtable系統(tǒng)內(nèi)部最后，我們發(fā)現(xiàn)，建設(shè)Google自己的存儲(chǔ)解決方案帶來(lái)了很多優(yōu)勢(shì)。通過(guò)為Bigtable設(shè)計(jì)我們自己的數(shù)BigtableBigtable使用到的其它的Google的基礎(chǔ)構(gòu)件，這就意味著我們?cè)谙到y(tǒng)出現(xiàn)瓶頸或效率低下的情況時(shí)，能夠快速的解決這些問(wèn)GoogleFileSystem中文版目錄TOC\o"1-2"\h\u3008 1251201. 132572. 174783. 1119231 158722 265772.1 2272202.2 321502.3 3282052原文：well- 3279182.4Master 5202852.5 5322362.6 6238318Chunk 6320362.6.2Chunk 799232.6.3 7134610 71168012 7100252.7 82664517Master 9195622.7.2 10233163 10105673.1 1021813.2 12921020ChunkChunk 1287033.3 137523.4 14108944Master 145334.1 15182524.2 15121464.3 16158934.4 171269924metadata 17232104.5 18283635 18301915.1 184135.2 20307725.3 2142866 21139886.1 2123246.2 23197926.3工作負(fù)荷分析(Workload 263024629 26252026.3.2Chunk 27212026.3.3vs. 28258156.3.4Master 29154997 2998778 3014649 31GoogleFileSystem我們?cè)O(shè)計(jì)并實(shí)現(xiàn)了GoogleGFSGFS雖然運(yùn)行在廉價(jià)的普遍硬件設(shè)備上，但是它依然了提供災(zāi)難冗余的能力，為大量客戶機(jī)提供了高性能的GFS的設(shè)計(jì)目標(biāo)與許多傳統(tǒng)的分布式文件系統(tǒng)有很多相同之處，但是，我們的設(shè)計(jì)還是以我們對(duì)自己的應(yīng)用的負(fù)載情況和技術(shù)環(huán)境的分析為基礎(chǔ)的，不管現(xiàn)在還是將來(lái)，GFS和早期的分布式文件系統(tǒng)的設(shè)GFS完全滿足了我們對(duì)存儲(chǔ)的需求。GFSGoogle內(nèi)部，存儲(chǔ)我們的利用數(shù)千臺(tái)機(jī)器的數(shù)千個(gè)硬盤(pán)，提供了數(shù)百TB的存儲(chǔ)空間，同時(shí)為數(shù)百個(gè)客戶機(jī)服務(wù)。D43—DGoogleGoogle文件系統(tǒng)(GoogleFileSystem–GFS和早期文件系統(tǒng)的假設(shè)都有明顯的不同。所以我們重新審視了傳統(tǒng)文件系統(tǒng)在設(shè)計(jì)上的折衷選擇，衍生GoogleGoogleFileSystem1.0GoogleGoogleFileSystem1.0GSubugGS中。webTB的數(shù)據(jù)KB大小的小文件的方式是非常不明智的，盡管有些文件系統(tǒng)支持這樣的管理方式。I/OBlock的尺寸都需要重新考慮。性模型的要求，這樣就減輕了文件系統(tǒng)對(duì)應(yīng)用程序的苛刻要求，大大簡(jiǎn)化了GFS的設(shè)計(jì)。我們引入了原子性GoogleGFS1000KB數(shù)據(jù)。3.43.3節(jié)分別討論。GFSMaster節(jié)點(diǎn)3Chunk2原文：well-3MasterGFSMasterMaster節(jié)點(diǎn)復(fù)制，MasterMaster節(jié)點(diǎn)包括兩臺(tái)物理主機(jī)Chunk服務(wù)器和客戶端都放在同一臺(tái)機(jī)器上，前提是機(jī)器資源允許，并且我們能夠接受不可靠的應(yīng)用程GFS存儲(chǔ)的文件都被分割成固定大小的ChunkChunk創(chuàng)建的時(shí)候，MasterChunk分64位的Chunk標(biāo)識(shí)。Chunk服務(wù)器把ChunkLinux文件的形式保存在本地硬盤(pán)Chunk標(biāo)識(shí)和字節(jié)范圍來(lái)讀寫(xiě)塊數(shù)據(jù)。出于可靠性的考慮，每個(gè)塊都會(huì)復(fù)制到多個(gè)塊服3個(gè)存儲(chǔ)復(fù)制節(jié)點(diǎn)，不過(guò)用戶可以為不同的文件命名空間設(shè)定不同的復(fù)制級(jí)MasterChunk的映Chunk5ChunkChunk服務(wù)器之間的遷移。MasterChunk服務(wù)器通訊，發(fā)送指令到各個(gè)Chunk服務(wù)器并接收Chunk服務(wù)器的狀態(tài)信息。GFSGFSAPI接口函數(shù)、Master節(jié)點(diǎn)和ChunkMaster節(jié)點(diǎn)的通信只獲取能，因此，GFSAPILinuxvnode級(jí)別。4BDBlease5原文：orphaned6Master單一的Master節(jié)點(diǎn)的策略大大簡(jiǎn)化了我們的設(shè)計(jì)。單一的Master節(jié)點(diǎn)可以通過(guò)全局的信息精確定位ChunkMaster節(jié)點(diǎn)的讀寫(xiě)，避免Master節(jié)點(diǎn)成為系統(tǒng)的瓶MasterMaster節(jié)點(diǎn)詢(xún)問(wèn)它應(yīng)該聯(lián)系的Chunk服務(wù)器。Chunk服務(wù)器進(jìn)行數(shù)據(jù)讀寫(xiě)操作。1解釋一下一次簡(jiǎn)單讀取的流程。首先，客戶端把文件名和程序指定的字節(jié)偏移，根據(jù)固定ChunkChunkChunkMaster節(jié)點(diǎn)。Master節(jié)Chunk標(biāo)識(shí)和副本的位置信息發(fā)還給客戶端?？蛻舳擞梦募虲hunkkey緩存這些信Chunk的標(biāo)識(shí)和字節(jié)范圍。在對(duì)這個(gè)ChunkMaster節(jié)點(diǎn)通訊了，除非緩存的元數(shù)據(jù)信息過(guò)期或Chunk信息，Master節(jié)點(diǎn)的回應(yīng)也可能包含了緊跟著這些被請(qǐng)求的Chunk后面的Chunk的信息。在實(shí)際應(yīng)用中，這些額外的信息在沒(méi)有任何代價(jià)的情Master節(jié)點(diǎn)未來(lái)可能會(huì)發(fā)生的幾次通訊。64MB每個(gè)Chunk的副本都以普通Linux文件的形式保存在Chunk服務(wù)器上，只有在需要的時(shí)候才擴(kuò)大。惰性空間Chunk尺寸最具爭(zhēng)議一點(diǎn)。ChunkMaster節(jié)點(diǎn)通訊的需求，因?yàn)橹恍枰淮魏蚆ater節(jié)點(diǎn)的通信就可以獲取Chunk的位置信息，之后就可以對(duì)同一個(gè)Chunk進(jìn)行多次的讀寫(xiě)操ChunkTB的工作數(shù)據(jù)集所有的ChunkChunk尺寸，客戶端能夠?qū)σ粋€(gè)塊進(jìn)行多次操作，這樣就可以Chunk。當(dāng)有許多的客戶端對(duì)同一個(gè)小文件進(jìn)行多次的訪問(wèn)時(shí)，存儲(chǔ)這些Chunk的ChunkChunk的大文件，熱點(diǎn)還不是主GFS用于批處理隊(duì)列系統(tǒng)的時(shí)候，熱點(diǎn)的問(wèn)題還是產(chǎn)生了：一個(gè)可執(zhí)行文件在GFSsingle-chunk文件，之后這個(gè)可執(zhí)行文件在數(shù)百臺(tái)機(jī)器上同時(shí)啟動(dòng)。存放這個(gè)可執(zhí)行文件的幾Chunk服務(wù)器被數(shù)百個(gè)客戶端的并發(fā)請(qǐng)求訪問(wèn)導(dǎo)致系統(tǒng)局部過(guò)載。我們通過(guò)使用更大的復(fù)制參數(shù)來(lái)保存可Mser7存儲(chǔ)3ChukChukChukMser8同時(shí)也制到其它的遠(yuǎn)程MserMseraeraer服務(wù)器不會(huì)持久保存hukaer服務(wù)器在啟動(dòng)時(shí)，或者有新的Chuk服務(wù)器加入時(shí)，向各個(gè)Chuk服務(wù)器輪詢(xún)它們所存儲(chǔ)的Chunk的信息。服務(wù)器失效的時(shí)重新復(fù)制數(shù)據(jù)、通過(guò)Chunk的遷移實(shí)現(xiàn)跨Chunk服務(wù)器的負(fù)載均衡以及磁盤(pán)使用狀況統(tǒng)計(jì)等功能。4.34.4章節(jié)將深入討論這些行為。Chunk64Master服務(wù)器增加額外內(nèi)存的費(fèi)用是很少的，而通過(guò)增加有限的7MasterMasterMaster服務(wù)器的行為，如存儲(chǔ)、內(nèi)存等等，因8ChunkGoogleGoogleFileSystem1.0GoogleGoogleFileSystem1.0ChunkMaster服務(wù)器并不保存持久化保存哪個(gè)ChunkChunk的副本的信息。Master服務(wù)器只是Chunk服務(wù)器以獲取這些信息。Master服務(wù)器能夠保證它持有的信息始終是最新的，因?yàn)镃hunk位置的分配，而且通過(guò)周期性的心跳信息監(jiān)控Chunk服務(wù)器的狀態(tài)。時(shí)候輪詢(xún)Chunk服務(wù)器，之后定期輪詢(xún)更新的方式更簡(jiǎn)單。這種設(shè)計(jì)簡(jiǎn)化了在有Chunk服務(wù)器加入集群、離開(kāi)集群、更名、失效、以及重啟的時(shí)候，MasterChunk服務(wù)器數(shù)據(jù)同步的問(wèn)題。在一個(gè)擁有數(shù)百臺(tái)Chunk服務(wù)器才能最終確定一個(gè)Chunk是否在它的硬盤(pán)Chunk自動(dòng)消失(比如，硬盤(pán)損壞了或者無(wú)法訪問(wèn)了)，亦或者操作人員可能會(huì)重命名一個(gè)Chunk服務(wù)器。操作日志包含了關(guān)鍵的元數(shù)據(jù)變更歷史記錄。這對(duì)GFS非常重要。這不僅僅是因?yàn)椴僮魅罩臼窃獢?shù)據(jù)唯一的持久化存儲(chǔ)記錄，它也作為判斷同步操作順序的邏輯時(shí)間基線9。文件和Chunk，連同它們的版本(參考4.5節(jié))，都由它們創(chuàng)建的邏輯時(shí)間唯一的、永久的標(biāo)識(shí)。Chunk本身沒(méi)有出現(xiàn)任何問(wèn)題，我們?nèi)杂锌赡軄G失整個(gè)文件系統(tǒng)，或者丟失客戶機(jī)器的硬盤(pán)后，才會(huì)響應(yīng)客戶端的操作請(qǐng)求。Master服務(wù)器會(huì)收集多個(gè)日志記錄后批量處理，以減少寫(xiě)入磁有的狀態(tài)數(shù)據(jù)寫(xiě)入一個(gè)Checkpoint文件12。在災(zāi)難恢復(fù)的時(shí)候，Master服務(wù)器就通過(guò)從磁盤(pán)上讀取這個(gè)CheckpointCheckpoint之后的有限個(gè)日志文件就能夠恢復(fù)系統(tǒng)。CheckpointB-樹(shù)91011Checkpoint12CheckpointMaster服務(wù)器的內(nèi)部狀態(tài)被組織為一種格式，這Checkpoint過(guò)程中不會(huì)阻塞正在進(jìn)行的修改操作。Master服務(wù)器使用獨(dú)立的線程切換到新的日志文件和創(chuàng)建新的Checkpoint文件。新的Checkpoint文件包括切換前所有的修改。對(duì)于一個(gè)包含數(shù)百萬(wàn)個(gè)Checkpoint1分鐘左右的時(shí)間。創(chuàng)建完成后，Checkpoint文件會(huì)被寫(xiě)入在本MasterCheckpoint文件和后續(xù)的日志文件。舊的Checkpoint文件和日志文件可Checkpoint文件。GFS支持一個(gè)寬松的一致性模型，這個(gè)模型能夠很好的支撐我們的高度分布的應(yīng)用，同時(shí)還保持了相對(duì)簡(jiǎn)單且容易實(shí)現(xiàn)的優(yōu)點(diǎn)。本節(jié)我們討論GFS的一致性的保障機(jī)制，以及對(duì)應(yīng)用程序的意義。我們也著重描述GFS如何管理這些一致性保障機(jī)制，但是實(shí)現(xiàn)的細(xì)節(jié)將在本論文的其它部分討論。GFS原子性和正確性（4.1章）的保障；Master節(jié)點(diǎn)的操作日志定義了這些操作在全局的順序（2.6.3章。數(shù)據(jù)修改后文件region141總結(jié)了各種操作如果所有客戶端，無(wú)論從哪個(gè)副本讀取，讀到的數(shù)據(jù)都一樣，那么我們認(rèn)為文件regionregion就是13catastrophes14regionregionregion處于regionregion的不同類(lèi)型。另外，GFSregion被認(rèn)定是不一致的，經(jīng)過(guò)了一系列的成功的修改操作之后，GFSregion是已定義的，并且包含最后一次修（a）（b）而導(dǎo)致其失效。失效的副本不會(huì)再進(jìn)行任何修改操作，MasterChunk副本的位置信息由于ChunkChunk位置信息。而且，由于我們的文件大多數(shù)都是只進(jìn)行追加操作的，所以，一個(gè)失效的副Chunk位置信息。即使在修改操作成功執(zhí)行很長(zhǎng)時(shí)間之后，組件的失效也可能損壞或者刪除數(shù)據(jù)。GFSMaster服務(wù)ChunkChunkChecksum來(lái)校驗(yàn)數(shù)據(jù)是否損壞（5.2章。一旦發(fā)現(xiàn)問(wèn)題，數(shù)據(jù)要盡快利用有效的副本進(jìn)行恢復(fù)（4.3章Chunk的所有副本GFSChunkGFS的16本文中將用到兩個(gè)專(zhuān)有名詞，ReaderWriterGFS17Master使用GFS的應(yīng)用程序可以利用一些簡(jiǎn)單技術(shù)實(shí)現(xiàn)這個(gè)寬松的一致性模型，這些技術(shù)也用來(lái)實(shí)現(xiàn)一些其它包含程序級(jí)別的校驗(yàn)和。Readers僅校驗(yàn)并處理上個(gè)Checkpoint之后產(chǎn)生的文件regionregion的狀對(duì)應(yīng)用程序的失敗處理更具有彈性。CheckpointWriterReader者是一個(gè)生產(chǎn)者-Writer的輸出。Readers使用下面的方法來(lái)處理偶然性的填充數(shù)據(jù)和重復(fù)內(nèi)容。Writers在每條寫(xiě)入的記錄中都包含了額外的信息，例如Checksum，用來(lái)驗(yàn)證它的有效性。ReaderChecksum識(shí)別和拋棄額外的填充數(shù)據(jù)和記錄片段。如果們的程序共享的庫(kù)中，并且適用于Google內(nèi)部的其它的文件接口實(shí)現(xiàn)。所以，相同序列的記錄，加上一些偶Reader了。帶著這樣的設(shè)計(jì)理念，我們現(xiàn)在描述一下客戶機(jī)、MasterChunk服務(wù)器如何進(jìn)行交互，以實(shí)現(xiàn)變更是一個(gè)會(huì)改變Chunk18ThesefunctionalitiesforrecordI/O19leaseChunkChunkChunk的所有更改操作進(jìn)行序列化。Master節(jié)點(diǎn)選擇的租約的順序決定，然后由租約中主Chunk分配的序列號(hào)決定。Master60秒。不過(guò)，只要ChunkChunkMaster節(jié)點(diǎn)的確認(rèn)并收到租約延長(zhǎng)的時(shí)間。Master節(jié)點(diǎn)和Chunk服務(wù)器之間的心跳消息中來(lái)傳遞。有時(shí)Master節(jié)點(diǎn)會(huì)試圖提前取消租約（例如，Master節(jié)點(diǎn)想取消在一個(gè)已經(jīng)被改名的文件上的修改操作。即使Master節(jié)點(diǎn)和主ChunkChunk副本簽訂新的租約。MasterChunkMasterChunk的標(biāo)識(shí)符以及其它副本（secondary副本、二級(jí)副本）的位置返回給客戶Chunk不可用，或者主Chunk回復(fù)信息表明它已不再持Master節(jié)點(diǎn)聯(lián)系?？蛻魴C(jī)把數(shù)據(jù)推送到所有的副本上?？蛻魴C(jī)可以以任意的順序推送數(shù)據(jù)。Chunk服務(wù)器接收到數(shù)據(jù)并保Chunk服務(wù)器保存了主Chunk。3.2章節(jié)會(huì)進(jìn)一步討論這點(diǎn)。Chunk服務(wù)器。這個(gè)請(qǐng)求標(biāo)識(shí)了早前推送到Chunk為接收到的所有操作分配連續(xù)的序列號(hào)，這些操作可能來(lái)自不同的客戶機(jī)，序列ChunkChunk分配的序列號(hào)以相同的順序執(zhí)行所有的二級(jí)副本回復(fù)主ChunkChunk服務(wù)器20回復(fù)客戶機(jī)。任何副本產(chǎn)生的任何錯(cuò)誤都會(huì)返回給客戶機(jī)。在出現(xiàn)錯(cuò)誤的情況下，寫(xiě)Chunk（Chunk上失敗了，操作就不會(huì)被分配序列region的尾部可能包含來(lái)自不同客戶機(jī)的數(shù)據(jù)片段，盡管如此，由于這些分解后的寫(xiě)入操Chunk、然后再Chunk服務(wù)器鏈推送。我們的目標(biāo)為了盡可能的避免出現(xiàn)網(wǎng)絡(luò)瓶頸和高延遲的鏈接（eg，inter-switch最有可能出現(xiàn)類(lèi)似問(wèn)題，每臺(tái)機(jī)器S4S2。同樣的，S2S3和S4之間更近的機(jī)器，依次類(lèi)推推送下去。我們IPTCP連接的、管道式數(shù)據(jù)推送方式來(lái)最小化延遲。Chunk服務(wù)器接收到數(shù)據(jù)后，20ChunkChunk立刻向前推送不會(huì)降低接收的速度。在沒(méi)有網(wǎng)絡(luò)擁塞的情況下，傳送B字節(jié)的數(shù)據(jù)到R（T，LGFS提供了一種原子的數(shù)據(jù)追加操作–記錄追加。傳統(tǒng)方式的寫(xiě)入操作，客戶程序會(huì)指定數(shù)據(jù)寫(xiě)入的偏使用記錄追加，客戶機(jī)只需要指定要寫(xiě)入的數(shù)據(jù)。GFS保證至少有一次原子的寫(xiě)入操作成功執(zhí)行（即寫(xiě)入一byte流GFS指定的偏移位置上，之后GFS返回這個(gè)偏移量給客戶機(jī)。這類(lèi)似UnixO_APPEND模式打開(kāi)的文件，多個(gè)并發(fā)寫(xiě)操作在沒(méi)有競(jìng)態(tài)條件時(shí)的行3.1Chunk有些額外的控制邏輯。客Chunk的所有副本，之后發(fā)送請(qǐng)求給主ChunkChunk會(huì)檢查這次記錄追（64MBChunk重新進(jìn)行記錄追加操）ChunkChunk把數(shù)據(jù)追加到自己的副本內(nèi)，然后通知二級(jí)副本把數(shù)據(jù)寫(xiě)在跟主Chunk一樣的位置上，最后回復(fù)客戶機(jī)操作成功。同一個(gè)ChunkGFS并不保證ChunkChunk的所有副本的相同偏移位置上。這之Chunk上，即使其它的Chunk副本被Master節(jié)點(diǎn)選為了主Chunk。就我們的一致性保障模型而言，記錄追加）就像AFS（alex注：AFSAndrewFileSystem，一種分布式文件系統(tǒng)copy-on-write保證了后續(xù)對(duì)這些ChunkMasterMaster節(jié)點(diǎn)一個(gè)率先創(chuàng)建Chunk的新拷貝的機(jī)會(huì)。和源文件指向完全相同的Chunk地址。Master節(jié)點(diǎn)注意到ChunkC122Master節(jié)點(diǎn)不會(huì)馬上回復(fù)客戶機(jī)的請(qǐng)求，而是選擇一個(gè)新的Chunk句柄C`。之后，MasterChunkCChunk服務(wù)器創(chuàng)建一C`的新ChunkChunk所在Chunk服務(wù)器上創(chuàng)建新的Chunk，我們確保數(shù)據(jù)在本地而不是通沒(méi)什么不同：MasterChunkC`的一個(gè)副本擁有租約，之后回復(fù)客戶機(jī)，客戶機(jī)得到回復(fù)后就可以正常的寫(xiě)這個(gè)Chunk，而不必理會(huì)它是從一個(gè)已存在的Chunk克隆出來(lái)的。MasterMasterChunkChunk21COW221.SnapshotMasterChunk服務(wù)器上快照所涉及的所有region上的鎖來(lái)保證執(zhí)行的正確順序。支持文件或者目錄的鏈接（Unix術(shù)語(yǔ)中的硬鏈接或者符號(hào)鏈接。在邏輯上，GFS的名稱(chēng)空間就是一個(gè)全每個(gè)Master節(jié)點(diǎn)的操作在開(kāi)始之前都要獲得一系列的鎖。通常情況下，如果一個(gè)操作涉及意，根據(jù)操作的不同，leaf可以是一個(gè)文件，也可以是一個(gè)目錄?，F(xiàn)在，我們演示一下在/home/user被快照到/save/user的時(shí)候，鎖機(jī)制如何防止創(chuàng)建文件/home/user/foo?？煺詹僮鳙@取/home和/save的讀取鎖，以及/home/user和/save/user的寫(xiě)入鎖。文件創(chuàng)建操作獲得/home和GFS集群是高度分布的多層布局結(jié)構(gòu)，而不是平面結(jié)構(gòu)。典型的拓?fù)浣Y(jié)構(gòu)是有數(shù)百個(gè)Chunk服務(wù)器安裝在許多機(jī)架上。Chunk服務(wù)器被來(lái)自同一或者不同機(jī)架上的數(shù)百個(gè)客戶機(jī)輪流訪問(wèn)。不同機(jī)架上的兩臺(tái)機(jī)器Chunk副本位置選擇的策略服務(wù)兩大目標(biāo)：最大化數(shù)據(jù)可靠性和可用性，最大化網(wǎng)絡(luò)帶寬利用率。為了ChunkChunkChunk的讀操作，能夠有效利用多個(gè)機(jī)架的Master節(jié)點(diǎn)創(chuàng)建一個(gè)Chunk時(shí)，它會(huì)選擇在哪里放置初始的空的副本。MasterChunkChunk創(chuàng)建操作的次數(shù)。雖然創(chuàng)建操作本身是廉價(jià)的，但是創(chuàng)建操作也意味著隨之會(huì)有大量的寫(xiě)入數(shù)據(jù)的操作，因?yàn)镃hunkWriter真正寫(xiě)入數(shù)據(jù)的時(shí)候才被創(chuàng)建，而在我們的“追加一次，讀取多次”的工作模式下，Chunk一旦寫(xiě)入成功之后就會(huì)變?yōu)橹蛔x的了。Chunk的有效副本數(shù)量少于用戶指定的復(fù)制因數(shù)的時(shí)候，Master節(jié)點(diǎn)會(huì)重新復(fù)制它。這可能是由幾個(gè)Chunk服務(wù)器不可用了，Chunk服務(wù)器報(bào)告它所存儲(chǔ)的一個(gè)副本損壞了，Chunk服務(wù)器的一個(gè)磁盤(pán)因?yàn)殄e(cuò)誤不可用了，或者Chunk副本的復(fù)制因數(shù)提高了。每個(gè)需要被重新復(fù)制的Chunk都會(huì)根據(jù)幾個(gè)因素進(jìn)行排序。一個(gè)因素是Chunk現(xiàn)有副本數(shù)量和復(fù)制因數(shù)相差多少。例如，丟失兩個(gè)副本的Chunk比丟Chunk有更高的優(yōu)先級(jí)。另外，我們優(yōu)先重新復(fù)制活躍（live）Chunk而不是最近剛被刪除的文件的Chunk（4.4節(jié)Chunk對(duì)正在運(yùn)行的應(yīng)用程序的影響，我們提Chunk的優(yōu)先級(jí)。Chunk服務(wù)器上的正在進(jìn)行的克隆操作的數(shù)量、在機(jī)架間分布副本。為了防止克隆產(chǎn)生的網(wǎng)絡(luò)流量大大超過(guò)客戶機(jī)的流量，Master節(jié)點(diǎn)對(duì)Chunk服務(wù)器上的同時(shí)進(jìn)行的克隆操作的數(shù)量都進(jìn)行了限制。另外，Chunk服務(wù)器通過(guò)調(diào)節(jié)Chunk服務(wù)器讀請(qǐng)求的頻率來(lái)限制它用于克隆操作的帶寬。MasterChunk填滿它，以至于過(guò)載。新副本的存儲(chǔ)位置選擇策略和上面討論的相當(dāng)一個(gè)文件被應(yīng)用程序刪除時(shí)，Master節(jié)點(diǎn)象對(duì)待其它修改操作一樣，立刻把刪除操作以日志的方式記錄下來(lái)。但是，Master節(jié)點(diǎn)并不馬上回收資源，而是把文件名改為一個(gè)包含刪除時(shí)間戳的、隱藏的名字。當(dāng)Master節(jié)點(diǎn)對(duì)文件系統(tǒng)命名空間做常規(guī)掃描的時(shí)候，它會(huì)刪除所有三天前的隱藏文件（這個(gè)時(shí)間間隔是可以元數(shù)據(jù)才會(huì)被刪除。這也有效的切斷了文件和它包含的所有Chunk的連接23。Chunk名字空間做類(lèi)似的常規(guī)掃描時(shí)，MasterChunk（Chunk）并刪除它們的元數(shù)據(jù)。ChunkMasterChunk子集的信息，Master節(jié)點(diǎn)回復(fù)Chunk服務(wù)器哪些Chunk在MasterChunk服務(wù)器可以任Chunk的副本。GFS系統(tǒng)中是非常ChunkMaster服務(wù)器上的文件到塊的映射表中。我們也可以很輕易的得到所有ChunkLinux文件的形式存儲(chǔ)在Chunk服務(wù)器的指定目錄下。Master垃圾回收方式簡(jiǎn)單可靠。ChunkChunk服務(wù)器創(chuàng)建成功，某些Chunk服務(wù)器上創(chuàng)建失敗，失敗的副本處于無(wú)法被MasterMaster節(jié)點(diǎn)必須重新發(fā)送失敗的刪除消息，包括自身的和Chunk服務(wù)器的24。垃圾回收提供了一致的、可靠的清除無(wú)用副本的方法。第二，垃圾回收把Master節(jié)點(diǎn)規(guī)律性的后臺(tái)活動(dòng)中，比如，例行掃描和與Chunk服務(wù)器握手等。因此，操作被批量的執(zhí)行，開(kāi)銷(xiāo)會(huì)被分散。另外，垃圾回收在Master節(jié)點(diǎn)相對(duì)空閑的時(shí)候完成。這樣Master23原文：Thiseffectivelyseversitslinkstoallits24metadataChunk服務(wù)器失效時(shí)，Chunk的副本有可能因錯(cuò)失了一些修改操作而過(guò)期失效。Master節(jié)點(diǎn)保存了每Chunk的版本號(hào)，用來(lái)區(qū)分當(dāng)前的副本和過(guò)期副本。副本。Master節(jié)點(diǎn)和這些副本都把新的版本號(hào)記錄在它們持久化存儲(chǔ)的狀態(tài)信息中。這個(gè)動(dòng)作發(fā)生在任何客Chunk開(kāi)始寫(xiě)之前。如果某個(gè)副本所在的Chunk服務(wù)器正好處于失效狀態(tài)，那么副本的版本號(hào)就不會(huì)被增加。Master節(jié)點(diǎn)在這個(gè)ChunkMaster節(jié)點(diǎn)報(bào)告它Chunk的集合以及相應(yīng)的版本號(hào)的時(shí)候，就會(huì)檢測(cè)出它包含過(guò)期的ChunkMaster節(jié)點(diǎn)看到一個(gè)比它記錄的版本號(hào)更高的版本號(hào)，Master節(jié)點(diǎn)會(huì)認(rèn)為它和Chunk服務(wù)器簽訂租約的操作失敗了，因此會(huì)選擇Master節(jié)點(diǎn)在例行的垃圾回收過(guò)程中移除所有的過(guò)期失效副本。在此之前，Master節(jié)點(diǎn)在回復(fù)客戶機(jī)的Chunk信息請(qǐng)求的時(shí)候，簡(jiǎn)單的認(rèn)為那些過(guò)期的塊根本就不存在。另外一重保障措施是，Master節(jié)點(diǎn)在通知ChunkChunk服務(wù)器從哪個(gè)Chunk服務(wù)器進(jìn)行克隆時(shí)，消息中都附帶我們?cè)谠O(shè)計(jì)GFS時(shí)遇到的最大挑戰(zhàn)之一是如何處理頻繁發(fā)生的組件失效。組件的數(shù)量和質(zhì)量讓這些問(wèn)題些挑戰(zhàn)，以及當(dāng)組件失效不可避免的發(fā)生時(shí)，用GFS自帶工具診斷系統(tǒng)故障。Master服務(wù)器和Chunk服務(wù)器是如何關(guān)閉的，它們都被設(shè)計(jì)為可以在數(shù)秒鐘內(nèi)恢復(fù)它們的狀態(tài)并重kill掉進(jìn)程來(lái)關(guān)閉服務(wù)器?？蛻糁卦囘@個(gè)請(qǐng)求。6.6.2章節(jié)記錄了實(shí)測(cè)的啟動(dòng)時(shí)間。Chunk正如之前討論的，每個(gè)ChunkChunk服務(wù)器上。用戶可以為文件命名空節(jié)）發(fā)現(xiàn)了已經(jīng)損壞的數(shù)據(jù)，MasterChunk都被完整復(fù)制26ChunkMaster為了保證Master服務(wù)器的可靠性，Master服務(wù)器的狀態(tài)也要復(fù)制。Master服務(wù)器所有的操作日志和checkpointMaster服務(wù)器狀態(tài)的修改操作能夠提交成功的前提是，操作日志程所在的機(jī)器或者磁盤(pán)失效了，處于GFS系統(tǒng)外部的監(jiān)控進(jìn)程會(huì)在其它的存有完整操作日志的機(jī)器上啟動(dòng)一MasterMaster節(jié)點(diǎn)。供文件系統(tǒng)的只讀訪問(wèn)。它們是影子，而不是鏡像，所以它們的數(shù)據(jù)可能比“主”Master服務(wù)器更新要慢，125aminor26Chunk27ErasurecodesbufferMasterChunk服務(wù)器上讀取的，因此，應(yīng)用程序不“影子”Master服務(wù)器為了保持自身狀態(tài)是最新的，它會(huì)讀取一份當(dāng)前正在進(jìn)行的操作的日志副本，并MasterMasterMasterChunk服務(wù)器輪詢(xún)數(shù)據(jù)（之后定期拉數(shù)據(jù)Chunk副本的位置信MasterChunkMaster服務(wù)器因創(chuàng)建MasterMaster服務(wù)器通信來(lái)更新自身狀態(tài)。每個(gè)Chunk服務(wù)器都使用Checksum來(lái)檢查保存的數(shù)據(jù)是否損壞。考慮到一個(gè)GFS集群通常都有好幾百臺(tái)機(jī)器、幾千塊硬盤(pán)，磁盤(pán)損壞導(dǎo)致數(shù)據(jù)在讀寫(xiě)過(guò)程中損壞或者丟失是非常常見(jiàn)的（7節(jié)講了一個(gè)原因。我們可以通過(guò)別的Chunk副本來(lái)解決數(shù)據(jù)損壞問(wèn)題，但是跨越Chunk服務(wù)器比較副本來(lái)檢查數(shù)據(jù)是否損壞很不實(shí)際。另外，GFS允許有歧義的副本存在：GFS修改操作的語(yǔ)義，特別是早先討論過(guò)的原子紀(jì)錄追加的操作，并不保證副本完全相同(alexbyte-wise完全一致的)Chunk服務(wù)器必須獨(dú)立維Checksum來(lái)校驗(yàn)自己的副本的完整性。Chunk64KB32Checksum。和其它元數(shù)據(jù)一樣，Checksum與其它的用戶數(shù)據(jù)是分開(kāi)的，并且保存在內(nèi)存和硬盤(pán)上，同時(shí)也記錄操作日志。Chunk服務(wù)器之前，Chunk服務(wù)器會(huì)校驗(yàn)讀取操作ChecksumChunk服務(wù)器不會(huì)把錯(cuò)誤數(shù)據(jù)傳遞到其它的機(jī)器上。如果發(fā)生某個(gè)塊的Checksum不正確，ChunkMaster服務(wù)器這個(gè)錯(cuò)誤。作為回應(yīng)，請(qǐng)求者應(yīng)當(dāng)從其它副本讀取數(shù)據(jù)，MasterMaster服務(wù)器通知副本錯(cuò)誤的Chunk服務(wù)器刪掉錯(cuò)誤的副本。幾個(gè)塊，而我們只需要讀取一小部分額外的相關(guān)數(shù)據(jù)進(jìn)行校驗(yàn)。GFS客戶端代碼通過(guò)每次把讀取操作都對(duì)齊ChecksumblockChunk服務(wù)器上，ChecksumI/O操作，ChecksumI/O操作同時(shí)進(jìn)行。ChecksumChunk（與之對(duì)應(yīng)的是覆蓋現(xiàn)有數(shù)據(jù)的寫(xiě)入操作Checksum，并且用所有的追加來(lái)的新Checksum塊來(lái)計(jì)算新的ChecksumChecksumChunk，我們必須讀取和校驗(yàn)被覆蓋的第一個(gè)和最后一個(gè)塊，然后再執(zhí)行寫(xiě)操作；操作完成之后再重新計(jì)算和寫(xiě)入新的Checksum。如果我們不校驗(yàn)第一個(gè)和最Checksum可能會(huì)隱藏沒(méi)有被覆蓋區(qū)域內(nèi)的數(shù)據(jù)錯(cuò)誤。Chunk服務(wù)器空閑的時(shí)候，它會(huì)掃描和校驗(yàn)每個(gè)不活動(dòng)的Chunk的內(nèi)容。這使得我們能夠發(fā)現(xiàn)很少被同時(shí)也只需要很小的開(kāi)銷(xiāo)。沒(méi)有日志的幫助，我們很難理解短暫的、不重復(fù)的機(jī)器之間的消息交互。GFS的RPC日志包含了網(wǎng)絡(luò)上發(fā)生的所有請(qǐng)求和響應(yīng)的詳細(xì)記錄，但是不包括讀寫(xiě)的文件數(shù)據(jù)。通過(guò)匹配請(qǐng)求本節(jié)中，我們將使用一些小規(guī)?；鶞?zhǔn)測(cè)試來(lái)展現(xiàn)GFSGoogle內(nèi)部使用的真實(shí)的GFS1Master服務(wù)器，2Master服務(wù)器復(fù)制節(jié)點(diǎn)，16臺(tái)Chunk16個(gè)客戶機(jī)組GFSGFS集群有數(shù)百個(gè)Chunk服務(wù)器和數(shù)百個(gè)客戶機(jī)。HP2524交換機(jī)。GFS1916臺(tái)1Gbps的線路連接。N個(gè)客戶機(jī)從GFS320GB4MBregion的32GB10%Linux的文件系統(tǒng)緩沖。我們的測(cè)試結(jié)95%的可靠性，因?yàn)橛袝r(shí)候測(cè)量會(huì)不夠精確。3（a）N1Gbps的鏈125MB/S12.5MB/s10MB/s，也80%1694MB/s，大約是理論整體讀取速度極限值的75%6MB/s80%降低到了75%，主要Chunk服務(wù)器的幾率也增加了，導(dǎo)致整體的讀取效N個(gè)客戶機(jī)同時(shí)向N1MB1GB的數(shù)據(jù)。3（b）67MB/s，因?yàn)槲覀冃枰衙恳籦yte16個(gè)Chunk3個(gè)上，而每個(gè)Chunk12.5MB/s。Chunk服務(wù)器時(shí)采用的管道模式不相適應(yīng)。從一個(gè)副本到另一個(gè)副本的數(shù)據(jù)傳輸2.2MB/sChunk服務(wù)器的幾率也增加了。而且，1616個(gè)客戶機(jī)并行讀取要大得多，因?yàn)槊總€(gè)寫(xiě)入都會(huì)3（c）顯示了記錄追加操作的性能。N個(gè)客戶機(jī)同時(shí)追加數(shù)據(jù)到一個(gè)文件。記錄追加操作的性能受限Chunk的Chunk服務(wù)器的帶寬，而與客戶機(jī)的數(shù)量無(wú)關(guān)。記錄追加的速度由一個(gè)客戶機(jī)N個(gè)客戶機(jī)同時(shí)追加數(shù)據(jù)到M個(gè)共享文件中，這里NM都是數(shù)十或者數(shù)百以上。所以，在我們的實(shí)際應(yīng)用中，Chunk服務(wù)器的網(wǎng)絡(luò)擁塞并沒(méi)有成為一個(gè)Chunk服務(wù)器的某個(gè)文件正在寫(xiě)入，客戶機(jī)會(huì)去寫(xiě)另外一個(gè)文件。MBTB的數(shù)據(jù)，之后進(jìn)行轉(zhuǎn)化或者分析，最后把結(jié)果寫(xiě)回到集群中。集群BB的TB的數(shù)據(jù)集。在這兩個(gè)案例中，一ChunkTB的硬盤(pán)空間；兩個(gè)集群雖18TB52TB的文件數(shù)據(jù)。B上有大量的死文件。所謂“死文件”是指文件被刪除了B存儲(chǔ)的文件較大，因此它的Chunk數(shù)量也比較多。ChunkGB的元數(shù)據(jù)，大多數(shù)是來(lái)自用戶數(shù)據(jù)的、64KBChecksum。Chunk服務(wù)器上其它的元數(shù)據(jù)是Chunk4.5節(jié)描述過(guò)。據(jù)。這和我們?cè)O(shè)想的是一樣的，Master服務(wù)器的內(nèi)存大小在實(shí)際應(yīng)用中并不會(huì)成為GFS系統(tǒng)容量的瓶頸。大多數(shù)文件的元數(shù)據(jù)都是以前綴壓縮模式存放的文件名。Master服務(wù)器上存放的其它元數(shù)據(jù)包括了文件的所有者和權(quán)限、文件到Chunk的映射關(guān)系，以及每一個(gè)ChunkChunk，我們都保存了當(dāng)前的副本位置以及對(duì)它的引用計(jì)數(shù)，這個(gè)引用計(jì)數(shù)用于實(shí)現(xiàn)寫(xiě)時(shí)拷貝（COW，copy-on-writeMaster服務(wù)器，并獲取到所有Chunk近都因?yàn)樯?jí)新版本的GFS重新啟動(dòng)過(guò)了。100MB/sChunk300MB/s。A80Bs的網(wǎng)絡(luò)配置可以支持7MBsB支持的峰值讀取速度是100B，0MB。Master3的數(shù)據(jù)顯示了發(fā)送到Master200500個(gè)。Master服務(wù)器可以輕松Master服務(wù)器的處理能力不是系統(tǒng)的瓶頸。Chunk服務(wù)器失效了，一些Chunk副本的數(shù)量可能會(huì)低于復(fù)制因子指定的數(shù)量，我們必須通過(guò)克ChunkChunk副本所花費(fèi)的時(shí)間取決于資源的數(shù)量。B上的一個(gè)ChunkKillChunk15000個(gè)Chunk，600GBGFS調(diào)度決策提供修正空間，91個(gè)（Chunk40%，每個(gè)克隆操作最多允6.25MB/s（50mbpsChunk23.2440MB/s。KillChunkChunk16000Chunk，共2分鐘內(nèi)恢復(fù)到至少有兩個(gè)副本；現(xiàn)在集群被帶入到另外一個(gè)狀態(tài)，在這個(gè)狀態(tài)下，系統(tǒng)可以容忍另Chunk服務(wù)器失效而不丟失數(shù)據(jù)。工作負(fù)荷分析(WorkloadGFS6.2節(jié)中的類(lèi)似，但是不完全相同。集群X用于研究和開(kāi)發(fā)，集群Y用于生產(chǎn)數(shù)據(jù)處理。GFS文件系統(tǒng)產(chǎn)生的全部工作負(fù)載。它們不包含那些為了實(shí)現(xiàn)客戶端請(qǐng)求而在服務(wù)器間交互的請(qǐng)求，也不包GFS內(nèi)部的后臺(tái)活動(dòng)相關(guān)的請(qǐng)求，比如前向轉(zhuǎn)發(fā)的寫(xiě)操作，或者重新負(fù)載均衡等操作。GFSRPCIO操作的統(tǒng)計(jì)信息。例如，GFS客RPCRPC請(qǐng)求推導(dǎo)出原始的讀應(yīng)該避免從我們的工作負(fù)荷數(shù)據(jù)中過(guò)度的歸納出普遍的結(jié)論29Google完全控制著GFS和使用GFS28原文：Sinceouraccesspatternsarehighlystylized,weexpectanyerrortobeinthe29Chunk表4顯示了操作按涉及的數(shù)據(jù)量大小的分布情況。讀取操作按操作涉及的數(shù)據(jù)量大小呈現(xiàn)了雙峰分布。小的讀取操作（64KB）一般是由查找操作的客戶端發(fā)起的，目的在于從巨大的文件中查找小塊的數(shù)據(jù)。大的讀取操作（512KB）一般是從頭到尾順序的讀取整個(gè)文件。Y上，有相當(dāng)數(shù)量的讀操作沒(méi)有返回任何的數(shù)據(jù)。在我們的應(yīng)用中，尤其是在生產(chǎn)系統(tǒng)中，經(jīng)常X通常用于短暫的數(shù)據(jù)分析任務(wù)，而不是長(zhǎng)時(shí)間運(yùn)行的分布式應(yīng)用，因此，集群X很少出現(xiàn)這種情況。寫(xiě)操作按數(shù)據(jù)量大小也同樣呈現(xiàn)為雙峰分布。大的寫(xiě)操作（256KB）Writer使用了緩存（64KB）的數(shù)據(jù)量(alex注：即匯集多次小的寫(xiě)入操作，當(dāng)數(shù)據(jù)量達(dá)到一個(gè)閾值，一次寫(xiě)入)，之后批量Y中大的記錄追加操作所占比例比集群X多的多，這是因?yàn)榧篩用于我們的生產(chǎn)系統(tǒng)，針對(duì)GFS做了更全面的調(diào)優(yōu)。表5顯示了按操作涉及的數(shù)據(jù)量的大小統(tǒng)計(jì)出來(lái)的總數(shù)據(jù)傳輸量。在所有的操作中，大的操作（超過(guò)Seek的工作負(fù)荷而導(dǎo)致的。vs.X，記錄追加操作和普通寫(xiě)操作的比例按照字節(jié)108:1X，buffer的X.001.003。Y.05Master（FindLocationLocker重新寫(xiě)入的模式打開(kāi)時(shí)，隱式的被刪除了（類(lèi)似UNIXopen函數(shù)中的“w”模式。namespaceY的這類(lèi)請(qǐng)求要多一在建造和部署GFS研究和開(kāi)發(fā)任務(wù)的支持。我們開(kāi)始增加一些小的功能，比如權(quán)限和配額，到了現(xiàn)在，GFS已經(jīng)初步支持了這Linux2.2fsync()的效率問(wèn)題。它的效率與文件Linux相關(guān)的問(wèn)題是單個(gè)讀寫(xiě)鎖的問(wèn)題，也就是說(shuō)，在某一個(gè)地址空間的任意一個(gè)線程都必須pagein（讀鎖）holdmmap()調(diào)用（寫(xiě)鎖）的時(shí)候改寫(xiě)地址空間。我們發(fā)現(xiàn)即pread()mmap()copy動(dòng)作來(lái)解決這個(gè)問(wèn)題。和其它的大型分布式文件系統(tǒng)，比如AFS[5]類(lèi)似，GFS提供了一個(gè)與位置無(wú)關(guān)的名字空間，這使得數(shù)據(jù)可以為了負(fù)載均衡或者災(zāi)難冗余等目的在不同位置透明的遷移。不同于AFS的是，GFS把文件分布存儲(chǔ)到不Xfs[1]Swift[3]，這是為了提高整體性能以及災(zāi)難冗余的能力。xFSSwift占用更多的裸存儲(chǔ)空間(alex注：Rawstorage，裸盤(pán)的空間)。Cache機(jī)制。我們主要的工作在單個(gè)應(yīng)用程序執(zhí)行的時(shí)候幾乎不會(huì)重復(fù)讀取數(shù)據(jù)，因?yàn)樗鼈兊墓ぷ鞣绞組asterHarp[7]primary-copy方案，從而提供比我們現(xiàn)在的方案更嚴(yán)格的一致性保證。Lustre[8]在如何在有大量客戶端時(shí)保障系統(tǒng)整體性能遇到的問(wèn)題。不過(guò)，我們通過(guò)只關(guān)注我們的應(yīng)用程序的需求，而不是提供一個(gè)兼容POSIX的文件系統(tǒng)，從而達(dá)到了簡(jiǎn)化問(wèn)GFS很類(lèi)似NASD架構(gòu)[4]。NASDGFSChunk服式，而不是分配變長(zhǎng)的對(duì)象存儲(chǔ)空間。此外，GFS實(shí)現(xiàn)了諸如重新負(fù)載均衡、復(fù)制、恢復(fù)機(jī)制等等在生產(chǎn)環(huán)不同于與Minnesota’sGFS和NASDModel30。我們只關(guān)注用普通的設(shè)備來(lái)解生產(chǎn)者并發(fā)追加記錄的持久化的文件的方式實(shí)現(xiàn)。Riverm-到-n的分布式隊(duì)列，但是缺少由持久化Google文件系統(tǒng)展示了一個(gè)使用普通硬件支持大規(guī)模數(shù)據(jù)處理的系統(tǒng)的特質(zhì)。雖然一些設(shè)計(jì)要點(diǎn)都是針我們系統(tǒng)通過(guò)持續(xù)監(jiān)控，復(fù)制關(guān)鍵數(shù)據(jù)，快速和自動(dòng)恢復(fù)提供災(zāi)難冗余。Chunk復(fù)制使得我們可以對(duì)Chunk服務(wù)器的失效進(jìn)行容錯(cuò)。高頻率的組件失效要求系統(tǒng)具備在線修復(fù)機(jī)制，能夠周期性的、透明的修復(fù)ChecksumIDE子系統(tǒng)級(jí)別30ModelmodelGoogleGoogleFileSystem1.0GFSGoogle內(nèi)部，無(wú)論是作為研究和開(kāi)發(fā)的存儲(chǔ)平臺(tái)，還是作為GoogleBigtable中文版目錄TOC\o"1-3"\h\u261971 1175822 127988 212833 2130563.1 330973.2 3207523.3 4258814 4177045BigTable 5168106 7252186.1 7142226.2 8249946.3 10143226.4 1117377 11303637.1 11238287.2 12263837.3 12131498 15267278.1 16126348.2 17154849 17201179.1 1834529.2Google 185529.3 19747010 203108411 212136712 22GoogleGoogleBigtable1.0GoogleBigtable務(wù)器上的PB級(jí)的數(shù)據(jù)。Google的很多項(xiàng)目使用Bigtable存儲(chǔ)數(shù)據(jù)，包括Web索引、GoogleEarth、GoogleFinance。這些應(yīng)用對(duì)Bigtable提出的要求差異非常大，無(wú)論是在數(shù)據(jù)量上（URL到網(wǎng)頁(yè)到衛(wèi)星圖像）還是在響應(yīng)速度上（從后本論文描述了Bigtable我們還將描述Bigtable的設(shè)計(jì)和實(shí)現(xiàn)。Google，我們Bigtable。Bigtable的設(shè)計(jì)目的是可靠的處理PB級(jí)別的數(shù)據(jù)，并且能夠部署到上千臺(tái)機(jī)器上。BigtableBigtable60個(gè)GoogleGoogleAnalytics、GoogleFinance、Orkut、PersonalizedSearch、WritelyGoogleEarth。這些產(chǎn)品對(duì)Bigtable提出了迥異的需求，有的需要高吞Bigtable集群的配置也有很大的差異，有的集群只有幾臺(tái)服務(wù)器，而有的則需要上千臺(tái)服務(wù)器、存儲(chǔ)幾百TB的數(shù)據(jù)。在很多方面，Bigtable和數(shù)據(jù)庫(kù)很類(lèi)似：它使用了很多數(shù)據(jù)庫(kù)的實(shí)現(xiàn)策略。并行數(shù)據(jù)庫(kù)【14】和內(nèi)存數(shù)據(jù)庫(kù)【13】已經(jīng)具備可擴(kuò)展性和高性能，但是Bigtable提供了一個(gè)和這些系統(tǒng)完全不同的接口。Bigtable不支3節(jié)描述關(guān)于數(shù)據(jù)模型更多細(xì)節(jié)方面的東西；4節(jié)概要介紹了客戶端API；5節(jié)簡(jiǎn)要介紹了BigTable底層使用的Google的基礎(chǔ)框架；6節(jié)描述了BigTable實(shí)現(xiàn)的關(guān)鍵部分；7BigTable的性能采用的一些精細(xì)的調(diào)優(yōu)方法；8節(jié)提供了BigTable的性能數(shù)據(jù)；9節(jié)講述了幾個(gè)Google內(nèi)部使用BigTable以及時(shí)間戳；Mapvalue都是一個(gè)未經(jīng)解析的Bigtable的系統(tǒng)的種種潛在用途之后，決定使用這個(gè)數(shù)據(jù)模型。我們先舉個(gè)WebtableWebtableURL作為行關(guān)鍵1WebURL。contents列族存放的是網(wǎng)頁(yè)的內(nèi)容，anchor列族存放引用該網(wǎng)頁(yè)的錨鏈接文本7。CNN的主頁(yè)被SportsIllustrator和MY-look的主頁(yè)引用，因此該行包含了名為“anchor:”和t6標(biāo)識(shí)。表中的行關(guān)鍵字可以是任意的字符串（64KB的字符串，但是對(duì)大多數(shù)用戶，10-100個(gè)字BgabeabeabetebabeURLap.goge.condex.hlo.googe.apndex.hl訪問(wèn)控制、磁盤(pán)和內(nèi)存的使用統(tǒng)計(jì)都是在列族層面進(jìn)行的。在我們的Webtable的例子中，上述的控制權(quán)Bigtable中，表的每一個(gè)數(shù)據(jù)項(xiàng)都可以包含同一份數(shù)據(jù)的不同版本；不同版本的數(shù)據(jù)通過(guò)時(shí)間戳來(lái)索n個(gè)版本的數(shù)據(jù)，或者只保存“足夠新”的版本的數(shù)據(jù)（7天的內(nèi)容寫(xiě)入的數(shù)據(jù)。Webtable的舉例里，contents:列存儲(chǔ)的時(shí)間戳信息是網(wǎng)絡(luò)爬蟲(chóng)抓取一個(gè)頁(yè)面的時(shí)間。上面提及的垃圾B(niǎo)igtableAPI函數(shù)。Bigtable////OpentheTable*T=//WriteanewanchoranddeleteanoldanchorRowMutationr1(T,“n.www”);r1.Set(“anchor:\h”,“CNN”);\hOperationApply(&op,2WritingtoBigtableBigtable中的值、從每個(gè)行中查找值、或者遍\hScannerScannerScanStreamstream=scanner.FetchColumnFamily(“anchor”);for(;!stream->Done();stream->Next()){printf(“%s%s%lld%s\n”,3Readingfrom3中的C++代碼使用Scanner抽象對(duì)象遍歷一個(gè)行內(nèi)的所有錨點(diǎn)。客戶程序可以遍歷多個(gè)列族，有幾正則表達(dá)式*.10天的錨點(diǎn)。Bigtable還支持一些其它的特性，利用這些特性，用戶可以對(duì)數(shù)據(jù)進(jìn)行更復(fù)雜的處理。首先，Bigtable支雖然Bigtable提供了一個(gè)允許用戶跨行批量寫(xiě)入數(shù)據(jù)的接口，但是，Bigtable目前還不支持通用的跨行事務(wù)處理。其次，Bigtable允許把數(shù)據(jù)項(xiàng)用做整數(shù)計(jì)數(shù)器。最后，Bigtable允許用戶在服務(wù)器的地址空間內(nèi)執(zhí)行腳本GoogleSawzall【28SawzallAPIBigtable，但是它允許多種形式的數(shù)據(jù)轉(zhuǎn)換、基于任意表達(dá)式的數(shù)據(jù)BigtableMapReduce【12】一起使用，MapReduceGoogle開(kāi)發(fā)的大規(guī)模并行計(jì)算框架。我們已WrapperWrapper類(lèi)，BigtableMapReduce框架的輸入和輸出。BigTable各樣的分布式應(yīng)用程序，BigTable的進(jìn)程經(jīng)常要和其它應(yīng)用的進(jìn)程共享機(jī)器。BigTable依賴(lài)集群管理系統(tǒng)來(lái)MapMap是一個(gè)key-value映射的數(shù)據(jù)結(jié)構(gòu)，keyvalueByteSSTablekeyvaluekeykey-value對(duì)。從內(nèi)SSTable都放在內(nèi)存中，這樣就不必訪問(wèn)硬盤(pán)了。BigTableChubby【8Chubby服務(wù)包括5Master，并且處理請(qǐng)求。只有在大多數(shù)副本都是正常運(yùn)行的，并【9,23】來(lái)保證副本的一致性。Chubby提供了一個(gè)名字空間，里面包括了目錄和小文件。每個(gè)目錄或者文件可以當(dāng)成一個(gè)鎖，讀寫(xiě)文件的操作都是原子的。ChubbyChubby文件的一致性緩存。每個(gè)ChubbyChubby服務(wù)的會(huì)話。如果客戶程序不能在租約到期的時(shí)間內(nèi)重新簽訂會(huì)話的租約，這個(gè)會(huì)話就過(guò)期失效了9。當(dāng)一個(gè)會(huì)話失效時(shí)，它擁有的鎖和打開(kāi)的文件句柄都失效了。Chubby客戶存儲(chǔ)BigTable數(shù)據(jù)的自引導(dǎo)指令的位置（5.1節(jié)查找TabletTablet服務(wù)器失效時(shí)進(jìn)行善后（5.2節(jié)存儲(chǔ)BigTable的模式信息（每張表的列族信息Bigable0.0326%10。BigtableMasterTablet服務(wù)器。針對(duì)系統(tǒng)工作負(fù)載的變化情況，BigTable可以動(dòng)態(tài)的向集群中添加（或者刪除）Tablet服務(wù)器。MasterTabletTabletsTable服務(wù)器、對(duì)TabletGFS上的文件進(jìn)行垃圾收集。除此之外，它還處理對(duì)模TabletSingle-Master類(lèi)型的分布式存儲(chǔ)系統(tǒng)【17.21Master