《云計算(第二版)》教材配套課件2-第二章-Google云計算原理與應用1_第1頁
《云計算(第二版)》教材配套課件2-第二章-Google云計算原理與應用1_第2頁
《云計算(第二版)》教材配套課件2-第二章-Google云計算原理與應用1_第3頁
《云計算(第二版)》教材配套課件2-第二章-Google云計算原理與應用1_第4頁
《云計算(第二版)》教材配套課件2-第二章-Google云計算原理與應用1_第5頁
已閱讀5頁,還剩35頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

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

京東商城姊妹力作《實戰Hadoop》購買網址:當當網

京東商城提綱Google文件系統GFS分布式數據處理MapReduce

分布式鎖服務Chubby

分布式結構化數據表Bigtable

分布式存儲系統Megastore大規模分布式系統的監控基礎架構DapperGoogle應用程序引擎Google文件系統GFS系統架構容錯機制系統管理技術Google業務全球最大搜索引擎、GoogleMaps、GoogleEarth、Gmail、YouTube等數據量巨大,且面向全球用戶提供實時服務

Google云計算平臺技術架構文件存儲,GoogleDistributedFileSystem,GFS并行數據處理MapReduce分布式鎖Chubby分布式結構化數據表BigTable分布式存儲系統Megastore分布式監控系統Dapper

秘密武器:云計算平臺!GFS設計動機Google需要一個支持海量存儲的文件系統購置昂貴的分布式文件系統與硬件?為什么不使用當時現存的文件系統?Google所面臨的問題與眾不同

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

GFS架構是怎樣的?系統架構Client(客戶端):應用程序的訪問接口

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

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

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

利用POSIX編程接口存取數據降低了實現難度,提高通用性

POSIX接口提供功能更豐富

用戶態下有多種調試工具

Master和ChunkServer都以進程方式運行,單個進程不影響整個操作系統

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

降低實現的難度

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

Google文件系統GFS系統架構容錯機制系統管理技術Master容錯

MasterNameSpace,文件系統目錄結構

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

NameSpace,文件系統目錄結構

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

第三種元數據信息保存在各個ChunkServer上,Master故障時,磁盤恢復

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

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

節點動態加入技術

節能技術

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

GFS構建在不可靠廉價計算機之上的文件系統,由于節點數目眾多,故障發生十分頻繁

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

小結簡單的,就是最好的!討論GFS有什么問題嗎?分布式數據處理MapReduce

產生背景

編程模型實現機制案例分析MapReduce一種處理海量數據的并行編程模式,用于大規模數據集(通常大于1TB)的并行運算。

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

Google擁有海量數據,并且需要快速處理Google全球Web數據郵件數據地圖數據衛星照片……計算問題簡單,但求解困難

待處理數據量巨大(PB級),只有分布在成百上千個節點上并行計算才能在可接受的時間內完成如何進行并行分布式計算?

如何分發待處理數據?

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

產生背景

編程模型實現機制案例分析MapReduce運行模型

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

開發者需編寫兩個主要函數

Map輸入參數:in_key和in_value,它指明了Map需要處理的原始數據Map輸出結果:一組<key,value>對,這是經過Map操作后所產生的中間結果

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

開發者需編寫兩個主要函數

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

怎么用MapReduce計算一個大型文本文件中各單詞出現次數?分布式數據處理MapReduce

產生背景

編程模型實現機制案例分析MapReduce操作執行流程圖

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

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

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

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

產生背景

編程模型實現機制案例分析假設有一批海量的數據,每個數據都是由26個字母組成的字

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論