9.1 Hadoop的優(yōu)化與發(fā)展

9.1.1 Hadoop1.0的局限與不足

（1）抽象層次低：簡單任務(wù)也要很復(fù)雜的編碼；
（2）表達(dá)能力優(yōu)先：不是所有的任務(wù)都能抽象成Map和Reduce
（3）需開發(fā)者自行管理Job間依賴關(guān)系
（4）難以看到程序的整體邏輯：可以理解為沒有主流程，只有一個(gè)個(gè)的MR程序組合起來
（5）執(zhí)行迭代操作時(shí)效率低：每次MR后都寫入磁盤，供下一次MR使用密任，這對機(jī)器學(xué)習(xí)等而言效率很低
（6）資源浪費(fèi)：M和R是嚴(yán)格分先后順序的
（7）實(shí)時(shí)性很差，只能離線批處理

9.1.2 主要的優(yōu)化和發(fā)展

（1）對M和R兩個(gè)核心組件的改進(jìn)
HDFS改進(jìn)：① 設(shè)計(jì)了HDFS HA纲菌，實(shí)現(xiàn)對名稱節(jié)點(diǎn)的熱備份贾陷，② HDFS聯(lián)邦
（2）新增了很多其它組件
① Pig - 抽象層次高，使用腳本語言處理大規(guī)模數(shù)據(jù)
② Spark - 基于內(nèi)存的分布式并行編程框架卿堂，較高實(shí)時(shí)性
③ Oozie - 工作流和協(xié)作服務(wù)引擎
④ Tez - 支持DAG作業(yè)的計(jì)算框架束莫，減少重復(fù)操作
⑤ Kafka - 銜接不同類型的分布式系統(tǒng)

9.2 HDFS2.0新特性

9.2.0 HDFS1.0的問題

1）單點(diǎn)故障問題
2）不可以水平擴(kuò)展，縱向擴(kuò)展會導(dǎo)致啟動耗時(shí)激增
3）系統(tǒng)整體整體性能受限于單個(gè)名稱節(jié)點(diǎn)的吞吐量
4）不同程序間不可以隔離

9.2.1 HDFS HA

解決單點(diǎn)故障問題：設(shè)置兩個(gè)名稱節(jié)點(diǎn)草描，一個(gè)活躍览绿，一個(gè)待命，兩者通過共享存儲系統(tǒng)實(shí)現(xiàn)實(shí)時(shí)的狀態(tài)同步穗慕，由Zookeeper確保任意時(shí)刻只有一個(gè)名稱節(jié)點(diǎn)對外服務(wù)饿敲。

9.2.2 HDFS Federation

解決9.2.0中后幾個(gè)問題：設(shè)置了多個(gè)相互獨(dú)立的名稱節(jié)點(diǎn)，共享底層的存儲資源揍诽，數(shù)據(jù)節(jié)點(diǎn)向所有名稱節(jié)點(diǎn)匯報(bào)诀蓉，不同的名稱節(jié)點(diǎn)管理不同業(yè)務(wù)數(shù)據(jù)栗竖，實(shí)現(xiàn)程序隔離暑脆。

9.3 新一代資源管理調(diào)度框架 - YARN

9.3.1 MR1.0的缺陷

1）單點(diǎn)故障，一個(gè)JobTracker負(fù)責(zé)所有MR作業(yè)的調(diào)度
2）任務(wù)過重：一個(gè)JoTracker既要管資源的管理分配狐肢，又要管作業(yè)調(diào)度和失敗恢復(fù)等添吗，進(jìn)而導(dǎo)致內(nèi)存開銷過大和易出故障
3）容易內(nèi)存溢出：TaskTracker端資源的分配僅根據(jù)MR任務(wù)的個(gè)數(shù)，而不管每個(gè)任務(wù)實(shí)際消耗的CPU和內(nèi)存資源
4）資源劃分不合理：CPU和內(nèi)存都被劃分為slot份名，slot又被進(jìn)一步劃分為M槽和R槽碟联，互相不使用對方的槽妓美，而同一個(gè)程序的M和R是串行的，所以容易導(dǎo)致資源浪費(fèi)鲤孵。

9.3.2 YARN設(shè)計(jì)思路

把JobTracker的資源管理壶栋、任務(wù)調(diào)度、任務(wù)監(jiān)控三個(gè)任務(wù)拆分出來普监，由YARN的不同模塊（ResourdeManager和ApplicationMaster）去負(fù)責(zé)贵试，原TaskTracker改為NodeManager。
注意：YARN是一個(gè)純粹的資源調(diào)度框架凯正，而MR2.0則是一個(gè)運(yùn)行在YARN之上的純粹的計(jì)算框架毙玻。

9.3.3 YARN體系結(jié)構(gòu)

YARN體系結(jié)構(gòu)

9.3.4 YARN工作流程

1）用戶準(zhǔn)備好AppMaster程序、啟動AppMaster的命令沥潭、用戶程序邀泉，三個(gè)東西，并提交給YARN
2）ResourceManager接收到請求，為應(yīng)用程序分配一個(gè)容器汇恤，并在容器里啟動一個(gè)AppMaster
具體流程看教材P163庞钢，如圖所示。

YARN的工作流程

9.3.5~6 YARN框架的補(bǔ)充

YARN不僅可以為MR計(jì)算框架提供資源調(diào)度服務(wù)因谎，也可以為Spark基括、Storm等跨框架服務(wù)。事實(shí)上财岔，這也是YARN的發(fā)展目標(biāo)阱穗，發(fā)展成為集群統(tǒng)一的資源管理調(diào)度框架，上面可以部署各式各樣的的計(jì)算框架使鹅，包括MR揪阶、Tez、HBase患朱、Storm鲁僚、Giraph、Spark裁厅、等等冰沙。

YARN之上，部署各種計(jì)算框架

9.4 Hadoop生態(tài)中的代表性組件

9.4.1 Pig

1）類SQL語言的Pig Latin語言执虹，支持過濾拓挥、分組、連接袋励、排序等類SQL操作侥啤；
2）把Pig腳本轉(zhuǎn)化成MR作業(yè)，且可以自動優(yōu)化茬故，因此不需要考慮代碼效率問題盖灸；
3）基本格式
① 通過LOAD語句從文件系統(tǒng)中讀取數(shù)據(jù)
② 一系列ETL語句進(jìn)行數(shù)據(jù)處理
③ 通過STORE把處理結(jié)果輸出到文件系統(tǒng)中

9.4.2 Tez

1）支持DAG作業(yè)的計(jì)算框架
2）把Map和Reduce進(jìn)一步拆分成更細(xì)的作業(yè)，包括輸入磺芭、處理赁炎、排序、合并钾腺、輸出等
3）在更細(xì)顆粒度的設(shè)計(jì)下徙垫，任務(wù)可以被轉(zhuǎn)換成一個(gè)有向無環(huán)圖，避免了重復(fù)的M或R操作放棒。經(jīng)過Tez優(yōu)化后的Hive性能可以提升100倍姻报。
4）在Hadoop生態(tài)中的位置：MR、Pig哨查、Hive等框架的任務(wù)最終都被轉(zhuǎn)換成MR任務(wù)執(zhí)行逗抑，而Tez相當(dāng)于對MR進(jìn)行了優(yōu)化，因此可以把MR寒亥、Pig邮府、Hive運(yùn)行于Tez之上，而把Tez運(yùn)行于YARN之上溉奕，把YARN運(yùn)行于HDFS之上褂傀。
5）于Impala的區(qū)別：Impala拋棄了MR框架，采用與商用并行關(guān)系數(shù)據(jù)庫類似的分布式查詢引擎加勤，效率更高仙辟，但是能處理的數(shù)據(jù)類型有限。

9.4.3 Spark

1）與MR相比鳄梅，每次計(jì)算把結(jié)果放到內(nèi)存中（而非放到磁盤中）
2）同樣采用DAG任務(wù)調(diào)度機(jī)制叠国，可以有效避免重復(fù)操作
上述兩點(diǎn)改進(jìn)，加之以結(jié)構(gòu)一體化戴尸、功能多元化的優(yōu)勢粟焊，使得Spark逐漸成為當(dāng)今大數(shù)據(jù)領(lǐng)域最熱門的計(jì)算平臺。

9.4.5 Kafka

1）高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)
2）同時(shí)滿足在線實(shí)時(shí)處理和批量離線處理
3）充當(dāng)數(shù)據(jù)樞紐的作用孙蒙，實(shí)現(xiàn)和Hadoop各個(gè)組件之間的不同類型的數(shù)據(jù)的實(shí)時(shí)高效交換项棠。
如下圖

Kafka充當(dāng)數(shù)據(jù)交換樞紐