1、google是與眾不同的。它的獨特不僅僅表現于革新的思維和充滿創意的應用 (比如那個大堂里的地球模型)，更在于其有別常規的it策略 加利福尼亞州山景城(mountain view)google公司(google，下稱google)總部有一個43號大樓，該建筑的中央大屏幕上顯示著一個與google地球(google earth)相仿的世界地圖，一個轉動的地球上不停地閃動著五顏六色的光點，恍如羅馬宮廷的千萬燭燈，每一次閃動標志著地球的這個角落一名google用 戶發起了一次新的搜索。 這同時意味著google又一次滿足了人們對未知信息的好

2、奇與渴望。 google是與眾不同的。它的獨特不僅僅表現于革新的思維和充滿創意的應用 (比如那個大堂里的地球模型)，更在于其有別常規的it策略。從人們的常理來看，簡單的硬件商品和免費軟件是無法構建出一個帝國的，但是google做到 了。在性能調整后，google把它們變成一個無可比擬的分布式計算平臺，該平臺能夠支持大規模的搜索和不斷涌現的新興應用。我們原本認為這些應用都是個 人消費級別的，但是google改變了這一切。現在商業世界也在使用它們，這就令這家搜索公司顯得那么與眾不同。 googleweb 服務背后的it架構對無數使用搜索引

3、擎的用戶來說也許并不是非常重要，但它是google幾百位致力于把全球信息組織起來，實現“隨處可達，隨時可用”目 標的工程師們的最核心工作。這就需要一個在覆蓋范圍和野心上都與google的商業愿景完全相符的it藍圖作為支撐。 google 的經理們一直對公司的it策略話題保持沉默，他們厭惡談及特定的廠商或者產品，當被問到他們的服務器和數據中心時，他們總是閉口不談。但與幾位 google的it領導一起呆了一天后，我們最終得以揭示該公司的it是如何運作的，那可不僅僅是一個運行在無數服務器集群上的、表面看來非常簡單的搜索 引擎。在其簡單的外表下，蘊涵著

4、許多內部研發軟件、定制硬件、人工智能，以及對性能的執著追求和打破常規的人力管理模式。 it理念方面，google對同行有一條建議：盡量避免那些人人都在使用的系統和軟件，以自己的方式做事會更有獨特的競爭優勢。 “企業文化決定了你的做事方式。”道格拉斯"美林(douglas merrill)，這位google工程副總裁和事實上的首席信息官(cio) 指出，“到了我們這樣的發展階段，企業觀念和文化非常與眾不同，這也反過來鞭策我們必須要采用與眾不同的方式來運行那些他人看來很常規的系統。” google 最大的it優勢在于它能建造出既

5、富于性價比(并非廉價)又能承受極高負載的高性能系統。因此it顧問史蒂芬"阿諾德(stephen arnold)指出，google與競爭對手，如亞馬遜網站(amazon)、電子港灣公司(ebay)、微軟公司(microsoft，下稱微軟)和雅 虎公司 (yahoo，下稱雅虎)等公司相比，具有更大的成本優勢。google程序員的效率比其他web公司同行們高出50%100%，原因是google已 經開發出了一整套專用于支持大規模并行系統編程的定制軟件庫。據他估算，其他競爭公司可能要花上四倍的時間才能獲得同等的效果。 打造服務器 g

6、oogle 究竟是怎樣做到這點的呢?其中一個手段，美林認為，“是因為我們自己動手打造硬件。”google并不制造計算機系統，但它根據自己的參數定制硬件，然后 像mtv的節目“靚車打造”(pimp my ride)那樣自己安裝和調整硬件系統。開源程序經理克里斯"迪博納(chris dibona)評論道：“我們很善于購買商業服務器，并且改造他們為我們所用，最后把性能壓榨和發揮到極致，以致有時候他們熱得像要融化了似的。” 這種親手打造的方式，來源于google從車庫誕生時與生俱來的節儉風格，更與google那超大型的系統規模息息相

7、關，良好的習慣一直延續至 今。據說 google在65個數據中心擁有20萬45萬臺服務器這個數目會有偏差(取決于你如何定義服務器和由誰來做這項統計)。但是，不變的是持續上升的趨 勢。 google不會去討論這些資產，因為它認為保密也是一種競爭優勢。事實上，google之所以喜歡開源軟件也是因為它的私密性。“如果我們購 買了軟件許可或代碼許可，人們只要對號入座，就可以猜出google的it基礎架構。”迪博納分析說， “使用開源軟件，就使我們多了一條把握自己命運的途徑。” google喜歡規模化的服務器運行方式。當有成百上千臺機

8、器時，定制服務器的優勢也會成倍增加，效果也會更趨明顯。google正在俄勒岡州 哥倫比亞河邊的達勒斯市建造一個占地30畝的數據中心，在那兒它可以獲得運算和降溫需要的低價水力電力能源(參見邊欄google數據中心自有一套)。 google以“單元”(cell)的形式組織這些運行 linux操作系統的服務器，迪博納把這種形式比喻成互聯網服務的“磁盤驅動器”(但別和一直謠傳的google存儲服務gdrive混淆了，“并沒有 gdrive這回事。”一位google女發言人明確表示。)，公司的軟件程序都駐扎在這些并不昂貴的電腦機箱里，由程序員決定它們的冗余工作量。

9、這種由 很多單元組成的文件系統代替了商業存儲設備;迪博納表示google這些單元設備更易于建造和維護，他還暗示他們能處理更大規模的數據。 google 不會漏過對任何技術細節的關注。多年來，公司的工程師就在研究微處理器的內部工作機制，隨著google規模的持續壯大，必然會用到特別定制和調節過的芯 片。知名工程師路易斯"巴羅索(luiz barroso)去年在一篇發表在工業雜志上的論文中證實，近年來google的主要負荷都由單核設計的系統承擔著。但許多服務器端的應用，如 google搜索索引服務，所需的并行計算在單核芯片的指令

10、級別上執行得并不好。 曾在數據設備公司(digital equipment)和康柏公司(compaq)當過芯片設計師的巴羅索認為，隨著amd公司、英特爾公司(intel)、太陽計算機系統公司(sun)開始制造多核芯片，必將會出現越來越多芯片級別的并行計算。 google 也曾考慮過自己制造計算機芯片，但從業界潮流來看，這個冒險的舉動似乎不是很必要。“微處理器的設計非常復雜而且成本昂貴，”運營高級副總裁烏爾斯"霍爾 茨勒(urs holzle)表示。google寧愿與芯片制造商合作，讓他們去理解自己的應用并設計適合的芯片。這是

11、一種客戶建議式的設計，其關注點在于總體吞吐量、 效能，以及耗電比，而不是看單線程的峰值性能。霍爾茨勒表示，“這也是最近多核cpu的設計潮流與未來方向。” 裁縫般地定制軟件 為了能盡量壓榨硬件性能，google開發了相當數量的定制軟件。創新產品主要包括用于簡化處理和創建大規模數據集的編程模型 mapreduce;用于存儲和管理大規模數據的系統bigtable;分析分布式運算環境中大規模數據集的解釋編程語言sawzall;用于數據密集型 應用的分布式文件系統的 “google文件系統”(google file syst

12、em);還有為處理分布式系統隊列分組和任務調度的“google工作隊列”(google workqueue)。 正是從sawzall這些工具里體現出google對計算效率的執著關注。并不是每家公司都能從底層去解決效率問題，但是對google來說， 為常規關系型數據庫無法容納的大規模數據集專門設計一種編程語言是完全合理的。即使其他編程工具可以解決問題，google的工程師們仍然會為了追求效率 而另外開發一套定制方案。google工程師認為，sawzall能與c+中的mapreduce相媲美，而且它更容易編寫一些。 google 對效率的

13、關注使它不可能對標準linux內核感到滿意;google會根據自己的需要運行修改過的內核版本。通過調整linux的底層性能，google 工程師們在提高了整體系統可靠性的基礎上，還一并解決了數據損壞和數據瓶頸等一系列棘手問題。對內核的修改也使google的計算機集群系統因為通信效率 的提高而運行得更快。 當然，google偶爾也會出現系統故障，情況一旦發生，無數的用戶就會受到影響了。三年前一次持續30分鐘的系統故障使20%的搜索流量受到影響。 google 開發了自己的網站服務器卻沒有使用開源的apache服務器，盡管它在網站服務器的市場占有率

14、超過60%。迪博納認為，google的網站服務器可以運行 在更多數量的主機上，對google站點上內容龐大又彼此互相依賴的應用程序來說，這種服務器的負載均衡能力遠比apache的能力更高。同時，在用標準 公共網關接口(cgi)訪問數據庫動態網頁方面，google服務器的編程難度要比 apache更高，但是最終運行速度卻更快。“如果我們能夠壓榨出10%20%的性能，我們就可以節省出更多系統資源、電量和人力了。”迪博納在總結中 指出。 google還設計了自己的客戶關系管理(crm)系統用于支持自己基于競價和點擊的互聯網廣告收費業務。但對是否需要設

15、計自己的工具，google的態度也不是一成不變的。比如在財會軟件上，它就使用了甲骨文公司(oracle)的financials軟件。 美林拿著一只叉子舉例說明現成的產品也可以帶來價值。但在有些場合現成的軟件產品就不一定適用了。“我們的文化在各個層面對我們的運作都有深遠影響，”他表示，“所以我們不想讓購買所得的工具改變我們的工作方式和文化層面。” google's bigtable 原理 （翻譯）     題記：google 的成功除了一個個出色的創意外，還因為有 je

16、ff dean 這樣的軟件架構天才。                                             &#

17、160;     - 編者 官方的 google reader blog 中有對bigtable 的解釋。這是google 內部開發的一個用來處理大數據量的系統。這種系統適合處理半結構化的數據比如 rss 數據源。 以下發言  是 andrew hitchcock  在 2005 年10月18號 基于： google 的工程師&

18、#160;jeff dean 在華盛頓大學的一次談話 (creative commons license). 首先，bigtable 從 2004 年初就開始研發了，到現在為止已經用了將近8個月。（2005年2月）目前大概有100個左右的服務使用bigtable，比如： print,search history,maps和 orkut。根據google的一貫做法，內部開發的bigtable是為跑在廉價的pc機上設計的。bigtable 讓google在提供新服務時的

19、運行成本降低，最大限度地利用了計算能力。bigtable 是建立在 gfs ，scheduler ，lock service 和 mapreduce 之上的。 每個table都是一個多維的稀疏圖 sparse map。table 由行和列組成，并且每個存儲單元 cell 都有一個時間戳。在不同的時間對同一個存儲單元cell有多份拷貝，這樣就可以記錄數據的變動情況。在他的例子中，行是urls ，列可以定義一個名字，比如：contents。conte

20、nts 字段就可以存儲文件的數據。或者列名是：”language”，可以存儲一個“en”的語言代碼字符串。 為了管理巨大的table，把table根據行分割，這些分割后的數據統稱為：tablets。每 個tablets大概有 100-200 mb，每個機器存儲100個左右的 tablets。底層的架構是：gfs。由于gfs是一種分布式的文件系統，采用tablets的機制后，可以獲得很好的負載均衡。比如：可以把經常響應 的表移動到其他空閑機器上，然后快速重建。 tablets在系統中的存儲方式是不可修改的 

21、immutable 的sstables，一臺機器一個日志文件。當系統的內存滿后，系統會壓縮一些tablets。由于jeff在論述這點的時候說的很快，所以我沒有時間把聽到的都記錄下來，因此下面是一個大概的說明： 壓縮分為：主要和次要的兩部分。次要的壓縮僅僅包括幾個tablets，而主要的壓縮時關于整個系統的壓縮。主壓縮有回收硬盤空間的功能。tablets的位置實際上是存儲在幾個特殊的bigtable的存儲單元cell中。看起來這是一個三層的系統。 客戶端有一個指向metao的tablets的指針。如果metao的tablets被頻繁使用，那個這臺機器就會放棄其他的t

22、ablets專門支持 metao這個tablets。metao tablets 保持著所有的meta1的tablets的記錄。這些tablets中包含著查找tablets的實際位置。（老實說翻譯到這里，我也不太明白。）在這個系統中不存在大的瓶頸，因為被頻繁調用的數據已經被提前獲得并進行了緩存。     現在我們返回到對列的說明：列是類似下面的形式： family:optional_qualifier。在他的例子中，行：www.search-  也許有列：”contents:其中包含ht

23、ml頁面的代碼。 “ anchor:    (翻譯到這里我要插一句，以前我看過一個關于萬能數據庫的文章，當時很激動，就聯系了作者，現在回想起來，或許google的 bigtable 才是更好的方案，切不說分布式的特性，就是這種建華的表結構就很有用處。)     注意這里說的是列信息，而不是列類型。列的信息是如下信息，一般是：屬性/規則。 比如：保存n份數據的拷貝或者保存數據n天長等等。當 tablets 重新建立的時候，就運用上面的規則

24、，剔出不符合條件的記錄。由于設計上的原因，列本身的創建是很容易的，但是跟列相關的功能確實非常復雜的，比如上文提到 的 類型和規則信息等。為了優化讀取速度，列的功能被分割然后以組的方式存儲在所建索引的機器上。這些被分割后的組作用于 列 ,然后被分割成不同的 sstables。這種方式可以提高系統的性能，因為小的，頻繁讀取的列可以被單獨存儲，和那些大的不經常訪問的列隔離開來。 在一臺機器上的所有的 tablets 共享一個log，在一個包含1億的tablets的集群中，這將會導致非常多的文件被打開和寫操作。新的log塊

25、經常被創建，一般是64m大小，這個gfs的塊大小相等。當一個機器down掉后，控制機器就會重新發布他的log塊到其他機器上繼續進行處理。這臺機器重建tablets然后詢問控制機器處理結構的存儲位置，然后直接對重建后的數據進行處理。 這個系統中有很多冗余數據，因此在系統中大量使用了壓縮技術。     dean 對壓縮的部分說的很快，我沒有完全記下來，所以我還是說個大概吧：壓縮前先尋找相似的 行，列，和時間數據。     他們使用不同版本的： bmdiff&#

26、160;和 zippy 技術。    bmdiff 提供給他們非常快的寫速度： 100mb/s  1000mb/s 。zippy 是和 lzw 類似的。zippy 并不像 lzw 或者 gzip 那樣壓縮比高，但是他處理速度非常快。     dean 還給了一個關于壓縮 web 蜘蛛數據的例子。這個例子的蜘蛛 包含&#

27、160;2.1b 的頁面，行按照以下的方式命名：“n.www/index.html:http”.在未壓縮前的web page 頁面大小是：45.1 tb ，壓縮后的大小是：4.2 tb ， 只是原來的 9.2%。links 數據壓縮到原來的 13.9% , 鏈接文本數據壓縮到原來的 12.7%。 google 還有很多沒有添加但是已經考慮的功能。     1.  數據

28、操作表達式，這樣可以把腳本發送到客戶端來提供修改數據的功能。     2. 多行數據的事物支持。     3.  提高大數據存儲單元的效率。     4. bigtable 作為服務運行。     好像：每個服務比如： maps 和 search history 歷史搜索記錄都有他們自己的集群運行&

29、#160;bigtable。     他們還考慮運行一個全局的 bigtable 系統，但這需要比較公平的分割資源和計算時間。 大表(bigtable):結構化數據的分布存儲系統 中是譯者評論,程序除外 本文的翻譯可能有不準確的地方,詳細資料請參考原文. 摘要 bigtable是設計來分布存儲大規模結構化數據的，從設計上它可以擴展到上50字節，分布存儲在幾千個普通服務器上google的很多項目使用 bt來存儲數據，包括網頁查詢，google earth和g

30、oogle金融這些應用程序對bt的要求各不相同：數據大小（從url到網頁到衛星圖象）不同，反應速度不同（從后端的大批處理到實時數 據服務）對于不同的要求，bt都成功的提供了靈活高效的服務在本文中，我們將描述bt的數據模型這個數據模型讓用戶動態的控制數據的分布和結構我 們還將描述bt的設計和實現 介紹 在過去兩年半里，我們設計，實現并部署了btbt是用來分布存儲和管理結構化數據的bt的設計使它能夠管理250 bytes(petabytes)數據，并可以部署到上千臺機器上bt完成了以下目標：應用廣泛，可擴展，高性能和高可用性（high a

31、vailability）. 包括google analytics, google finance, orkut, personalized search, writely和google earth在內的60多個項目都使用bt.這些應用對bt的要求各不相同，有的需要高吞吐量的批處理，有的需要快速反應給用戶數據它們使用的bt集群也各不相同，有的只有幾臺機器，有的有上千臺，能夠存儲240字節(terabytes)數據 bt在很多地方和數據庫很類似：它使用了很多數據庫的實現策略并行數據庫14和內存數據庫

32、13有可擴展性和高性能，但是bt的界面不同bt不支持完全的關系數據模型；而是為客戶提供了簡單的數據模型，讓客戶來動態控制數據的分布和格式就是只存儲字串，格式由客戶來解釋，并允許客戶推斷底層存儲數據的局部性以提高訪問速度數據下標是行和列的名字，數據本身可以是任何字串bt的數據是字串，沒有解釋類型等客戶會在把各種結構或者半結構化的數據串行化比如說日期串到數據中通過仔細選擇數據表示，客戶可以控制數據的局部化最后，可以使用bt模式來控制數據是放在內存里還是在硬盤上就是說用模式，你可以把數據放在離應用最近的地方畢竟程序在一個時間只用到一塊數據在體系結構里，就是：locality, locali

33、ty, locality 第二節描述數據模型細節第三節關于客戶api概述第四節簡介bt依賴的google框架第五節描述bt的實現關鍵部分第6節敘述提高bt性 能的一些調整第7節提供bt性能的數據在第8節，我們提供bt的幾個使用例子，第9節是經驗教訓在第10節，我們列出相關研究最后是我們的結論 數據模型 bt是一個稀疏的，長期存儲的存在硬盤上，多維度的，排序的映射表這張表的索引是行關鍵字，列關鍵字和時間戳每個值是一個不解釋的字符數組數據都是字符串，沒類型，客戶要解釋就自力更生吧 (row:string, column:stri

34、ng,time:int64)->string 能編程序的都能讀懂，不翻譯了 我們仔細查看過好些類似bigtable的系統之后定下了這個數據模型。舉一個具體例子（它促使我們做出某些設計決定）， 比如我們想要存儲大量網頁及相關信息，以用于很多不同的項目；我們姑且叫它webtable。在webtable里，我們將用url作為行關鍵字，用網頁 的某些屬性作為列名，把網頁內容存在contents:列中并用獲取該網頁的時間戳作為標識，如圖一所示。 圖一：一個存儲web網頁的范例列表片斷。行名是一個反向url即n.www。contents列族原文用&#

35、160;family，譯為族，詳見列族 存放網頁內容，anchor列族存放引用該網頁的錨鏈接文本。cnn的主頁被sports illustrater即所謂si，cnn的王牌體育節目和my-look的主頁引用，因此該行包含了名叫“anchor:”和 “anchhor:my.look.ca”的列。每個錨鏈接只有一個版本由時間戳標識，如t9，t8；而contents列則有三個版本，分別由時間 戳t3，t5，和t6標識。 行 表中的行關鍵字可以是任意字符串（目前支持最多64kb，多數情況下10100字節足夠了）。在一個行關鍵字下的每一個讀寫操

36、作都是原子操作（不管讀寫這一行里多少個不同列），這是一個設計決定，這樣在對同一行進行并發操作時，用戶對于系統行為更容易理解和掌控。 bigtable通過行關鍵字的字典序來維護數據。一張表可以動態劃分成多個連續行。連續行在這里叫做“子表”tablet，是數據分布和負載 均衡的單位。這樣一來，讀較少的連續行就比較有效率，通常只需要較少機器之間的通信即可。用戶可以利用這個屬性來選擇行關鍵字，從而達到較好數據訪問地域 性locality。舉例來說，在webtable里，通過反轉url中主機名的方式，可以把同一個域名下的網頁組織成連續行。具體來說，可以把 列族&#

37、160;一組列關鍵字組成了“列族”，這是訪問控制的基本單位。同一列族下存放的所有數據通常都是同一類型（同一列族下的數據可壓縮在一起）。列族必須先創 建，然后在能在其中的列關鍵字下存放數據；列族創建后，族中任何一個列關鍵字均可使用。我們希望，一張表中的不同列族不能太多（最多幾百個），并且列族在 運作中絕少改變。作為對比，一張表可以有無限列。 列關鍵字用如下語法命名：列族：限定詞。 列族名必須是看得懂printable的字串，而限定詞可以是任意字符串。比如，webtable可以有個列族叫language，存放撰寫網頁的語 言。我們在language

38、列族中只用一個列關鍵字，用來存放每個網頁的語言標識符。該表的另一個有用的列族是anchor；給列族的每一個列關鍵字代表 一個錨鏈接，如圖一所示。而這里的限定詞則是引用該網頁的站點名；表中一個表項存放的是鏈接文本。 訪問控制，磁盤使用統計，內存使用統計，均可在列族這個層面進行。在webtable舉例中，我們可以用這些控制來管理不同應用：有的應用添加新的基本數據，有的讀取基本數據并創建引申的列族，有的則只能瀏覽數據（甚至可能因為隱私權原因不能瀏覽所有數據）。 時間戳 bigtable表中每一個表項都可以包含同一數據的多個版本，由時間戳來索引。bigtable

39、的時間戳是64位整型。可以由bigtable來 賦值，表示準確到毫秒的“實時”；或者由用戶應用程序來賦值。需要避免沖突的應用程序必須自己產生具有唯一性的時間戳。不同版本的表項內容按時間戳倒序排 列，即最新的排在前面。 為了簡化對于不同數據版本的數據的管理，我們對每一個列族支持兩個設定，以便于bigtable對表項的版本自動進行垃圾清除。用戶可以指明只保留表項的最后n個版本，或者只保留足夠新的版本（比如，只保留最近7天的內容）。 在webtable舉例中，我們在contents:列中存放確切爬行一個網頁的時間戳。如上所述的垃圾清除機制可以讓我們只保留每個網

40、頁的最近三個版本。 3.api bt的api提供了建立和刪除表和列族的函數還提供了函數來修改集群，表和列族的元數據，比如說訪問權限 / open the table table *t = openordie(”/bigtable/web/webtable”); / write a new anchor and delete an old anchor rowmutation r

41、1(t, “n.www”); r1.set(”anchor:”, “cnn”); r1.delete(”anchor:”); operation op; apply(&op, &r1); 圖 2: 寫入bigtable. 在bt中，客戶應用可以寫或者刪除值，從每個行中找值，或者遍歷一個表中的數據子集圖2的c+代碼是使用rowmutation抽象表示來進行一系列的更新（為保證代碼精簡，沒有包括無關的細節）調用apply函數，就對ebt

42、able進行了一個原子修改：它為scanner scanner(t); scanstream *stream; stream = scanner.fetchcolumnfamily(”anchor”); stream->setreturnallversions(); scanner.lookup(”n.www”); for (; !stream->done(); stream->next()  printf(”%s %s

43、0;%lld %sn”, scanner.rowname(), stream->columnname(), stream->microtimestamp(), stream->value();  圖3: 從bigtable讀數據. 圖3的c+代碼是使用scanner抽象來遍歷一個行內的所有錨點客戶可以遍歷多個列族有很多方法可以限制一次掃描中產生的行，列和時間戳 例如，我們可以限制上面的掃描，讓它只找到那些匹配正則表達式*的錨點，或者那些時間戳在當前時間前10天的錨點 

44、bt還支持其他一些更復雜的處理數據的功能首先，bt支持單行處理這個功能可以用來對存儲在一個行關鍵字下的數據進行原子的讀-修改-寫操作 bt目前不支持跨行關鍵字的處理，但是它有一個界面，可以用來讓客戶進行批量的跨行關鍵字處理操作其次，bt允許把每個表項用做整數記數器最后，bt 支持在服務器的地址空間內執行客戶端提供的腳本程序腳本程序的語言是google開發的sawzall28數據處理語言目前，我們基于的 sawzall的api還不允許客戶腳本程序向bt內寫數據，但是它允許多種形式的數據變換，基于任何表達式的過濾和通過多種操作符的摘要 bt可以和mapred

45、uce12一起使用mapreduce是google開發的大規模并行計算框架我們為編寫了一套外層程序，使bt可以作為mapreduce處理的數據源頭和輸出結果 4.建立bt的基本單元 bt是建立在其他數個google框架單元上的bt使用google分布式文件系統(gfs)17來存儲日志和數據文件yeah, right, what else can it use, fat32?一個bt集群通常在一個共享的機器池中工作，池中的機器還運行其他的分布式應用雖然機器便宜的跟白菜似的，可是一樣要運行多個程序，命苦的象小

46、白菜，bt和其他程序共享機器bt的瓶頸是/內存，可以和cpu要求高的程序并存bt依賴集群管理系統來安排工作，在共享的機器上管理資源，處理失效機器并監視機器狀態典型的server farm結構，bt是上面的應用之一 bt內部存儲數據的格式是google sstable格式一個sstable提供一個從關鍵字到值的映射，關鍵字和值都可以是任意字符串映射是排序的，存儲的不會因為掉電而丟失，不可改寫的可以進行以下操作：查詢和一個關鍵字相關的值；或者根據給出的關鍵字范圍遍歷所有的關鍵字和值在內部，每個sstable包含一列數據塊（通常每個塊的大小是64kb,但是大小是可以配置

47、的索引大小是16 bits，應該是比較好的一個數）塊索引（存儲在sstable的最后）用來定位數據塊；當打開sstable的時候，索引被讀入內存性能每次查找都可以用一個硬盤搜索完成根據索引算出數據在哪個道上，一個塊應該不會跨兩個道，沒必要省那么點空間：首先在內存中的索引里進行二分查找找到數據塊的位置，然后再從硬盤讀去數據塊最佳情況是：整個sstable可以被放在內存里，這樣一來就不必訪問硬盤了想的美，前面是誰口口聲聲說要跟別人共享機器來著？你把內存占滿了別人上哪睡去？ bt還依賴一個高度可用的，存儲的分布式數據鎖服務chubby8看你怎么把這個high perfo

48、rmance給說圓嘍一個chubby服務由5個活的備份機器構成，其中一個被這些備份選成主備份，并且處理請求這個服務只有在大多數備份都活著并且互相通信的時候才是活的繞口令？去看原文吧，是在有出錯的前提下的冗余算法當有機器失效的時候，chubby使用paxos算法9,23來保證備份的一致性這個問題還是比較復雜的，建議去看引文了解一下問題本身chubby提供了一個名字空間，里面包括了目錄和小文件萬變不離其宗每個目錄或者文件可以當成一個鎖來用，讀寫文件操作都是原子化的chubby客戶端的程序庫提供了對chubby文件的一致性緩存究竟是提高性能還是降低性能？如果訪問是分布的，就是提高性能每個chubby

49、客戶維護一個和chubby服務的會話如果一個客戶不能在一定時間內更新它的會話，這個會話就過期失效了還是針對大server farm里機器失效的頻率設計的當一個會話失效時，其擁有的鎖和打開的文件句柄都失效根本設計原則：失效時回到安全狀態chubby客戶可以在文件和目錄上登記回調函數，以獲得改變或者會話過期的通知翻到這里，有沒有人聞到java的味道了？ bt使用chubby來做以下幾個任務：保證任何時間最多只有一個活躍的主備份；來存儲bt數據的啟動位置（參考5.1節）；發現小表 （tablet）服務器，并完成tablet服務器消亡的善后（5.2節）；存儲bt數據的模式

50、信息（每張表的列信息）；以及存儲訪問權限列表如果有相當長的時間chubby不能訪問，bt就也不能訪問了任何系統都有其弱點最近我們在使用11個chubby服務實例的14個bt集群中度量了這個效果，由于chubby不能訪問而導致bt中部分數據不能訪問的平均百分比是0.0047%,這里chubby不能訪問的原因是chubby本身失效或者網絡問題單個集群里，受影響最大的百分比是0.0326%基于文件系統的chubby還是很穩定的. gfs是一個可擴展的分布式文件系統，用于大型的、分布式的、對大量數據進行訪問的應用。它運行于廉價的普通硬件上，但可以提供容錯功能。它可以給大量的用戶提供總體性能較

51、高的服務。 出處：1、設計概覽 （1）設計想定 gfs與過去的分布式文件系統有很多相同的目標，但gfs的設計受到了當前及預期的應用方面的工作量及技術環境的驅動，這反映了它與早期的文件系統明顯不同的設想。這就需要對傳統的選擇進行重新檢驗并進行完全不同的設計觀點的探索。 gfs與以往的文件系統的不同的觀點如下： 1、部件錯誤不再被當作異常，而是將其作為常見的情況加以處理。因為文件系統由成百上千個用于存儲的機器構成，而這 些機器是由廉價的普通部件組成并被大量的客戶機訪問。部件的數量和質量使得一些機器隨時都有可能無法工作并且有一部分還可能無法

52、恢復。所以實時地監控、錯 誤檢測、容錯、自動恢復對系統來說必不可少。 2、按照傳統的標準，文件都非常大。長度達幾個gb的文件是很平常的。每個文件通常包含很多應用對象。當經常要處理 快速增長的、包含數以萬計的對象、長度達tb的數據集時，我們很難管理成千上萬的kb規模的文件塊，即使底層文件系統提供支持。因此，設計中操作的參數、 塊的大小必須要重新考慮。對大型的文件的管理一定要能做到高效，對小型的文件也必須支持，但不必優化。 3、大部分文件的更新是通過添加 新數據完成的，而不是改變已存在的數據。在一個文件中隨機的操作在實踐中幾乎不存在。一旦

53、寫完，文件就只可讀，很多數據都有這些特性。一些數據可能組成一 個大倉庫以供數據分析程序掃描。有些是運行中的程序連續產生的數據流。有些是檔案性質的數據，有些是在某個機器上產生、在另外一個機器上處理的中間數據。 由于這些對大型文件的訪問方式，添加操作成為性能優化和原子性保證的焦點。而在客戶機中緩存數據塊則失去了吸引力。 4、工作量主要由兩種讀操作構成：對大量數據的流方式的讀操作和對少量數據的隨機方式的讀操作。在前一種讀操作中， 可能要讀幾百kb，通常達 1mb和更多。來自同一個客戶的連續操作通常會讀文件的一個連續的區域。隨機的讀操作通常在一個隨機的

54、偏移處讀幾個kb。性能敏感的應用程序通常將對少量 數據的讀操作進行分類并進行批處理以使得讀操作穩定地向前推進，而不要讓它來來回回的讀。 5、工作量還包含許多對大量數據進行的、連續的、向文件添加數據的寫操作。所寫的數據的規模和讀相似。一旦寫完，文件很少改動。在隨機位置對少量數據的寫操作也支持，但不必非常高效。 6、系統必須高效地實現定義完好的大量客戶同時向同一個文件的添加操作的語義。 （2）系統接口 gfs提供了一個相似地文件系統界面，雖然它沒有向posix那樣實現標準的api。文件在目錄中按層次組織起來并由路徑名標識。 （3）體系結構

55、： 一個gfs集群由一個master和大量的chunkserver構成，并被許多客戶（client）訪問。如圖1 所示。master和 chunkserver通常是運行用戶層服務進程的linux機器。只要資源和可靠性允許，chunkserver和client可以運行在同一個機器 上。 文件被分成固定大小的塊。每個塊由一個不變的、全局唯一的64位的chunkhandle標識，chunk handle是在塊創建時由 master分配的。chunkserver將塊當作linux文件存儲在本地磁盤并可以讀和寫由chunkhandle

56、和位區間指定的數據。出于可靠 性考慮，每一個塊被復制到多個chunkserver上。默認情況下，保存3個副本，但這可以由用戶指定。 master維護文件系統所以的元數據（metadata），包括名字空間、訪問控制信息、從文件到塊的映射以及塊 的當前位置。它也控制系統范圍的活動，如塊租約（lease）管理，孤兒塊的垃圾收集，chunkserver間的塊遷移。master定期通過 heartbeat消息與每一個 chunkserver通信，給chunkserver傳遞指令并收集它的狀態。 與每個應用相聯的gfs客戶代碼實現了文件系統的ap

57、i并與master和chunkserver通信以代表應用程序讀和寫數據。客戶與master的交換只限于對元數據（metadata）的操作，所有數據方面的通信都直接和chunkserver聯系。 客戶和chunkserver都不緩存文件數據。因為用戶緩存的益處微乎其微，這是由于數據太多或工作集太大而無法 緩存。不緩存數據簡化了客戶程序和整個系統，因為不必考慮緩存的一致性問題。但用戶緩存元數據（metadata）。chunkserver也不必緩存文 件，因為塊時作為本地文件存儲的。 （4）單master。 只有一個master也極大的簡化了設計并使

58、得master可以根據全局情況作出先進的塊放置和復制決定。但是我們 必須要將master對讀和寫的參與減至最少，這樣它才不會成為系統的瓶頸。client從來不會從master讀和寫文件數據。client只是詢問 master它應該和哪個 chunkserver聯系。client在一段限定的時間內將這些信息緩存，在后續的操作中client直接和chunkserver交互。 以圖1解釋一下一個簡單的讀操作的交互。 1、client使用固定的塊大小將應用程序指定的文件名和字節偏移轉換成文件的一個塊索引（chunk index）。 

59、2、給master發送一個包含文件名和塊索引的請求。 3、master回應對應的chunk handle和副本的位置（多個副本）。 4、client以文件名和塊索引為鍵緩存這些信息。（handle和副本的位置）。 5、client 向其中一個副本發送一個請求，很可能是最近的一個副本。請求指定了chunk handle（chunkserver以chunk handle標識chunk）和塊內的一個字節區間。 6、除非緩存的信息不再有效（cache for a limited ti

60、me）或文件被重新打開，否則以后對同一個塊的讀操作不再需要client和master間的交互。 通常client可以在一個請求中詢問多個chunk的地址，而master也可以很快回應這些請求。 （5）塊規模： 塊規模是設計中的一個關鍵參數。我們選擇的是64mb，這比一般的文件系統的塊規模要大的多。每個塊的副本作為一個普通的linux文件存儲，在需要的時候可以擴展。 塊規模較大的好處有： 1、減少client和master之間的交互。因為讀寫同一個塊只是要在開始時向master請求塊位置信息。對于讀寫大型文件這種減少尤為重要。即使對于訪問少量數據

61、的隨機讀操作也可以很方便的為一個規模達幾個tb的工作集緩緩存塊位置信息。 2、client在一個給定的塊上很可能執行多個操作，和一個chunkserver保持較長時間的tcp連接可以減少網絡負載。 3、這減少了master上保存的元數據（metadata）的規模，從而使得可以將metadata放在內存中。這又會帶來一些別的好處。 不利的一面： 一個小文件可能只包含一個塊，如果很多client訪問改文件的話，存儲這些塊的chunkserver將成為訪問的熱點。但在實際應用中，應用程序通常順序地讀包含多個塊的文件，所以這不是一個主要問題。 （6）元

62、數據（metadata）： master存儲了三中類型的metadata：文件的名字空間和塊的名字空間，從文件到塊的映射，塊的副本的位 置。所有的metadata都放在內存中。前兩種類型的metadata通過向操作日志登記修改而保持不變，操作日志存儲在master的本地磁盤并在幾 個遠程機器上留有副本。使用日志使得我們可以很簡單地、可靠地更新master的狀態，即使在master崩潰的情況下也不會有不一致的問題。相反， mater在每次啟動以及當有 chuankserver加入的時候詢問每個chunkserver的所擁有的塊的情況。 

63、a、內存數據結構： 因為metadata存儲在內存中，所以master的操作很快。進一步，master可以輕易而且高效地定期在后臺掃描它的整個狀態。這種定期地掃描被用于實現塊垃圾收集、chunkserver出現故障時的副本復制、為平衡負載和磁盤空間而進行的塊遷移。 這種方法的一個潛在的問題就是塊的數量也即整個系統的容量是否受限與master的內存。實際上，這并不是一個嚴重 的問題。master為每個 64mb的塊維護的metadata不足64個字節。除了最后一塊，文件所有的塊都是滿的。類似的，每個文件的名字空間數據也不足64個字節，因為文件名 

64、是以一種事先確定的壓縮方式存儲的.如果要支持更大的文件系統，那么增加一些內存的方法對于我們將元數據（metadata）保存在內存種所獲得的簡單 性、可靠性、高性能和靈活性來說，這只是一個很小的代價。 b、塊位置： master并不為chunkserver所擁有的塊的副本的保存一個不變的記錄。它在啟動時通過簡單的查詢來獲得這些信息。master可以保持這些信息的更新，因為它控制所有塊的放置并通過heartbeat消息來監控chunkserver的狀態。 這樣做的好處：因為chunkserver可能加入或離開集群、改變路徑名、崩潰、重啟等，一個集群重有成百個

65、server，這些事件經常發生，這種方法就排除了master與chunkserver之間的同步問題。 另一個原因是：只有chunkserver才能確定它自己到底有哪些塊，由于錯誤，chunkserver中的一些塊可能會很自然的消失，這樣在master中就沒有必要為此保存一個不變的記錄。 c、操作日志： 操作日志包含了對metadata所作的修改的歷史記錄。它作為邏輯時間線定義了并發操作的執行順序。文件、塊以及它們的版本號都由它們被創建時的邏輯時間而唯一地、永久地被標識。 操作日志是如此的重要，我們必須要將它可靠地保存起來，并且只有在metadata的改變

66、固定下來之后才將變化呈現給用戶。所以我們將操作日志復制到數個遠程的機器上，并且只有在將相應的日志記錄寫到本地和遠程的磁盤上之后才回答用戶的請求。 master可以用操作日志來恢復它的文件系統的狀態。為了將啟動時間減至最小，日志就必須要比較小。每當日志的長度增長到超過一定的規模后，master就要檢查它的狀態，它可以從本地磁盤裝入最近的檢查點來恢復狀態。 創建一個檢查點比較費時，master的內部狀態是以一種在創建一個檢查點時并不耽誤即將到來的修改操作的方式來組 織的。master切換到一個新的日子文件并在一個單獨的線程中創建檢查點。這個新的檢查點記錄了切換前所有的修改。在一個有數十萬文件的集群中用一分鐘 左右就能完成。創建完后，將它寫入本地和遠程的磁盤。 （7）數據完整性 名字空間的修改必須是原子性的，它們只能有master處理：名字空間鎖保證了操作的原子性和正確性，而master的操作日志在全局范圍內定義了這些操作的順序。 文 件區間的狀態在修改之后依賴于修改的類型，不論操作成功