《云計算(第二版)》教材配套課件2-第二章-Google云計算原理與應用1

電子工業(yè)出版社《云計算(第二版)》配套課件解放軍理工大學教授主編華東交通大學制作第2章Google云計算原理與應用《云計算（第二版）》購買網(wǎng)址：當當網(wǎng)

京東商城姊妹力作《實戰(zhàn)Hadoop》購買網(wǎng)址：當當網(wǎng)

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

分布式鎖服務Chubby

分布式結構化數(shù)據(jù)表Bigtable

分布式存儲系統(tǒng)Megastore大規(guī)模分布式系統(tǒng)的監(jiān)控基礎架構DapperGoogle應用程序引擎Google文件系統(tǒng)GFS系統(tǒng)架構容錯機制系統(tǒng)管理技術Google業(yè)務全球最大搜索引擎、GoogleMaps、GoogleEarth、Gmail、YouTube等數(shù)據(jù)量巨大，且面向全球用戶提供實時服務

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

秘密武器：云計算平臺！GFS設計動機Google需要一個支持海量存儲的文件系統(tǒng)購置昂貴的分布式文件系統(tǒng)與硬件？為什么不使用當時現(xiàn)存的文件系統(tǒng)？Google所面臨的問題與眾不同

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

GFS架構是怎樣的？系統(tǒng)架構Client（客戶端）：應用程序的訪問接口

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

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

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

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

POSIX接口提供功能更豐富

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

Master和ChunkServer都以進程方式運行，單個進程不影響整個操作系統(tǒng)

GFS和操作系統(tǒng)運行在不同的空間，兩者耦合性降低只提供專用接口

降低實現(xiàn)的難度

對應用提供一些特殊支持降低復雜度

Google文件系統(tǒng)GFS系統(tǒng)架構容錯機制系統(tǒng)管理技術Master容錯

MasterNameSpace，文件系統(tǒng)目錄結構

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

NameSpace，文件系統(tǒng)目錄結構

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

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

GFS還提供了Master遠程的實時備份,防止Master徹底死機的情況ChunkServer容錯

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

節(jié)點動態(tài)加入技術

節(jié)能技術

新的ChunkServer加入時，只需裸機加入，大大減少GFS維護工作量

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

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

小結簡單的，就是最好的！討論GFS有什么問題嗎？分布式數(shù)據(jù)處理MapReduce

產生背景

編程模型實現(xiàn)機制案例分析MapReduce一種處理海量數(shù)據(jù)的并行編程模式，用于大規(guī)模數(shù)據(jù)集（通常大于1TB）的并行運算。

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

Google擁有海量數(shù)據(jù)，并且需要快速處理Google全球Web數(shù)據(jù)郵件數(shù)據(jù)地圖數(shù)據(jù)衛(wèi)星照片……計算問題簡單，但求解困難

待處理數(shù)據(jù)量巨大（PB級），只有分布在成百上千個節(jié)點上并行計算才能在可接受的時間內完成如何進行并行分布式計算？

如何分發(fā)待處理數(shù)據(jù)？

如何處理分布式計算中的錯誤？簡單的問題，計算并不簡單！JefferyDean設計一個新的抽象模型，封裝并行處理、容錯處理、本地化計算、負載均衡的細節(jié)，還提供了一個簡單而強大的接口這就是MapReduceGoogleMapReduce架構設計師JeffreyDean分布式數(shù)據(jù)處理MapReduce

產生背景

編程模型實現(xiàn)機制案例分析MapReduce運行模型

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

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

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

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

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

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

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

產生背景

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

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

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

（7）當所有的Map任務和Reduce任務都完成的時候，Master激活用戶程序。此時MapReduce返回用戶程序的調用點MapReduce容錯

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

產生背景

編程模型實現(xiàn)機制案例分析假設有一批海量的數(shù)據(jù)，每個數(shù)據(jù)都是由26個字母組成的字