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