大數(shù)據(jù)分析師培訓(xùn)教程-2.1 Hadoop入門-Hadoop 1.0 的局限與 Hadoop 2.0（YARN）的革新

Hadoop簡介

Apache Hadoop是存儲(chǔ)和處理大數(shù)據(jù)的開源軟件框架 Hadoop項(xiàng)目

Hadoop能夠在上千臺(tái)機(jī)器組成的集群上運(yùn)行大規(guī)模集群的可靠性，不能僅僅靠硬件來保證，因?yàn)楣?jié)點(diǎn)的失敗、網(wǎng)絡(luò)的失敗等狀況不可避免，為了能夠在大規(guī)模集群上順利運(yùn)行，Hadoop的所有模塊，其設(shè)計(jì)原則基于這樣的基本假設(shè)，即**硬件的失敗在所難免，每個(gè)節(jié)點(diǎn)都沒有那么可靠，可能發(fā)生節(jié)點(diǎn)失敗狀況，軟件框架應(yīng)該能夠自動(dòng)檢測和處理這些失敗情況。 Hadoop通過軟件，在大規(guī)模集群上提供高度的可用性(High Availability)

Hadoop 的生態(tài)系統(tǒng)

1. Hive是Hadoop平臺(tái)上的數(shù)據(jù)倉庫，用于對數(shù)據(jù)進(jìn)行離線分析。它提供了一種類 似于SQL的查詢語言HQL (Hive Query Language)。Hive將SQL轉(zhuǎn)化為 MapReduce作業(yè)(Job)在Hadoop上執(zhí)行。

2. HBase是Google Big Table在Hadoop平臺(tái)上的開源實(shí)現(xiàn)。它是一個(gè)針對結(jié)構(gòu)化數(shù) 據(jù)處理的、面向列分組(Column Family)的、可伸縮的、高度可靠的、高性能的分 布式數(shù)據(jù)庫。一般用于數(shù)據(jù)服務(wù)(Data Serving)應(yīng)用場合。

3. Pig實(shí)現(xiàn)了數(shù)據(jù)查詢腳本語言Pig Latin。用Pig Latin腳本語言編寫的應(yīng)用程序，翻 譯為MapReduce作業(yè)，在Hadoop上運(yùn)行

4. Flume是一個(gè)可擴(kuò)展的、高度可靠的、高可用的分布式海量日志收集系統(tǒng)，一般 用于把眾多服務(wù)器上的大量日志，聚合到某一個(gè)數(shù)據(jù)中心。Flume提供對日志數(shù) 據(jù)進(jìn)行簡單處理的能力，比如過濾、格式轉(zhuǎn)換等。同時(shí)，F(xiàn)lume可以將日志寫往 各種目標(biāo)(本地文件、分布式文件系統(tǒng))。

5. Sqoop是SQL to Hadoop的縮寫，主要用于在關(guān)系數(shù)據(jù)庫或者其它結(jié)構(gòu)化數(shù)據(jù)源 和Hadoop之間交換數(shù)據(jù)

6. Mahout是Hadoop平臺(tái)上的機(jī)器學(xué)習(xí)軟件包，它的主要目標(biāo)是實(shí)現(xiàn)高度可擴(kuò)展的 機(jī)器學(xué)習(xí)算法，以便幫助開發(fā)人員利用大數(shù)據(jù)進(jìn)行機(jī)器學(xué)習(xí)模型訓(xùn)練。Mahout現(xiàn) 在已經(jīng)包含聚類、分類、推薦引擎(協(xié)同過濾)、頻繁集挖掘等經(jīng)典數(shù)據(jù)挖掘和機(jī) 器學(xué)習(xí)算法。

7. Oozie是一個(gè)工作流調(diào)度器(Scheduler)。Oozie協(xié)調(diào)運(yùn)行的作業(yè)，屬于一次性非 循環(huán)的作業(yè)，比如MapReduce作業(yè)、Pig腳本、Hive查詢、Sqoop數(shù)據(jù)導(dǎo)入/導(dǎo)出 作業(yè)等。Oozie基于時(shí)間、和數(shù)據(jù)可用性進(jìn)行作業(yè)調(diào)度，根據(jù)作業(yè)間的依賴關(guān) 系，協(xié)調(diào)作業(yè)的運(yùn)行

8. Zookeeper是模仿Google公司的Chubby系統(tǒng)的開源實(shí)現(xiàn)，Chubby是一個(gè)分布式 的鎖(Lock)服務(wù)

HDFS 的原理及其讀寫過程

原理:

1. HDFS，是一個(gè)分布式的、高度可擴(kuò)展的文件系統(tǒng)。
2. 一個(gè)HDFS集群，一般由一個(gè)NameNode和若干DataNode組成，分別負(fù)責(zé)元信息 的管理和數(shù)據(jù)塊的管理 . HDFS支持TB級(jí)甚至PB級(jí)大小文件的存儲(chǔ);
3. 它把文件劃分成數(shù)據(jù)塊(Block)，分布到多臺(tái)機(jī)器上進(jìn)行存儲(chǔ);
4. 為了保證系統(tǒng)的可靠性，HDFS把數(shù)據(jù)塊在多個(gè)節(jié)點(diǎn)上進(jìn)行復(fù)制(Replicate)
5. 采用心跳機(jī)制確認(rèn)節(jié)點(diǎn)可用:
6. DataNode默認(rèn)每秒像NameNode匯報(bào)一次，向NameNode匯報(bào)狀態(tài)信息，并且返 回NameNode對DataNode的操作命令
7. 如果某一時(shí)刻DataNode不匯報(bào)，可能宕機(jī) . NameNode超過十分鐘沒有收到DataNode的心跳，則認(rèn)為該節(jié)點(diǎn)不可用 寫文件
8. 客戶端通過Distributed FileSystem模塊向NameNode請求上傳文件，NameNode檢 查目標(biāo)文件是否已存在，父目錄是否存在。
9. NameNode返回是否可以上傳。 . 客戶端請求第一個(gè) Block上傳到哪幾個(gè)DataNode服務(wù)器上。
10. NameNode返回個(gè)DataNode節(jié)點(diǎn)，分別為DataNode1、DataNode2、DataNode。 5. 客戶端通過FSDataOutputStream模塊請求DataNode1上傳數(shù)據(jù)，DataNode1收到 請求會(huì)繼續(xù)調(diào)用DataNode2，然后DataNode2調(diào)用DataNode，將這個(gè)通信管道建立 完成。
11. DataNode1、DataNode2、DataNode逐級(jí)應(yīng)答客戶端。
12. 客戶端開始往DataNode1上傳第一個(gè)Block(先從磁盤讀取數(shù)據(jù)放到一個(gè)本地內(nèi)存 緩存)，以Packet為單位，DataNode1收到一個(gè)Packet就會(huì)傳給DataNode2， DataNode2傳給DataNode;DataNode1每傳一個(gè)packet會(huì)放入一個(gè)應(yīng)答隊(duì)列等待應(yīng) 答。
13. 當(dāng)一個(gè)Block傳輸完成之后，客戶端再次請求NameNode上傳第二個(gè)Block的服務(wù) 器。(重復(fù)執(zhí)行-7步)。

讀文件

1. 客戶端通過DistributedFileSystem向NameNode請求下載文件，NameNode通過 查詢元數(shù)據(jù)，找到文件塊所在的DataNode地址。
2. 挑選一臺(tái)DataNode(就近原則，然后隨機(jī))服務(wù)器，請求讀取數(shù)據(jù)。 . DataNode開始傳輸數(shù)據(jù)給客戶端(從磁盤里面讀取數(shù)據(jù)輸入流，以Packet為單 位來做校驗(yàn))。
3. 客戶端以Packet為單位接收，先在本地緩存，然后寫入目標(biāo)文件。

Hadoop 1.0 的局限與 Hadoop 2.0(YARN)的原理是什么?

在大數(shù)據(jù)處理的領(lǐng)域中，Hadoop 可謂是一位 “重量級(jí)選手”。然而，就像任何技術(shù)一樣，Hadoop 1.0 也有它的不足之處。

Hadoop 1.0 存在著明顯的單點(diǎn)故障問題。這就好比一個(gè)團(tuán)隊(duì)中，如果關(guān)鍵人物出了問題，整個(gè)團(tuán)隊(duì)的運(yùn)作可能就會(huì)陷入混亂。在 Hadoop 1.0 中，一旦 NameNode 這個(gè)關(guān)鍵節(jié)點(diǎn)出現(xiàn)故障，整個(gè)系統(tǒng)就可能面臨崩潰的風(fēng)險(xiǎn)。

而且，它的資源管理方式也不夠靈活。就好像分配房間，如果只有一種固定的分配方式，很難滿足各種不同的需求。

不過，技術(shù)總是在不斷進(jìn)步的。Hadoop 2.0（YARN）的出現(xiàn)，給我們帶來了新的希望。

YARN 的原理就像是一個(gè)更聰明的 “管家”。它把資源管理和任務(wù)調(diào)度分開了。ResourceManager 就像是大管家，負(fù)責(zé)整體資源的分配和監(jiān)控。而 ApplicationMaster 則像是每個(gè)任務(wù)的小管家，專門負(fù)責(zé)自己任務(wù)的資源申請和調(diào)度。

這種分離的方式，讓系統(tǒng)的擴(kuò)展性大大增強(qiáng)。就好比原來的房子不夠住了，現(xiàn)在可以很方便地加蓋新的房間，而不會(huì)影響原來的居住者。

同時(shí)，容錯(cuò)性也得到了提高。即使某個(gè) “小管家” 出了問題，也不會(huì)讓整個(gè) “家” 亂了套。

資源利用率也因?yàn)檫@種更精細(xì)的管理而得到了提升，不再有資源浪費(fèi)或者分配不均的情況。

Hadoop 1.0 的局限

1. 它僅僅支持一種計(jì)算模型，即MapReduce。MapReduce計(jì)算模型的表達(dá)能力有 限，尤其是復(fù)雜的數(shù)據(jù)處理任務(wù)
2. MapReduce作業(yè)通過磁盤進(jìn)行數(shù)據(jù)交換，效率低下，影響了查詢的執(zhí)行效率。
3. Hadoop 1.0的任務(wù)調(diào)度方法，遠(yuǎn)未達(dá)到優(yōu)化資源利用率的效果。

Hadoop 2.0(YARN)的原理

YARN(Yet Another Resource Negotiator)

1. 在新的架構(gòu)里，包含ResourceManager和NodeManager兩個(gè)重要的組件。 ResourceManager運(yùn)行在Master節(jié)點(diǎn)上，NodeManager運(yùn)行在Slave節(jié)點(diǎn)上，一起負(fù) 責(zé)分布式應(yīng)用程序的調(diào)度和運(yùn)行
2. ResourceManager是為應(yīng)用程序分配資源的最高權(quán)威。ResourceManager包含兩個(gè)組件，包括Scheduler和ApplicationManager

總的來說，Hadoop 2.0（YARN）的出現(xiàn)，解決了 Hadoop 1.0 的很多痛點(diǎn)，讓大數(shù)據(jù)處理變得更加高效、可靠和靈活。相信在未來，它還會(huì)不斷進(jìn)化，為我們處理大數(shù)據(jù)帶來更多的便利和驚喜！

Hadoop 2.0 的主要優(yōu)勢有哪些?

• 1. 擴(kuò)展性:

ResourceManager的主要功能，是資源的調(diào)度工作。所以它能夠輕松地 管理更大規(guī)模的集群系統(tǒng)，適應(yīng)了數(shù)據(jù)量增長對數(shù)據(jù)中心的擴(kuò)展性提出的挑戰(zhàn)。

• 2. 更高的集群使用效率:

ResourceManager是一個(gè)單純的資源管理器，它根據(jù)資源 預(yù)留要求、公平性、服務(wù)水平協(xié)議(Service Level Agreement, SLA)等標(biāo)準(zhǔn)，優(yōu)化 整個(gè)集群的資源，使之得到很好的利用。

• 3. 兼容Hadoop1.0:

在Hadoop1.0平臺(tái)上開發(fā)的 MapReduce應(yīng)用程序，無需修 改，直接在YARN上運(yùn)行。

• 4. 支持更多的負(fù)載類型:

當(dāng)數(shù)據(jù)存儲(chǔ)到HDFS以后，用戶希望能夠?qū)?shù)據(jù)以不同的 方式進(jìn)行處理。除了MapReduce應(yīng)用程序(主要對數(shù)據(jù)進(jìn)行批處理)，YARN支持 更多的編程模型，包括圖數(shù)據(jù)的處理、迭代式計(jì)算模型、實(shí)時(shí)流數(shù)據(jù)處理、交互 式查詢等。一般來講，機(jī)器學(xué)習(xí)算法需要在數(shù)據(jù)集上，經(jīng)過多次迭代，才能獲得 最終的計(jì)算結(jié)果。

• 5. 靈活性: MapReduce等計(jì)算模型可以獨(dú)立于資源管理層，單獨(dú)演化和改進(jìn)。使 得系統(tǒng)各個(gè)部件的演進(jìn)和配合，更加具有靈活性