Hadoop架構(gòu)分析

1、S201407031 尹鵬飛Hadoop架構(gòu)分析北京工業(yè)大學(xué)計(jì)算機(jī)學(xué)院 S201407138 李 娟目標(biāo) 熟悉分布式系統(tǒng)、Hadoop的背景知識(shí) 理解Hadoop的應(yīng)用場(chǎng)景 理解HDFS系統(tǒng)結(jié)構(gòu) 理解 MapReduce 編程模型 理解Hadoop生態(tài)系統(tǒng)結(jié)構(gòu) 分析Hadoop架構(gòu)的優(yōu)缺點(diǎn)背景：云時(shí)代的變革應(yīng)用的挑戰(zhàn) 海量數(shù)據(jù) 成本 成本應(yīng)用的挑戰(zhàn)分布式解決方案？變革 分布式編程已成為必備的技能 編程的對(duì)象：?jiǎn)螜C(jī)vs集群？ 全新的系統(tǒng)棧 存儲(chǔ) 調(diào)度 計(jì)算 什么是Hadoop?Hadoop是一個(gè)開(kāi)源的、可靠的、可擴(kuò)展的分布式并行計(jì)算框架主要組成：分布式文件系統(tǒng)HDFS和MapReduce算法執(zhí)行

2、作者：Doug Cutting語(yǔ)言：Java，支持多種編程語(yǔ)言，如：Python、C+名稱(chēng)起源： Doug Cutting兒子的黃色大象玩具的名字揭開(kāi)面紗Hadoop應(yīng)用場(chǎng)景:電信運(yùn)營(yíng)商信令分析與監(jiān)測(cè)生物工程股票預(yù)測(cè)Hadoop的思想一百個(gè)Loser Vs 一個(gè)高富帥Hadoop的思想之源：的思想之源：Google Google搜索引擎，Gmail，安卓，AppspotGoogle Maps，Google earth，Google學(xué)術(shù)，Google翻譯，Google+，下一步Google what？倒排索引倒排索引Google面對(duì)的數(shù)據(jù)和計(jì)算難題面對(duì)的數(shù)據(jù)和計(jì)算難題 大量的網(wǎng)頁(yè)怎么存儲(chǔ)？ 搜索

3、算法 Page-Rank 計(jì)算問(wèn)題 兩大問(wèn)題:1.分布式的文件存儲(chǔ)2.分布式數(shù)據(jù)計(jì)算Hadoop提供了解決方案:1. HDFS分布式文件存儲(chǔ)系統(tǒng)2. MapReduce分布式計(jì)算模型HDFS分布式文件存儲(chǔ)系統(tǒng)Hadoop HDFS HDFS特性 大容量 高容錯(cuò)性 高吞吐量 HDFS數(shù)據(jù)模型 包 塊 文件HDFS系統(tǒng)架構(gòu)圖NameNodeDatanodes機(jī)架另一個(gè)機(jī)架DFSClient讀操作寫(xiě)操作塊操作Datanodes元數(shù)據(jù)操作DFSClientSecondaryNameNode Metadata(Name, replicas.) (/home/foo/data,6. .同步元數(shù)據(jù)和日志HD

4、FS 架構(gòu) NameNode Namenode 是一個(gè)中心服務(wù)器，單一節(jié)點(diǎn)（簡(jiǎn)化系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)），負(fù)責(zé)管理文件系統(tǒng)的名字空間(namespace)以及客戶(hù)端對(duì)文件的訪問(wèn)。 文件操作，NameNode 負(fù)責(zé)文件元數(shù)據(jù)的操作，DataNode負(fù)責(zé)處理文件內(nèi)容的讀寫(xiě)請(qǐng)求，跟文件內(nèi)容相關(guān)的數(shù)據(jù)流不經(jīng)過(guò)NameNode，只會(huì)詢(xún)問(wèn)它跟那個(gè)DataNode聯(lián)系，否則NameNode會(huì)成為系統(tǒng)的瓶頸。HDFS 架構(gòu) NameNode 副本存放在哪些DataNode上由 NameNode來(lái)控制，根據(jù)全局情況做出塊放置決定，讀取文件時(shí)NameNode盡量讓用戶(hù)先讀取最近的副本，降低帶塊消耗和讀取時(shí)延。 Name

5、node 全權(quán)管理數(shù)據(jù)塊的復(fù)制，它周期性地從集群中的每個(gè)Datanode接收心跳信號(hào)和塊狀態(tài)報(bào)告(Blockreport)。接收到心跳信號(hào)意味著該Datanode節(jié)點(diǎn)工作正常。塊狀態(tài)報(bào)告包含了一個(gè)該Datanode上所有數(shù)據(jù)塊的列表。HDFS 架構(gòu) DataNode一個(gè)數(shù)據(jù)塊在DataNode以文件存儲(chǔ)在磁盤(pán)上，包括兩個(gè)文件，一 個(gè)是數(shù)據(jù)本身，一個(gè)是元數(shù)據(jù)包括數(shù)據(jù)塊的長(zhǎng)度，塊數(shù)據(jù)的校驗(yàn)和，以及時(shí)間戳。DataNode啟動(dòng)后向NameNode注冊(cè)，通過(guò)后，周期性（1小時(shí)）的向NameNode上報(bào)所有的塊信息。心跳是每3秒一次，心跳返回結(jié)果帶有NameNode給該DataNode的命令如復(fù)制塊數(shù)據(jù)

6、到另一臺(tái)機(jī)器，或刪除某個(gè)數(shù)據(jù)塊。如果超過(guò)10分鐘沒(méi)有收到某DataNode 的心跳，則認(rèn)為該節(jié)點(diǎn)不可用。集群運(yùn)行中可以安全加入和退出一些機(jī)器 HDFS 架構(gòu) 保障可靠性的措施 一個(gè)名字節(jié)點(diǎn)和多個(gè)數(shù)據(jù)節(jié)點(diǎn) 數(shù)據(jù)復(fù)制（冗余機(jī)制） 存放的位置（機(jī)架感知策略） 故障檢測(cè) 數(shù)據(jù)節(jié)點(diǎn) 心跳包（檢測(cè)是否宕機(jī)） 塊報(bào)告（安全模式下檢測(cè)） 數(shù)據(jù)完整性檢測(cè)（校驗(yàn)和比較） 名字節(jié)點(diǎn)（日志文件，鏡像文件）HDFS 架構(gòu) 保障可靠性的措施HDFS通訊結(jié)構(gòu)圖11讀取文件寫(xiě)入文件fsimagefsimage包含文件的目錄結(jié)構(gòu)和分塊信息，而數(shù)據(jù)塊的位置信息則是通過(guò)動(dòng)態(tài)匯總過(guò)來(lái)的，僅僅存活在內(nèi)存數(shù)據(jù)結(jié)構(gòu)中，每一個(gè)TaskTra

7、cker啟動(dòng)后，都會(huì)向NameNode發(fā)送注冊(cè)消息，將其上數(shù)據(jù)塊的狀況都告知于NameNode。主從式結(jié)構(gòu)對(duì)等式結(jié)構(gòu)兩種結(jié)構(gòu)相結(jié)合哎呀！需要人工干預(yù)宕機(jī)期間整個(gè)集群都沒(méi)反應(yīng)！Secondary NameNode可以代替NameNode但可能會(huì)導(dǎo)致部分Editlog的丟失，無(wú)法100%恢復(fù)HDFS故障恢復(fù) DFSClient 崩潰？ 租約：當(dāng)客戶(hù)端需要占用某個(gè)文件時(shí)，與NameNode簽訂的一個(gè)短期合同 超過(guò)期限沒(méi)有續(xù)約，則終止租約，避免資源被長(zhǎng)期霸占 DataNode 崩潰? 客戶(hù)端讀取另外一個(gè)副本 后臺(tái)負(fù)責(zé)副本的均衡和復(fù)制 NameNode 崩潰?Hadoop也是一個(gè)能夠分布式處理大規(guī)模海量

8、數(shù)據(jù)的軟件框架，這一切都是在可靠、高效、可擴(kuò)展的基礎(chǔ)上。Hadoop的可靠性因?yàn)镠adoop假設(shè)計(jì)算元素和存儲(chǔ)會(huì)出現(xiàn)故障，因?yàn)樗S護(hù)多個(gè)工作數(shù)據(jù)副本，在出現(xiàn)故障時(shí)可以對(duì)失敗的節(jié)點(diǎn)重新分布處理。Hadoop的高效性在MapReduce的思想下，Hadoop是并行工作的，以加快任務(wù)處理速度。Hadoop的可擴(kuò)展依賴(lài)于部署Hadoop軟件框架計(jì)算集群的規(guī)模，Hadoop的運(yùn)算是可擴(kuò)展的，具有處理PB級(jí)數(shù)據(jù)的能力。MapReduce分布式計(jì)算模型什么是MapReduce編程模型 Map(映射)：對(duì)一些獨(dú)立元素組成的列表的每一個(gè)元素進(jìn)行指定的操作，可以高度并行。 Reduce(化簡(jiǎn))：對(duì)一個(gè)列表的元素進(jìn)

9、行合并。 一個(gè)簡(jiǎn)單的MapReduce程序只需要指定map()、reduce()、輸入和輸出，剩下的事由框架幫你搞定。MapReduce編程模型 中間數(shù)據(jù)結(jié)構(gòu)：對(duì) map (in_key, in_value) - list(out_key, intermediate_value) reduce (out_key, list(intermediate_value) - list(out_value) 設(shè)計(jì)MapReduce算法的核心概念 MapReduce：一種通用解決方案：一種通用解決方案它主要有以下4個(gè)部分組成：1）Client2）JobTracker JobTracke負(fù)責(zé)資源監(jiān)控和作業(yè)調(diào)

10、度。JobTracker 監(jiān)控所有TaskTracker 與job的健康狀況，一旦發(fā)現(xiàn)失敗，就將相應(yīng)的任務(wù)轉(zhuǎn)移到其他節(jié)點(diǎn)；同時(shí)，JobTracker 會(huì)跟蹤任務(wù)的執(zhí)行進(jìn)度、資源使用量等信息，并將這些信息告訴任務(wù)調(diào)度器，而調(diào)度器會(huì)在資源出現(xiàn)空閑時(shí)，選擇合適的任務(wù)使用這些資源。在Hadoop 中，任務(wù)調(diào)度器是一個(gè)可插拔的模塊，用戶(hù)可以根據(jù)自己的需要設(shè)計(jì)相應(yīng)的調(diào)度器。3）TaskTrackerTaskTracker 會(huì)周期性地通過(guò)Heartbeat 將本節(jié)點(diǎn)上資源的使用情況和任務(wù)的運(yùn)行進(jìn)度匯報(bào)給JobTracker，同時(shí)接收J(rèn)obTracker 發(fā)送過(guò)來(lái)的命令并執(zhí)行相應(yīng)的操作（如啟動(dòng)新任務(wù)、殺死任務(wù)

11、等）。TaskTracker 使用“slot”等量劃分本節(jié)點(diǎn)上的資源量?！皊lot”代表計(jì)算資源（CPU、內(nèi)存等）。一個(gè)Task 獲取到一個(gè)slot 后才有機(jī)會(huì)運(yùn)行，而Hadoop 調(diào)度器的作用就是將各個(gè)TaskTracker 上的空閑slot 分配給Task 使用。slot 分為Map slot 和Reduce slot 兩種，分別供MapTask 和Reduce Task 使用。TaskTracker 通過(guò)slot 數(shù)目（可配置參數(shù)）限定Task 的并發(fā)度。4）TaskTask 分為Map Task 和Reduce Task 兩種，均由TaskTracker 啟動(dòng)。 HDFS 以固定大小的

12、block 為基本單位存儲(chǔ)數(shù)據(jù)，而對(duì)于MapReduce 而言，其處理單位是split。split 是一個(gè)邏輯概念，它只包含一些元數(shù)據(jù)信息，比如數(shù)據(jù)起始位置、數(shù)據(jù)長(zhǎng)度、數(shù)據(jù)所在節(jié)點(diǎn)等。它的劃分方法完全由用戶(hù)自己決定。但需要注意的是，split 的多少?zèng)Q定了Map Task 的數(shù)目，因?yàn)槊總€(gè)split 只會(huì)交給一個(gè)Map Task 處理。Split 和 Block的關(guān)系如下圖所示：Map Task 執(zhí)行過(guò)程如下圖 所示。由該圖可知，Map Task 先將對(duì)應(yīng)的split 迭代解析成一個(gè)個(gè)key/value 對(duì)，依次調(diào)用用戶(hù)自定義的map() 函數(shù)進(jìn)行處理，最終將臨時(shí)結(jié)果存放到本地磁盤(pán)上，其中臨時(shí)

13、數(shù)據(jù)被分成若干個(gè)partition，每個(gè)partition 將被一個(gè)Reduce Task 處理。Reduce Task 執(zhí)行過(guò)程下圖所示。該過(guò)程分為三個(gè)階段：從遠(yuǎn)程節(jié)點(diǎn)上讀取MapTask 中間結(jié)果（稱(chēng)為“Shuffle 階段”）；按照key 對(duì)key/value 對(duì)進(jìn)行排序（稱(chēng)為“Sort 階段”）；依次讀取，調(diào)用用戶(hù)自定義的reduce() 函數(shù)處理，并將最終結(jié)果存到HDFS 上（稱(chēng)為“Reduce 階段”）。MapReduce流程圖MapReduce通訊圖只有一個(gè)reduce task的數(shù)據(jù)流圖有N個(gè)reduce task的數(shù)據(jù)流圖可以只有map task，沒(méi)有reduce taskM

14、apReduce故障恢復(fù) Client崩潰？ 掛了就掛了，無(wú)傷大雅 Task失敗 本機(jī)重試 向JobTracker報(bào)告錯(cuò)誤 在別的TaskTracker中重試 TaskTracker 崩潰? 由JobTracker將其任務(wù)移交給別的TaskTracker JobTracker 崩潰? 哎呀！需要人工干預(yù) 正在運(yùn)行的Job需要重新執(zhí)行離線(xiàn)計(jì)算框架MapReduce 將計(jì)算過(guò)程分為兩個(gè)階段，Map和ReduceMap 階段并行處理輸入數(shù)據(jù)Reduce階段對(duì)Map結(jié)果進(jìn)行匯總 Shuffle連接Map和Reduce兩個(gè)階段Map Task將數(shù)據(jù)寫(xiě)到本地磁盤(pán)Reduce Task從每個(gè)Map Task

15、上讀取一份數(shù)據(jù) 僅適合離線(xiàn)批處理具有很好的容錯(cuò)性和擴(kuò)展性適合簡(jiǎn)單的批處理任務(wù) 缺點(diǎn)明顯啟動(dòng)開(kāi)銷(xiāo)大、過(guò)多使用磁盤(pán)導(dǎo)致效率低下等Hadoop整體系統(tǒng)架構(gòu)Hadoop 新 MapReduce 框架 YarnHadoop YARN產(chǎn)生背景 直接源于MRv1在幾個(gè)方面的缺陷 擴(kuò)展性受限 單點(diǎn)故障 難以支持MR之外的計(jì)算 多計(jì)算框架各自為戰(zhàn)，數(shù)據(jù)共享困難 MR：離線(xiàn)計(jì)算框架 Storm：實(shí)時(shí)計(jì)算框架 Spark：內(nèi)存計(jì)算框架Hadoop 1.0和2.0 Hadoop 2.0由HDFS、MapReduce和YARN三個(gè)分支構(gòu)成； HDFS：NN Federation、HA； MapReduce：運(yùn)行在YAR

16、N上的MR； YARN：資源管理系統(tǒng)Hadoop YARN基本架構(gòu)Hadoop YARN運(yùn)行流程分析對(duì)比Yarn 框架相對(duì)于老的 MapReduce 框架什么優(yōu)勢(shì)呢？我們可以看到：1.這個(gè)設(shè)計(jì)大大減小了 JobTracker（也就是現(xiàn)在的 ResourceManager）的資源消耗，并且讓監(jiān)測(cè)每一個(gè) Job 子任務(wù) (tasks) 狀態(tài)的程序分布式化了，更安全、更優(yōu)美。2.在新的 Yarn 中，ApplicationMaster 是一個(gè)可變更的部分，用戶(hù)可以對(duì)不同的編程模型寫(xiě)自己的 AppMst，讓更多類(lèi)型的編程模型能夠跑在 Hadoop 集群中，可以參考 hadoop Yarn 官方配置模板中的 mapred-site.xml 配置。3.對(duì)于資源的表示以?xún)?nèi)存為單位 ( 在目前版本的 Yarn 中，沒(méi)有考慮 cpu 的占用 )，比之前以剩余 slot 數(shù)目更合理。4.老的框架中，JobTracker 一個(gè)很大的負(fù)擔(dān)就是監(jiān)控 job 下的 tasks 的運(yùn)行狀況，現(xiàn)在，這個(gè)部分就扔給 ApplicationMaster 做了，而 ResourceManager 中有一個(gè)模塊叫做 ApplicationsMasters( 注意不是 ApplicationMaster)，它是監(jiān)測(cè) ApplicationMas