第六章-Hadoop优化与发展
第六章-Hadoop優(yōu)化與發(fā)展
文章目錄
- 第六章-Hadoop優(yōu)化與發(fā)展
- Hadoop探討
- HDFS HA
- HDFS Federation
- 資源調(diào)度框架YARN
- MapReduce1.0的缺陷
- YARN設(shè)計(jì)思路
- YARN體系結(jié)構(gòu)
- YARN工作流程
- YARN與MapReduce1.0的對(duì)比
- YARN的發(fā)展目標(biāo)
Hadoop探討
Hadoop1.0 的核心組件（僅指 MapReduce 和 HDFS， 不包括 Hadoop 生態(tài)系統(tǒng)內(nèi)的 Pig、Hive、HBase 等其他組件），主要存在以下不足：
- 抽象層次低，需人工編碼
- 表達(dá)能力有限
- 開(kāi)發(fā)者自己管理作業(yè)（Job）之間的依賴關(guān)系
- 難以看到程序整體邏輯
- 執(zhí)行迭代操作效率低
- 資源浪費(fèi)（Map和Reduce分兩階段執(zhí)行）
- 實(shí)時(shí)性差（適合批處理，不支持實(shí)時(shí)交互式）
Hadoop的優(yōu)化與發(fā)展主要體現(xiàn)在兩個(gè)方面：
- 一方面是 Hadoop 自身兩大核心組件 MapReduce 和 HDFS的架構(gòu)設(shè)計(jì)改進(jìn)
- 另一方面是 Hadoop 生態(tài)系統(tǒng)其它組件的不斷豐富，加入了Pig、Tez、Spark 等新組件
| HDFS | 單一名稱節(jié)點(diǎn)，存在單點(diǎn)失效問(wèn)題 | 設(shè)計(jì)了HDFS HA，提供名稱節(jié)點(diǎn)熱備機(jī)制 |
| HDFS | 單一命名空間，無(wú)法實(shí)現(xiàn)資源隔離 | 設(shè)計(jì)了HDFS Federation，管理多個(gè)命名空間 |
| MapReduce | 資源管理效率低 | 設(shè)計(jì)了新的資源管理框架YARN |
HDFS HA
HDFS 1.0 只存在一個(gè)名稱節(jié)點(diǎn)，一旦這個(gè)唯一的節(jié)點(diǎn)發(fā)生故障，將會(huì)導(dǎo)致整個(gè)集群的不可用，因此存在“單點(diǎn)故障問(wèn)題”。而第二名稱節(jié)點(diǎn)只能起到冷備份的作用，無(wú)法解決單點(diǎn)故障問(wèn)題。
為了解決單點(diǎn)故障問(wèn)題，HDFS 2.0 采用了 HA（High Availability）架構(gòu)。
HA集群中設(shè)置兩個(gè)名稱節(jié)點(diǎn)，分別處于“活躍（Active）”狀態(tài)和“待命（Standby）”狀態(tài)。活躍名稱節(jié)點(diǎn)負(fù)責(zé)對(duì)外處理所有客戶端的請(qǐng)求，而待命名稱節(jié)點(diǎn)作為備用節(jié)點(diǎn)。兩種名稱節(jié)點(diǎn)的狀態(tài)同步，可以借助于一個(gè)共享存儲(chǔ)系統(tǒng)來(lái)實(shí)現(xiàn)。（相當(dāng)于說(shuō)待命名稱節(jié)點(diǎn)提供了“熱備份”的功能）
一旦活躍名稱節(jié)點(diǎn)出現(xiàn)故障，就可以立即切換到待命名稱節(jié)點(diǎn)，不會(huì)影響到系統(tǒng)的正常對(duì)外服務(wù)。Zookeeper確保只有一個(gè)名稱節(jié)點(diǎn)在對(duì)外服務(wù)，不會(huì)出現(xiàn)“兩個(gè)管家”的情況。名稱節(jié)點(diǎn)維護(hù)映射信息，數(shù)據(jù)節(jié)點(diǎn)同時(shí)向兩個(gè)名稱節(jié)點(diǎn)匯報(bào)信息。
HDFS Federation
HDFS 1.0中存在的問(wèn)題：
- 單點(diǎn)故障問(wèn)題
- 不可以水平擴(kuò)展（通過(guò)縱向擴(kuò)展會(huì)帶來(lái)過(guò)長(zhǎng)的系統(tǒng)啟動(dòng)時(shí)間，不可取）
- 系統(tǒng)整體性能受限于單個(gè)名稱節(jié)點(diǎn)的吞吐量
- 單個(gè)名稱節(jié)點(diǎn)難以提供不同程序之間的隔離性
雖然 HDFS HA 是熱備份，提供高可用性，但是其本質(zhì)上還是單名稱節(jié)點(diǎn)，只是解決了單點(diǎn)故障，還是無(wú)法解決可擴(kuò)展性、系統(tǒng)性能和隔離性的問(wèn)題，而 HDFS Federation 可以很好地解決這三個(gè)問(wèn)題。
HDFS Federation的設(shè)計(jì)：
- 在HDFS Federation中，設(shè)計(jì)了多個(gè)相互獨(dú)立的名稱節(jié)點(diǎn)，使得 HDFS 的命名服務(wù)能夠水平擴(kuò)展， 這些名稱節(jié)點(diǎn)分別進(jìn)行各自命名空間和塊的管理，相互之間是聯(lián)盟（Federation）關(guān)系，不需要彼此協(xié)調(diào)。并且向后兼容
- HDFS Federation中，所有名稱節(jié)點(diǎn)會(huì)共享底層的數(shù)據(jù)節(jié)點(diǎn)存儲(chǔ) 資源，數(shù)據(jù)節(jié)點(diǎn)向所有名稱節(jié)點(diǎn)匯報(bào)
- 屬于同一個(gè)命名空間的塊構(gòu)成一個(gè)“塊池”
HDFS Federation設(shè)計(jì)可解決單名稱節(jié)點(diǎn)存在的以下幾個(gè)問(wèn)題：
需要注意的，HDFS Federation并不能解決單點(diǎn)故障問(wèn)題，也就是說(shuō)，每個(gè)名稱節(jié)點(diǎn)都存在在單點(diǎn)故障問(wèn)題，需要為每個(gè)名稱節(jié)點(diǎn)部署一個(gè)后備名稱節(jié)點(diǎn)，以應(yīng)對(duì)名稱節(jié)點(diǎn)故障對(duì)業(yè)務(wù)產(chǎn)生的影響。
資源調(diào)度框架YARN
MapReduce1.0的缺陷
MapReduce 1.0采用 Master/Slaver 架構(gòu)設(shè)計(jì)，包括一個(gè) JobTracer 和若干個(gè) TaskTracer ，前者負(fù)責(zé)作業(yè)的調(diào)度和資源的管理，后者負(fù)責(zé)執(zhí)行 JobTracer 指派的具體任務(wù)。 MapReduce 1.0既是一個(gè)計(jì)算框架，也是一個(gè)資源管理調(diào)度框架。
但是，這樣一種架構(gòu)有一些難以克服的缺陷：
YARN設(shè)計(jì)思路
Hadoop2.0 以后， MapReduce 1.0中的資源 管理調(diào)度功能，被單獨(dú)分離出來(lái)形成了 YARN，它是一個(gè)純粹的資源管理調(diào)度框架，而不是一個(gè)計(jì)算框架。被剝離了資源管理調(diào)度功能的 MapReduce 框架就變成了MapReduce 2.0， 它是運(yùn)行在 YARN 之上的 一個(gè)純粹的計(jì)算框架，不再自己負(fù)責(zé)資源調(diào)度管理服務(wù)，而是由 YARN 為其提供資源管理調(diào)度服務(wù)。
YARN的設(shè)計(jì)思路：把原 JobTracer 的三大功能進(jìn)行拆分，即不讓JobTracer 承擔(dān)過(guò)多的功能，這樣大大降低了 JobTracer 的負(fù)擔(dān)，提升了系統(tǒng)運(yùn)行的效率和穩(wěn)定性。
重新設(shè)計(jì)后得到的 YARN 包括 ResourceManager、ApplicationMater 和 NodeManager。
- ResourceManager 負(fù)責(zé)資源管理
- ApplicationMaster 負(fù)責(zé)任務(wù)調(diào)度和監(jiān)控
- NodeManager 負(fù)責(zé)執(zhí)行原 TaskTracer 的任務(wù)
YARN體系結(jié)構(gòu)
| ResourceManager |
|
| ApplicationMaster |
|
| NodeManager |
|
Resource Manager：
- ResourceManager（RM）是一個(gè)全局的資源管理器，負(fù)責(zé)整個(gè)系統(tǒng)的資源 管理和分配，主要包括兩個(gè)組件，即調(diào)度器（Scheduler）和應(yīng)用程序管理 器（Applications Manager）
- 調(diào)度器接收來(lái)自ApplicationMaster的應(yīng)用程序資源請(qǐng)求，把集群中的資源以 “容器”的形式分配給提出申請(qǐng)的應(yīng)用程序，容器的選擇通常會(huì)考慮應(yīng)用 程序所要處理的數(shù)據(jù)的位置，進(jìn)行就近選擇，從而實(shí)現(xiàn)“計(jì)算向數(shù)據(jù)靠攏”
- 容器（Container）作為動(dòng)態(tài)資源分配單位，每個(gè)容器中都封裝了一定數(shù)量 的CPU、內(nèi)存、磁盤(pán)等資源，從而限定每個(gè)應(yīng)用程序可以使用的資源量
- 調(diào)度器被設(shè)計(jì)成是一個(gè)可插拔的組件，YARN不僅自身提供了許多種直接可 用的調(diào)度器，也允許用戶根據(jù)自己的需求重新設(shè)計(jì)調(diào)度器
- 應(yīng)用程序管理器（Applications Manager）負(fù)責(zé)系統(tǒng)中所有應(yīng)用程序的管理 工作，主要包括應(yīng)用程序提交、與調(diào)度器協(xié)商資源以啟動(dòng)ApplicationMaster、 監(jiān)控ApplicationMaster運(yùn)行狀態(tài)并在失敗時(shí)重新啟動(dòng)等
Application Master：
- ResourceManager接收用戶提交的作業(yè)，按照作業(yè)的上下文信息以及從 NodeManager收集來(lái)的容器狀態(tài)信息，啟動(dòng)調(diào)度過(guò)程，為用戶作業(yè)啟動(dòng)一 個(gè)ApplicationMaster
- ApplicationMaster的主要功能是：
- 當(dāng)用戶作業(yè)提交時(shí)，ApplicationMaster與ResourceManager協(xié)商獲取資源， ResourceManager會(huì)以容器的形式為ApplicationMaster分配資源；
- 把獲得的資源進(jìn)一步分配給內(nèi)部的各個(gè)任務(wù)（Map任務(wù)或Reduce任務(wù)）， 實(shí)現(xiàn)資源的“二次分配”；
- 與NodeManager保持交互通信進(jìn)行應(yīng)用程序的啟動(dòng)、運(yùn)行、監(jiān)控和停止，監(jiān)控申請(qǐng)到的資源的使用情況，對(duì)所有任務(wù)的執(zhí)行進(jìn)度和狀態(tài)進(jìn)行監(jiān)控， 并在任務(wù)發(fā)生失敗時(shí)執(zhí)行失敗恢復(fù)（即重新申請(qǐng)資源重啟任務(wù)）；
- 定時(shí)向ResourceManager發(fā)送“心跳”消息，報(bào)告資源的使用情況和應(yīng)用的進(jìn)度信息；
- 當(dāng)作業(yè)完成時(shí)，ApplicationMaster向ResourceManager注銷容器，執(zhí)行周期完成。
Node Manager：
- NodeManager是駐留在一個(gè)YARN集群中的每個(gè)節(jié)點(diǎn)上的代理，主要負(fù)責(zé)：
- 容器生命周期管理
- 監(jiān)控每個(gè)容器的資源（CPU、內(nèi)存等）使用情況
- 跟蹤節(jié)點(diǎn)健康狀況
- 以“心跳”的方式與ResourceManager保持通信
- 向ResourceManager匯報(bào)作業(yè)的資源使用情況和每個(gè)容器的運(yùn)行狀態(tài)
- 接收來(lái)自ApplicationMaster的啟動(dòng)/停止容器的各種請(qǐng)求
需要說(shuō)明的是，NodeManager主要負(fù)責(zé)管理抽象的容器，只處理與容器相關(guān) 的事情，而不具體負(fù)責(zé)每個(gè)任務(wù)（Map任務(wù)或Reduce任務(wù)）自身狀態(tài)的管理， 因?yàn)檫@些管理工作是由ApplicationMaster完成的，ApplicationMaster會(huì)通過(guò)不 斷與NodeManager通信來(lái)掌握各個(gè)任務(wù)的執(zhí)行狀態(tài)。
在集群部署方面，YARN的各個(gè)組件是和Hadoop集群中的其他組件進(jìn)行統(tǒng)一部署的
YARN工作流程
在 YARN 框架中執(zhí)行一個(gè) MapReduce 程序時(shí)，從提交到完成需要經(jīng)歷 8 個(gè)步驟：
- 步驟1：用戶編寫(xiě)客戶端應(yīng)用程序，向YARN提交應(yīng)用程序
- 步驟2：YARN中的ResourceManager負(fù)責(zé)接收和處理來(lái)自客戶端的請(qǐng)求，為應(yīng)用 程序分配一個(gè)容器，在該容器中啟動(dòng)一個(gè)ApplicationMaster
- 步驟3：ApplicationMaster被創(chuàng)建后會(huì)首 先向ResourceManager注冊(cè)
- 步驟4：ApplicationMaster向 ResourceManager申請(qǐng)資源
- 步驟5：ResourceManager以“容器”的 形式向提出申請(qǐng)的ApplicationMaster分 配資源
- 步驟6：對(duì)資源二次分配，并在容器中 啟動(dòng)任務(wù)
- 步驟7：各個(gè)任務(wù)向ApplicationMaster匯 報(bào)自己的狀態(tài)和進(jìn)度
- 步驟8：應(yīng)用程序運(yùn)行完成后， ApplicationMaster向ResourceManager的 應(yīng)用程序管理器注銷并關(guān)閉自己
YARN與MapReduce1.0的對(duì)比
從MapReduce1.0框架發(fā)展到Y(jié)ARN框架，客戶端并沒(méi)有發(fā)生變 化，其大部分調(diào)用API及接口都保持兼容。
YARN 大大減少了承擔(dān)中心服務(wù)功能的ResourceManager的資源消耗
- ApplicationMaster來(lái)完成需要大量資源消耗的任務(wù)調(diào)度和監(jiān)控
- 多個(gè)作業(yè)對(duì)應(yīng)多個(gè)ApplicationMaster，實(shí)現(xiàn)了監(jiān)控分布化
MapReduce1.0既是一個(gè)計(jì)算框架，又是一個(gè)資源管理調(diào)度框 架，但是，只能支持MapReduce編程模型。而YARN則是一個(gè) 純粹的資源調(diào)度管理框架，在它上面可以運(yùn)行包括 MapReduce在內(nèi)的不同類型的計(jì)算框架，只要編程實(shí)現(xiàn)相應(yīng) 的ApplicationMaster
YARN中的資源管理比MapReduce1.0更加高效，它以容器為單位，而不是以 slot 為單位
YARN的發(fā)展目標(biāo)
YARN的目標(biāo)是實(shí)現(xiàn)“一個(gè)集群多個(gè)框架”
一個(gè)企業(yè)當(dāng)中同時(shí)存在各種不同的業(yè)務(wù)應(yīng)用場(chǎng)景，需要采用不同的計(jì)算框架
- MapReduce實(shí)現(xiàn)離線批處理
- 使用Storm實(shí)現(xiàn)流式數(shù)據(jù)實(shí)時(shí)分析
- 使用Spark實(shí)現(xiàn)迭代計(jì)算
- ······
這些產(chǎn)品通常來(lái)自不同的開(kāi)發(fā)團(tuán)隊(duì)，具有各自的資源調(diào)度管理機(jī)制，為了避免不同類型應(yīng)用之間互相干擾，企業(yè)就需要把內(nèi)部的服務(wù)器拆分成多個(gè)集群，分別安裝運(yùn)行不同的計(jì)算框架，即“一個(gè)框架一個(gè)集群”
- 集群資源利用率低
- 數(shù)據(jù)無(wú)法共享
- 維護(hù)代價(jià)高
YARN的目標(biāo)就是實(shí)現(xiàn)“一個(gè)集群多個(gè)框架”，即在一個(gè)集群上部署一個(gè)統(tǒng)一的資源調(diào)度管理框架YARN，在YARN之上可以部署其他各種計(jì)算框架。
由YARN為這些計(jì)算框架提供統(tǒng)一的資源調(diào)度管理服務(wù)，并且能夠根據(jù)各種 計(jì)算框架的負(fù)載需求，調(diào)整各自占用的資源，實(shí)現(xiàn)集群資源共享和資源彈性收縮。可以實(shí)現(xiàn)一個(gè)集群上的不同應(yīng)用負(fù)載混搭，有效提高了集群的利用率。不同計(jì)算框架可以共享底層存儲(chǔ)，避免了數(shù)據(jù)集跨集群移動(dòng)。
總結(jié)
以上是生活随笔為你收集整理的第六章-Hadoop优化与发展的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 使用IDEA在SpringBoot项目中
- 下一篇： 第七章-NoSQL数据库