Hadoop各模塊的示例分析

這篇文章主要介紹Hadoop各模塊的示例分析，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

Hadoop集群架構

Hadoop集群由一個Master主節(jié)點和若干個Slave節(jié)點組成。其中，Master節(jié)點上運行NameNode和JobTracker守護進程；Slave節(jié)點上運行DataNode和TaskTracker守護進程。 
Hadoop分別從三個角度將集群中的主機劃分為兩種角色：

Hadoop集群主機角色劃分

1. 從主機服務角度 
   ??從主機服務功能上將集群中的主機分為Master和Slave。Master主機負責分布式文件系統(tǒng)的元數據管理和分布式計算的作業(yè)調度，一般在一個集群中有一到數臺Master主機；Slave主機負責具體的數據存儲和計算。

2. 從文件系統(tǒng)HDFS的角度 
   ??從文件系統(tǒng)HDFS的的角度將主機劃分為NameNode和DatanNode。Namenode存儲分布式文件系統(tǒng)中的元數據信息，換句話說也就是命名空間，它維護著文件系統(tǒng)樹及整課樹內所有文件和目錄，這些信息以兩個文件形式永久的保存在本地磁盤上：命名空間鏡像文件和編輯日志文件。同時namenode也記錄每個文件中各個塊所在的數據節(jié)點信息，但是不會永久保留這些信息，因為這些信息系會在系統(tǒng)啟動的時候由數據節(jié)點重建；DataNode存儲文件系統(tǒng)中實際文件數據，它們根據需要儲存和檢索數據塊(受客戶端或namenode調度)，并且定期的向namenode發(fā)送他們所存儲的塊列表(所謂的心跳檢測)。

換句話說，namenode的安全機制很重要，如果丟失或者損壞了namenode，文件系統(tǒng)上所有的文件就將丟失。因為我們不知道如何根據datanode塊重建文件。Hadoop提供了兩種保護機制：

• 冗余備份namenode

• 另一種方式是運行輔助namenode，它定期通過編輯日志合并命名空間鏡像，以防止編輯日志過大。

而實際上，這兩種方法在后來我們會繼續(xù)討論，更重要的是，namenode HA的機制眾多大牛已經將其設計的非?？茖W了，我們可以參考一下這篇文章：namenode的HA原理詳解。

實際上，Hadoop的文件系統(tǒng)遠不止HDFS一種，它整合了眾多的文件系統(tǒng)，首先提供了一個高層的文件系統(tǒng)抽象org.apache.hadoop.fs.FileSystem，該抽象類展示了一個分布式文件系統(tǒng)，并有幾個具體的實現(xiàn)，見下表：

Hadoop文件系統(tǒng)

    3.  從MapReduce角度 

??從MapReduce角度將主機劃分為JobTracker和TaskTracker。JobTracker是作業(yè)的調度與管理者，屬于master;TaskTracker是任務的實際執(zhí)行者，屬于slave。

所以HDFS只是其中的一個文件系統(tǒng)之一

HDFS簡介

??HDFS是Hadoop使用的標準存儲系統(tǒng)，是基于網絡環(huán)境下的分布式文件系統(tǒng)。它是基于流數據模式訪問和處理超大文件的需求開發(fā)的，實際上，這并不是什么新穎的事情，80年代左右就已經有人這么去實現(xiàn)了。存儲在HDFS上的數據文件首先進行分塊，每個分塊創(chuàng)建多個副本，并存儲在集群的不同節(jié)點上，Hadoop MapReduce程序可以在所有節(jié)點上處理這些數據。HDFS上數據存儲和處理過程如下所示。

Hadoop上的數據存儲和處理模型

HDFS的兩個主要組件

??HDFS的設計遵從主從體系結構，每個HDFS集群都有一個名字節(jié)點（NameNode)和若干數據節(jié)點（DataNode)。HDFS存儲文件的機制是將數據文件分塊，這里的文件塊指的是系統(tǒng)讀寫操作的最小文件大小，文件系統(tǒng)每次只能處理磁盤塊大小的整數倍數據。然后將這些數據塊按照一定的策略存放在數據節(jié)點上。NameNode節(jié)點管理文件系統(tǒng)的命名空間、文件、目錄操作，同時也負責確定數據節(jié)點和文件塊的映射關系。DataNode節(jié)點負責來自客戶端的文件讀/寫請求，同時還要執(zhí)行塊的創(chuàng)建、刪除以及來自名字節(jié)點的文件和塊的操作命令。 
??NameNode和DataNode在功能上的區(qū)別： 

HDFS的系統(tǒng)架構

HDFS的架構如圖所示: 

HDFS讀取文件流程

HDFS中客戶端讀取文件的流程如下所示:

HDFS讀取文件流程

讀取操作的具體流程如下： 
1. 客戶端(client)用FileSystem的open()函數打開文件。 
2. DistributedFileSystem用RPC和NameNode通信，得到文件的所有數據塊信息以及這些數據塊所在節(jié)點的地址信息。 
3. DistributedFileSystem將獲取的數據塊信息保存在FSDataInputStream中，然后返回給客戶端，用來讀取數據。 
4. 客戶端根據NameNode返回的信息，連接到存有數據塊的數據節(jié)點，然后調用stream的read()函數開始讀取數據。 
5. DFSInputStream連接保存此文件第一個數據塊的最近的數據節(jié)點。 
6. Data從數據節(jié)點讀到客戶端(client)。 
7. 當此數據塊讀取完畢時，DFSInputStream關閉和此數據節(jié)點的連接，然后連接此文件下一個數據塊的最近的數據節(jié)點。 
8. 當客戶端讀取完畢數據的時候，調用FSDataInputStream的close函數。 
9. 在讀取數據的過程中，如果客戶端在與數據節(jié)點通信出現(xiàn)錯誤，則嘗試連接包含此數據塊的下一個數據節(jié)點。 
10. 失敗的數據節(jié)點將被記錄，以后不再連接。

3.5、HDFS寫入文件流程

HDFS寫入文件流程如下所示。

HDFS寫入文件流程

寫入操作的具體流程如下： 
1. 客戶端調用create()來創(chuàng)建文件 
2. DistributedFileSystem用RPC調用元數據節(jié)點，在文件系統(tǒng)的命名空間中創(chuàng)建一個新的文件。 
3. 元數據節(jié)點首先確定文件原來不存在，并且客戶端有創(chuàng)建文件的權限，然后創(chuàng)建新文件。 
4. DistributedFileSystem返回DFSOutputStream，客戶端用于寫數據。 
5. 客戶端開始寫入數據，DFSOutputStream將數據分成塊，寫入data queue。 
6. Data queue由Data Streamer讀取，并通知元數據節(jié)點分配數據節(jié)點，用來存儲數據塊(每塊默認復制3塊)。分配的數據節(jié)點放在一個pipeline里。 
7. Data Streamer將數據塊寫入pipeline中的第一個數據節(jié)點。第一個數據節(jié)點將數據塊發(fā)送給第二個數據節(jié)點。第二個數據節(jié)點將數據發(fā)送給第三個數據節(jié)點。 
8. DFSOutputStream為發(fā)出去的數據塊保存了ack queue，等待pipeline中的數據節(jié)點告知數據已經寫入成功。 
?如果數據節(jié)點在寫入的過程中失?。?nbsp;
?關閉pipeline，將ack queue中的數據塊放入data queue的開始。 
?當前的數據塊在已經寫入的數據節(jié)點中被元數據節(jié)點賦予新的標示，則錯誤節(jié)點重啟后能夠察覺其數據塊是過時的，會被刪除。 
?失敗的數據節(jié)點從pipeline中移除，另外的數據塊則寫入pipeline中的另外兩個數據節(jié)點。 
?元數據節(jié)點則被通知此數據塊是復制塊數不足，將來會再創(chuàng)建第三份備份。 
9. 當客戶端結束寫入數據，則調用stream的close函數。此操作將所有的數據塊寫入pipeline中的數據節(jié)點，并等待ack queue返回成功。最后通知元數據節(jié)點寫入完畢。

一些補充的地方：

1. NameNode啟動后會進入一個成為安全模式的特殊狀態(tài)。此時NameNode不會進行數據塊復制。NameNode從所有的DataNode接收心跳信號和塊狀態(tài)報告。塊狀態(tài)報告包括了某個DataNode所有的數據塊列表。每個數據塊都有一個指定的最小副本數，當NameNode檢測確認某個數據塊的副本數達到要求的時候，該數據塊就會被認為是副本安全的。等安全DataNode達到了一定比率，NameNode就會推出安全模式，接下來還會繼續(xù)確定還有哪些數據的副本沒有達到指定數目。

2. Hadoop的優(yōu)缺點

優(yōu)點：

• 處理超大文件

• 流式的訪問數據

• 運行于廉價的商用機器集群上

缺點：

• 不適合低延遲訪問

• 無法高效存儲大量小文件

MapReduce

MapReduce作業(yè)執(zhí)行過程中涉及到的實體

• 客戶端 
  作用是提交MapReduce作業(yè)到集群的計算機主節(jié)點JobTracker上?？蛻舳丝梢允羌荷系墓?jié)點也可以不是集群上的節(jié)點，從集群外的節(jié)點提交作業(yè)時需要制定JobTRacker的地址。

• 計算主節(jié)點JobTracker 
  JobTracker 的功能主要是負責作業(yè)的任務分配，計算任務的管理和監(jiān)控。

• 從節(jié)點TaskTracker 
  運行JobTracker分配給他的任務。

• HDFS 
  計算開始的時候，程序從HDFS中讀入數據；計算結束后，將數據保存到HDFS中。

MapReduce的工作流程

整個MapReduce作業(yè)的工作工程，如下所示：

MapReduce工作流程

1. 作業(yè)的提交 
客戶端調用JobClient的runjob()方法創(chuàng)建一個 JobClient實例，然后調用submitJob()方法提交作業(yè)到集群，其中主要包括以下步驟： 
1）通過JobTracker的getNewJobId()請求一個新的作業(yè)ID； 
2）檢查作業(yè)的輸出（比如沒有指定輸出目錄或輸出目錄已經存在，就拋出異常），以免覆蓋原有文件內容； 
3）計算作業(yè)的輸入分片，為了高效，分片大小最好和HDFS塊的大小相同（當分片無法計算時，比如輸入路徑不存在等原因，就拋出異常）； 
4）將運行作業(yè)所需的資源（比如作業(yè)Jar文件，配置文件，計算所得的輸入分片等）復制到一個以作業(yè)ID命名的目錄中。（集群中有多個副本可供TaskTracker訪問）； 
5）通過調用JobTracker的submitJob()方法告知作業(yè)準備執(zhí)行； 
6）JobTracker調度任務到工作節(jié)點上執(zhí)行。runjob每隔1秒輪訓一次節(jié)點，看看執(zhí)行進度，指導任務執(zhí)行完畢。 

2. 作業(yè)的初始化 
1）JobTracker接收到對其submitJob()方法的調用后，就會把這個調用放入一個內部隊列中，交由作業(yè)調度器（比如先進先出調度器，容量調度器，公平調度器等）進行調度； 
2）初始化主要是創(chuàng)建一個表示正在運行作業(yè)的對象——封裝任務和記錄信息，以便跟蹤任務的狀態(tài)和進程； 
3）為了創(chuàng)建任務運行列表，作業(yè)調度器首先從HDFS中獲取JobClient已計算好的輸入分片信息； 
4）然后為每個分片創(chuàng)建一個MapTask，并且創(chuàng)建ReduceTask。（Task在此時被指定ID，請區(qū)分清楚Job的ID和Task的ID）。 

3. 任務的分配 
1）TaskTracker定期通過“心跳”與JobTracker進行通信，主要是告知JobTracker自身是否還存活，以及是否已經準備好運行新的任務等； 
2）JobTracker在為TaskTracker分配一個Task前，JobTracker需要按照優(yōu)先級選擇一個作業(yè)，在最高優(yōu)先級的job中選擇一個task。Hadoop默認的作業(yè)調度Map Task優(yōu)先級比Reduce Task高； 
3）TaskTracker根據一定的策略運行一定數量的map task和reduce task?？蛇\行的數量有TaskTracker的數量和內存大小決定

4. 任務的執(zhí)行 
1）TaskTracker分配到一個任務后，通過從HDFS把作業(yè)的Jar文件復制到TaskTracker所在的文件系統(tǒng)（Jar本地化用來啟動JVM），同時TaskTracker將應用程序所需要的全部文件從分布式緩存復制到本地磁盤； 
2）TaskTracker為任務新建一個本地工作目錄，并把Jar文件中的內容解壓到這個文件夾中； 
3）TaskTracker啟動一個新的JVM來運行每個Task（包括MapTask和ReduceTask），這樣Client的MapReduce就不會影響TaskTracker守護進程（比如，導致崩潰或掛起等）。 
子進程通過umbilical接口與父進程進行通信，Task的子進程每隔幾秒便告知父進程它的進度，直到任務完成。

5. 進程和狀態(tài)的更新 
一個作業(yè)和它的每個任務都有一個狀態(tài)信息，包括作業(yè)或任務的運行狀態(tài)，Map和Reduce的進度，計數器值，狀態(tài)消息或描述（可以由用戶代碼來設置）。這些狀態(tài)信息在作業(yè)期間不斷改變，它們是如何與Client通信的呢？

任務在運行時，對其進度（即任務完成的百分比）保持追蹤。對于MapTask，任務進度是已處理輸入所占的比例。對于ReduceTask，情況稍微有點復雜，但系統(tǒng)仍然會估計已處理Reduce輸入的比例；

這些消息通過一定的時間間隔由Child JVM—>TaskTracker—>JobTracker匯聚。JobTracker將產生一個表明所有運行作業(yè)及其任務狀態(tài)的全局視圖?？梢酝ㄟ^Web UI查看。同時JobClient通過每秒查詢JobTracker來獲得最新狀態(tài)，并且輸出到控制臺上。

4.3、Shuffle和Sort

Shuffle階段是指從Map的輸出開始，包括系統(tǒng)執(zhí)行排序以及傳送Map輸出到Reduce作為輸入的過程。Sort階段是指對Map端輸出的Key進行排序的過程。不同的Map可能輸出相同的Key，相同的Key必須發(fā)送到同一個Reduce端處理。Shuffle階段可以分為Map端的Shuffle和Reduce端的Shuffle。Shuffle階段和Sort階段的工作過程，如下所示：

1、Map端的Shuffle 
Map函數開始產生輸出時，并不是簡單地把數據寫到磁盤，因為頻繁的磁盤操作會導致性能嚴重下降。它的處理過程更復雜，數據首先寫到內存中的一個緩沖區(qū)，并做一些預排序，以提升效率；

每個MapTask都有一個用來寫入輸出數據的循環(huán)內存緩沖區(qū)（默認大小為100MB），當緩沖區(qū)中的數據量達到一個特定閾值時（默認是80%）系統(tǒng)將會啟動一個后臺線程把緩沖區(qū)中的內容寫到磁盤（即spill階段）。在寫磁盤過程中，Map輸出繼續(xù)被寫到緩沖區(qū)，但如果在此期間緩沖區(qū)被填滿，那么Map就會阻塞直到寫磁盤過程完成；

在寫磁盤前，線程首先根據數據最終要傳遞到的Reducer把數據劃分成相應的分區(qū)（partition）。在每個分區(qū)中，后臺線程按Key進行排序（快速排序），如果有一個Combiner（即Mini Reducer）便會在排序后的輸出上運行；

一旦內存緩沖區(qū)達到溢出寫的閾值，就會創(chuàng)建一個溢出寫文件，因此在MapTask完成其最后一個輸出記錄后，便會有多個溢出寫文件。在在MapTask完成前，溢出寫文件被合并成一個索引文件和數據文件（多路歸并排序）（Sort階段）；

溢出寫文件歸并完畢后，Map將刪除所有的臨時溢出寫文件，并告知TaskTracker任務已完成，只要其中一個MapTask完成，ReduceTask就開始復制它的輸出（Copy階段）；

Map的輸出文件放置在運行MapTask的TaskTracker的本地磁盤上，它是運行ReduceTask,TaskTracker所需要的輸入數據，但是Reduce輸出不是這樣的，它一般寫到HDFS中（Reduce階段）。

2、Reduce端的Shuffle 
Copy階段：Reduce進程啟動一些數據copy線程，通過HTTP方式請求MapTask所在的TaskTracker以獲取輸出文件。 

Merge階段：將Map端復制過來的數據先放入內存緩沖區(qū)中，Merge有3種形式，分別是內存到內存，內存到磁盤，磁盤到磁盤。默認情況下第一種形式不啟用，第二種Merge方式一直在運行（spill階段）直到結束，然后啟用第三種磁盤到磁盤的Merge方式生成最終的文件。 

Reduce階段：最終文件可能存在于磁盤，也可能存在于內存中，但是默認情況下是位于磁盤中的。當Reduce的輸入文件已定，整個Shuffle就結束了，然后就是Reduce執(zhí)行，把結果放到HDFS中。

HBase

HBase表的特點

1、大：一個表可以有數十億行，上百萬列； 
2、無模式：每行都有一個可排序的主鍵和任意多的列，列可以根據需要動態(tài)的增加，同一張表中不同的行可以有截然不同的列； 
3、面向列：面向列（族）的存儲和權限控制，列（族）獨立檢索； 
稀疏：空（null）列并不占用存儲空間，表可以設計的非常稀疏； 
4、數據多版本：每個單元中的數據可以有多個版本，默認情況下版本號自動分配，是單元格插入時的時間戳； 
5、數據類型單一：Hbase中的數據都是字符串，沒有類型。

HBase的物理集群架構

HBase集群在物理組成上由一個Zookeeper集群、一個Master主服務器、多個RegionServer從服務器組成，同時，HBse在底層依賴于HDFS集群。整體系統(tǒng)架構如下所示：

HBase的物理集群架構

HBase集群運行依賴于Zookeeper，默認情況下，它管理一個Zookeeper實例，作為集群“權威”。如果區(qū)域分配過程中有服務器崩潰，就需要Zookeeper來協(xié)調分配?？蛻舳俗x寫HBase中的數據時也需要先訪問Zookeeper，了解集群屬性。

在底層，HBase的所有信息都保存在HDFS中，HBase是構建在HDFS上的分布式數據庫。

HBase的存儲架構

HBase的存儲架構如下所示：

HBase的存儲架構

HBASE集群種重要的角色就是其守護進程。包括運行在集群Master節(jié)點上的HMaster進程和運行在每個從節(jié)點RegionServer節(jié)點上的HRegionServer進程，初次之外，還包括若干Zookeeper進程。具體組件實體如下： 
1、Client 
HBse Client使用HBase的RPC機制與HMaster（進行管理操作）和HRegionServer（進行讀寫操作）進行通信。 

2、HMaster 
HMaster是集群Master節(jié)點的主進程，HMaster沒有單點問題，HBase中可以啟動多個HMaster，通過Zookeper的Master Election機制保證總有一個Master運行，HMaster在功能上主要負責Table和Region的管理工作。包括：Table的增刪該查、Region分布等。 

3、HRegionServer 
HRegionServer進程運行在集群從節(jié)點上，主要負責響應用戶的IO請求，向HDFS系統(tǒng)中讀寫數據。其內部功能結構圖如下： 

HRegionServer內部功能結構圖

從圖上可以看出，HRegionServer管理一系列HRegion對象，每一個HRegion又由多個HStore組成。HRegion對應Table中的一個Region;HStore對應Table中的一個列簇。每個列簇就是一個存儲單元。 
HStore由兩部分組成：MemStore和StoreFile。用戶寫入的數據首先會放入MemSore,MemStore滿了之后，flush成一個StoreFile.

4、Zookeeper 
Zookeeper中除了存儲-ROOT表的地址和Master的地址，還會有HRegionServer的信息，使得Hmaster可以隨時知道HRegionServer的狀況。

5、Hlog 
每一個HRegionServer都有一個Hlog對象，用戶寫入數據時，會備份一份到HLOG中，以便出現(xiàn)意外好恢復。

5.4、HBase運行時特點

1、Hbase中的區(qū)域 
當HBase中數據記錄數不斷增多時，達到閾值后，就會從行的方向分裂成多份，每份是一個region,一個region由【startkey,endkey】表示。不同的region會被集群的Master分配給相應的RegionServer進行管理。 

2、HBse中兩種特殊表 
運行中的HBase內部保留了2中特殊的目錄表：-ROOT- 和 .META. 。-ROOT-表包含了.META.表的所有區(qū)域列表的信息，而.META.表保存了所有用戶空間的區(qū)域列表信息，以及RegionServer的服務器地址。

HBse中兩種特殊表

六、Hive

6.1、Hive簡介

Hive是建立在Hadoop之上的數據倉庫軟件工具，它提供了一系列的工具，幫助用戶對大規(guī)模的數據進行提取、轉換和加載，即ETL操作。Hive定義了簡單的類SQL查詢語言，稱為HiveSql。從本質上講，Hive其實就是一個SQL解釋器，它能夠將用戶輸入的HiveSql語句轉換成MapReduce作業(yè)在Hadoop集群上執(zhí)行。

6.2、Hive的體系結構

以上是“Hadoop各模塊的示例分析”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業(yè)資訊頻道！