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