Google背後的分佈式計算架構策略
Google是與衆不同的。它的獨特不僅僅表現於革新的思維和充滿創意的應用 (比如那個大堂裏的地球模型)，更在於其有別常規的IT策略……
加利福尼亞州山景城(Mountain View)Google公司(Google，下稱Google)總部有一個43號大樓，該建築的中央大屏幕上顯示着一個與Google地球(Google Earth)相仿的世界地圖，一個轉動的地球上不停地閃動着五顏六色的光點，恍如羅馬宮廷的千萬燭燈，每一次閃動標誌着地球的這個角落一名Google用 戶發起了一次新的搜索。
這同時意味着Google又一次滿足了人們對未知信息的好奇與渴望。
Google是與衆不同的。它的獨特不僅僅表現於革新的思維和充滿創意的應用 (比如那個大堂裏的地球模型)，更在於其有別常規的IT策略。從人們的常理來看，簡單的硬件商品和免費軟件是無法構建出一個帝國的，但是Google做到 了。在性能調整後，Google把它們變成一個無可比擬的分佈式計算平臺，該平臺能夠支持大規模的搜索和不斷湧現的新興應用。我們原本認爲這些應用都是個 人消費級別的，但是Google改變了這一切。現在商業世界也在使用它們，這就令這家搜索公司顯得那麼與衆不同。
GoogleWeb 服務背後的IT架構對無數使用搜索引擎的用戶來說也許並不是非常重要，但它是Google幾百位致力於把全球信息組織起來，實現“隨處可達，隨時可用”目 標的工程師們的最核心工作。這就需要一個在覆蓋範圍和野心上都與Google的商業願景完全相符的IT藍圖作爲支撐。
Google 的經理們一直對公司的IT策略話題保持沉默，他們厭惡談及特定的廠商或者產品，當被問到他們的服務器和數據中心時，他們總是閉口不談。但與幾位 Google的IT領導一起呆了一天後，我們最終得以揭示該公司的IT是如何運作的，那可不僅僅是一個運行在無數服務器集羣上的、表面看來非常簡單的搜索 引擎。在其簡單的外表下，蘊涵着許多內部研發軟件、定製硬件、人工智能，以及對性能的執着追求和打破常規的人力管理模式。
IT理念方面，Google對同行有一條建議：儘量避免那些人人都在使用的系統和軟件，以自己的方式做事會更有獨特的競爭優勢。
“企業文化決定了你的做事方式。”道格拉斯"美林(Douglas Merrill)，這位Google工程副總裁和事實上的首席信息官(CIO) 指出，“到了我們這樣的發展階段，企業觀念和文化非常與衆不同，這也反過來鞭策我們必須要採用與衆不同的方式來運行那些他人看來很常規的系統。”
Google 最大的IT優勢在於它能建造出既富於性價比(並非廉價)又能承受極高負載的高性能系統。因此IT顧問史蒂芬"阿諾德(Stephen Arnold)指出，Google與競爭對手，如亞馬遜網站(Amazon)、電子港灣公司(eBay)、微軟公司(Microsoft，下稱微軟)和雅 虎公司 (Yahoo，下稱雅虎)等公司相比，具有更大的成本優勢。Google程序員的效率比其他Web公司同行們高出50%～100%，原因是Google已 經開發出了一整套專用於支持大規模並行系統編程的定製軟件庫。據他估算，其他競爭公司可能要花上四倍的時間才能獲得同等的效果。
打造服務器
Google 究竟是怎樣做到這點的呢?其中一個手段，美林認爲，“是因爲我們自己動手打造硬件。”Google並不製造計算機系統，但它根據自己的參數定製硬件，然後 像MTV的節目“靚車打造”(Pimp My Ride)那樣自己安裝和調整硬件系統。開源程序經理克里斯"迪博納(Chris DiBona)評論道：“我們很善於購買商業服務器，並且改造他們爲我們所用，最後把性能壓榨和發揮到極致，以致有時候他們熱得像要融化了似的。”
這種親手打造的方式，來源於Google從車庫誕生時與生俱來的節儉風格，更與Google那超大型的系統規模息息相關，良好的習慣一直延續至 今。據說 Google在65個數據中心擁有20萬～45萬臺服務器—這個數目會有偏差(取決於你如何定義服務器和由誰來做這項統計)。但是，不變的是持續上升的趨 勢。
Google不會去討論這些資產，因爲它認爲保密也是一種競爭優勢。事實上，Google之所以喜歡開源軟件也是因爲它的私密性。“如果我們購 買了軟件許可或代碼許可，人們只要對號入座，就可以猜出Google的IT基礎架構。”迪博納分析說， “使用開源軟件，就使我們多了一條把握自己命運的途徑。”
Google喜歡規模化的服務器運行方式。當有成百上千臺機器時，定製服務器的優勢也會成倍增加，效果也會更趨明顯。Google正在俄勒岡州 哥倫比亞河邊的達勒斯市建造一個佔地30畝的數據中心，在那兒它可以獲得運算和降溫需要的低價水力電力能源(參見邊欄《Google數據中心自有一套》)。
Google以“單元”(Cell)的形式組織這些運行 Linux操作系統的服務器，迪博納把這種形式比喻成互聯網服務的“磁盤驅動器”(但別和一直謠傳的Google存儲服務Gdrive混淆了，“並沒有 Gdrive這回事。”一位Google女發言人明確表示。)，公司的軟件程序都駐紮在這些並不昂貴的電腦機箱裏，由程序員決定它們的冗餘工作量。這種由 很多單元組成的文件系統代替了商業存儲設備;迪博納表示Google這些單元設備更易於建造和維護，他還暗示他們能處理更大規模的數據。
Google 不會漏過對任何技術細節的關注。多年來，公司的工程師就在研究微處理器的內部工作機制，隨着Google規模的持續壯大，必然會用到特別定製和調節過的芯 片。知名工程師路易斯"巴羅索(Luiz Barroso)去年在一篇發表在工業雜誌上的論文中證實，近年來Google的主要負荷都由單核設計的系統承擔着。但許多服務器端的應用，如 Google搜索索引服務，所需的並行計算在單核芯片的指令級別上執行得並不好。
曾在數據設備公司(Digital Equipment)和康柏公司(Compaq)當過芯片設計師的巴羅索認爲，隨着AMD公司、英特爾公司(Intel)、太陽計算機系統公司(Sun)開始製造多核芯片，必將會出現越來越多芯片級別的並行計算。
Google 也曾考慮過自己製造計算機芯片，但從業界潮流來看，這個冒險的舉動似乎不是很必要。“微處理器的設計非常複雜而且成本昂貴，”運營高級副總裁烏爾斯"霍爾 茨勒(Urs Holzle)表示。Google寧願與芯片製造商合作，讓他們去理解自己的應用並設計適合的芯片。這是一種客戶建議式的設計，其關注點在於總體吞吐量、 效能，以及耗電比，而不是看單線程的峯值性能。霍爾茨勒表示，“這也是最近多核CPU的設計潮流與未來方向。”
裁縫般地定製軟件
爲了能儘量壓榨硬件性能，Google開發了相當數量的定製軟件。創新產品主要包括用於簡化處理和創建大規模數據集的編程模型 MapReduce;用於存儲和管理大規模數據的系統BigTable;分析分佈式運算環境中大規模數據集的解釋編程語言Sawzall;用於數據密集型 應用的分佈式文件系統的 “Google文件系統”(Google File System);還有爲處理分佈式系統隊列分組和任務調度的“Google工作隊列”(Google Workqueue)。
正是從Sawzall這些工具裏體現出Google對計算效率的執著關注。並不是每家公司都能從底層去解決效率問題，但是對Google來說， 爲常規關係型數據庫無法容納的大規模數據集專門設計一種編程語言是完全合理的。即使其他編程工具可以解決問題，Google的工程師們仍然會爲了追求效率 而另外開發一套定製方案。Google工程師認爲，Sawzall能與C++中的MapReduce相媲美，而且它更容易編寫一些。
Google 對效率的關注使它不可能對標準Linux內核感到滿意;Google會根據自己的需要運行修改過的內核版本。通過調整Linux的底層性能，Google 工程師們在提高了整體系統可靠性的基礎上，還一併解決了數據損壞和數據瓶頸等一系列棘手問題。對內核的修改也使Google的計算機集羣系統因爲通信效率 的提高而運行得更快。
當然，Google偶爾也會出現系統故障，情況一旦發生，無數的用戶就會受到影響了。三年前一次持續30分鐘的系統故障使20%的搜索流量受到影響。
Google 開發了自己的網站服務器卻沒有使用開源的Apache服務器，儘管它在網站服務器的市場佔有率超過60%。迪博納認爲，Google的網站服務器可以運行 在更多數量的主機上，對Google站點上內容龐大又彼此互相依賴的應用程序來說，這種服務器的負載均衡能力遠比Apache的能力更高。同時，在用標準 公共網關接口(CGI)訪問數據庫動態網頁方面，Google服務器的編程難度要比 Apache更高，但是最終運行速度卻更快。“如果我們能夠壓榨出10%～20%的性能，我們就可以節省出更多系統資源、電量和人力了。”迪博納在總結中 指出。
Google還設計了自己的客戶關係管理(CRM)系統用於支持自己基於競價和點擊的互聯網廣告收費業務。但對是否需要設計自己的工具，Google的態度也不是一成不變的。比如在財會軟件上，它就使用了甲骨文公司(Oracle)的Financials軟件。
美林拿着一隻叉子舉例說明現成的產品也可以帶來價值。但在有些場合現成的軟件產品就不一定適用了。“我們的文化在各個層面對我們的運作都有深遠影響，”他表示，“所以我們不想讓購買所得的工具改變我們的工作方式和文化層面。”
Google's BigTable 原理 （翻譯）
題記：google 的成功除了一個個出色的創意外，還因爲有 Jeff Dean 這樣的軟件架構天才。
------ 編者
官方的 Google Reader blog 中有對BigTable 的解釋。這是Google 內部開發的一個用來處理大數據量的系統。這種系統適合處理半結構化的數據比如 RSS 數據源。 以下發言 是 Andrew Hitchcock 在 2005 年10月18號 基於： Google 的工程師 Jeff Dean 在華盛頓大學的一次談話 (Creative Commons License).
首先，BigTable 從 2004 年初就開始研發了，到現在爲止已經用了將近8個月。（2005年2月）目前大概有100個左右的服務使用BigTable，比如： Print,Search History,Maps和 Orkut。根據Google的一貫做法，內部開發的BigTable是爲跑在廉價的PC機上設計的。BigTable 讓Google在提供新服務時的運行成本降低，最大限度地利用了計算能力。BigTable 是建立在 GFS ，Scheduler ，Lock Service 和 MapReduce 之上的。
每個Table都是一個多維的稀疏圖 sparse map。Table 由行和列組成，並且每個存儲單元 cell 都有一個時間戳。在不同的時間對同一個存儲單元cell有多份拷貝，這樣就可以記錄數據的變動情況。在他的例子中，行是URLs ，列可以定義一個名字，比如：contents。Contents 字段就可以存儲文件的數據。或者列名是：”language”，可以存儲一個“EN”的語言代碼字符串。
爲了管理巨大的Table，把Table根據行分割，這些分割後的數據統稱爲：Tablets。每 個Tablets大概有 100-200 MB，每個機器存儲100個左右的 Tablets。底層的架構是：GFS。由於GFS是一種分佈式的文件系統，採用Tablets的機制後，可以獲得很好的負載均衡。比如：可以把經常響應 的表移動到其他空閒機器上，然後快速重建。
Tablets在系統中的存儲方式是不可修改的 immutable 的SSTables，一臺機器一個日誌文件。當系統的內存滿後，系統會壓縮一些Tablets。由於Jeff在論述這點的時候說的很快，所以我沒有時間把聽到的都記錄下來，因此下面是一個大概的說明：
壓縮分爲：主要和次要的兩部分。次要的壓縮僅僅包括幾個Tablets，而主要的壓縮時關於整個系統的壓縮。主壓縮有回收硬盤空間的功能。Tablets的位置實際上是存儲在幾個特殊的BigTable的存儲單元cell中。看起來這是一個三層的系統。
客戶端有一個指向METAO的Tablets的指針。如果METAO的Tablets被頻繁使用，那個這臺機器就會放棄其他的tablets專門支持 METAO這個Tablets。METAO tablets 保持着所有的META1的tablets的記錄。這些tablets中包含着查找tablets的實際位置。（老實說翻譯到這裏，我也不太明白。）在這個系統中不存在大的瓶頸，因爲被頻繁調用的數據已經被提前獲得並進行了緩存。
現在我們返回到對列的說明：列是類似下面的形式： family:optional_qualifier。在他的例子中，行：www.search-analysis.com 也許有列：”contents:其中包含html頁面的代碼。 “ anchor:cnn.com/news” 中包含着 相對應的url，”anchor:www.search-analysis.com/” 包含着鏈接的文字部分。列中包含着類型信息。
(翻譯到這裏我要插一句，以前我看過一個關於萬能數據庫的文章，當時很激動，就聯繫了作者，現在回想起來，或許google的 bigtable 纔是更好的方案，切不說分佈式的特性，就是這種建華的表結構就很有用處。)
注意這裏說的是列信息，而不是列類型。列的信息是如下信息，一般是：屬性/規則。 比如：保存n份數據的拷貝或者保存數據n天長等等。當 tablets 重新建立的時候，就運用上面的規則，剔出不符合條件的記錄。由於設計上的原因，列本身的創建是很容易的，但是跟列相關的功能確實非常複雜的，比如上文提到 的 類型和規則信息等。爲了優化讀取速度，列的功能被分割然後以組的方式存儲在所建索引的機器上。這些被分割後的組作用於 列 ,然後被分割成不同的 SSTables。這種方式可以提高系統的性能，因爲小的，頻繁讀取的列可以被單獨存儲，和那些大的不經常訪問的列隔離開來。
在一臺機器上的所有的 tablets 共享一個log，在一個包含1億的tablets的集羣中，這將會導致非常多的文件被打開和寫操作。新的log塊經常被創建，一般是64M大小，這個GFS的塊大小相等。當一個機器down掉後，控制機器就會重新發布他的log塊到其他機器上繼續進行處理。這臺機器重建tablets然後詢問控制機器處理結構的存儲位置，然後直接對重建後的數據進行處理。
這個系統中有很多冗餘數據，因此在系統中大量使用了壓縮技術。
Dean 對壓縮的部分說的很快，我沒有完全記下來，所以我還是說個大概吧：壓縮前先尋找相似的 /行，列，和時間數據。
他們使用不同版本的： BMDiff 和 Zippy 技術。
BMDiff 提供給他們非常快的寫速度： 100MB/s – 1000MB/s 。Zippy 是和 LZW 類似的。Zippy 並不像 LZW 或者 gzip 那樣壓縮比高，但是他處理速度非常快。
Dean 還給了一個關於壓縮 web 蜘蛛數據的例子。這個例子的蜘蛛 包含 2.1B 的頁面，行按照以下的方式命名：“com.cnn.www/index.html:http”.在未壓縮前的web page 頁面大小是：45.1 TB ，壓縮後的大小是：4.2 TB ， 只是原來的 9.2%。Links 數據壓縮到原來的 13.9% , 鏈接文本數據壓縮到原來的 12.7%。
Google 還有很多沒有添加但是已經考慮的功能。
1. 數據操作表達式，這樣可以把腳本發送到客戶端來提供修改數據的功能。
2. 多行數據的事物支持。
3. 提高大數據存儲單元的效率。
4. BigTable 作爲服務運行。
好像：每個服務比如： maps 和 search history 歷史搜索記錄都有他們自己的集羣運行 BigTable。
他們還考慮運行一個全局的 BigTable 系統，但這需要比較公平的分割資源和計算時間。
大表(Bigtable):結構化數據的分佈存儲系統
http://labs.google.com/papers/bigtable-osdi06.pdf
｛中是譯者評論,程序除外｝
{本文的翻譯可能有不準確的地方,詳細資料請參考原文.}
摘要
bigtable是設計來分佈存儲大規模結構化數據的，從設計上它可以擴展到上２^50字節，分佈存儲在幾千個普通服務器上．google的很多項目使用 bt來存儲數據，包括網頁查詢，google earth和google金融．這些應用程序對bt的要求各不相同：數據大小（從URL到網頁到衛星圖象）不同，反應速度不同（從後端的大批處理到實時數 據服務）．對於不同的要求，bt都成功的提供了靈活高效的服務．在本文中，我們將描述bt的數據模型．這個數據模型讓用戶動態的控制數據的分佈和結構．我 們還將描述BT的設計和實現．
１．介紹
在過去兩年半里，我們設計，實現並部署了BT．BT是用來分佈存儲和管理結構化數據的．BT的設計使它能夠管理2^50 bytes(petabytes)數據，並可以部署到上千臺機器上．BT完成了以下目標：應用廣泛，可擴展，高性能和高可用性（high availability）. 包括google analytics, google finance, orkut, personalized search, writely和google earth在內的60多個項目都使用BT.這些應用對BT的要求各不相同，有的需要高吞吐量的批處理，有的需要快速反應給用戶數據．它們使用的BT集羣也各不相同，有的只有幾臺機器，有的有上千臺，能夠存儲2^40字節(terabytes)數據．
BT在很多地方和數據庫很類似：它使用了很多數據庫的實現策略．並行數據庫[14]和內存數據庫[13]有可擴展性和高性能，但是BT的界面不同．BT不支持完全的關係數據模型；而是爲客戶提供了簡單的數據模型，讓客戶來動態控制數據的分佈和格式{就是隻存儲字串，格式由客戶來解釋}，並允許客戶推斷底層存儲數據的局部性｛以提高訪問速度｝．數據下標是行和列的名字，數據本身可以是任何字串．BT的數據是字串，沒有解釋｛類型等｝．客戶會在把各種結構或者半結構化的數據串行化｛比如說日期串｝到數據中．通過仔細選擇數據表示，客戶可以控制數據的局部化．最後，可以使用BT模式來控制數據是放在內存裏還是在硬盤上．｛就是說用模式，你可以把數據放在離應用最近的地方．畢竟程序在一個時間只用到一塊數據．在體系結構裏，就是：locality, locality, locality｝
第二節描述數據模型細節．第三節關於客戶API概述．第四節簡介BT依賴的google框架．第五節描述BT的實現關鍵部分．第6節敘述提高BT性 能的一些調整．第7節提供BT性能的數據．在第8節，我們提供BT的幾個使用例子，第9節是經驗教訓．在第10節，我們列出相關研究．最後是我們的結論．
２．數據模型
BT是一個稀疏的，長期存儲的｛存在硬盤上｝，多維度的，排序的映射表．這張表的索引是行關鍵字，列關鍵字和時間戳．每個值是一個不解釋的字符數組．｛數據都是字符串，沒類型，客戶要解釋就自力更生吧｝．
(row:string, column:string,time:int64)->string {能編程序的都能讀懂，不翻譯了}
我們仔細查看過好些類似bigtable的系統之後定下了這個數據模型。舉一個具體例子（它促使我們做出某些設計決定）， 比如我們想要存儲大量網頁及相關信息，以用於很多不同的項目；我們姑且叫它Webtable。在Webtable裏，我們將用URL作爲行關鍵字，用網頁 的某些屬性作爲列名，把網頁內容存在contents:列中並用獲取該網頁的時間戳作爲標識，如圖一所示。
圖一：一個存儲Web網頁的範例列表片斷。行名是一個反向URL｛即com.cnn.www｝。contents列族｛原文用 family，譯爲族，詳見列族｝ 存放網頁內容，anchor列族存放引用該網頁的錨鏈接文本。CNN的主頁被Sports Illustrater｛即所謂SI，CNN的王牌體育節目｝和MY-look的主頁引用，因此該行包含了名叫“anchor:cnnsi.com”和 “anchhor:my.look.ca”的列。每個錨鏈接只有一個版本｛由時間戳標識，如t9，t8｝；而contents列則有三個版本，分別由時間 戳t3，t5，和t6標識。
行
表中的行關鍵字可以是任意字符串（目前支持最多64KB，多數情況下10－100字節足夠了）。在一個行關鍵字下的每一個讀寫操作都是原子操作（不管讀寫這一行裏多少個不同列），這是一個設計決定，這樣在對同一行進行併發操作時，用戶對於系統行爲更容易理解和掌控。
Bigtable通過行關鍵字的字典序來維護數據。一張表可以動態劃分成多個連續行。連續行在這裏叫做“子表”｛tablet｝，是數據分佈和負載 均衡的單位。這樣一來，讀較少的連續行就比較有效率，通常只需要較少機器之間的通信即可。用戶可以利用這個屬性來選擇行關鍵字，從而達到較好數據訪問地域 性｛locality｝。舉例來說，在Webtable裏，通過反轉URL中主機名的方式，可以把同一個域名下的網頁組織成連續行。具體來說，可以把 maps.google.com/index.html中的數據存放在關鍵字com.google.maps/index.html下。按照相同或屬性相 近的域名來存放網頁可以讓基於主機和基於域名的分析更加有效。
列族
一組列關鍵字組成了“列族”，這是訪問控制的基本單位。同一列族下存放的所有數據通常都是同一類型（同一列族下的數據可壓縮在一起）。列族必須先創 建，然後在能在其中的列關鍵字下存放數據；列族創建後，族中任何一個列關鍵字均可使用。我們希望，一張表中的不同列族不能太多（最多幾百個），並且列族在 運作中絕少改變。作爲對比，一張表可以有無限列。
列關鍵字用如下語法命名：列族：限定詞。 列族名必須是看得懂｛printable｝的字串，而限定詞可以是任意字符串。比如，Webtable可以有個列族叫language，存放撰寫網頁的語 言。我們在language列族中只用一個列關鍵字，用來存放每個網頁的語言標識符。該表的另一個有用的列族是anchor；給列族的每一個列關鍵字代表 一個錨鏈接，如圖一所示。而這裏的限定詞則是引用該網頁的站點名；表中一個表項存放的是鏈接文本。
訪問控制，磁盤使用統計，內存使用統計，均可在列族這個層面進行。在Webtable舉例中，我們可以用這些控制來管理不同應用：有的應用添加新的基本數據，有的讀取基本數據並創建引申的列族，有的則只能瀏覽數據（甚至可能因爲隱私權原因不能瀏覽所有數據）。
時間戳
Bigtable表中每一個表項都可以包含同一數據的多個版本，由時間戳來索引。Bigtable的時間戳是64位整型。可以由Bigtable來 賦值，表示準確到毫秒的“實時”；或者由用戶應用程序來賦值。需要避免衝突的應用程序必須自己產生具有唯一性的時間戳。不同版本的表項內容按時間戳倒序排 列，即最新的排在前面。
爲了簡化對於不同數據版本的數據的管理，我們對每一個列族支持兩個設定，以便於Bigtable對錶項的版本自動進行垃圾清除。用戶可以指明只保留表項的最後n個版本，或者只保留足夠新的版本（比如，只保留最近7天的內容）。
在Webtable舉例中，我們在contents:列中存放確切爬行一個網頁的時間戳。如上所述的垃圾清除機制可以讓我們只保留每個網頁的最近三個版本。
3.API
BT的API提供了建立和刪除表和列族的函數．還提供了函數來修改集羣，表和列族的元數據，比如說訪問權限．
// Open the table
Table *T = OpenOrDie(”/bigtable/web/webtable”);
// Write a new anchor and delete an old anchor
RowMutation r1(T, “com.cnn.www”);
r1.Set(”anchor:www.c-span.org”, “CNN”);
r1.Delete(”anchor:www.abc.com”);
Operation op;
Apply(&op, &r1);
圖 2: 寫入Bigtable.
在BT中，客戶應用可以寫或者刪除值，從每個行中找值，或者遍歷一個表中的數據子集．圖2的c++代碼是使用RowMutation抽象表示來進行一系列的更新（爲保證代碼精簡，沒有包括無關的細節）．調用Apply函數，就對Ｗebtable進行了一個原子修改：它爲http://www.cnn.com/增加了一個錨點，並刪除了另外一個錨點．
Scanner scanner(T);
ScanStream *stream;
stream = scanner.FetchColumnFamily(”anchor”);
stream->SetReturnAllVersions();
scanner.Lookup(”com.cnn.www”);
for (; !stream->Done(); stream->Next()) {
printf(”%s %s %lld %s/n”,
scanner.RowName(),
stream->ColumnName(),
stream->MicroTimestamp(),
stream->Value());
}
圖3: 從Bigtable讀數據.
圖3的C++代碼是使用Scanner抽象來遍歷一個行內的所有錨點．客戶可以遍歷多個列族．有很多方法可以限制一次掃描中產生的行，列和時間戳． 例如，我們可以限制上面的掃描，讓它只找到那些匹配正則表達式*.cnn.com的錨點，或者那些時間戳在當前時間前10天的錨點．
BT還支持其他一些更復雜的處理數據的功能．首先，BT支持單行處理．這個功能可以用來對存儲在一個行關鍵字下的數據進行原子的讀-修改-寫操作． BT目前不支持跨行關鍵字的處理，但是它有一個界面，可以用來讓客戶進行批量的跨行關鍵字處理操作．其次，BT允許把每個表項用做整數記數器．最後，BT 支持在服務器的地址空間內執行客戶端提供的腳本程序．腳本程序的語言是google開發的Sawzall[28]數據處理語言．目前，我們基於的 Sawzall的API還不允許客戶腳本程序向BT內寫數據，但是它允許多種形式的數據變換，基於任何表達式的過濾和通過多種操作符的摘要．
BT可以和MapReduce[12]一起使用．MapReduce是google開發的大規模並行計算框架．我們爲編寫了一套外層程序，使BT可以作爲MapReduce處理的數據源頭和輸出結果．
4.建立BT的基本單元
BT是建立在其他數個google框架單元上的．BT使用google分佈式文件系統(GFS)[17]來存儲日誌和數據文件{yeah, right, what else can it use, FAT32?}．一個BT集羣通常在一個共享的機器池中工作，池中的機器還運行其他的分佈式應用{雖然機器便宜的跟白菜似的，可是一樣要運行多個程序，命苦的象小白菜}，BT和其他程序共享機器｛BT的瓶頸是ＩＯ/內存，可以和CPU要求高的程序並存｝．BT依賴集羣管理系統來安排工作，在共享的機器上管理資源，處理失效機器並監視機器狀態｛典型的server farm結構，BT是上面的應用之一｝．
BT內部存儲數據的格式是google SSTable格式．一個SSTable提供一個從關鍵字到值的映射，關鍵字和值都可以是任意字符串．映射是排序的，存儲的｛不會因爲掉電而丟失｝，不可改寫的．可以進行以下操作：查詢和一個關鍵字相關的值；或者根據給出的關鍵字範圍遍歷所有的關鍵字和值．在內部，每個SSTable包含一列數據塊（通常每個塊的大小是64KB,但是大小是可以配置的｛索引大小是16 bits，應該是比較好的一個數｝）．塊索引（存儲在SSTable的最後）用來定位數據塊；當打開SSTable的時候，索引被讀入內存｛性能｝．每次查找都可以用一個硬盤搜索完成｛根據索引算出數據在哪個道上，一個塊應該不會跨兩個道，沒必要省那麼點空間｝：首先在內存中的索引裏進行二分查找找到數據塊的位置，然後再從硬盤讀去數據塊．最佳情況是：整個SSTable可以被放在內存裏，這樣一來就不必訪問硬盤了．｛想的美，前面是誰口口聲聲說要跟別人共享機器來着？你把內存佔滿了別人上哪睡去？｝
BT還依賴一個高度可用的，存儲的分佈式數據鎖服務Chubby[8]｛看你怎麼把這個high performance給說圓嘍｝．一個Chubby服務由5個活的備份｛機器｝構成，其中一個被這些備份選成主備份，並且處理請求．這個服務只有在大多數備份都活着並且互相通信的時候纔是活的｛繞口令？去看原文吧，是在有出錯的前提下的冗餘算法｝．當有機器失效的時候，Chubby使用Paxos算法[9,23]來保證備份的一致性｛這個問題還是比較複雜的，建議去看引文了解一下問題本身｝．Chubby提供了一個名字空間，裏面包括了目錄和小文件｛萬變不離其宗｝．每個目錄或者文件可以當成一個鎖來用，讀寫文件操作都是原子化的．Chubby客戶端的程序庫提供了對Chubby文件的一致性緩存｛究竟是提高性能還是降低性能？如果訪問是分佈的，就是提高性能｝．每個Chubby客戶維護一個和Chubby服務的會話．如果一個客戶不能在一定時間內更新它的會話，這個會話就過期失效了｛還是針對大server farm裏機器失效的頻率設計的｝．當一個會話失效時，其擁有的鎖和打開的文件句柄都失效｛根本設計原則：失效時回到安全狀態｝．Chubby客戶可以在文件和目錄上登記回調函數，以獲得改變或者會話過期的通知．｛翻到這裏，有沒有人聞到java的味道了？｝
BT使用Chubby來做以下幾個任務：保證任何時間最多隻有一個活躍的主備份；來存儲BT數據的啓動位置（參考5.1節）；發現小表 （tablet）服務器，並完成tablet服務器消亡的善後（5.2節）；存儲BT數據的模式信息（每張表的列信息）；以及存儲訪問權限列表．如果有相當長的時間Chubby不能訪問，BT就也不能訪問了｛任何系統都有其弱點｝．最近我們在使用11個Chubby服務實例的14個BT集羣中度量了這個效果，由於Chubby不能訪問而導致BT中部分數據不能訪問的平均百分比是0.0047%,這裏Chubby不能訪問的原因是Chubby本身失效或者網絡問題．單個集羣裏，受影響最大的百分比是0.0326%｛基於文件系統的Chubby還是很穩定的｝.
GFS是一個可擴展的分佈式文件系統，用於大型的、分佈式的、對大量數據進行訪問的應用。它運行於廉價的普通硬件上，但可以提供容錯功能。它可以給大量的用戶提供總體性能較高的服務。
出處：http://labs.google.com/papers/gfs.html
1、設計概覽
（1）設計想定
GFS與過去的分佈式文件系統有很多相同的目標，但GFS的設計受到了當前及預期的應用方面的工作量及技術環境的驅動，這反映了它與早期的文件系統明顯不同的設想。這就需要對傳統的選擇進行重新檢驗並進行完全不同的設計觀點的探索。
GFS與以往的文件系統的不同的觀點如下：
1、部件錯誤不再被當作異常，而是將其作爲常見的情況加以處理。因爲文件系統由成百上千個用於存儲的機器構成，而這 些機器是由廉價的普通部件組成並被大量的客戶機訪問。部件的數量和質量使得一些機器隨時都有可能無法工作並且有一部分還可能無法恢復。所以實時地監控、錯 誤檢測、容錯、自動恢復對系統來說必不可少。
2、按照傳統的標準，文件都非常大。長度達幾個GB的文件是很平常的。每個文件通常包含很多應用對象。當經常要處理 快速增長的、包含數以萬計的對象、長度達TB的數據集時，我們很難管理成千上萬的KB規模的文件塊，即使底層文件系統提供支持。因此，設計中操作的參數、 塊的大小必須要重新考慮。對大型的文件的管理一定要能做到高效，對小型的文件也必須支持，但不必優化。
3、大部分文件的更新是通過添加 新數據完成的，而不是改變已存在的數據。在一個文件中隨機的操作在實踐中幾乎不存在。一旦寫完，文件就只可讀，很多數據都有這些特性。一些數據可能組成一 個大倉庫以供數據分析程序掃描。有些是運行中的程序連續產生的數據流。有些是檔案性質的數據，有些是在某個機器上產生、在另外一個機器上處理的中間數據。 由於這些對大型文件的訪問方式，添加操作成爲性能優化和原子性保證的焦點。而在客戶機中緩存數據塊則失去了吸引力。
4、工作量主要由兩種讀操作構成：對大量數據的流方式的讀操作和對少量數據的隨機方式的讀操作。在前一種讀操作中， 可能要讀幾百KB，通常達 1MB和更多。來自同一個客戶的連續操作通常會讀文件的一個連續的區域。隨機的讀操作通常在一個隨機的偏移處讀幾個KB。性能敏感的應用程序通常將對少量 數據的讀操作進行分類並進行批處理以使得讀操作穩定地向前推進，而不要讓它來來回回的讀。
5、工作量還包含許多對大量數據進行的、連續的、向文件添加數據的寫操作。所寫的數據的規模和讀相似。一旦寫完，文件很少改動。在隨機位置對少量數據的寫操作也支持，但不必非常高效。
6、系統必須高效地實現定義完好的大量客戶同時向同一個文件的添加操作的語義。
（2）系統接口
GFS提供了一個相似地文件系統界面，雖然它沒有向POSIX那樣實現標準的API。文件在目錄中按層次組織起來並由路徑名標識。
（3）體系結構：
一個GFS集羣由一個master和大量的chunkserver構成，並被許多客戶（Client）訪問。如圖1 所示。Master和 chunkserver通常是運行用戶層服務進程的Linux機器。只要資源和可靠性允許，chunkserver和client可以運行在同一個機器 上。
文件被分成固定大小的塊。每個塊由一個不變的、全局唯一的64位的chunk－handle標識，chunk－ handle是在塊創建時由 master分配的。ChunkServer將塊當作Linux文件存儲在本地磁盤並可以讀和寫由chunk－handle和位區間指定的數據。出於可靠 性考慮，每一個塊被複制到多個chunkserver上。默認情況下，保存3個副本，但這可以由用戶指定。
Master維護文件系統所以的元數據（metadata），包括名字空間、訪問控制信息、從文件到塊的映射以及塊 的當前位置。它也控制系統範圍的活動，如塊租約（lease）管理，孤兒塊的垃圾收集，chunkserver間的塊遷移。Master定期通過 HeartBeat消息與每一個 chunkserver通信，給chunkserver傳遞指令並收集它的狀態。
與每個應用相聯的GFS客戶代碼實現了文件系統的API並與master和chunkserver通信以代表應用程序讀和寫數據。客戶與master的交換隻限於對元數據（metadata）的操作，所有數據方面的通信都直接和chunkserver聯繫。
客戶和chunkserver都不緩存文件數據。因爲用戶緩存的益處微乎其微，這是由於數據太多或工作集太大而無法 緩存。不緩存數據簡化了客戶程序和整個系統，因爲不必考慮緩存的一致性問題。但用戶緩存元數據（metadata）。Chunkserver也不必緩存文 件，因爲塊時作爲本地文件存儲的。
（4）單master。
只有一個master也極大的簡化了設計並使得master可以根據全局情況作出先進的塊放置和複製決定。但是我們 必須要將master對讀和寫的參與減至最少，這樣它纔不會成爲系統的瓶頸。Client從來不會從master讀和寫文件數據。Client只是詢問 master它應該和哪個 chunkserver聯繫。Client在一段限定的時間內將這些信息緩存，在後續的操作中Client直接和chunkserver交互。
以圖1解釋一下一個簡單的讀操作的交互。
1、client使用固定的塊大小將應用程序指定的文件名和字節偏移轉換成文件的一個塊索引（chunk index）。
2、給master發送一個包含文件名和塊索引的請求。
3、master迴應對應的chunk handle和副本的位置（多個副本）。
4、client以文件名和塊索引爲鍵緩存這些信息。（handle和副本的位置）。
5、Client 向其中一個副本發送一個請求，很可能是最近的一個副本。請求指定了chunk handle（chunkserver以chunk handle標識chunk）和塊內的一個字節區間。
6、除非緩存的信息不再有效（cache for a limited time）或文件被重新打開，否則以後對同一個塊的讀操作不再需要client和master間的交互。
通常Client可以在一個請求中詢問多個chunk的地址，而master也可以很快回應這些請求。
（5）塊規模：
塊規模是設計中的一個關鍵參數。我們選擇的是64MB，這比一般的文件系統的塊規模要大的多。每個塊的副本作爲一個普通的Linux文件存儲，在需要的時候可以擴展。
塊規模較大的好處有：
1、減少client和master之間的交互。因爲讀寫同一個塊只是要在開始時向master請求塊位置信息。對於讀寫大型文件這種減少尤爲重要。即使對於訪問少量數據的隨機讀操作也可以很方便的爲一個規模達幾個TB的工作集緩緩存塊位置信息。
2、Client在一個給定的塊上很可能執行多個操作，和一個chunkserver保持較長時間的TCP連接可以減少網絡負載。
3、這減少了master上保存的元數據（metadata）的規模，從而使得可以將metadata放在內存中。這又會帶來一些別的好處。
不利的一面：
一個小文件可能只包含一個塊，如果很多Client訪問改文件的話，存儲這些塊的chunkserver將成爲訪問的熱點。但在實際應用中，應用程序通常順序地讀包含多個塊的文件，所以這不是一個主要問題。
（6）元數據（metadata）：
master存儲了三中類型的metadata：文件的名字空間和塊的名字空間，從文件到塊的映射，塊的副本的位 置。所有的metadata都放在內存中。前兩種類型的metadata通過向操作日誌登記修改而保持不變，操作日誌存儲在master的本地磁盤並在幾 個遠程機器上留有副本。使用日誌使得我們可以很簡單地、可靠地更新master的狀態，即使在master崩潰的情況下也不會有不一致的問題。相反， mater在每次啓動以及當有 chuankserver加入的時候詢問每個chunkserver的所擁有的塊的情況。
A、內存數據結構：
因爲metadata存儲在內存中，所以master的操作很快。進一步，master可以輕易而且高效地定期在後臺掃描它的整個狀態。這種定期地掃描被用於實現塊垃圾收集、chunkserver出現故障時的副本複製、爲平衡負載和磁盤空間而進行的塊遷移。
這種方法的一個潛在的問題就是塊的數量也即整個系統的容量是否受限與master的內存。實際上，這並不是一個嚴重 的問題。Master爲每個 64MB的塊維護的metadata不足64個字節。除了最後一塊，文件所有的塊都是滿的。類似的，每個文件的名字空間數據也不足64個字節，因爲文件名 是以一種事先確定的壓縮方式存儲的.如果要支持更大的文件系統，那麼增加一些內存的方法對於我們將元數據（metadata）保存在內存種所獲得的簡單 性、可靠性、高性能和靈活性來說，這只是一個很小的代價。
B、塊位置：
master並不爲chunkserver所擁有的塊的副本的保存一個不變的記錄。它在啓動時通過簡單的查詢來獲得這些信息。Master可以保持這些信息的更新，因爲它控制所有塊的放置並通過HeartBeat消息來監控chunkserver的狀態。
這樣做的好處：因爲chunkserver可能加入或離開集羣、改變路徑名、崩潰、重啓等，一個集羣重有成百個server，這些事件經常發生，這種方法就排除了master與chunkserver之間的同步問題。
另一個原因是：只有chunkserver才能確定它自己到底有哪些塊，由於錯誤，chunkserver中的一些塊可能會很自然的消失，這樣在master中就沒有必要爲此保存一個不變的記錄。
C、操作日誌：
操作日誌包含了對metadata所作的修改的歷史記錄。它作爲邏輯時間線定義了併發操作的執行順序。文件、塊以及它們的版本號都由它們被創建時的邏輯時間而唯一地、永久地被標識。
操作日誌是如此的重要，我們必須要將它可靠地保存起來，並且只有在metadata的改變固定下來之後纔將變化呈現給用戶。所以我們將操作日誌複製到數個遠程的機器上，並且只有在將相應的日誌記錄寫到本地和遠程的磁盤上之後纔回答用戶的請求。
Master可以用操作日誌來恢復它的文件系統的狀態。爲了將啓動時間減至最小，日誌就必須要比較小。每當日誌的長度增長到超過一定的規模後，master就要檢查它的狀態，它可以從本地磁盤裝入最近的檢查點來恢復狀態。
創建一個檢查點比較費時，master的內部狀態是以一種在創建一個檢查點時並不耽誤即將到來的修改操作的方式來組 織的。Master切換到一個新的日子文件並在一個單獨的線程中創建檢查點。這個新的檢查點記錄了切換前所有的修改。在一個有數十萬文件的集羣中用一分鐘 左右就能完成。創建完後，將它寫入本地和遠程的磁盤。
（7）數據完整性
名字空間的修改必須是原子性的，它們只能有master處理：名字空間鎖保證了操作的原子性和正確性，而master的操作日誌在全局範圍內定義了這些操作的順序。
文 件區間的狀態在修改之後依賴於修改的類型，不論操作成功還是失敗，也不論是不是併發操作。如果不論從哪個副本上讀，所有的客戶都看到同樣的數據，那麼文件 的這個區域就是一致的。如果文件的區域是一致的並且用戶可以看到修改操作所寫的數據，那麼它就是已定義的。如果修改是在沒有併發寫操作的影響下完成的，那 麼受影響的區域是已定義的，所有的client都能看到寫的內容。成功的併發寫操作是未定義但卻是一致的。失敗的修改將使區間處於不一致的狀態。
Write操作在應用程序指定的偏移處寫入數據，而record append操作使得數據（記錄）即使在有併發修改操作的情況下也至少原子性的被加到GFS指定的偏移處，偏移地址被返回給用戶。
在一系列成功的修改操作後，最後的修改操作保證文件區域是已定義的。GFS通過對所有的副本執行同樣順序的修改操作並且使用塊版本號檢測過時的副本（由於chunkserver退出而導致丟失修改）來做到這一點。
因爲用戶緩存了會位置信息，所以在更新緩存之前有可能從一個過時的副本中讀取數據。但這有緩存的截止時間和文件的重新打開而受到限制。
在修改操作成功後，部件故障仍可以是數據受到破壞。GFS通過master和chunkserver間定期的handshake，藉助校驗和來檢測對數據的破壞。一旦檢測到，就從一個有效的副本儘快重新存儲。只有在GFS檢測前，所有的副本都失效，這個塊纔會丟失。
2、系統交互
（1）租約（lease）和修改順序
（2）數據流
我們的目標是充分利用每個機器的網絡帶寬，避免網絡瓶頸和延遲
爲了有效的利用網絡，我們將數據流和控制流分離。數據是以流水線的方式在選定的chunkerserver鏈上線性的傳遞的。每個機器的整個對外帶寬都被用作傳遞數據。爲避免瓶頸，每個機器在收到數據後，將它收到數據儘快傳遞給離它最近的機器。
（3）原子性的record Append：
GFS提供了一個原子性的添加操作：record append。在傳統的寫操作中，client指定被寫數據的偏移位置，向同一個區間的併發的寫操作是不連續的：區間有可能包含來自多個client的數 據碎片。在record append中， client只是指定數據。GFS在其選定的偏移出將數據至少原子性的加入文件一次，並將偏移返回給client。
在分佈式的應用中，不同機器上的許多client可能會同時向一個文件執行添加操作，添加操作被頻繁使用。如果用傳 統的write操作，可能需要額外的、複雜的、開銷較大的同步，例如通過分佈式鎖管理。在我們的工作量中，這些文件通常以多個生產者單個消費者隊列的方式 或包含從多個不同 client的綜合結果。
Record append和前面講的write操作的控制流差不多，只是在primary上多了一些邏輯判斷。首先，client將數據發送到文件最後一塊的所有副本 上。然後向primary發送請求。Primary檢查添加操作是否會導致該塊超過最大的規模（64M）。如果這樣，它將該塊擴充到最大規模，並告訴其它 副本做同樣的事，同時通知client該操作需要在下一個塊上重新嘗試。如果記錄滿足最大規模的要求，primary就會將數據添加到它的副本上，並告訴 其它的副本在在同樣的偏移處寫數據，最後primary向client報告寫操作成功。如果在任何一個副本上record append操作失敗，client將重新嘗試該操作。這時候，同一個塊的副本可能包含不同的數據，因爲有的可能複製了全部的數據，有的可能只複製了部 分。GFS不能保證所有的副本每個字節都是一樣的。它只保證每個數據作爲一個原子單元被寫過至少一次。這個是這樣得出的：操作要是成功，數據必須在所有的 副本上的同樣的偏移處被寫過。進一步，從這以後，所有的副本至少和記錄一樣長，所以後續的記錄將被指定到更高的偏移處或者一個不同的塊上，即使另一個副本 成了primary。根據一致性保證，成功的record append操作的區間是已定義的。而受到干擾的區間是不一致的。
（4）快照（snapshot）
快照操作幾乎在瞬間構造一個文件和目錄樹的副本，同時將正在進行的其他修改操作對它的影響減至最小。
我們使用copy-on-write技術來實現snapshot。當master受到一個snapshot請求時， 它首先將要snapshot的文件上塊上的lease。這使得任何一個向這些塊寫數據的操作都必須和master交互以找到擁有lease的副本。這就給 master一個創建這個塊的副本的機會。
副本被撤銷或終止後，master在磁盤上登記執行的操作，然後複製源文件或目錄樹的metadata以對它的內存狀態實施登記的操作。這個新創建的snapshot文件和源文件（其metadata）指向相同的塊（chunk）。
Snapshot之後，客戶第一次向chunk c寫的時候，它發一個請求給master以找到擁有lease的副本。Master注意到chunk c的引用記數比1大，它延遲對用戶的響應，選擇一個chunk handle C’,然後要求每一有chunk c的副本的chunkserver創建一個塊C’。每個chunkserver在本地創建chunk C’避免了網絡開銷。從這以後和對別的塊的操作沒有什麼區別。
3、MASTER操作
MASTER執行所有名字空間的操作，除此之外，他還在系統範圍管理數據塊的複製：決定數據塊的放置方案，產生新數據塊並將其備份，和其他系統範圍的操作協同來確保數據備份的完整性，在所有的數據塊服務器之間平衡負載並收回沒有使用的存儲空間。
3.1 名字空間管理和加鎖
與傳統文件系統不同的是，GFS沒有與每個目錄相關的能列出其所有文件的數據結構，它也不支持別名（unix中的硬連接或符號連接），不管是對文件或是目錄。GFS的名字空間邏輯上是從文件元數據到路徑名映射的一個查用表。
MASTER在執行某個操作前都要獲得一系列鎖，例如，它要對/d1/d2…/dn/leaf執行操作，則它必須獲 得/d1，/d1/d2，…， /d1/d2/…/dn的讀鎖，/d1/d2…/dn/leaf的讀鎖或寫鎖（其中leaf可以使文件也可以是目錄）。MASTER操作的並行性和數據的 一致性就是通過這些鎖來實現的。
3.2 備份存儲放置策略
一個GFS集羣文件系統可能是多層分佈的。一般情況下是成千上萬個文件塊服務器分佈於不同的機架上，而這些文件塊服 務器又被分佈於不同機架上的客戶來訪問。因此，不同機架上的兩臺機器之間的通信可能通過一個或多個交換機。數據塊冗餘配置策略要達到連個目的：最大的數據 可靠性和可用性，最大的網絡帶寬利用率。因此，如果僅僅把數據的拷貝置於不同的機器上很難滿足這兩個要求，必須在不同的機架上進行數據備份。這樣即使整個 機架被毀或是掉線，也能確保數據的正常使用。這也使數據傳輸，尤其是讀數據，可以充分利用帶寬，訪問到多個機架，而寫操作，則不得不涉及到更多的機架。
3.3 產生、重複制、重平衡數據塊
當MASTER產生新的數據塊時，如何放置新數據塊，要考慮如下幾個因素：（1）儘量放置在磁盤利用率低的數據塊服 務器上，這樣，慢慢地各服務器的磁盤利用率就會達到平衡。（2）儘量控制在一個服務器上的“新創建”的次數。（3）由於上一小節討論的原因，我們需要把數 據塊放置於不同的機架上。
MASTER在可用的數據塊備份低於用戶設定的數目時需要進行重複制。這種情況源於多種原因：服務器不可用，數據被 破壞，磁盤被破壞，或者備份數目被修改。每個被需要重複制的數據塊的優先級根據以下幾項確定：第一是現在的數目距目標的距離，對於能阻塞用戶程序的數據 塊，我們也提高它的優先級。最後， MASTER按照產生數據塊的原則複製數據塊，並把它們放到不同的機架內的服務器上。
MASTER週期性的平衡各服務器上的負載：它檢查chunk分佈和負載平衡，通過這種方式來填充一個新的服務器而 不是把其他的內容統統放置到它上面帶來大量的寫數據。數據塊放置的原則與上面討論的相同，此外，MASTER還決定那些數據塊要被移除，原則上他會清除那 些空閒空間低於平均值的那些服務器。
3.4 垃圾收集
在一個文件被刪除之後，GFS並不立即收回磁盤空間，而是等到垃圾收集程序在文件和數據塊級的的檢查中收回。
當一個文件被應用程序刪除之後，MASTER會立即記錄下這些變化，但文件所佔用的資源卻不會被立即收回，而是重新 給文件命了一個隱藏的名字，並附上了刪除的時間戳。在MASTER定期檢查名字空間時，它刪除超過三天（可以設定）的隱藏的文件。在此之前，可以以一個新 的名字來讀文件，還可以以前的名字恢復。當隱藏的文件在名字空間中被刪除以後，它在內存中的元數據即被擦除，這就有效地切斷了他和所有數據塊的聯繫。
在一個相似的定期的名字空間檢查中，MASTER確認孤兒數據塊（不屬於任何文件）並擦除他的元數據，在和MASTER的心跳信息交換中，每個服務器報告他所擁有的數據塊，MASTER返回元數據不在內存的數據塊，服務器即可以刪除這些數據塊。
3.5 過時數據的探測
在數據更新時如果服務器停機了，那麼他所保存的數據備份就會過時。對每個數據塊，MASTER設置了一個版本號來區別更新過的數據塊和過時的數據塊。
當MASTER授權一個新的lease時，他會增加數據塊的版本號並會通知更新數據備份。MASTER和備份都會記 錄下當前的版本號，如果一個備份當時不可用，那麼他的版本號不可能提高，當ChunkServer重新啓動並向MASTER報告他的數據塊集時， MASTER就會發現過時的數據。
MASTER在定期的垃圾收集程序中清除過時的備份，在此以前，處於效率考慮，在各客戶及英大使，他會認爲根本不存 在過時的數據。作爲另一個安全措施， MASTER在給客戶及關於數據塊的應答或是另外一個讀取數據的服務器數據是都會帶上版本信息，在操作前客戶機和服務器會驗證版本信息以確保得到的是最新 的數據。
4、容錯和診斷
4.1 高可靠性
4.1.1 快速恢復
不管如何終止服務，MASTER和數據塊服務器都會在幾秒鐘內恢復狀態和運行。實際上，我們不對正常終止和不正常終止進行區分，服務器進程都會被切斷而終止。客戶機和其他的服務器會經歷一個小小的中斷，然後它們的特定請求超時，重新連接重啓的服務器，重新請求。
4.1.2 數據塊備份
如上文所討論的，每個數據塊都會被備份到放到不同機架上的不同服務器上。對不同的名字空間，用戶可以設置不同的備份級別。在數據塊服務器掉線或是數據被破壞時，MASTER會按照需要來複制數據塊。
4.1.3 MASTER備份
爲確保可靠性，MASTER的狀態、操作記錄和檢查點都在多臺機器上進行了備份。一個操作只有在數據塊服務器硬盤上 刷新並被記錄在MASTER和其備份的上之後纔算是成功的。如果MASTER或是硬盤失敗，系統監視器會發現並通過改變域名啓動它的一個備份機，而客戶機 則僅僅是使用規範的名稱來訪問，並不會發現MASTER的改變。
4.2 數據完整性
每個數據塊服務器都利用校驗和來檢驗存儲數據的完整性。原因：每個服務器隨時都有發生崩潰的可能性，並且在兩個服務器間比較數據塊也是不現實的，同時，在兩臺服務器間拷貝數據並不能保證數據的一致性。
每個Chunk按64kB的大小分成塊，每個塊有32位的校驗和，校驗和和日誌存儲在一起，和用戶數據分開。
在讀數據時，服務器首先檢查與被讀內容相關部分的校驗和，因此，服務器不會傳播錯誤的數據。如果所檢查的內容和校驗 和不符，服務器就會給數據請求者返回一個錯誤的信息，並把這個情況報告給MASTER。客戶機就會讀其他的服務器來獲取數據，而MASTER則會從其他的 拷貝來複制數據，等到一個新的拷貝完成時，MASTER就會通知報告錯誤的服務器刪除出錯的數據塊。
附加寫數據時的校驗和計算優化了，因爲這是主要的寫操作。我們只是更新增加部分的校驗和，即使末尾部分的校驗和數據已被損壞而我們沒有檢查出來，新的校驗和與數據會不相符，這種衝突在下次使用時將會被檢查出來。
相反，如果是覆蓋現有數據的寫，在寫以前，我們必須檢查第一和最後一個數據塊，然後才能執行寫操作，最後計算和記錄校驗和。如果我們在覆蓋以前不先檢查首位數據塊，計算出的校驗和則會因爲沒被覆蓋的數據而產生錯誤。
在空閒時間，服務器會檢查不活躍的數據塊的校驗和，這樣可以檢查出不經常讀的數據的錯誤。一旦錯誤被檢查出來，服務器會拷貝一個正確的數據塊來代替錯誤的。
4.3 診斷工具
廣泛而細緻的診斷日誌以微小的代價換取了在問題隔離、診斷、性能分析方面起到了重大的作用。GFS服務器用日誌來記 錄顯著的事件（例如服務器停機和啓動）和遠程的應答。遠程日誌記錄機器之間的請求和應答，通過收集不同機器上的日誌記錄，並對它們進行分析恢復，我們可以 完整地重現活動的場景，並用此來進行錯誤分析。
5 測量
5.1 測試環境
一臺主控機，兩臺主控機備份，16臺數據塊服務器，16臺客戶機。
每臺機器：2塊PIII1.4G處理器，2G內存，2塊80G5400rpm的硬盤，1塊100Mbps全雙工網卡
19臺服務器連接到一個HP2524交換機上，16臺客戶機倆接到領外一臺交換機上，兩臺交換機通過1G的鏈路相連。
資料來源:http://bigweb.group.javaeye.com/group/topic/5749