課件4—第二章 Google云計(jì)算原理與應(yīng)用(3).ppt

電子工業(yè)出版社 云計(jì)算 第二版 配套課件 解放軍理工大學(xué)劉鵬教授主編華東交通大學(xué)劉鵬制作 第2章Google云計(jì)算原理與應(yīng)用 云計(jì)算 第二版 購(gòu)買(mǎi)網(wǎng)址 當(dāng)當(dāng)網(wǎng)京東商城 姊妹力作 實(shí)戰(zhàn)Hadoop 購(gòu)買(mǎi)網(wǎng)址 當(dāng)當(dāng)網(wǎng)京東商城 提綱 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)Dapper Google應(yīng)用程序引擎 設(shè)計(jì)目標(biāo)及方案選擇 Megastore數(shù)據(jù)模型 Megastore中的事務(wù)及并發(fā)控制 Megastore基本架構(gòu) 核心技術(shù) 復(fù)制 產(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)以滿(mǎ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ū)被稱(chēng)為實(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 中 設(shè)計(jì)目標(biāo)及方案選擇 Megastore數(shù)據(jù)模型 Megastore中的事務(wù)及并發(fā)控制 Megastore基本架構(gòu) 核心技術(shù) 復(fù)制 產(chǎn)品性能及控制措施 Megastore數(shù)據(jù)模型 傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)是通過(guò)連接 Join 來(lái)滿(mǎn)足用戶(hù)的需求的 但是就Megastore而言 這種數(shù)據(jù)模型是不合適的 主要有以下三個(gè)原因 1 對(duì)于高負(fù)載的交互式應(yīng)用來(lái)說(shuō) 可預(yù)期的性能提升要比使用一種代價(jià)高昂的查詢(xún)語(yǔ)言所帶來(lái)的好處多 2 Megastore所面對(duì)的應(yīng)用是讀遠(yuǎn)多于寫(xiě) 因此好的選擇是將讀操作所需要做的工作盡可能地轉(zhuǎn)移到寫(xiě)操作上 3 在Bigtable這樣的鍵 值存儲(chǔ)系統(tǒng)中存儲(chǔ)和查詢(xún)級(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)類(lèi)型的 stronglytyped 每個(gè)模式都由一系列的表 tables 構(gòu)成 表又包含有一系列的實(shí)體 entities 每實(shí)體中包含一系列屬性 properties 屬性是命名的且具有類(lèi)型 這些類(lèi)型包括字符型 strings 數(shù)字類(lèi)型 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è)不同的根表 表示不同類(lèi)型的實(shí)體組集 圖中實(shí)例還可以看到三種不同屬性設(shè)置 既有必須的 如user id 也有可選的 如thumbnail url 值得注意的是Photo中的可重復(fù)類(lèi)型的tag屬性 這也就意味著一個(gè)Photo中允許同時(shí)出現(xiàn)多個(gè)tag屬性 索引 Index Megastore索引分成兩大類(lèi) 局部索引 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ǔ)情況 表中不難看出 Bigtable的列名實(shí)際上是表名和屬性名結(jié)合在一起得到 不同表中實(shí)體可存儲(chǔ)在同一個(gè)Bigtable行中 設(shè)計(jì)目標(biāo)及方案選擇 Megastore數(shù)據(jù)模型 Megastore中的事務(wù)及并發(fā)控制 Megastore基本架構(gòu) 核心技術(shù) 復(fù)制 產(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ù)中的寫(xiě)操作采用了預(yù)寫(xiě)式日志 Write aheadLog 一個(gè)寫(xiě)事務(wù)總是開(kāi)始于一個(gè)current讀以便確認(rèn)下一個(gè)可用的日志位置 提交操作將數(shù)據(jù)變更聚集到日志 接著分配一個(gè)比之前任意一個(gè)都高的時(shí)間戳 然后使用Paxos將數(shù)據(jù)變更加入到日志中 協(xié)議使用了樂(lè)觀并發(fā) OptimisticConcurrency 盡管可能有多個(gè)寫(xiě)操作同時(shí)試圖寫(xiě)同一個(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ī)制 設(shè)計(jì)目標(biāo)及方案選擇 Megastore數(shù)據(jù)模型 Megastore中的事務(wù)及并發(fā)控制 Megastore基本架構(gòu) 核心技術(shù) 復(fù)制 產(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 和快速寫(xiě) FastWrites 機(jī)制 快速讀 如果讀操作不需要副本之間進(jìn)行通信即可完成 那么讀取的效率必然相對(duì)較高 利用本地讀取 LocalReads 實(shí)現(xiàn)快速讀 能夠帶來(lái)更好的用戶(hù)體驗(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)是由寫(xiě)算法來(lái)保證 快速寫(xiě) Megastore采用了一種在主 從式系統(tǒng)中常用的優(yōu)化方法 如果一次寫(xiě)成功 那么下一次寫(xiě)的時(shí)候就跳過(guò)準(zhǔn)備過(guò)程 直接進(jìn)入接受階段 Megastore沒(méi)有使用專(zhuān)門(mén)的主服務(wù)器 而是使用leaders leader主要是來(lái)裁決哪個(gè)寫(xiě)入的值可以獲取0號(hào)提議 優(yōu)化 提交值最多的位置附近選擇一副本作為leader 客戶(hù)端 網(wǎng)絡(luò)及Bigtable的故障都會(huì)導(dǎo)致一個(gè)寫(xiě)操作處于不確定的狀態(tài) 設(shè)計(jì)目標(biāo)及方案選擇 Megastore數(shù)據(jù)模型 Megastore中的事務(wù)及并發(fā)控制 Megastore基本架構(gòu) 核心技術(shù) 復(fù)制 產(chǎn)品性能及控制措施 復(fù)制的日志 預(yù)寫(xiě)式日志 當(dāng)日志有不完整的前綴時(shí)我們就稱(chēng)一個(gè)日志副本有 缺失 Holes 圖中0 99的日志位置已經(jīng)被全部清除 100的日志位置被部分清除 101的日志位置被全部副本接受 102的日志位置被 獲得 103的日志位置被副本A和C接受 副本B則留下了一個(gè) 缺失 104的日志位置則未達(dá)到一致性 數(shù)據(jù)讀取 數(shù)據(jù)讀取 數(shù)據(jù)讀取過(guò)程 本地查詢(xún) QueryLocal 發(fā)現(xiàn)位置 FindPosition 本地讀取 LocalRead 多數(shù)派讀取 MajorityRead 追趕 Catchup Paxos將會(huì)促使絕大多數(shù)副本達(dá)成一個(gè)共識(shí)值 達(dá)到一種分布式一致?tīng)顟B(tài) 驗(yàn)證 Validate 查詢(xún)數(shù)據(jù) QueryData 數(shù)據(jù)寫(xiě)入 數(shù)據(jù)寫(xiě)入 數(shù)據(jù)寫(xiě)入完整過(guò)程 1 接受leader 請(qǐng)求leader接受值作為0號(hào)提議 快速寫(xiě)方法 若成功 跳至步驟 3 2 準(zhǔn)備 將值替換成擁有最高提議號(hào)的那個(gè)值 3 接受 請(qǐng)求剩余的副本接受該值 如果大多數(shù)副本拒絕這個(gè)值 返回步驟 2 4 失效 將不接受值的副本上的協(xié)調(diào)者進(jìn)行失效操作 5 生效 將值的更新在盡可能多的副本上生效 如果選擇的值和原來(lái)提議的有沖突 返回一個(gè)沖突錯(cuò)誤 協(xié)調(diào)者的可用性 協(xié)調(diào)者在系統(tǒng)中是比較重要的 協(xié)調(diào)者的進(jìn)程運(yùn)行在每個(gè)數(shù)據(jù)中心 每次的寫(xiě)操作中都要涉及協(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)問(wèn)題導(dǎo)致它丟失了大部分鎖 協(xié)調(diào)者就會(huì)恢復(fù)到一個(gè)默認(rèn)保守狀態(tài) 除了可用性問(wèn)題 對(duì)于協(xié)調(diào)者的讀寫(xiě)協(xié)議必須滿(mǎn)足一系列的競(jìng)爭(zhēng)條件 設(shè)計(jì)目標(biāo)及方案選擇 Megastore數(shù)據(jù)模型 Megastore中的事務(wù)及并發(fā)控制 Megastore基本架構(gòu) 核心技術(shù) 復(fù)制 產(chǎn)品性能及控制措施 可用性分布情況 可用性分布情況 Megastore在Google中已經(jīng)部署和使用了若干年 有超過(guò)100個(gè)產(chǎn)品使用Megastore作為其存儲(chǔ)系統(tǒng) 從圖中可以看出 絕大多數(shù)產(chǎn)品具有極高的可用性 99 999 這表明Megastore系統(tǒng)的設(shè)計(jì)是非常成功的 基本達(dá)到了預(yù)期目標(biāo) 產(chǎn)品延遲情況分布 應(yīng)用程序的平均讀取延遲在萬(wàn)分之一毫秒之內(nèi) 平均寫(xiě)入延遲在100至400毫秒之間 避免Megastore的性能下降 可采取以下三種應(yīng)對(duì)方法 可能結(jié)合使用 1 重新選擇路由使客戶(hù)端繞開(kāi)出現(xiàn)問(wèn)題的副本 2 將出現(xiàn)問(wèn)題副本上的協(xié)調(diào)者禁用 確保問(wèn)題的影響降至最小 3 禁用整個(gè)副本 平均延遲的分布 需要指出 Megastore已經(jīng)是Google相對(duì)過(guò)時(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ù)傳遞提供通道 基本設(shè)計(jì)目標(biāo) Dapper監(jiān)控系統(tǒng)簡(jiǎn)介 關(guān)鍵性技術(shù) 常用Dapper工具 Dapper使用經(jīng)驗(yàn) 用戶(hù)將一個(gè)關(guān)鍵字通過(guò)Google的輸入框傳到Google的后臺(tái) 在我們看來(lái)很簡(jiǎn)單的一次搜索實(shí)際上涉及了眾多Google后臺(tái)子系統(tǒng) 這些子系統(tǒng)的運(yùn)行狀態(tài)都需要進(jìn)行監(jiān)控 廣泛可部署性 不間斷的監(jiān)控 監(jiān)控系統(tǒng)設(shè)計(jì)兩個(gè)基本要求 設(shè)計(jì)目標(biāo) 03 02 01 廣泛可部署性的必然要求 監(jiān)控系統(tǒng)的開(kāi)銷(xiāo)越低 對(duì)于原系統(tǒng)的影響就越小 系統(tǒng)的開(kāi)發(fā)人員也就越愿意接受這個(gè)監(jiān)控系統(tǒng) Google的服務(wù)增長(zhǎng)速度是驚人的 設(shè)計(jì)出的系統(tǒng)至少在未來(lái)幾年里要能夠滿(mǎn)足Google服務(wù)和集群的需求 如果監(jiān)控系統(tǒng)的使用需要程序開(kāi)發(fā)人員對(duì)其底層的一些細(xì)節(jié)進(jìn)行調(diào)整才能正常工作的話 這個(gè)監(jiān)控系統(tǒng)肯定不是一個(gè)完善的監(jiān)控系統(tǒng) 低開(kāi)銷(xiāo) 應(yīng)用層透明 可擴(kuò)展性 基本設(shè)計(jì)目標(biāo) Dapper監(jiān)控系統(tǒng)簡(jiǎn)介 關(guān)鍵性技術(shù) 常用Dapper工具 Dapper使用經(jīng)驗(yàn) 基本概念 圖中 用戶(hù)發(fā)出請(qǐng)求X 前端A發(fā)現(xiàn)該請(qǐng)求的處理需要涉及服務(wù)器B和服務(wù)器C 因此A又向B和C發(fā)出兩個(gè)RPC 遠(yuǎn)程過(guò)程調(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ì)用戶(hù)請(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)鍵性問(wèn)題之一 典型分布式系統(tǒng)的請(qǐng)求及應(yīng)答過(guò)程 方案一黑盒 BlackBox 方案 方案比較輕便 但在消息關(guān)系判斷過(guò)程中 主要是利用一些統(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)控樹(shù) TraceTree 區(qū)間 Span 和注釋 Annotation 圖示是一個(gè)典型的監(jiān)控樹(shù) 實(shí)際上就是一個(gè)同特定事件相關(guān)的按照一定的規(guī)律以樹(shù)的形式組織起來(lái)所有消息 每一個(gè)節(jié)點(diǎn)稱(chēng)為一個(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)控樹(shù) 監(jiān)控id圖中并沒(méi)有列出 一棵監(jiān)控樹(shù)中所有區(qū)間的監(jiān)控id相同 隨機(jī)分配且唯一 區(qū)間Helper Call的詳細(xì)信息 圖中區(qū)間包含來(lái)自客戶(hù)端的注釋信息 ClientSend ClientRecv 和 也包含來(lái)自服務(wù)器端的注釋信息 ServerRecv foo 和 ServerSend 除 foo 是用戶(hù)自定義的注釋外 其他的注釋信息都是和時(shí)間相關(guān)的信息 Dapper不但支持用戶(hù)進(jìn)行簡(jiǎn)單的文本方式的注釋 還支持鍵 值對(duì)方式的注釋 基本概念 監(jiān)控信息的匯總 監(jiān)控信息匯總 監(jiān)控信息匯總 1 將區(qū)間的數(shù)據(jù)寫(xiě)入到本地的日志文件 2 所有機(jī)器上的本地日志文件匯集 3 匯集后的數(shù)據(jù)寫(xiě)入到Bigtable存儲(chǔ)庫(kù)中 監(jiān)控?cái)?shù)據(jù)匯總是單獨(dú)進(jìn)行的 而不是伴隨系統(tǒng)對(duì)用戶(hù)的應(yīng)答一起返回的 如此選擇主要原因 內(nèi)置的匯總方案 監(jiān)控?cái)?shù)據(jù)隨RPC應(yīng)答頭返回 會(huì)影響網(wǎng)絡(luò)動(dòng)態(tài) 內(nèi)置的匯總方案需要保證所有的RPC都是完全嵌套 安全問(wèn)題 應(yīng)用層注釋提供一種方便的選擇機(jī)制 Opt inMechanism 應(yīng)用程序開(kāi)發(fā)者可以將任何對(duì)后期分析有益的數(shù)據(jù)和區(qū)間關(guān)聯(lián)起來(lái) 基本設(shè)計(jì)目標(biāo) Dapper監(jiān)控系統(tǒng)簡(jiǎn)介 關(guān)鍵性技術(shù) 常用Dapper工具 Dapper使用經(jīng)驗(yàn) Dapper三個(gè)設(shè)計(jì)目標(biāo)中 實(shí)現(xiàn)難度最大的是 應(yīng)用層透明 怎么實(shí)現(xiàn)應(yīng)用層透明 輕量級(jí)的核心功能庫(kù) 二次抽樣技術(shù) 輕量級(jí)核心功能庫(kù) 將Dapper的核心監(jiān)控實(shí)現(xiàn)限制在一個(gè)由通用線程 UbiquitousThreading 控制流 ControlFlow 和RPC代碼庫(kù) RPCLibraryCode 組成的小規(guī)模庫(kù)基礎(chǔ)上 其中最關(guān)鍵的代碼基礎(chǔ)是基本RPC 線程和控制流函數(shù)庫(kù)的實(shí)現(xiàn) 主要功能是實(shí)現(xiàn)區(qū)間創(chuàng)建 抽樣和在本地磁盤(pán)上記錄日志 二次抽樣技術(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ù)寫(xiě)入Bigtable前 具體方法是將監(jiān)控id散列成一個(gè)標(biāo)量z 0 z 1 如果某個(gè)區(qū)間的z小于事先定義好的匯總抽樣系數(shù) 則保留這個(gè)區(qū)間并將它寫(xiě)入Bigtable 否則丟棄 基本設(shè)計(jì)目標(biāo) Dapper監(jiān)控系統(tǒng)簡(jiǎn)介 關(guān)鍵性技術(shù) 常用Dapper工具 Dapper使用經(jīng)驗(yàn) Dapper存儲(chǔ)API Dapper的 存儲(chǔ)API 簡(jiǎn)稱(chēng)為DAPI 提供了對(duì)分散在區(qū)域Dapper存儲(chǔ)庫(kù) DEPOTS 的監(jiān)控記錄的直接訪問(wèn) 一般來(lái)說(shuō) 有以下三種方式可以對(duì)這些記錄進(jìn)行訪問(wèn) 1 監(jiān)控id訪問(wèn) AccessbyTraceid 利用全局唯一的監(jiān)控id直接訪問(wèn)所需的監(jiān)控?cái)?shù)據(jù) 2 塊訪問(wèn) BulkAccess 借助MapReduce對(duì)數(shù)以十億計(jì)的Dapper監(jiān)控?cái)?shù)據(jù)的并行訪問(wèn) 3 索引訪問(wèn) IndexedAccess Dapper存儲(chǔ)庫(kù)支持單索引 SingleIndex 根據(jù)不完全統(tǒng)計(jì) 目前大約有三個(gè)基于DAPI的持久應(yīng)用程序 八個(gè)額外的基于DAPI的按需分析工具及大約15 20個(gè)使用DAPI框架構(gòu)建的一次性分析工具 Dapper用戶(hù)界面 1 選擇監(jiān)控對(duì)象 起止時(shí)間 區(qū)分監(jiān)控模式的信息及一個(gè)衡量開(kāi)銷(xiāo)的標(biāo)準(zhǔn) 2 用戶(hù)對(duì)這