網(wǎng)絡(luò)存儲(chǔ)2-Z-海量存儲(chǔ)示例

示例2023/2/112023/2/122023/2/132023/2/142023/2/152023/2/162023/2/172023/2/182023/2/192023/2/1102023/2/111秘密武器：云計(jì)算平臺(tái)！Google業(yè)務(wù)全球最大搜索引擎、GoogleMaps、GoogleEarth、Gmail、YouTube等數(shù)據(jù)量巨大，且面向全球用戶提供實(shí)時(shí)服務(wù)

Google云計(jì)算平臺(tái)技術(shù)架構(gòu)文件存儲(chǔ)，GoogleDistributedFileSystem，GFS并行數(shù)據(jù)處理MapReduce分布式鎖Chubby分布式結(jié)構(gòu)化數(shù)據(jù)表BigTable分布式存儲(chǔ)系統(tǒng)Megastore分布式監(jiān)控系統(tǒng)Dapper

提綱Google文件系統(tǒng)GFS分布式數(shù)據(jù)處理MapReduce

分布式鎖服務(wù)Chubby

分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable

分布式存儲(chǔ)系統(tǒng)Megastore大規(guī)模分布式系統(tǒng)的監(jiān)控基礎(chǔ)架構(gòu)DapperGoogle應(yīng)用程序引擎Google文件系統(tǒng)GFS系統(tǒng)架構(gòu)容錯(cuò)機(jī)制系統(tǒng)管理技術(shù)GFS設(shè)計(jì)動(dòng)機(jī)Google需要一個(gè)支持海量存儲(chǔ)的文件系統(tǒng)購(gòu)置昂貴的分布式文件系統(tǒng)與硬件？是否可以在一堆廉價(jià)且不可靠的硬件上構(gòu)建可靠的分布式文件系統(tǒng)？GFS設(shè)計(jì)動(dòng)機(jī)為什么不使用當(dāng)時(shí)現(xiàn)存的文件系統(tǒng)？Google所面臨的問(wèn)題與眾不同

不同的工作負(fù)載，不同的設(shè)計(jì)優(yōu)先級(jí)（廉價(jià)、不可靠的硬件）需要設(shè)計(jì)與Google應(yīng)用和負(fù)載相符的文件系統(tǒng)GFS將容錯(cuò)的任務(wù)交給文件系統(tǒng)完成，利用軟件的方法解決系統(tǒng)可靠性問(wèn)題，使存儲(chǔ)的成本成倍下降。GFS將服務(wù)器故障視為正常現(xiàn)象，并采用多種方法，從多個(gè)角度，使用不同的容錯(cuò)措施，確保數(shù)據(jù)存儲(chǔ)的安全、保證提供不間斷的數(shù)據(jù)存儲(chǔ)服務(wù)

GFS架構(gòu)是怎樣的？系統(tǒng)架構(gòu)Client（客戶端）：應(yīng)用程序的訪問(wèn)接口

Master（主服務(wù)器）：管理節(jié)點(diǎn)，在邏輯上只有一個(gè)，保存系統(tǒng)的元數(shù)據(jù)，負(fù)責(zé)整個(gè)文件系統(tǒng)的管理ChunkServer（數(shù)據(jù)塊服務(wù)器）：負(fù)責(zé)具體的存儲(chǔ)工作。數(shù)據(jù)以文件的形式存儲(chǔ)在ChunkServer上實(shí)現(xiàn)機(jī)制客戶端首先訪問(wèn)Master節(jié)點(diǎn)，獲取交互的ChunkServer信息，然后訪問(wèn)這些ChunkServer，完成數(shù)據(jù)存取工作。這種設(shè)計(jì)方法實(shí)現(xiàn)了控制流和數(shù)據(jù)流的分離。Client與Master之間只有控制流，而無(wú)數(shù)據(jù)流，極大地降低了Master的負(fù)載。Client與ChunkServer之間直接傳輸數(shù)據(jù)流，同時(shí)由于文件被分成多個(gè)Chunk進(jìn)行分布式存儲(chǔ)，Client可以同時(shí)訪問(wèn)多個(gè)ChunkServer，從而使得整個(gè)系統(tǒng)的I/O高度并行，系統(tǒng)整體性能得到提高。

GFS特點(diǎn)有哪些？GFS特點(diǎn)采用中心服務(wù)器模式可以方便地增加ChunkServerMaster掌握系統(tǒng)內(nèi)所有ChunkServer的情況，方便進(jìn)行負(fù)載均衡不存在元數(shù)據(jù)的一致性問(wèn)題不緩存數(shù)據(jù)

文件操作大部分是流式讀寫，不存在大量重復(fù)讀寫，使用Cache對(duì)性能提高不大ChunkServer上數(shù)據(jù)存取使用本地文件系統(tǒng)，若讀取頻繁，系統(tǒng)具有Cache從可行性看，Cache與實(shí)際數(shù)據(jù)的一致性維護(hù)也極其復(fù)雜在用戶態(tài)下實(shí)現(xiàn)

利用POSIX編程接口存取數(shù)據(jù)降低了實(shí)現(xiàn)難度，提高通用性

POSIX接口提供功能更豐富

用戶態(tài)下有多種調(diào)試工具

Master和ChunkServer都以進(jìn)程方式運(yùn)行，單個(gè)進(jìn)程不影響整個(gè)操作系統(tǒng)

GFS和操作系統(tǒng)運(yùn)行在不同的空間，兩者耦合性降低只提供專用接口降低實(shí)現(xiàn)的難度對(duì)應(yīng)用提供一些特殊支持降低復(fù)雜度

Google文件系統(tǒng)GFS系統(tǒng)架構(gòu)容錯(cuò)機(jī)制系統(tǒng)管理技術(shù)Master容錯(cuò)

MasterNameSpace，文件系統(tǒng)目錄結(jié)構(gòu)

Chunk與文件名的映射Chunk副本的位置信息(默認(rèn)有三個(gè)副本)

NameSpace，文件系統(tǒng)目錄結(jié)構(gòu)

Chunk與文件名的映射Chunk副本的位置信息Master單個(gè)Master，對(duì)于前兩種元數(shù)據(jù)，GFS通過(guò)操作日志來(lái)提供容錯(cuò)功能

第三種元數(shù)據(jù)信息保存在各個(gè)ChunkServer上，Master故障時(shí)，磁盤恢復(fù)

GFS還提供了Master遠(yuǎn)程的實(shí)時(shí)備份,防止Master徹底死機(jī)的情況ChunkServer容錯(cuò)

采用副本方式實(shí)現(xiàn)ChunkServer容錯(cuò)每一個(gè)Chunk有多個(gè)存儲(chǔ)副本（默認(rèn)為三個(gè)），分布存儲(chǔ)在不同的ChunkServer上用戶態(tài)的GFS不會(huì)影響ChunkServer的穩(wěn)定性副本的分布策略需要考慮多種因素，如網(wǎng)絡(luò)的拓?fù)洹C(jī)架的分布、磁盤的利用率等對(duì)于每一個(gè)Chunk，必須將所有的副本全部寫入成功，才視為成功寫入盡管一份數(shù)據(jù)需要存儲(chǔ)三份，好像磁盤空間的利用率不高，但綜合比較多種因素，加之磁盤的成本不斷下降，采用副本無(wú)疑是最簡(jiǎn)單、最可靠、最有效，而且實(shí)現(xiàn)的難度也最小的一種方法。Simple,andgoodenough!GFS中的每一個(gè)文件被劃分成多個(gè)Chunk，Chunk的默認(rèn)大小是64MBChunkServer存儲(chǔ)的是Chunk的副本，副本以文件的形式進(jìn)行存儲(chǔ)每個(gè)Chunk又劃分為若干Block（64KB），每個(gè)Block對(duì)應(yīng)一個(gè)32bit的校驗(yàn)碼，保證數(shù)據(jù)正確（若某個(gè)Block錯(cuò)誤，則轉(zhuǎn)移至其他Chunk副本）Google文件系統(tǒng)GFS系統(tǒng)架構(gòu)容錯(cuò)機(jī)制系統(tǒng)管理技術(shù)大規(guī)模集群安裝技術(shù)故障檢測(cè)技術(shù)

節(jié)點(diǎn)動(dòng)態(tài)加入技術(shù)

節(jié)能技術(shù)

新的ChunkServer加入時(shí)，只需裸機(jī)加入，大大減少GFS維護(hù)工作量

GFS構(gòu)建在不可靠廉價(jià)計(jì)算機(jī)之上的文件系統(tǒng)，由于節(jié)點(diǎn)數(shù)目眾多，故障發(fā)生十分頻繁

Google采用了多種機(jī)制降低服務(wù)器能耗，如采用蓄電池代替昂貴的UPS系統(tǒng)管理技術(shù)GFS集群中通常有非常多的節(jié)點(diǎn)，需要相應(yīng)的技術(shù)支撐

小結(jié)簡(jiǎn)單的，就是最好的！提綱Google文件系統(tǒng)GFS分布式數(shù)據(jù)處理MapReduce

分布式鎖服務(wù)Chubby

分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable

分布式存儲(chǔ)系統(tǒng)Megastore大規(guī)模分布式系統(tǒng)的監(jiān)控基礎(chǔ)架構(gòu)DapperGoogle應(yīng)用程序引擎MapReduce一種處理海量數(shù)據(jù)的并行編程模式，用于大規(guī)模數(shù)據(jù)集（通常大于1TB）的并行運(yùn)算。

“Map（映射）”、“Reduce（化簡(jiǎn)）”的概念和主要思想，都是從函數(shù)式編程語(yǔ)言和矢量編程語(yǔ)言借鑒適合非結(jié)構(gòu)化和結(jié)構(gòu)化的海量數(shù)據(jù)的搜索、挖掘、分析與機(jī)器智能學(xué)習(xí)等

分布式數(shù)據(jù)處理MapReduce

產(chǎn)生背景

編程模型實(shí)現(xiàn)機(jī)制案例分析Google擁有海量數(shù)據(jù)，并且需要快速處理計(jì)算問(wèn)題簡(jiǎn)單，但求解困難

待處理數(shù)據(jù)量巨大（PB級(jí)），只有分布在成百上千個(gè)節(jié)點(diǎn)上并行計(jì)算才能在可接受的時(shí)間內(nèi)完成如何進(jìn)行并行分布式計(jì)算？如何分發(fā)待處理數(shù)據(jù)？如何處理分布式計(jì)算中的錯(cuò)誤？簡(jiǎn)單的問(wèn)題，計(jì)算并不簡(jiǎn)單！JefferyDean設(shè)計(jì)一個(gè)新的抽象模型，封裝并行處理、容錯(cuò)處理、本地化計(jì)算、負(fù)載均衡的細(xì)節(jié)，還提供了一個(gè)簡(jiǎn)單而強(qiáng)大的接口這就是MapReduceGoogleMapReduce架構(gòu)設(shè)計(jì)師JeffreyDean分布式數(shù)據(jù)處理MapReduce

產(chǎn)生背景

編程模型實(shí)現(xiàn)機(jī)制案例分析MapReduce運(yùn)行模型

Map函數(shù)——對(duì)一部分原始數(shù)據(jù)進(jìn)行指定的操作。每個(gè)Map操作都針對(duì)不同的原始數(shù)據(jù)，因此Map與Map之間是互相獨(dú)立的，這使得它們可以充分并行化Reduce操作——對(duì)每個(gè)Map所產(chǎn)生的一部分中間結(jié)果進(jìn)行合并操作，每個(gè)Reduce所處理的Map中間結(jié)果是互不交叉的，所有Reduce產(chǎn)生的最終結(jié)果經(jīng)過(guò)簡(jiǎn)單連接就形成了完整的結(jié)果集Map:(in_key,in_value){(keyj,valuej)|j=1…k}Reduce:(key,[value1,…,valuem])(key,final_value)

開(kāi)發(fā)者需編寫兩個(gè)主要函數(shù)

Map輸入?yún)?shù)：in_key和in_value，它指明了Map需要處理的原始數(shù)據(jù)Map輸出結(jié)果：一組<key,value>對(duì)，這是經(jīng)過(guò)Map操作后所產(chǎn)生的中間結(jié)果

Map:(in_key,in_value){(keyj,valuej)|j=1…k}Reduce:(key,[value1,…,valuem])(key,final_value)

開(kāi)發(fā)者需編寫兩個(gè)主要函數(shù)

Reduce輸入?yún)?shù)：（key,[value1,…,valuem]）Reduce工作：對(duì)這些對(duì)應(yīng)相同key的value值進(jìn)行歸并處理Reduce輸出結(jié)果：（key,final_value），所有Reduce的結(jié)果并在一起就是最終結(jié)果Map的輸入?yún)?shù)指明了需要處理哪部分?jǐn)?shù)據(jù)，以“<在文本中的起始位置，需要處理的數(shù)據(jù)長(zhǎng)度>”表示，經(jīng)過(guò)Map處理，形成一批中間結(jié)果“<單詞，出現(xiàn)次數(shù)>”。而Reduce函數(shù)處理中間結(jié)果，將相同單詞出現(xiàn)的次數(shù)進(jìn)行累加，得到每個(gè)單詞總的出現(xiàn)次數(shù)

怎么用MapReduce計(jì)算一個(gè)大型文本文件中各單詞出現(xiàn)次數(shù)？分布式數(shù)據(jù)處理MapReduce

產(chǎn)生背景

編程模型實(shí)現(xiàn)機(jī)制案例分析MapReduce操作執(zhí)行流程圖

操作過(guò)程（1）輸入文件分成M塊，每塊大概16M～64MB（可以通過(guò)參數(shù)決定），接著在集群的機(jī)器上執(zhí)行分派處理程序

（2）M個(gè)Map任務(wù)和R個(gè)Reduce任務(wù)需要分派，Master選擇空閑Worker來(lái)分配這些Map或Reduce任務(wù)（3）Worker讀取并處理相關(guān)輸入塊，Map函數(shù)產(chǎn)生的中間結(jié)果<key,value>對(duì)暫時(shí)緩沖到內(nèi)存（4）中間結(jié)果定時(shí)寫到本地硬盤，分區(qū)函數(shù)將其分成R個(gè)區(qū)。中間結(jié)果在本地硬盤的位置信息將被發(fā)送回Master，然后Master負(fù)責(zé)把這些位置信息傳送給ReduceWorker操作過(guò)程（5）當(dāng)Master通知執(zhí)行Reduce的Worker關(guān)于中間<key,value>對(duì)的位置時(shí)，它調(diào)用遠(yuǎn)程過(guò)程，從MapWorker的本地硬盤上讀取緩沖的中間數(shù)據(jù)。當(dāng)ReduceWorker讀到所有的中間數(shù)據(jù)，它就使用中間key進(jìn)行排序，這樣可使相同key的值都在一起（6）ReduceWorker根據(jù)每一個(gè)唯一中間key來(lái)遍歷所有的排序后的中間數(shù)據(jù)，并且把key和相關(guān)的中間結(jié)果值集合傳遞給用戶定義的Reduce函數(shù)。Reduce函數(shù)的結(jié)果寫到一個(gè)最終的輸出文件

（7）當(dāng)所有的Map任務(wù)和Reduce任務(wù)都完成的時(shí)候，Master激活用戶程序。此時(shí)MapReduce返回用戶程序的調(diào)用點(diǎn)MapReduce容錯(cuò)

Master周期性地給Worker發(fā)送ping命令，若沒(méi)有應(yīng)答，則認(rèn)為Worker失效，終止其任務(wù)調(diào)度，把該任務(wù)調(diào)度到其他Worker上重新執(zhí)行Master會(huì)周期性地設(shè)置檢查點(diǎn)（checkpoint），并導(dǎo)出Master的數(shù)據(jù)。一旦某個(gè)任務(wù)失效，系統(tǒng)就從最近的一個(gè)檢查點(diǎn)恢復(fù)并重新執(zhí)行MapReduce容錯(cuò)分布式數(shù)據(jù)處理MapReduce

產(chǎn)生背景

編程模型實(shí)現(xiàn)機(jī)制案例分析假設(shè)有一批海量的數(shù)據(jù)，每個(gè)數(shù)據(jù)都是由26個(gè)字母組成的字符串，原始的數(shù)據(jù)集合是完全無(wú)序的，怎樣通過(guò)MapReduce完成排序工作，使其有序（字典序）呢？排序通常用于衡量分布式數(shù)據(jù)處理框架的數(shù)據(jù)處理能力

對(duì)原始的數(shù)據(jù)進(jìn)行分割（Split），得到N個(gè)不同的數(shù)據(jù)分塊每一個(gè)數(shù)據(jù)分塊都啟動(dòng)一個(gè)Map進(jìn)行處理。采用桶排序的方法，每個(gè)Map中按照首字母將字符串分配到26個(gè)不同的桶中按照首字母將Map中不同桶中的字符串集合放置到相應(yīng)的Reduce中進(jìn)行處理。具體來(lái)說(shuō)就是首字母為a的字符串全部放在Reduce1中處理，首字母為b的字符串全部放在Reduce2，以此類推提綱Google文件系統(tǒng)GFS分布式數(shù)據(jù)處理MapReduce

分布式鎖服務(wù)Chubby

分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable

分布式存儲(chǔ)系統(tǒng)Megastore大規(guī)模分布式系統(tǒng)的監(jiān)控基礎(chǔ)架構(gòu)DapperGoogle應(yīng)用程序引擎分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable設(shè)計(jì)動(dòng)機(jī)與目標(biāo)數(shù)據(jù)模型系統(tǒng)架構(gòu)主服務(wù)器

子表服務(wù)器

性能優(yōu)化設(shè)計(jì)動(dòng)機(jī)與目標(biāo)需要存儲(chǔ)的數(shù)據(jù)種類繁多：Google目前向公眾開(kāi)放的服務(wù)很多，需要處理的數(shù)據(jù)類型也非常多。包括URL、網(wǎng)頁(yè)內(nèi)容、用戶的個(gè)性化設(shè)置在內(nèi)的數(shù)據(jù)都是Google需要經(jīng)常處理的海量的服務(wù)請(qǐng)求：Google運(yùn)行著目前世界上最繁忙的系統(tǒng)，它每時(shí)每刻處理的客戶服務(wù)請(qǐng)求數(shù)量是普通的系統(tǒng)根本無(wú)法承受的商用數(shù)據(jù)庫(kù)無(wú)法滿足Google的需求：一方面現(xiàn)有商用數(shù)據(jù)庫(kù)設(shè)計(jì)著眼點(diǎn)在于通用性，根本無(wú)法滿足Google的苛刻服務(wù)要求；另一方面對(duì)于底層系統(tǒng)的完全掌控會(huì)給后期的系統(tǒng)維護(hù)、升級(jí)帶來(lái)極大的便利設(shè)計(jì)動(dòng)機(jī)設(shè)計(jì)動(dòng)機(jī)與目標(biāo)基本目標(biāo)高可用性

Bigtable設(shè)計(jì)的重要目標(biāo)之一就是確保幾乎所有的情況下系統(tǒng)都可用

廣泛的適用性

Bigtable是為了滿足系列Google產(chǎn)品而非特定產(chǎn)品存儲(chǔ)要求

簡(jiǎn)單性

底層系統(tǒng)簡(jiǎn)單性既可減少系統(tǒng)出錯(cuò)概率，也為上層應(yīng)用開(kāi)發(fā)帶來(lái)便利

很強(qiáng)的可擴(kuò)展性

根據(jù)需要隨時(shí)可以加入或撤銷服務(wù)器

針對(duì)結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)數(shù)據(jù)分類分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable設(shè)計(jì)動(dòng)機(jī)與目標(biāo)數(shù)據(jù)模型系統(tǒng)架構(gòu)主服務(wù)器

子表服務(wù)器

性能優(yōu)化數(shù)據(jù)模型

Bigtable是一個(gè)分布式多維映射表，表中的數(shù)據(jù)通過(guò)一個(gè)行關(guān)鍵字（RowKey）、一個(gè)列關(guān)鍵字（ColumnKey）以及一個(gè)時(shí)間戳（TimeStamp）進(jìn)行索引Bigtable對(duì)存儲(chǔ)在其中的數(shù)據(jù)不做任何解析，一律看做字符串Bigtable數(shù)據(jù)模型Bigtable的存儲(chǔ)邏輯可以表示為：

(row:string,column:string,time:int64)→string數(shù)據(jù)模型行

Bigtable的行關(guān)鍵字可以是任意的字符串，但是大小不能超過(guò)64KB。Bigtable和傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)有很大不同，它不支持一般意義上的事務(wù)，但能保證對(duì)于行的讀寫操作具有原子性（Atomic）

表中數(shù)據(jù)都是根據(jù)行關(guān)鍵字進(jìn)行排序的，排序使用的是詞典序。

一個(gè)典型實(shí)例，其中n.www就是一個(gè)行關(guān)鍵字。不直接存儲(chǔ)網(wǎng)頁(yè)地址而將其倒排是Bigtable的一個(gè)巧妙設(shè)計(jì)。這樣做至少會(huì)帶來(lái)以下兩個(gè)好處同一地址域的網(wǎng)頁(yè)會(huì)被存儲(chǔ)在表中的連續(xù)位置，有利于用戶查找和分析

倒排便于數(shù)據(jù)壓縮，可以大幅提高壓縮率

數(shù)據(jù)模型列

Bigtable并不是簡(jiǎn)單地存儲(chǔ)所有的列關(guān)鍵字，而是將其組織成所謂的列族（ColumnFamily），每個(gè)族中的數(shù)據(jù)都屬于同一個(gè)類型，并且同族的數(shù)據(jù)會(huì)被壓縮在一起保存。引入了列族的概念之后，列關(guān)鍵字就采用下述的語(yǔ)法規(guī)則來(lái)定義：

族名：限定詞（family：qualifier）族名必須有意義，限定詞則可以任意選定圖中，內(nèi)容（Contents）、錨點(diǎn)（Anchor）都是不同的族。而和my.look.ca則是錨點(diǎn)族中不同的限定詞族同時(shí)也是Bigtable中訪問(wèn)控制（AccessControl）基本單元，也就是說(shuō)訪問(wèn)權(quán)限的設(shè)置是在族這一級(jí)別上進(jìn)行的數(shù)據(jù)模型時(shí)間戳

Google的很多服務(wù)比如網(wǎng)頁(yè)檢索和用戶的個(gè)性化設(shè)置等都需要保存不同時(shí)間的數(shù)據(jù)，這些不同的數(shù)據(jù)版本必須通過(guò)時(shí)間戳來(lái)區(qū)分。圖2中內(nèi)容列的t3、t5和t6表明其中保存了在t3、t5和t6這三個(gè)時(shí)間獲取的網(wǎng)頁(yè)。Bigtable中的時(shí)間戳是64位整型數(shù)，具體的賦值方式可以采取系統(tǒng)默認(rèn)的方式，也可以用戶自行定義為了簡(jiǎn)化不同版本的數(shù)據(jù)管理，Bigtable目前提供了兩種設(shè)置：一種是保留最近的N個(gè)不同版本，圖中數(shù)據(jù)模型采取的就是這種方法，它保存最新的三個(gè)版本數(shù)據(jù)。另一種就是保留限定時(shí)間內(nèi)的所有不同版本，比如可以保存最近10天的所有不同版本數(shù)據(jù)。失效的版本將會(huì)由Bigtable的垃圾回收機(jī)制自動(dòng)處理

分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable設(shè)計(jì)動(dòng)機(jī)與目標(biāo)數(shù)據(jù)模型系統(tǒng)架構(gòu)主服務(wù)器

子表服務(wù)器

性能優(yōu)化系統(tǒng)架構(gòu)

一個(gè)分布式的任務(wù)調(diào)度器，主要被用來(lái)處理分布式系統(tǒng)隊(duì)列分組和任務(wù)調(diào)度

系統(tǒng)架構(gòu)

在Bigtable中Chubby主要有以下幾個(gè)作用：（1）選取并保證同一時(shí)間內(nèi)只有一個(gè)主服務(wù)器（MasterServer）（2）獲取子表的位置信息（3）保存Bigtable的模式信息及訪問(wèn)控制列表另外在Bigtable的實(shí)際執(zhí)行過(guò)程中，Google的MapReduce和Sawzall也被用來(lái)改善其性能系統(tǒng)架構(gòu)

Bigtable主要由三個(gè)部分組成：客戶端程序庫(kù)（ClientLibrary）、一個(gè)主服務(wù)器（MasterServer）和多個(gè)子表服務(wù)器（TabletServer）客戶訪問(wèn)Bigtable服務(wù)時(shí)，首先要利用其庫(kù)函數(shù)執(zhí)行Open()操作來(lái)打開(kāi)一個(gè)鎖（實(shí)際上就是獲取了文件目錄），鎖打開(kāi)以后客戶端就可以和子表服務(wù)器進(jìn)行通信和許多具有單個(gè)主節(jié)點(diǎn)分布式系統(tǒng)一樣，客戶端主要與子表服務(wù)器通信，幾乎不和主服務(wù)器進(jìn)行通信，這使得主服務(wù)器的負(fù)載大大降低主服務(wù)主要進(jìn)行一些元數(shù)據(jù)操作以及子表服務(wù)器之間負(fù)載調(diào)度問(wèn)題，實(shí)際數(shù)據(jù)是存儲(chǔ)在子表服務(wù)器上

分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable設(shè)計(jì)動(dòng)機(jī)與目標(biāo)數(shù)據(jù)模型系統(tǒng)架構(gòu)主服務(wù)器

子表服務(wù)器

性能優(yōu)化主服務(wù)器當(dāng)一個(gè)新子表產(chǎn)生時(shí)，主服務(wù)器通過(guò)一個(gè)加載命令將其分配給一個(gè)空間足夠的子表服務(wù)器。創(chuàng)建新表、表合并以及較大子表的分裂都會(huì)產(chǎn)生一個(gè)或多個(gè)新子表。對(duì)于前面兩種，主服務(wù)器會(huì)自動(dòng)檢測(cè)到，而較大子表的分裂是由子服務(wù)發(fā)起并完成的，所以主服務(wù)器并不能自動(dòng)檢測(cè)到，因此在分割完成之后子服務(wù)器需要向主服務(wù)發(fā)出一個(gè)通知由于系統(tǒng)設(shè)計(jì)之初就要求能達(dá)到良好的擴(kuò)展性，所以主服務(wù)器必須對(duì)子表服務(wù)器的狀態(tài)進(jìn)行監(jiān)控，以便及時(shí)檢測(cè)到服務(wù)器的加入或撤銷Bigtable中主服務(wù)器對(duì)子表服務(wù)器的監(jiān)控是通過(guò)Chubby完成的——子表服務(wù)器在初始化時(shí)都會(huì)從Chubby中得到一個(gè)獨(dú)占鎖。通過(guò)這種方式所有子表服務(wù)器基本信息被保存在Chubby中一個(gè)稱為服務(wù)器目錄（ServerDirectory）的特殊目錄之中主服務(wù)器主服務(wù)器會(huì)定期向其詢問(wèn)獨(dú)占鎖的狀態(tài)。如果子表服務(wù)器的鎖丟失或沒(méi)有回應(yīng)，則此時(shí)可能有兩種情況要么是Chubby出現(xiàn)了問(wèn)題（雖然這種概率很小，但的確存在，Google自己也做過(guò)相關(guān)測(cè)試）要么是子表服務(wù)器自身出現(xiàn)了問(wèn)題。對(duì)此主服務(wù)器首先自己嘗試獲取這個(gè)獨(dú)占鎖，如果失敗說(shuō)明Chubby服務(wù)出現(xiàn)問(wèn)題，需等待恢復(fù)；如果成功則說(shuō)明Chubby服務(wù)良好而子表服務(wù)器本身出現(xiàn)了問(wèn)題當(dāng)在狀態(tài)監(jiān)測(cè)時(shí)發(fā)現(xiàn)某個(gè)子表服務(wù)器上負(fù)載過(guò)重時(shí)，主服務(wù)器會(huì)自動(dòng)對(duì)其進(jìn)行負(fù)載均衡操作

主服務(wù)器基于系統(tǒng)出現(xiàn)故障是一種常態(tài)的設(shè)計(jì)理念，每個(gè)主服務(wù)器被設(shè)定了一個(gè)會(huì)話時(shí)間的限制。當(dāng)某個(gè)主服務(wù)器到時(shí)退出后，管理系統(tǒng)就會(huì)指定一個(gè)新的主服務(wù)器，這個(gè)主服務(wù)器的啟動(dòng)需要經(jīng)歷以下四個(gè)步驟：

（1）從Chubby中獲取一個(gè)獨(dú)占鎖，確保同一時(shí)間只有一個(gè)主服務(wù)器（2）掃描服務(wù)器目錄，發(fā)現(xiàn)目前活躍的子表服務(wù)器（3）與所有的活躍子表服務(wù)器取得聯(lián)系以便了解所有子表的分配情況（4）掃描元數(shù)據(jù)表，發(fā)現(xiàn)未分配的子表并將其分配到合適子表服務(wù)器如果元數(shù)據(jù)表未分配，則首先需要將根子表（RootTablet）加入未分配的子表中。由于根子表保存了其他所有元數(shù)據(jù)子表的信息，確保了掃描能夠發(fā)現(xiàn)所有未分配的子表分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable設(shè)計(jì)動(dòng)機(jī)與目標(biāo)數(shù)據(jù)模型系統(tǒng)架構(gòu)主服務(wù)器

子表服務(wù)器

性能優(yōu)化SSTable及子表基本結(jié)構(gòu)

SSTable是Google為Bigtable設(shè)計(jì)的內(nèi)部數(shù)據(jù)存儲(chǔ)格式。所有的SSTable文件都存儲(chǔ)在GFS上

SSTable中數(shù)據(jù)被劃分成一個(gè)個(gè)的塊（Block），每個(gè)塊的大小是可以設(shè)置的，一般為64KB在SSTable的結(jié)尾有一個(gè)索引（Index），這個(gè)索引保存了塊的位置信息，在SSTable打開(kāi)時(shí)這個(gè)索引會(huì)被加載進(jìn)內(nèi)存，用戶在查找某個(gè)塊時(shí)首先在內(nèi)存中查找塊的位置信息，然后在硬盤上直接找到這個(gè)塊由于每個(gè)SSTable一般都不是很大，用戶還可以選擇將其整體加載進(jìn)內(nèi)存，這樣查找起來(lái)會(huì)更快

SSTable結(jié)構(gòu)

子表實(shí)際組成

每個(gè)子表都是由多個(gè)SSTable以及日志（Log）文件構(gòu)成不同子表的SSTable可以共享Bigtable中的日志文件是一種共享日志，每個(gè)子表服務(wù)器上僅保存一個(gè)日志文件，某個(gè)子表日志只是這個(gè)共享日志的一個(gè)片段。這樣會(huì)節(jié)省大量的空間，但在恢復(fù)時(shí)卻有一定的難度Google為了避免這種情況出現(xiàn)，對(duì)日志做了一些改進(jìn)。Bigtable規(guī)定將日志的內(nèi)容按照鍵值進(jìn)行排序，這樣不同的子表服務(wù)器都可以連續(xù)讀取日志文件了一般來(lái)說(shuō)每個(gè)子表的大小在100MB到200MB之間。每個(gè)子表服務(wù)器上保存的子表數(shù)量可以從幾十到上千不等，通常情況下是100個(gè)左右

子表地址結(jié)構(gòu)

子表地址的查詢是經(jīng)常碰到的操作。在Bigtable系統(tǒng)的內(nèi)部采用的是一種類似B+樹(shù)的三層查詢體系

所有子表地址都被記錄在元數(shù)據(jù)表中，元數(shù)據(jù)表也是由一個(gè)個(gè)的元數(shù)據(jù)子表（Metadatatablet）組成根子表是元數(shù)據(jù)表中一個(gè)比較特殊的子表，它既是元數(shù)據(jù)表的第一條記錄，也包含了其他元數(shù)據(jù)子表的地址，同時(shí)Chubby中的一個(gè)文件也存儲(chǔ)了這個(gè)根子表的信息。查詢時(shí)，首先從Chubby中提取這個(gè)根子表的地址，進(jìn)而讀取所需的元數(shù)據(jù)子表的位置，最后就可以從元數(shù)據(jù)子表中找到待查詢的子表。除了這些子表的元數(shù)據(jù)之外，元數(shù)據(jù)表中還保存了其他一些有利于調(diào)試和分析的信息，比如事件日志等為了減少訪問(wèn)開(kāi)銷，提高客戶訪問(wèn)效率，Bigtable使用了緩存（Cache）和預(yù)取（Prefetch）技術(shù)

子表的地址信息被緩存在客戶端，客戶在尋址時(shí)直接根據(jù)緩存信息進(jìn)行查找。一旦出現(xiàn)緩存為空或緩存信息過(guò)時(shí)的情況，客戶端就需要進(jìn)行網(wǎng)絡(luò)的來(lái)回通信（NetworkRound-trips）進(jìn)行尋址，在緩存為空的情況下需要三個(gè)網(wǎng)絡(luò)來(lái)回通信。如果緩存的信息是過(guò)時(shí)的，則需要六個(gè)網(wǎng)絡(luò)來(lái)回通信。其中三個(gè)用來(lái)確定信息是過(guò)時(shí)的，另外三個(gè)獲取新的地址

預(yù)取則是在每次訪問(wèn)元數(shù)據(jù)表時(shí)不僅僅讀取所需的子表元數(shù)據(jù)，而是讀取多個(gè)子表的元數(shù)據(jù)，這樣下次需要時(shí)就不用再次訪問(wèn)元數(shù)據(jù)表

分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable設(shè)計(jì)動(dòng)機(jī)與目標(biāo)數(shù)據(jù)模型系統(tǒng)架構(gòu)主服務(wù)器

子表服務(wù)器

性能優(yōu)化局部性群組（Localitygroups）

局部性群組(LocalityGroup)根據(jù)需要，將原本不存儲(chǔ)在一起的數(shù)據(jù)，以列族為單位存儲(chǔ)至單獨(dú)的子表有的用戶可能只對(duì)網(wǎng)頁(yè)內(nèi)容感興趣，那么它可以通過(guò)設(shè)置局部性群組（見(jiàn)下圖）只看內(nèi)容這一列；有的對(duì)諸如網(wǎng)頁(yè)語(yǔ)言、網(wǎng)站排名等可以用于分析的信息比較感興趣，他也可以將這些列設(shè)置到一個(gè)群組中

壓縮壓縮

壓縮可以有效地節(jié)省空間，Bigtable中的壓縮被應(yīng)用于很多場(chǎng)合

首先壓縮可以被用在構(gòu)成局部性群組的SSTable中，可以選擇是否對(duì)個(gè)人的局部性群組的SSTable進(jìn)行壓縮。這種壓縮是對(duì)每個(gè)局部性群組獨(dú)立進(jìn)行，雖然會(huì)浪費(fèi)一些空間，但是在需要讀時(shí)解壓速度非?？靿嚎s技術(shù)還可以提高子表的恢復(fù)速度，當(dāng)某個(gè)子表服務(wù)器停止使用后，需要將上面所有的子表移至另一個(gè)子表服務(wù)器。轉(zhuǎn)移前兩次壓縮：第一次壓縮減少了提交日志中未壓縮狀態(tài)；文件正式轉(zhuǎn)移前還要進(jìn)行一次壓縮，主要是將第一次壓縮后遺留的未壓縮空間進(jìn)行壓縮提綱Google文件系統(tǒng)GFS分布式數(shù)據(jù)處理MapReduce

分布式鎖服務(wù)Chubby

分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable

分布式存儲(chǔ)系統(tǒng)Megastore大規(guī)模分布式系統(tǒng)的監(jiān)控基礎(chǔ)架構(gòu)DapperGoogle應(yīng)用程序引擎分布式存儲(chǔ)系統(tǒng)Megastore設(shè)計(jì)目標(biāo)及方案選擇Megastore數(shù)據(jù)模型Megastore中的事務(wù)及并發(fā)控制

Megastore基本架構(gòu)產(chǎn)品性能及控制措施在互聯(lián)網(wǎng)的應(yīng)用中，為了達(dá)到好的可擴(kuò)展性，常常會(huì)采用NoSQL存儲(chǔ)方式。但是從應(yīng)用程序的構(gòu)建方面來(lái)看，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)又有著NoSQL所不具備的優(yōu)勢(shì)。

Google設(shè)計(jì)和構(gòu)建了用于互聯(lián)網(wǎng)中交互式服務(wù)的分布式存儲(chǔ)系統(tǒng)Megastore，該系統(tǒng)成功的將關(guān)系型數(shù)據(jù)庫(kù)和NoSQL的特點(diǎn)與優(yōu)勢(shì)進(jìn)行了融合設(shè)計(jì)目標(biāo)及方案選擇

可用性——實(shí)現(xiàn)了一個(gè)同步的、容錯(cuò)的、適合遠(yuǎn)距離傳輸?shù)膹?fù)制機(jī)制。引入Paxos算法并對(duì)其做出一定的改進(jìn)以滿足遠(yuǎn)距離同步復(fù)制的要求

可擴(kuò)展性——借鑒了數(shù)據(jù)庫(kù)中數(shù)據(jù)分區(qū)的思想，將整個(gè)大的數(shù)據(jù)分割成很多小的數(shù)據(jù)分區(qū)，每個(gè)數(shù)據(jù)分區(qū)連同它自身的日志存放在NoSQL數(shù)據(jù)庫(kù)中，具體來(lái)說(shuō)就是存放在Bigtable中設(shè)計(jì)目標(biāo)一種介于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)和NoSQL之間的存儲(chǔ)技術(shù)，盡可能達(dá)到高可用性和高可擴(kuò)展性的統(tǒng)一數(shù)據(jù)分區(qū)和復(fù)制

數(shù)據(jù)分區(qū)和復(fù)制Megastore中，這些小的數(shù)據(jù)分區(qū)被稱為實(shí)體組集（EntityGroups）。每個(gè)實(shí)體組集包含若干實(shí)體組（EntityGroup，相當(dāng)于分區(qū)中表的概念），而一個(gè)實(shí)體組中又包含很多的實(shí)體（Entity，相當(dāng)于表中記錄的概念）。從圖中還可以看出單個(gè)實(shí)體組支持ACID語(yǔ)義實(shí)體組集之間只具有比較松散的一致性。每個(gè)實(shí)體組都通過(guò)復(fù)制技術(shù)在數(shù)據(jù)中心中保存若干數(shù)據(jù)副本，這些實(shí)體組及其副本都存儲(chǔ)在NoSQL數(shù)據(jù)庫(kù)（Bigtable）中

分布式存儲(chǔ)系統(tǒng)Megastore設(shè)計(jì)目標(biāo)及方案選擇Megastore數(shù)據(jù)模型Megastore中的事務(wù)及并發(fā)控制

Megastore基本架構(gòu)產(chǎn)品性能及控制措施Megastore數(shù)據(jù)模型

傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)是通過(guò)連接（Join）來(lái)滿足用戶的需求的，但是就Megastore而言，這種數(shù)據(jù)模型是不合適的，主要有以下三個(gè)原因：（1）對(duì)于高負(fù)載的交互式應(yīng)用來(lái)說(shuō)，可預(yù)期的性能提升要比使用一種代價(jià)高昂的查詢語(yǔ)言所帶來(lái)的好處多（2）Megastore所面對(duì)的應(yīng)用是讀遠(yuǎn)多于寫，因此好的選擇是將讀操作所需要做的工作盡可能地轉(zhuǎn)移到寫操作上（3）在Bigtable這樣的鍵/值存儲(chǔ)系統(tǒng)中存儲(chǔ)和查詢級(jí)聯(lián)數(shù)據(jù)（HierarchicalData）是很方便的

Megastore數(shù)據(jù)模型怎么設(shè)計(jì)？Google設(shè)計(jì)了一種能夠提供細(xì)粒度控制的數(shù)據(jù)模型和模式語(yǔ)言

同關(guān)系型數(shù)據(jù)庫(kù)一樣，Megastore的數(shù)據(jù)模型是在模式（schema）中定義的且是強(qiáng)類型的（stronglytyped）

每個(gè)模式都由一系列的表（tables）構(gòu)成，表又包含有一系列的實(shí)體（entities），每實(shí)體中包含一系列屬性（properties）

屬性是命名的且具有類型，這些類型包括字符型（strings）、數(shù)字類型（numbers）或者Google的ProtocolBuffers。這些屬性可以被設(shè)置成必須的（required）、可選的（optional）或者可重復(fù)的（repeated，即允許單個(gè)屬性上有多個(gè)值）

數(shù)據(jù)模型實(shí)例

照片共享服務(wù)數(shù)據(jù)模型實(shí)例

圖中表Photo就是一個(gè)子表，因?yàn)樗暶髁艘粋€(gè)外鍵；User則是一個(gè)根表。一個(gè)Megastore實(shí)例中可以有若干個(gè)不同的根表，表示不同類型的實(shí)體組集圖中實(shí)例還可以看到三種不同屬性設(shè)置，既有必須的（如user_id），也有可選的（如thumbnail_url）；值得注意的是Photo中的可重復(fù)類型的tag屬性，這也就意味著一個(gè)Photo中允許同時(shí)出現(xiàn)多個(gè)tag屬性索引（Index）

Megastore索引分成兩大類：局部索引（localindex）和全局索引（globalindex）

局部索引定義在單個(gè)實(shí)體組中，作用域僅限于單個(gè)實(shí)體組（如PhotosByTime）

全局索引則可以橫跨多個(gè)實(shí)體組集進(jìn)行數(shù)據(jù)讀取操作（如PhotosByTag）Megastore還提供了一些額外的索引特性：

STORING子句（STORINGClause）

可重復(fù)的索引（RepeatedIndexes）

內(nèi)聯(lián)索引（InlineIndexes）Bigtable中數(shù)據(jù)存儲(chǔ)情況

行鍵（RowKey）UPhoto.timePhoto.tagPhoto._url101John101,50012:30:01Dinner,Paris…101,50212:15:22Betty,Paris…102Mary表中不難看出——Bigtable的列名實(shí)際上是表名和屬性名結(jié)合在一起得到，不同表中實(shí)體可存儲(chǔ)在同一個(gè)Bigtable行中分布式存儲(chǔ)系統(tǒng)Megastore設(shè)計(jì)目標(biāo)及方案選擇Megastore數(shù)據(jù)模型Megastore中的事務(wù)及并發(fā)控制

Megastore基本架構(gòu)產(chǎn)品性能及控制措施Megastore中的事務(wù)及并發(fā)控制Megastore三種方式的讀，分別是current、snapshot和inconsistent

其中current讀和snapshot讀總是在單個(gè)實(shí)體組中完成

對(duì)于snapshot讀，系統(tǒng)取出已知的最后一個(gè)完整提交的事務(wù)的時(shí)間戳，接著從這個(gè)位置讀數(shù)據(jù)inconsistent讀忽略日志的狀態(tài)直接讀取最新的值Megastore中的事務(wù)及并發(fā)控制Megastore事務(wù)中的寫操作采用了預(yù)寫式日志（Write-aheadLog）

一個(gè)寫事務(wù)總是開(kāi)始于一個(gè)current讀以便確認(rèn)下一個(gè)可用的日志位置。提交操作將數(shù)據(jù)變更聚集到日志，接著分配一個(gè)比之前任意一個(gè)都高的時(shí)間戳，然后使用Paxos將數(shù)據(jù)變更加入到日志中

協(xié)議使用了樂(lè)觀并發(fā)（OptimisticConcurrency）：盡管可能有多個(gè)寫操作同時(shí)試圖寫同一個(gè)日志位置，但只會(huì)有1個(gè)成功讀：獲取最后一次提交的事務(wù)的時(shí)間戳和日志位置完整事務(wù)周期應(yīng)用邏輯：從Bigtable讀取且聚集數(shù)據(jù)到日志入口提交：使用Paxos達(dá)到一致，將個(gè)入口追加到日志生效：將數(shù)據(jù)更新到Bigtable中的實(shí)體和索引清除：清理不再需要的數(shù)據(jù)Megastore中的事務(wù)機(jī)制

消息隊(duì)列機(jī)制消息能夠橫跨實(shí)體組

每個(gè)消息都有一個(gè)發(fā)送和接收實(shí)體組如果兩個(gè)實(shí)體組是不同的，則傳輸將是異步特點(diǎn)規(guī)模：聲明一個(gè)隊(duì)列后可以在其他所有的實(shí)體組上創(chuàng)建一個(gè)收件箱支持兩階段提交增加競(jìng)爭(zhēng)風(fēng)險(xiǎn)，不鼓勵(lì)使用

Megastore中的事務(wù)機(jī)制

分布式存儲(chǔ)系統(tǒng)Megastore設(shè)計(jì)目標(biāo)及方案選擇Megastore數(shù)據(jù)模型Megastore中的事務(wù)及并發(fā)控制

Megastore基本架構(gòu)產(chǎn)品性能及控制措施Megastore的基本架構(gòu)Megastore中三種副本

完整副本：Bigtable中存儲(chǔ)完整的日志和數(shù)據(jù)見(jiàn)證者副本：在Paxos算法執(zhí)行過(guò)程中無(wú)法產(chǎn)生一個(gè)決議時(shí)參與投票只讀副本：讀取最近過(guò)去某一個(gè)時(shí)間點(diǎn)一致性數(shù)據(jù)

Megastore的基本架構(gòu)Megastore中提供快速讀（FastReads）和快速寫（FastWrites）機(jī)制

快速讀如果讀操作不需要副本之間進(jìn)行通信即可完成，那么讀取的效率必然相對(duì)較高利用本地讀?。↙ocalReads）實(shí)現(xiàn)快速讀，能夠帶來(lái)更好的用戶體驗(yàn)及更低的延遲確?？焖僮x成功的