《云計(jì)算(第三版)》第2章-Google云計(jì)算原理與應(yīng)用(三)

電子工業(yè)出版社《云計(jì)算(第三版)》配套課件第2章Google云計(jì)算原理與應(yīng)用（三）目錄

2.1Google文件系統(tǒng)GFS2.2分布式數(shù)據(jù)處理MapReduce2.3分布式鎖服務(wù)Chubby2.4分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable2.5分布式存儲(chǔ)系統(tǒng)Megastore2.6

大規(guī)模分布式系統(tǒng)的監(jiān)控基礎(chǔ)架構(gòu)Dapper2.7海量數(shù)據(jù)的交互式分析工具Dremel2.8內(nèi)存大數(shù)據(jù)分析系統(tǒng)PowerDrill2.9Google應(yīng)用程序引擎2.5分布式存儲(chǔ)系統(tǒng)Megastore2.5.1設(shè)計(jì)目標(biāo)及方案選擇2.5.2Megastore數(shù)據(jù)模型2.5.3Megastore中的事務(wù)及并發(fā)控制2.5.4Megastore基本架構(gòu)2.5.5核心技術(shù)——復(fù)制2.5.6產(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)行了融合針對(duì)可用性的要求，實(shí)現(xiàn)了一個(gè)同步的、容錯(cuò)的、適合遠(yuǎn)距離傳輸?shù)膹?fù)制機(jī)制。針對(duì)可擴(kuò)展性的要求，將整個(gè)大的數(shù)據(jù)分割成很多小的數(shù)據(jù)分區(qū)，每個(gè)數(shù)據(jù)分區(qū)連同它自身的日志存放在NoSQL數(shù)據(jù)庫(kù)中，具體來(lái)說就是存放在Bigtable中。設(shè)計(jì)目標(biāo)及方案選擇2.5分布式存儲(chǔ)系統(tǒng)Megastore設(shè)計(jì)一種介于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)和NoSQL之間的存儲(chǔ)技術(shù)，盡可能達(dá)到高可用性和高可擴(kuò)展性的統(tǒng)一。方法一設(shè)計(jì)目標(biāo)方法二5數(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í)體組都通過復(fù)制技術(shù)在數(shù)據(jù)中心中保存若干數(shù)據(jù)副本，這些實(shí)體組及其副本都存儲(chǔ)在NoSQL數(shù)據(jù)庫(kù)（Bigtable）中

2.5分布式存儲(chǔ)系統(tǒng)Megastore2.5.1設(shè)計(jì)目標(biāo)及方案選擇2.5.2Megastore數(shù)據(jù)模型2.5.3Megastore中的事務(wù)及并發(fā)控制2.5.4Megastore基本架構(gòu)2.5.5核心技術(shù)——復(fù)制2.5.6產(chǎn)品性能及控制措施82.5分布式存儲(chǔ)系統(tǒng)Megastore傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)不合適的三個(gè)原因傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)是通過連接（Join）來(lái)滿足用戶的需求的，但是就Megastore而言，這種數(shù)據(jù)模型是不合適的，主要有以下三個(gè)原因：原因1對(duì)于高負(fù)載的交互式應(yīng)用來(lái)說，可預(yù)期的性能提升要比使用一種代價(jià)高昂的查詢語(yǔ)言所帶來(lái)的好處多原因2Megastore所面對(duì)的應(yīng)用是讀遠(yuǎn)多于寫，因此好的選擇是將讀操作所需要做的工作盡可能地轉(zhuǎn)移到寫操作上原因3在Bigtable這樣的鍵/值存儲(chǔ)系統(tǒng)中存儲(chǔ)和查詢級(jí)聯(lián)數(shù)據(jù)（HierarchicalData）是很方便的Megastore數(shù)據(jù)模型怎么設(shè)計(jì)？102.5分布式存儲(chǔ)系統(tǒng)Megastore細(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。Google團(tuán)隊(duì)設(shè)計(jì)的Megastore數(shù)據(jù)模型112.5分布式存儲(chǔ)系統(tǒng)Megastore照片共享服務(wù)數(shù)據(jù)模型實(shí)例表Photo就是一個(gè)子表，因?yàn)樗暶髁艘粋€(gè)外鍵User則是一個(gè)根表一個(gè)Megastore實(shí)例中可以有若干個(gè)不同的根表，表示不同類型的實(shí)體組集三種不同屬性設(shè)置，既有必須的（如user_id），也有可選的（如thumbnail_url）Photo中的可重復(fù)類型的tag屬性122.5分布式存儲(chǔ)系統(tǒng)MegastoreMegastore索引局部索引定義在單個(gè)實(shí)體組中，作用域僅限于單個(gè)實(shí)體組（如PhotosByTime）可以橫跨多個(gè)實(shí)體組集進(jìn)行數(shù)據(jù)讀取操作（如PhotosByTag）全局索引主要兩類額外索引STORING子句（STORINGClause）可重復(fù)的索引（RepeatedIndexes）內(nèi)聯(lián)索引（InlineIndexes）132.5分布式存儲(chǔ)系統(tǒng)MegastoreBigtable中存儲(chǔ)情況行鍵（RowKey）UPhoto.timePhoto.tagPhoto._url101John101,50012:30:01Dinner,Paris…101,50212:15:22Betty,Paris…102MaryBigtable的列名實(shí)際上是表名和屬性名結(jié)合在一起得到，不同表中實(shí)體可存儲(chǔ)在同一個(gè)Bigtable行中2.5分布式存儲(chǔ)系統(tǒng)Megastore2.5.1設(shè)計(jì)目標(biāo)及方案選擇2.5.2Megastore數(shù)據(jù)模型2.5.3Megastore中的事務(wù)及并發(fā)控制2.5.4Megastore基本架構(gòu)2.5.5核心技術(shù)——復(fù)制2.5.6產(chǎn)品性能及控制措施15Megastore提供的三種讀currentsnapshotinconsistent總是在單個(gè)實(shí)體組中完成總是在單個(gè)實(shí)體組中完成系統(tǒng)取出已知的最后一個(gè)完整提交的事務(wù)的時(shí)間戳，接著從這個(gè)位置讀數(shù)據(jù)忽略日志的狀態(tài)直接讀取最新的值2.5分布式存儲(chǔ)系統(tǒng)MegastoreMegastore中的事務(wù)及并發(fā)控制Megastore事務(wù)中的寫操作采用了預(yù)寫式日志（Write-aheadLog）

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

協(xié)議使用了樂觀并發(fā)（OptimisticConcurrency）：盡管可能有多個(gè)寫操作同時(shí)試圖寫同一個(gè)日志位置，但只會(huì)有1個(gè)成功17完整的事務(wù)周期讀應(yīng)用邏輯提交生效清除獲取最后一次提交的事務(wù)的時(shí)間戳和日志位置從Bigtable讀取且聚集數(shù)據(jù)到日志入口使用Paxos達(dá)到一致，將入口追加到日志將數(shù)據(jù)更新到Bigtable中的實(shí)體和索引清理不再需要的數(shù)據(jù)2.5分布式存儲(chǔ)系統(tǒng)Megastore182.5分布式存儲(chǔ)系統(tǒng)MegastoreMegastore中的事務(wù)機(jī)制2.5分布式存儲(chǔ)系統(tǒng)Megastore2.5.1設(shè)計(jì)目標(biāo)及方案選擇2.5.2Megastore數(shù)據(jù)模型2.5.3Megastore中的事務(wù)及并發(fā)控制2.5.4Megastore基本架構(gòu)2.5.5核心技術(shù)——復(fù)制2.5.6產(chǎn)品性能及控制措施Megastore的基本架構(gòu)Megastore中三種副本

完整副本：Bigtable中存儲(chǔ)完整的日志和數(shù)據(jù)見證者副本：在Paxos算法執(zhí)行過程中無(wú)法產(chǎn)生一個(gè)決議時(shí)參與投票只讀副本：讀取最近過去某一個(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成功的關(guān)鍵是保證選擇的副本上數(shù)據(jù)是最新的。為了達(dá)到這一目標(biāo)，引入了協(xié)調(diào)者的概念

協(xié)調(diào)者是一個(gè)服務(wù)，該服務(wù)分布在每個(gè)副本的數(shù)據(jù)中心里面。它的主要作用就是跟蹤一個(gè)實(shí)體組集合協(xié)調(diào)者的狀態(tài)是由寫算法來(lái)保證快速寫

Megastore采用了一種在主/從式系統(tǒng)中常用的優(yōu)化方法。如果一次寫成功，那么下一次寫的時(shí)候就跳過準(zhǔn)備過程，直接進(jìn)入接受階段

Megastore沒有使用專門的主服務(wù)器，而是使用leadersleader主要是來(lái)裁決哪個(gè)寫入的值可以獲取0號(hào)提議優(yōu)化：提交值最多的位置附近選擇一副本作為leader

客戶端、網(wǎng)絡(luò)及Bigtable的故障都會(huì)導(dǎo)致一個(gè)寫操作處于不確定的狀態(tài)2.5分布式存儲(chǔ)系統(tǒng)Megastore2.5.1設(shè)計(jì)目標(biāo)及方案選擇2.5.2Megastore數(shù)據(jù)模型2.5.3Megastore中的事務(wù)及并發(fā)控制2.5.4Megastore基本架構(gòu)2.5.5核心技術(shù)——復(fù)制2.5.6產(chǎn)品性能及控制措施242.5分布式存儲(chǔ)系統(tǒng)Megastore復(fù)制的日志每個(gè)副本都存有記錄所有更新的數(shù)據(jù)。Megastore允許副本不按順序接受日志，這些日志將獨(dú)立的存儲(chǔ)在Bigtable中。預(yù)寫式日志復(fù)制的日志

預(yù)寫式日志當(dāng)日志有不完整的前綴時(shí)我們就稱一個(gè)日志副本有“缺失”（Holes）

圖中0～99的日志位置已經(jīng)被全部清除；100的日志位置被部分清除；101的日志位置被全部副本接受；102的日志位置被γ獲得；103的日志位置被副本A和C接受，副本B則留下了一個(gè)“缺失”；104的日志位置則未達(dá)到一致性數(shù)據(jù)讀取

數(shù)據(jù)讀取數(shù)據(jù)讀取過程:本地查詢（QueryLocal）發(fā)現(xiàn)位置（FindPosition）

本地讀?。↙ocalRead）

多數(shù)派讀取（MajorityRead）追趕（Catchup）

Paxos將會(huì)促使絕大多數(shù)副本達(dá)成一個(gè)共識(shí)值達(dá)到一種分布式一致狀態(tài)驗(yàn)證（Validate）查詢數(shù)據(jù)（QueryData）數(shù)據(jù)寫入

數(shù)據(jù)寫入數(shù)據(jù)寫入完整過程:（1）接受leader：請(qǐng)求leader接受值作為0號(hào)提議（快速寫方法），若成功，跳至步驟（3）（2）準(zhǔn)備：將值替換成擁有最高提議號(hào)的那個(gè)值（3）接受：請(qǐng)求剩余的副本接受該值，如果大多數(shù)副本拒絕這個(gè)值，返回步驟（2）（4）失效：將不接受值的副本上的協(xié)調(diào)者進(jìn)行失效操作（5）生效：將值的更新在盡可能多的副本上生效。如果選擇的值和原來(lái)提議的有沖突，返回一個(gè)沖突錯(cuò)誤

282.5分布式存儲(chǔ)系統(tǒng)Megastore協(xié)調(diào)者的可用性協(xié)調(diào)者在系統(tǒng)中是比較重要的——協(xié)調(diào)者的進(jìn)程運(yùn)行在每個(gè)數(shù)據(jù)中心。每次的寫操作中都要涉及協(xié)調(diào)者，因此協(xié)調(diào)者的故障將會(huì)導(dǎo)致系統(tǒng)的不可用Megastore使用了Chubby鎖服務(wù)，為了處理請(qǐng)求，一個(gè)協(xié)調(diào)者必須持有多數(shù)鎖。一旦因?yàn)槌霈F(xiàn)問題導(dǎo)致它丟失了大部分鎖，協(xié)調(diào)者就會(huì)恢復(fù)到一個(gè)默認(rèn)保守狀態(tài)除了可用性問題，對(duì)于協(xié)調(diào)者的讀寫協(xié)議必須滿足一系列的競(jìng)爭(zhēng)條件2.5分布式存儲(chǔ)系統(tǒng)Megastore2.5.1設(shè)計(jì)目標(biāo)及方案選擇2.5.2Megastore數(shù)據(jù)模型2.5.3Megastore中的事務(wù)及并發(fā)控制2.5.4Megastore基本架構(gòu)2.5.5核心技術(shù)——復(fù)制2.5.6產(chǎn)品性能及控制措施302.5分布式存儲(chǔ)系統(tǒng)Megastore可用性的分布情況Megastore在Google中已經(jīng)部署和使用了若干年，有超過100個(gè)產(chǎn)品使用Megastore作為其存儲(chǔ)系統(tǒng)從圖中可以看出，絕大多數(shù)產(chǎn)品具有極高的可用性（>99.999%）。這表明Megastore系統(tǒng)的設(shè)計(jì)是非常成功的，基本達(dá)到了預(yù)期目標(biāo)31產(chǎn)品延遲情況的分布2.5分布式存儲(chǔ)系統(tǒng)Megastore應(yīng)用程序的平均讀取延遲在萬(wàn)分之一毫秒之內(nèi)，平均寫入延遲在100至400毫秒之間避免Megastore的性能下降，可采取以下三種應(yīng)對(duì)方法：（1）重新選擇路由使客戶端繞開出現(xiàn)問題的副本（2）將出現(xiàn)問題副本上的協(xié)調(diào)者禁用，確保問題的影響降至最小。（3）禁用整個(gè)副本需要指出：Megastore已經(jīng)是Google相對(duì)過時(shí)的存儲(chǔ)技術(shù)。Google目前正在使用的存儲(chǔ)系統(tǒng)是Spanner架構(gòu)，Spanner的設(shè)計(jì)目標(biāo)是能夠控制一百萬(wàn)到一千萬(wàn)臺(tái)服務(wù)器，Spanner最強(qiáng)大之處在于能夠在50毫秒之內(nèi)為數(shù)據(jù)傳遞提供通道目錄

2.1Google文件系統(tǒng)GFS2.2分布式數(shù)據(jù)處理MapReduce2.3分布式鎖服務(wù)Chubby2.4分布式結(jié)構(gòu)化數(shù)據(jù)表Bigtable2.5分布式存儲(chǔ)系統(tǒng)Megastore2.6大規(guī)模分布式系統(tǒng)的監(jiān)控基礎(chǔ)架構(gòu)Dapper2.7海量數(shù)據(jù)的交互式分析工具Dremel2.8內(nèi)存大數(shù)據(jù)分析系統(tǒng)PowerDrill2.9Google應(yīng)用程序引擎2.6大規(guī)模分布式系統(tǒng)的監(jiān)控

基礎(chǔ)架構(gòu)Dapper2.6.1基本設(shè)計(jì)目標(biāo)2.6.2Dapper監(jiān)控系統(tǒng)簡(jiǎn)介2.6.3關(guān)鍵性技術(shù)2.6.4常用Dapper工具2.6.5Dapper使用經(jīng)驗(yàn)在我們看來(lái)很簡(jiǎn)單的一次搜索實(shí)際上涉及了眾多Google后臺(tái)子系統(tǒng)，這些子系統(tǒng)的運(yùn)行狀態(tài)都需要進(jìn)行監(jiān)控用戶的平均每一次前臺(tái)搜索會(huì)導(dǎo)致Google的后臺(tái)發(fā)生1011次的處理352.6大規(guī)模分布式系統(tǒng)的監(jiān)控基礎(chǔ)架構(gòu)Dapper兩個(gè)基本要求設(shè)計(jì)出的監(jiān)控系統(tǒng)應(yīng)當(dāng)能夠?qū)ΡM可能多的Google服務(wù)進(jìn)行監(jiān)控Google的服務(wù)是全天候的，如果不能對(duì)Google的后臺(tái)同樣進(jìn)行全天候的監(jiān)控很可能會(huì)錯(cuò)過某些無(wú)法再現(xiàn)的關(guān)鍵性故障監(jiān)控系統(tǒng)設(shè)計(jì)兩個(gè)基本要求1.廣泛可部署性（UbiquitousDeployment）2.不間斷的監(jiān)控362.6大規(guī)模分布式系統(tǒng)的監(jiān)控基礎(chǔ)架構(gòu)Dapper三個(gè)基本設(shè)計(jì)目標(biāo)低開銷這個(gè)是廣泛可部署性的必然要求。監(jiān)控系統(tǒng)的開銷越低，對(duì)于原系統(tǒng)的影響就越小，系統(tǒng)的開發(fā)人員也就越愿意接受這個(gè)監(jiān)控系統(tǒng)。對(duì)應(yīng)用層透明監(jiān)控系統(tǒng)對(duì)程序員應(yīng)當(dāng)是不可見的。如果監(jiān)控系統(tǒng)的使用需要程序開發(fā)人員對(duì)其底層的一些細(xì)節(jié)進(jìn)行調(diào)整才能正常工作的話，這個(gè)監(jiān)控系統(tǒng)肯定不是一個(gè)完善的監(jiān)控系統(tǒng)?？蓴U(kuò)展性Google的服務(wù)增長(zhǎng)速度是驚人的，設(shè)計(jì)出的系統(tǒng)至少在未來(lái)幾年里要能夠滿足Google服務(wù)和集群的需求。2.6大規(guī)模分布式系統(tǒng)的監(jiān)控

基礎(chǔ)架構(gòu)Dapper2.6.1基本設(shè)計(jì)目標(biāo)2.6.2Dapper監(jiān)控系統(tǒng)簡(jiǎn)介2.6.3關(guān)鍵性技術(shù)2.6.4常用Dapper工具2.6.5Dapper使用經(jīng)驗(yàn)基本概念

圖中，用戶發(fā)出請(qǐng)求X，前端A發(fā)現(xiàn)該請(qǐng)求的處理需要涉及服務(wù)器B和服務(wù)器C，因此A又向B和C發(fā)出兩個(gè)RPC（遠(yuǎn)程過程調(diào)用）。B收到后立刻做出響應(yīng)，但是C在接到后發(fā)現(xiàn)它還需要調(diào)用服務(wù)器D和E才能完成請(qǐng)求X，因此C對(duì)D和E分別發(fā)出了RPC，D和E接到后分別做出了應(yīng)答，收到D和E的應(yīng)答之后C才向A做出響應(yīng)，在接收到B和C的應(yīng)答之后A才對(duì)用戶請(qǐng)求X做出一個(gè)應(yīng)答X

在監(jiān)控系統(tǒng)中記錄下所有這些消息不難，如何將這些消息記錄同特定的請(qǐng)求（本例中的X）關(guān)聯(lián)起來(lái)才是分布式監(jiān)控系統(tǒng)設(shè)計(jì)中需要解決的關(guān)鍵性問題之一典型分布式系統(tǒng)的請(qǐng)求及應(yīng)答過程

方案一黑盒（BlackBox）方案——方案比較輕便，但在消息關(guān)系判斷過程中，主要是利用一些統(tǒng)計(jì)學(xué)知識(shí)來(lái)進(jìn)行推斷，有時(shí)不是很準(zhǔn)確方案二基于注釋的方案

——利用應(yīng)用程序或中間件給每條記錄賦予一個(gè)全局性的標(biāo)示符，借此將相關(guān)消息串聯(lián)起來(lái)（Google最終選擇）基本概念

Dapper監(jiān)控系統(tǒng)中三個(gè)基本概念：監(jiān)控樹（TraceTree）、區(qū)間（Span）和注釋（Annotation）圖示是一個(gè)典型的監(jiān)控樹，實(shí)際上就是一個(gè)同特定事件相關(guān)的按照一定的規(guī)律以樹的形式組織起來(lái)所有消息，每一個(gè)節(jié)點(diǎn)稱為一個(gè)區(qū)間（一條記錄），所有記錄聯(lián)系在一起就構(gòu)成了對(duì)某個(gè)事件的完整監(jiān)控。每個(gè)區(qū)間包括如下的內(nèi)容：區(qū)間名（SpanName）、區(qū)間id（Spanid）、父id（Parentid）和監(jiān)控id（Traceid）

監(jiān)控樹監(jiān)控id圖中并沒有列出，一棵監(jiān)控樹中所有區(qū)間的監(jiān)控id相同，隨機(jī)分配且唯一區(qū)間Helper.Call的詳細(xì)信息圖中區(qū)間包含來(lái)自客戶端的注釋信息：“<Start>”、“ClientSend”、“ClientRecv”和“<End>”，也包含來(lái)自服務(wù)器端的注釋信息：“ServerRecv”、“foo”和“ServerSend”。除“foo”是用戶自定義的注釋外，其他的注釋信息都是和時(shí)間相關(guān)的信息。Dapper不但支持用戶進(jìn)行簡(jiǎn)單的文本方式的注釋，還支持鍵-值對(duì)方式的注釋基本概念

412.6大規(guī)模分布式系統(tǒng)的監(jiān)控基礎(chǔ)架構(gòu)Dapper監(jiān)控信息的匯總（1）將區(qū)間的數(shù)據(jù)寫入到本地的日志文件（2）所有機(jī)器上的本地日志文件匯集（3）匯集后的數(shù)據(jù)寫入到Bigtable存儲(chǔ)庫(kù)中監(jiān)控?cái)?shù)據(jù)匯總是單獨(dú)進(jìn)行的，而不是伴隨系統(tǒng)對(duì)用戶的應(yīng)答一起返回的，如此選擇主要原因：內(nèi)置的匯總方案（監(jiān)控?cái)?shù)據(jù)隨RPC應(yīng)答頭返回）會(huì)影響網(wǎng)絡(luò)動(dòng)態(tài)內(nèi)置的匯總方案需要保證所有的RPC都是完全嵌套安全問題

應(yīng)用層注釋提供一種方便的選擇機(jī)制（Opt-inMechanism）：應(yīng)用程序開發(fā)者可以將任何對(duì)后期分析有益的數(shù)據(jù)和區(qū)間關(guān)聯(lián)起來(lái)

2.6大規(guī)模分布式系統(tǒng)的監(jiān)控

基礎(chǔ)架構(gòu)Dapper2.6.1基本設(shè)計(jì)目標(biāo)2.6.2Dapper監(jiān)控系統(tǒng)簡(jiǎn)介2.6.3關(guān)鍵性技術(shù)2.6.4常用Dapper工具2.6.5Dapper使用經(jīng)驗(yàn)Dapper三個(gè)設(shè)計(jì)目標(biāo)中，實(shí)現(xiàn)難度最大的是？應(yīng)用層透明怎么實(shí)現(xiàn)應(yīng)用層透明輕量級(jí)的核心功能庫(kù)

二次抽樣技術(shù)

452.6大規(guī)模分布式系統(tǒng)的監(jiān)控基礎(chǔ)架構(gòu)Dapper輕量級(jí)核心功能庫(kù)最關(guān)鍵的代碼基礎(chǔ)是基本RPC、線程和控制流函數(shù)庫(kù)的實(shí)現(xiàn)主要功能是實(shí)現(xiàn)區(qū)間創(chuàng)建、抽樣和在本地磁盤上記錄日志。將復(fù)雜的功能實(shí)現(xiàn)限制在一個(gè)輕量級(jí)的核心功能庫(kù)中保證了Dapper的監(jiān)控過程基本對(duì)應(yīng)用層透明。小規(guī)模庫(kù)通用線程（UbiquitousThreading）控制流（ControlFlow）RPC代碼庫(kù)（RPCLibraryCode）462.6大規(guī)模分布式系統(tǒng)的監(jiān)控基礎(chǔ)架構(gòu)Dapper二次抽樣技術(shù)利用二次抽樣技術(shù)成功地解決了低開銷及廣泛可部署性的問題。第一次抽樣第二次抽樣實(shí)踐中，設(shè)計(jì)人員發(fā)現(xiàn)當(dāng)抽樣率低至1/1024時(shí)也能夠產(chǎn)生足夠多的有效監(jiān)控?cái)?shù)據(jù)，即在1024個(gè)請(qǐng)求中抽取1個(gè)進(jìn)行監(jiān)控也是可行的，從而可以捕獲有效數(shù)據(jù)發(fā)生在數(shù)據(jù)寫入Bigtable前，具體方法是將監(jiān)控id散列成一個(gè)標(biāo)量z（0≤z≤1），如果某個(gè)區(qū)間的z小于事先定義好的匯總抽樣系數(shù)，則保留這個(gè)區(qū)間并將它寫入Bigtable，否則丟棄2.6大規(guī)模分布式系統(tǒng)的監(jiān)控

基礎(chǔ)架構(gòu)Dapper2.6.1基本設(shè)計(jì)目標(biāo)2.6.2Dapper監(jiān)控系統(tǒng)簡(jiǎn)介2.6.3關(guān)鍵性技術(shù)2.6.4常用Dapper工具2.6.5Dapper使用經(jīng)驗(yàn)482.6大規(guī)模分布式系統(tǒng)的監(jiān)控基礎(chǔ)架構(gòu)DapperDapper存儲(chǔ)APIDapper的“存儲(chǔ)API”簡(jiǎn)稱為DAPI，提供了對(duì)分散在區(qū)域Dapper存儲(chǔ)庫(kù)（DEPOTS）的監(jiān)控記錄的直接訪問。一般有以下三種方式訪問這些記錄。（1）通過監(jiān)控id訪問（AccessbyTraceid）（2）塊訪問（B