第九講GoogleMegastoreDapper

1、第九講第九講-Google Megastore、Dapper Google Megastore Google DapperGoogle Megastore 設(shè)計目標(biāo)及方案選擇 Megastore數(shù)據(jù)模型 Megastore中的事務(wù)及并發(fā)控制 Megastore基本架構(gòu) 核心技術(shù)復(fù)制 產(chǎn)品性能及控制措施 在互聯(lián)網(wǎng)的應(yīng)用中，為了達(dá)到好的可擴(kuò)展性可擴(kuò)展性，常常會采用NoSQL存儲方式。但是從應(yīng)用程序的構(gòu)建方面來看，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫又有著NoSQL所不具備的優(yōu)勢。 Google設(shè)計和構(gòu)建了用于互聯(lián)網(wǎng)中交互式服務(wù)的分布式存儲系統(tǒng)MegastoreMegastore，該系統(tǒng)成功的將關(guān)系型數(shù)據(jù)庫和NoSQ

2、L的特點與優(yōu)勢進(jìn)行了融合 設(shè)計目標(biāo)及方案選擇 可用性可用性實現(xiàn)了一個實現(xiàn)了一個同步的、同步的、容錯的、適合遠(yuǎn)距離傳輸?shù)膹?fù)制容錯的、適合遠(yuǎn)距離傳輸?shù)膹?fù)制機(jī)制機(jī)制。引入。引入Paxos算法并對其做算法并對其做出一定的改進(jìn)以滿足遠(yuǎn)距離同步出一定的改進(jìn)以滿足遠(yuǎn)距離同步復(fù)制的要求復(fù)制的要求 可擴(kuò)展性可擴(kuò)展性 借鑒了數(shù)據(jù)庫中數(shù)借鑒了數(shù)據(jù)庫中數(shù)據(jù)據(jù)分區(qū)分區(qū)的思想，將整個大的數(shù)據(jù)的思想，將整個大的數(shù)據(jù)分割成很多小的數(shù)據(jù)分區(qū)，分割成很多小的數(shù)據(jù)分區(qū)，每個每個數(shù)據(jù)分區(qū)連同它自身的日志存放數(shù)據(jù)分區(qū)連同它自身的日志存放在在NoSQLNoSQL數(shù)據(jù)庫中數(shù)據(jù)庫中，具體來說就是，具體來說就是存放在存放在BigtableBi

3、gtable中中 設(shè)計目標(biāo)設(shè)計目標(biāo)一種介于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫和NoSQL之間的存儲技術(shù)，盡可能達(dá)到高可用性高可用性和高可擴(kuò)展性高可擴(kuò)展性的統(tǒng)一 數(shù)據(jù)分區(qū)和復(fù)制 數(shù)據(jù)分區(qū)和復(fù)制數(shù)據(jù)分區(qū)和復(fù)制 Megastore中，這些小的數(shù)據(jù)分區(qū)被稱為實體組集（Entity Groups）。每個實體組集包含若干實體組（Entity Group，相當(dāng)于分區(qū)中表的概念），而一個實體組中又包含很多的實體（Entity，相當(dāng)于表中記錄的概念）。從圖中還可以看出單個實體組支持ACID語義實體組集之間只具有比較松散的一致性。每個實體組都通過復(fù)制技術(shù)在數(shù)據(jù)中心中保存若干數(shù)據(jù)副本，這些實體組及其副本都存儲在NoSQL數(shù)據(jù)庫（B

4、igtable）中 Google Megastore設(shè)計目標(biāo)及方案選擇 Megastore數(shù)據(jù)模型 Megastore中的事務(wù)及并發(fā)控制 Megastore基本架構(gòu) 核心技術(shù)復(fù)制 產(chǎn)品性能及控制措施 MegastoreMegastore數(shù)據(jù)模型數(shù)據(jù)模型 傳統(tǒng)的關(guān)系型數(shù)據(jù)庫是通過連接（Join）來滿足用戶的需求的，但是就Megastore而言，這種數(shù)據(jù)模型是不合適的，主要有以下三個原因：（1）對于高負(fù)載的交互式應(yīng)用來說，可預(yù)期的性能提升要比使用一種代價高昂的查詢語言所帶來的好處多（2）Megastore所面對的應(yīng)用是讀遠(yuǎn)多于寫，因此好的選擇是將讀操作所需要做的工作盡可能地轉(zhuǎn)移到寫操作上（3）在B

5、igtable這樣的鍵/值存儲系統(tǒng)中存儲和查詢級聯(lián)數(shù)據(jù)（Hierarchical Data）是很方便的 Megastore數(shù)據(jù)模型怎么設(shè)計？數(shù)據(jù)模型怎么設(shè)計？ GoogleGoogle設(shè)計了一種能夠提供設(shè)計了一種能夠提供細(xì)粒度控制的數(shù)據(jù)模型和模式語言細(xì)粒度控制的數(shù)據(jù)模型和模式語言 同關(guān)系型數(shù)據(jù)庫一樣，同關(guān)系型數(shù)據(jù)庫一樣，MegastoreMegastore的數(shù)據(jù)模型是在的數(shù)據(jù)模型是在模式模式（schemaschema）中定義的且是強(qiáng)類型的（）中定義的且是強(qiáng)類型的（strongly typedstrongly typed） 每個模式都由一系列的表（每個模式都由一系列的表（tablestables

6、）構(gòu)成，表又包含有一系列）構(gòu)成，表又包含有一系列的實體（的實體（entitiesentities），每實體中包含一系列屬性（），每實體中包含一系列屬性（propertiesproperties） 屬性是命名的且具有類型，這些類型包括屬性是命名的且具有類型，這些類型包括字符型（字符型（stringsstrings）、）、數(shù)字類型（數(shù)字類型（numbersnumbers）或者）或者GoogleGoogle的的Protocol BuffersProtocol Buffers。這些屬。這些屬性可以被設(shè)置成性可以被設(shè)置成必須的必須的（requiredrequired）、）、可選的可選的（optional

7、optional）或者）或者可重復(fù)的可重復(fù)的（repeatedrepeated，即允許單個屬性上有多個值），即允許單個屬性上有多個值） 數(shù)據(jù)模型實例數(shù)據(jù)模型實例 照片共享服務(wù)數(shù)據(jù)模型實例照片共享服務(wù)數(shù)據(jù)模型實例 圖中表PhotoPhoto就是一個子表，因為它聲明了一個外鍵；UserUser則是一個根表。一個Megastore實例中可以有若干個不同的根表，表示不同類型的實體組集 圖中實例還可以看到三種不同屬性設(shè)置，既有必須的必須的（如user_id），也有可選的可選的（如thumbnail_url）；值得注意的是Photo中的可重復(fù)類型的tag屬性，這也就意味著一個一個PhotoPhoto中允許

8、同時出現(xiàn)多個中允許同時出現(xiàn)多個tagtag屬性屬性 索引（索引（IndexIndex） Megastore索引分成兩大類：局部索引（local index）和全局索引（global index） 局部索引定義在單個實體組中，作用域僅限于單個實體組（ 如PhotosByTime ） 全局索引則可以橫跨多個實體組集進(jìn)行數(shù)據(jù)讀取操作（ 如PhotosByTag ）Megastore還提供了一些額外的索引特性： STORING子句（STORING Clause） 可重復(fù)的索引（Repeated Indexes） 內(nèi)聯(lián)索引（Inline Indexes）BigtableBigtable中數(shù)據(jù)存儲情況中數(shù)

9、據(jù)存儲情況 行鍵（Row Key）UPhoto.timePhoto.tagPhoto._url101John101,50012:30:01Dinner, Paris101,50212:15:22Betty, Paris102Mary表中不難看出表中不難看出Bigtable的列名實際上是表名和屬性名結(jié)合在一起得到，不同表中實體可存儲在同一個Bigtable行中Google Megastore設(shè)計目標(biāo)及方案選擇 Megastore數(shù)據(jù)模型 Megastore中的事務(wù)及并發(fā)控制 Megastore基本架構(gòu) 核心技術(shù)復(fù)制 產(chǎn)品性能及控制措施 Megastore中的事務(wù)及并發(fā)控制Mega

10、store三種方式的讀，分別是current、snapshot和inconsistent 其中current讀和snapshot讀總是在單個實體組中完成 對于snapshot讀，系統(tǒng)取出已知的最后一個完整提交的事務(wù)的時間戳，接著從這個位置讀數(shù)據(jù) inconsistent讀忽略日志的狀態(tài)直接讀取最新的值Megastore中的事務(wù)及并發(fā)控制Megastore事務(wù)中的寫操作采用了預(yù)寫式日志預(yù)寫式日志（Write-ahead Log） 一個寫事務(wù)總是開始于開始于一個current讀以便確認(rèn)下一個可用的日志位置。提交操作將數(shù)據(jù)變更聚集到日志，接著接著分配一個比之前任意一個都高的時間戳，然后然后使用Pax

11、os將數(shù)據(jù)變更加入到日志中 協(xié)議使用了樂觀并發(fā)（Optimistic Concurrency）：盡管可能有多個寫操作同時試圖寫同一個日志位置，但只會有1個成功讀：獲取最后一次提交的事務(wù)的時間戳和日志位置 完整完整事務(wù)事務(wù)周期周期應(yīng)用邏輯：從Bigtable讀取且聚集數(shù)據(jù)到日志入口 提交：使用Paxos達(dá)到一致，將個入口追加到日志 生效：將數(shù)據(jù)更新到Bigtable中的實體和索引 清除：清理不再需要的數(shù)據(jù) Megastore中的事務(wù)機(jī)制 消息隊列機(jī)制消息能夠橫跨實體組 每個消息都有一個發(fā)送和接收實體組 如果兩個實體組是不同的，則傳輸將是異步特點規(guī)模：聲明一個隊列后可以在其他所有的實體組上創(chuàng)建一個

12、收件箱支持兩階段提交增加競爭風(fēng)險，不鼓勵使用 MegastoreMegastore中的事務(wù)機(jī)制中的事務(wù)機(jī)制 Google Megastore設(shè)計目標(biāo)及方案選擇 Megastore數(shù)據(jù)模型 Megastore中的事務(wù)及并發(fā)控制 Megastore基本架構(gòu) 核心技術(shù)復(fù)制 產(chǎn)品性能及控制措施 Megastore的基本架構(gòu)Megastore中三種副本 完整副本：Bigtable中存儲完整的日志和數(shù)據(jù) 見證者副本：在Paxos算法執(zhí)行過程中無法產(chǎn)生一個決議時參與投票 只讀副本：讀取最近過去某一個時間點一致性數(shù)據(jù) MegastoreMegastore的基本架構(gòu)的基本架構(gòu) Megastore中提供快速讀（F

13、ast Reads）和快速寫（Fast Writes）機(jī)制 快速讀 如果讀操作不需要副本之間進(jìn)行通信即可完成，那么讀取的效率必然相對較高 利用本地讀?。↙ocal Reads）實現(xiàn)快速讀，能夠帶來更好的用戶體驗及更低的延遲 確?？焖僮x成功的關(guān)鍵是保證選擇的副本上數(shù)據(jù)是最新的。為了達(dá)到這一目標(biāo)，引入了協(xié)調(diào)者的概念 協(xié)調(diào)者是一個服務(wù)，該服務(wù)分布在每個副本的數(shù)據(jù)中心里面。它的主要作用就是跟蹤一個實體組集合 協(xié)調(diào)者的狀態(tài)是由寫算法來保證 快速寫 Megastore采用了一種在主/從式系統(tǒng)中常用的優(yōu)化方法。如果一次寫成功，那么下一次寫的時候就跳過準(zhǔn)備過程，直接進(jìn)入接受階段 Megastore沒有使用專門

14、的主服務(wù)器，而是使用leaders leader主要是來裁決哪個寫入的值可以獲取0號提議 優(yōu)化：提交值最多的位置附近選擇一副本作為leader 客戶端、網(wǎng)絡(luò)及Bigtable的故障都會導(dǎo)致一個寫操作處于不確定的狀態(tài) Google Megastore設(shè)計目標(biāo)及方案選擇 Megastore數(shù)據(jù)模型 Megastore中的事務(wù)及并發(fā)控制 Megastore基本架構(gòu) 核心技術(shù)復(fù)制 產(chǎn)品性能及控制措施 復(fù)制的日志 預(yù)寫式日志預(yù)寫式日志 當(dāng)日志有不完整的前綴時我們就稱一個日志副本有“缺失缺失”（Holes） 圖中099的日志位置已經(jīng)被全部清除全部清除；100的日志位置被部分清除部分清除；101的日志位置被

15、全部全部副本副本接受；102的日志位置被獲得；103的日志位置被副本副本A A和和C C接受，副本B則留下了一個“缺失缺失”；104的日志位置則未達(dá)到一致性未達(dá)到一致性數(shù)據(jù)讀取 數(shù)據(jù)讀取 數(shù)據(jù)讀取過程:本地查詢（Query Local）發(fā)現(xiàn)位置（Find Position） 本地讀?。↙ocal Read） 多數(shù)派讀?。∕ajority Read） 追趕 （Catchup） Paxos將會促使絕大多數(shù)副本達(dá)成一個共識值 達(dá)到一種分布式一致狀態(tài) 驗證（Validate）查詢數(shù)據(jù)（Query Data） 數(shù)據(jù)寫入 數(shù)據(jù)寫入 數(shù)據(jù)寫入完整過程 :（1）接受leader：請求leader接受值作為0號

16、提議（快速寫方法），若成功，跳至步驟（3） （2）準(zhǔn)備：將值替換成擁有最高提議號的那個值 （3）接受：請求剩余的副本接受該值，如果大多數(shù)副本拒絕這個值，返回步驟（2） （4）失效：將不接受值的副本上的協(xié)調(diào)者進(jìn)行失效操作 （5）生效：將值的更新在盡可能多的副本上生效。如果選擇的值和原來提議的有沖突，返回一個沖突錯誤 協(xié)調(diào)者的可用性 協(xié)調(diào)者在系統(tǒng)中是比較重要的協(xié)調(diào)者在系統(tǒng)中是比較重要的協(xié)調(diào)者的進(jìn)程運(yùn)行在每個數(shù)據(jù)中心。每次的寫操作中都要涉及協(xié)調(diào)者，因此協(xié)調(diào)者的故障將會導(dǎo)致系統(tǒng)的不可用 Megastore使用了Chubby鎖服務(wù)，為了處理請求，一個協(xié)調(diào)者必須持有多數(shù)鎖。一旦因為出現(xiàn)問題導(dǎo)致它丟失了大部

17、分鎖，協(xié)調(diào)者就會恢復(fù)到一個默認(rèn)保守狀態(tài) 除了可用性問題，對于協(xié)調(diào)者的讀寫協(xié)議必須滿足一系列的競爭條件 Google Megastore設(shè)計目標(biāo)及方案選擇 Megastore數(shù)據(jù)模型 Megastore中的事務(wù)及并發(fā)控制 Megastore基本架構(gòu) 核心技術(shù)復(fù)制 產(chǎn)品性能及控制措施 可用性分布情況 可用性分布情況 Megastore在Google中已經(jīng)部署和使用了若干年，有超過100個產(chǎn)品使用Megastore作為其存儲系統(tǒng)從圖中可以看出，絕大多數(shù)產(chǎn)品具有極高的可用性（99.999%）。這表明Megastore系統(tǒng)的設(shè)計是非非常成功的，基本達(dá)到了預(yù)常成功的，基本達(dá)到了預(yù)期目標(biāo)期目標(biāo) 產(chǎn)品延遲情況

18、分布 應(yīng)用程序的平均讀取延遲在萬分之一毫秒之內(nèi)，平均寫入延遲在100至400毫秒之間 避免Megastore的性能下降，可采取以下三種應(yīng)對方法（可能結(jié)合使用）： （1）重新選擇路由使客戶端繞開出現(xiàn)問題的副本（2）將出現(xiàn)問題副本上的協(xié)調(diào)者禁用，確保問題的影響降至最小。（3）禁用整個副本平均延遲的分布 需要指出：Megastore已經(jīng)是Google相對過時的存儲技術(shù)。Google目前正在使用的存儲系統(tǒng)是Spanner架構(gòu)，Spanner的設(shè)計目標(biāo)是能夠控制一百萬到一千萬臺服務(wù)器，Spanner最強(qiáng)大之處在于能夠在50毫秒之內(nèi)為數(shù)據(jù)傳遞提供通道 Google Dapper 基本設(shè)計目標(biāo) Dapper

19、監(jiān)控系統(tǒng)簡介 關(guān)鍵性技術(shù) 常用Dapper工具 Dapper使用經(jīng)驗用戶將一個關(guān)鍵字通過用戶將一個關(guān)鍵字通過GoogleGoogle的輸入框傳到的輸入框傳到GoogleGoogle的后臺，在的后臺，在我們看來很簡單的一次搜索實際上涉及了眾多我們看來很簡單的一次搜索實際上涉及了眾多GoogleGoogle后臺子系后臺子系統(tǒng)，這些子系統(tǒng)的運(yùn)行狀態(tài)都需要進(jìn)行統(tǒng)，這些子系統(tǒng)的運(yùn)行狀態(tài)都需要進(jìn)行監(jiān)控監(jiān)控 廣泛可部署性不間斷的監(jiān)控 監(jiān)控系統(tǒng)設(shè)計監(jiān)控系統(tǒng)設(shè)計兩個基本要求兩個基本要求 設(shè)計目標(biāo) 030302020101n廣泛可部署性的必然要求。廣泛可部署性的必然要求。監(jiān)控系統(tǒng)的開銷越低，對監(jiān)控系統(tǒng)的開銷越低，

20、對于原系統(tǒng)的影響就越小，于原系統(tǒng)的影響就越小，系統(tǒng)的開發(fā)人員也就越愿系統(tǒng)的開發(fā)人員也就越愿意接受這個監(jiān)控系統(tǒng)意接受這個監(jiān)控系統(tǒng) nGoogle的服務(wù)增長速的服務(wù)增長速度是驚人的，設(shè)計出度是驚人的，設(shè)計出的系統(tǒng)至少在未來幾的系統(tǒng)至少在未來幾年里要能夠滿足年里要能夠滿足Google服務(wù)和集群的需求服務(wù)和集群的需求 n如果監(jiān)控系統(tǒng)的使用需要如果監(jiān)控系統(tǒng)的使用需要程序開發(fā)人員對其底層的程序開發(fā)人員對其底層的一些細(xì)節(jié)進(jìn)行調(diào)整才能正一些細(xì)節(jié)進(jìn)行調(diào)整才能正常工作的話，這個監(jiān)控系常工作的話，這個監(jiān)控系統(tǒng)肯定不是一個完善的監(jiān)統(tǒng)肯定不是一個完善的監(jiān)控系統(tǒng)控系統(tǒng) 低開銷 應(yīng)用層透明 可擴(kuò)展性 大規(guī)模分布式系統(tǒng)的監(jiān)控

21、基礎(chǔ)架構(gòu)Dapper 基本設(shè)計目標(biāo) Dapper監(jiān)控系統(tǒng)簡介 關(guān)鍵性技術(shù) 常用Dapper工具 Dapper使用經(jīng)驗基本概念 圖中，用戶發(fā)出請求X，前端A發(fā)現(xiàn)該請求的處理需要涉及服務(wù)器B和服務(wù)器C，因此A又向B和C發(fā)出兩個RPC（遠(yuǎn)程過程調(diào)用）。B收到后立刻做出響應(yīng)，但是C在接到后發(fā)現(xiàn)它還需要調(diào)用服務(wù)器D和E才能完成請求X，因此C對D和E分別發(fā)出了RPC，D和E接到后分別做出了應(yīng)答，收到D和E的應(yīng)答之后C才向A做出響應(yīng)，在接收到B和C的應(yīng)答之后A才對用戶請求X做出一個應(yīng)答X 在監(jiān)控系統(tǒng)中記錄下所有這些消息不難，如何將這些消息記錄同特定的請求（本例中的X）關(guān)聯(lián)起來才是分布式監(jiān)控系統(tǒng)設(shè)計中需要解決

22、的關(guān)鍵性問題之一 典型分布式系統(tǒng)的請求及應(yīng)答過程典型分布式系統(tǒng)的請求及應(yīng)答過程 方案一方案一 黑盒（黑盒（Black BoxBlack Box）方案）方案方案比較輕便，但在消息關(guān)系判斷過程中，主要是利用一些統(tǒng)計學(xué)知識來進(jìn)行推斷，有時不是很準(zhǔn)確 方案二方案二 基于注釋的方案基于注釋的方案 利用應(yīng)用程序或中間件給每條記錄賦予一個全局性的標(biāo)示符，借此將相關(guān)消息串聯(lián)起來（GoogleGoogle最終選擇最終選擇 ）基本概念 Dapper監(jiān)控系統(tǒng)中三個基本概念：監(jiān)控樹（Trace Tree）、區(qū)間（Span）和注釋（Annotation）圖示是一個典型的監(jiān)控樹，實際上就是一個同特定事件相關(guān)的按照一定的規(guī)

23、律以樹的形式組織起來所有消息，每一個節(jié)點稱為一個區(qū)間（一條記錄），所有記錄聯(lián)系在一起就構(gòu)成了對某個事件的完整監(jiān)控。每個區(qū)間包括如下的內(nèi)容：區(qū)間名（Span Name）、區(qū)間id（Span id）、父id（Parent id）和監(jiān)控id（Trace id） 監(jiān)控樹監(jiān)控樹 監(jiān)控id圖中并沒有列出，一棵監(jiān)控樹中所有區(qū)間的監(jiān)控id相同，隨機(jī)分配且唯一 區(qū)間區(qū)間Helper.CallHelper.Call的詳細(xì)信息的詳細(xì)信息 圖中區(qū)間包含來自客戶端的注釋信息：“”、“Client Send”、“Client Recv”和“”，也包含來自服務(wù)器端的注釋信息：“Server Recv”、“foo”和“Ser

24、ver Send”。除“foo”是用戶自定義的注釋外，其他的注釋信息都是和時間相關(guān)的信息。Dapper不但支持用戶進(jìn)行簡單的文本方式的注釋，還支持鍵-值對方式的注釋基本概念 監(jiān)控信息的匯總監(jiān)控信息的匯總 監(jiān)控信息匯總監(jiān)控信息匯總 監(jiān)控信息匯總監(jiān)控信息匯總（1）將區(qū)間的數(shù)據(jù)寫入到本地的日志文件 （2）所有機(jī)器上的本地日志文件匯集 （3）匯集后的數(shù)據(jù)寫入到Bigtable存儲庫中 監(jiān)控數(shù)據(jù)匯總是單獨進(jìn)行單獨進(jìn)行的，而不是伴隨系統(tǒng)對用戶的應(yīng)答一起返回的，如此選擇主要原因： 內(nèi)置的匯總方案（監(jiān)控數(shù)據(jù)隨RPC應(yīng)答頭返回）會影響網(wǎng)絡(luò)動態(tài) 內(nèi)置的匯總方案需要保證所有的RPC都是完全嵌套安全問題 應(yīng)用層注釋提

25、供一種方便的選擇機(jī)制選擇機(jī)制（Opt-in Mechanism）：應(yīng)用程序開發(fā)者可以將任何對后期分析有益的數(shù)據(jù)和區(qū)間關(guān)聯(lián)起來 Google Dapper基本設(shè)計目標(biāo) Dapper監(jiān)控系統(tǒng)簡介 關(guān)鍵性技術(shù) 常用Dapper工具 Dapper使用經(jīng)驗Dapper三個設(shè)計目標(biāo)中，實現(xiàn)難度最大的是 ？應(yīng)用層透明 怎么實現(xiàn)應(yīng)用層透明 輕量級的核心功能庫輕量級的核心功能庫 二次抽樣技術(shù)二次抽樣技術(shù) 輕量級核心功能庫 將Dapper的核心監(jiān)控實現(xiàn)限制在一個由通用線程（Ubiquitous Threading）、控制流（Control Flow）和RPC代碼庫（RPC Library Code）組成的小規(guī)模庫

26、基礎(chǔ)上其中最關(guān)鍵的代碼基礎(chǔ)是基本RPC、線程和控制流函數(shù)庫的實現(xiàn)，主要功能是實現(xiàn)區(qū)間創(chuàng)建、抽樣和在本地磁盤上記錄日志 二次抽樣技術(shù) 第一次抽樣實踐中，設(shè)計人員發(fā)現(xiàn)當(dāng)抽樣率低至1/1024時也能夠產(chǎn)生足夠多的有效監(jiān)控數(shù)據(jù)，即在1024個請求中抽取1個進(jìn)行監(jiān)控也是可行的，從而可以捕獲有效數(shù)據(jù)第二次抽樣發(fā)生在數(shù)據(jù)寫入Bigtable前，具體方法是將監(jiān)控id散列成一個標(biāo)量z（0z1），如果某個區(qū)間的z小于事先定義好的匯總抽樣系數(shù)，則保留這個區(qū)間并將它寫入Bigtable，否則丟棄 Google Dapper基本設(shè)計目標(biāo) Dapper監(jiān)控系統(tǒng)簡介 關(guān)鍵性技術(shù) 常用Dapper工具 Dapper使用經(jīng)驗Dapper存儲API Dapper的“存儲API”簡稱為 DAPI，提供了對分散在區(qū)域Dapper存儲庫（DEPOTS）的監(jiān)控記錄的直接訪問。一般來說，有以下三種方式三種方式可以對這些記錄進(jìn)行訪問： （1）監(jiān)控id訪問（Access by Trace id） 利用全局唯一的監(jiān)控id直接訪問所需的監(jiān)控數(shù)據(jù) （2）塊訪問（Bulk Access） 借助MapReduce對數(shù)以十億計的Dapper監(jiān)控數(shù)據(jù)的并行訪問 （3）索引訪問（Indexed Access） Dapper存儲庫支持單索引（Single Index）根據(jù)不完全統(tǒng)計，目前大約有三個基于DAPI的