HDFS、YARN、Mapreduce簡介

1、 HDFS介紹：

1. Hadoop2介紹
2. HDFS概述
3. HDFS讀寫流程

 

     1.  Hadoop2介紹

Hadoop是Apache軟件基金會旗下的一個分佈式系統基礎架構。Hadoop2的框架最核心的設計就是HDFS、MapReduce和YARN，爲海量的數據提供了存儲和計算。

HDFS主要是Hadoop的存儲，用於海量數據的存儲；

MapReduce主要運用於分佈式計算；

YARN是Hadoop2中的資源管理系統。

 

Hadoop1和Hadoop2的結構對比：

 

 

Hadoop2主要改進：

YARN

經過YARN實現資源的調度與管理，從而使Hadoop 2.0能夠運行更多種類的計算框架，如Spark等；

NameNode HA

實現了NameNode的HA方案，即同時有2個NameNode（一個Active另外一個Standby），若是ActiveNameNode掛掉的話，另外一個NameNode會轉入Active狀態提供服務，保證了整個集羣的高可用；

HDFS federation

實現了HDFS federation，因爲元數據放在NameNode的內存當中，內存限制了整個集羣的規模，經過HDFS federation使多個NameNode組成一個聯邦共同管理DataNode，這樣就能夠擴大集羣規模；

Hadoop RPC序列化擴展性

Hadoop RPC序列化擴展性好，經過將數據類型模塊從RPC中獨立出來，成爲一個獨立的可插拔模塊。

 

2.  HDFS概述

HDFS是一個分佈式文件系統，具備高容錯的特色，它能夠部署在廉價的通用硬件上，提供高吞吐率的數據訪問，適合那些須要處理海量數據集的應用程序。

 

HDFS主要特性：

支持超大文件

通常是幾百MB、GB甚至TB級別的文件

檢測和快讀應對硬件故障

HDFS的檢測和冗餘機制很好的克服了大量通用硬件平臺上硬件故障的問題；

流式數據訪問

HDFS處理的數據規模都很大，應用一次須要訪問大量數據，同時，這些應用通常是批量處理，而不是用戶交互式處理，HDFS使用戶可以以流的形式訪問數據集，注重的是數據的吞吐；

簡化一致性模型

大部分的HDFS程序操做文件時，須要一次寫入，屢次讀取，在HDFS中，一個文件一旦通過建立寫入，關閉後通常不須要修改，這樣簡單的一致性模型有利於提升吞吐量。

 

HDFS不適合的場景：

低延遲數據訪問

大量的小文件

多用戶寫入文件，修改文件

 

HDFS體系結構：

 

Namenode上保存着HDFS的名字空間，任何對文件系統元數據產生修改的操做都會做用於Namenode上。

Datanode將HDFS數據以文件的形式存儲在本地的文件系統中，它並不知道有關HDFS文件的信息，它把每一個HDFS數據塊存儲在本地文件系統的一個單獨的文件中。

 

數據塊：

HDFS也有塊的概念，Hadoop2中HDFS塊默認大小爲128MB（此大小能夠根據各自的業務狀況進行配置，Hadoop1中HDFS塊默認大小爲64MB），以Linux上普通文件的形式保存在數據節點的文件系統中，數據塊是HDFS的文件存儲處理的單元。

數據塊的好處：

HDFS能夠保存比存儲節點單一磁盤大的文件

簡化了存儲子系統和存儲管理，也消除了分佈式管理文件元數據的複雜性

方便容錯，有利於數據複製

 

     3.  HDFS讀寫流程

讀流程：

 

一、客戶端client使用open函數打開文件；

二、DistributedFileSystem用RPC調用元數據節點，獲得文件的數據塊信息；

三、對於每個數據塊，元數據節點返回保存數據塊的數據節點的地址；

四、DistributedFileSystem返回FSDataInputStream給客戶端，用來讀取數據；

五、客戶端調用FSDataInputStream的read函數開始讀取數據；

六、FSDataInputStream鏈接保存此文件第一個數據塊的最近的數據節點；

七、Data從數據節點讀到客戶端；

八、當此數據塊讀取完畢時，FSDataInputStream關閉和此數據節點的鏈接，而後鏈接此文件下一個數據塊的最近的數據節點；

九、當客戶端讀取數據完畢時，調用FSDataInputStream的close函數；

十、在讀取數據的過程當中，若是客戶端在與數據節點通訊出現錯誤，則嘗試鏈接包含此數據塊的下一個數據節點。失敗的數據節點將被記錄，之後再也不鏈接。

 

寫流程：

 

一、客戶端client調用create函數建立文件；

二、DistributedFileSystem用RPC調用元數據節點，在文件系統的命名空間中建立一個新的文件；

三、元數據節點首先肯定文件是否存在，而且客戶端是否有建立文件的權限，而後建立新文件；

四、DistributedFileSystem返回FSDataOutputStream給客戶端用於寫數據；

五、客戶端開始寫入數據，FSDataOutputStream將數據分紅塊，寫入data queue；

六、Data queue由DataStreamer讀取，並通知元數據節點分配數據節點，用來存儲數據塊（每塊默認複製3塊），分配的數據節點放在一個pipeline裏；

七、DataStreamer將數據塊寫入pipeline中的第一個數據節點，第一個數據節點將數據塊發送給第二個數據節點，第二個數據節點將數據發送給第三個數據節點；

八、FSDataOutputStream爲發出去的數據塊保存了ack queue，等待pipeline中的數據節點告知數據已經寫入成功；

九、若是數據節點在寫入的過程當中失敗，則進行如下幾個操做：一是關閉pipeline並將ack queue中的數據塊放入data queue的開始；二是當前數據塊在已寫入的數據節點中被元數據節點賦予新的標示，錯誤節點重啓後察覺其數據塊過期而被刪除；三是失敗的數據節點從pipeline中移除，另外的數據塊則寫入pipeline中的另外兩個數據節點；四是元數據節點被通知此數據塊的複製塊數不足，從而再建立第三份備份；

十、當客戶端結束寫入數據，則調用close函數將全部的數據塊寫入pipeline中的數據節點，並等待ack queue返回成功，最後通知元數據節點寫入完畢。

 

 

建立子路徑流程：

 

 

刪除數據流程：

 

 總結

 本章對Hadoop2進行了介紹，並詳細介紹了HDFS的體系結構，塊，讀寫流程等。學完此章應對hadoop和HDFS有必定的認識。

 

 

2、YARN原理介紹

2.1 YARN產生背景

Hadoop 1.0的弊端包括：

一、擴展性差：JobTracker兼備資源管理和做業控制兩個功能，這是整個系統的最大瓶頸，它嚴重製約了整個集羣的可擴展性。

二、可靠性差：JobTracker存在單點故障，JobTracker出現問題將致使整個集羣不可用。

三、資源利用率低：資源沒法在多個任務間共享或合理分配，致使沒法有效利用各類資源。

四、沒法支持多種計算框架：Hadoop 1.0只支持MapReduce這種離線批處理計算模式，而沒法支持內存計算、流式計算、迭代式計算等。

正是因爲Hadoop 1.0存在以上這些弊端，因此Hadoop 2.0推出了資源管理器YARN，有效解決了上述問題。

 

2.2 YARN基本架構

YARN是Hadoop 2.0的資源管理器。它是一個通用的資源管理系統，可爲上層應用提供統一的資源管理和調度，它的引入爲集羣在利用率、資源統一管理和數據共享等方面帶來了巨大好處。

YARN的基本設計思想是將Hadoop 1.0中的JobTracker拆分紅了兩個獨立的服務：一個全局的資源管理器ResourceManager和每一個應用程序特有的ApplicationMaster。其中ResourceManager負責整個系統的資源管理和分配，而ApplicationMaster負責單個應用程序的管理，其基本架構以下圖所示：

 

 

YARN整體上仍然是Master/Slave結構。在整個資源管理框架中，ResourceManager爲Master，NodeManager爲Slave，並經過HA方案實現了ResourceManager的高可用。ResourceManager負責對各個NodeManager上的資源進行統一管理和調度。當用戶提交一個應用程序時，須要提供一個用以跟蹤和管理這個程序的ApplicationMaster，它負責向ResourceManager申請資源，並要求NodeManger啓動能夠佔用必定資源的任務。因爲不一樣的ApplicationMaster被分佈到不一樣的節點上，所以它們之間不會相互影響。

 

ResourceManager：它是一個全局的資源管理器，負責整個系統的資源管理和分配，主要由調度器和應用程序管理器兩個組件構成。

調度器：根據容量、隊列等限制條件，將系統中的資源分配給各個正在運行的應用程序。調度器僅根據應用程序的資源需求進行資源分配，而資源分配單位用一個抽象概念「資源容器」（簡稱Container）表示，Container是一個動態資源分配單位，它將內存、CPU、磁盤、網絡等資源封裝在一塊兒，從而限定每一個任務使用的資源量。

應用程序管理器：負責管理整個系統中全部的應用程序，包括應用程序提交、與調度器協商資源以啓動ApplicationMaster、監控ApplicationMaster運行狀態並在失敗時從新啓動它等。

ApplicationMaster：用戶提交的每一個應用程序均包含1個ApplicationMaster，主要功能包括與ResourceManager調度器協商以獲取資源、將獲得的任務進一步分配給內部的任務、與NodeManager通訊以啓動/中止任務、監控全部任務運行狀態並在任務運行失敗時從新爲任務申請資源以重啓任務等。

NodeManager：它是每一個節點上的資源和任務管理器，它不只定時向ResourceManager彙報本節點上的資源使用狀況和各個Container的運行狀態，還接收並處理來自ApplicationMaster的Container啓動/中止等各類請求。

Container：它是YARN中的資源抽象，它封裝了某個節點上的多維度資源，如內存、CPU、磁盤、網絡等，當ApplicationMaster向ResourceManager申請資源時，返回的資源即是用Container表示的。YARN會爲每一個任務分配一個Container，且該任務只能使用該Container中描述的資源。

 

2.3 YARN工做流程

YARN的工做流程以下圖所示：

 

1：用戶向YARN中提交應用程序，其中包括用戶程序、ApplicationMaster程序、ApplicationMaster啓動命令等。

2：ResourceManager爲應用程序分配第一個Container，並與對應的NodeManager通訊，要求它在這個Container中啓動應用程序的ApplicationMaster。

3：ApplicationMaster首先向ResourceManager註冊，這樣用戶能夠直接經過ResourceManager查看應用程序的運行狀態，而後ApplicationMaster爲各個任務申請資源，並監控它們的運行狀態，直到運行結束，即重複步驟4-7。

4：ApplicationMaster採用輪詢的方式經過RPC協議向ResourceManager申請和領取資源。

5：一旦ApplicationMaster成功申請到資源，便開始與對應的NodeManager通訊，要求它啓動任務。

6：NodeManager爲任務設置好運行環境（包括環境變量、JAR包、二進制程序等）後，將任務啓動命令寫到一個腳本中，並經過運行該腳本啓動任務。

7：各個任務經過某個RPC協議向ApplicationMaster彙報本身的狀態和進度，使ApplicationMaster可以隨時掌握各個任務的運行狀態，從而能夠在任務失敗時從新啓動任務。在應用程序運行過程當中，用戶可隨時經過RPC向ApplicationMaster查詢應用程序的當前運行狀態。

8：應用程序運行完成後，ApplicationMaster經過RPC協議向ResourceManager註銷並關閉本身。

 

總結

本章對YARN的造成背景及基本架構，運行原理作了介紹。學完此章對YARN有必定的理論基礎。這對後面編寫基於YARN的計算有很是大的幫助。

 

3、 MapReduce原理介紹

3.1 MapReduce介紹

MapReduce是由Google公司研究提出的一種面向大規模數據處理的並行計算模型和方法，是Hadoop面向大數據並行處理的計算模型、框架和平臺。

MapReduce執行流包括input、map、shuffle、reduce和output共5個過程，以下圖所示：

 

 

3.2 MapReduce2運行原理

YARN框架下的Mapreduce工做流程以下圖所示：

 

1：客戶端向集羣提交做業。

2：Job從ResourceManager獲取新的做業應用程序ID。

3：客戶端檢查做業的輸出狀況，計算輸入分片，並將做業jar包、配置、分片信息等做業資源複製到HDFS。

4：Job向ResourceManager提交做業。

5：ResourceManager接收到做業後，將做業請求傳遞給調度器，調度器根據做業信息爲ResourceManager分配一個container，而後ResourceManager在NodeManager的管理下，在container中啓動一個ApplicationMaster進程。

6：ApplicationMaster對做業進行初始化，並保持對做業的跟蹤，判斷做業是否完成。

7：ApplicationMaster根據存儲在HDFS中的分片信息肯定Map和Reduce的數量。

8：ApplicationMaster爲本次做業的Map和Reduce以輪詢的方式向ResourceManager申請container。

9：ApplicationMaster獲取到container後，與NodeManager進行通訊啓動container。

10：container從HDFS中獲取做業的jar包、配置和分佈式緩存文件等，將任務須要的資源本地化。

11：container啓動Map或Reduce任務。

 

3.3 shuffle及排序

Mapreduce的map端輸出做爲輸入傳遞給reduce端，並按鍵排序的過程稱爲shuffle。shuffle的字面含義是洗牌，即將map產生的數據經過分區、排序等過程分配給了不一樣的reduce任務。Mapreduce的數據處理流程以下圖所示：

 

Map階段：

一、每一個輸入分片會讓一個map任務來處理，默認狀況下，以HDFS的一個塊的大小（默認爲64M，可設置）爲一個分片。map輸出的結果會暫時放在一個環形內存緩衝區中（該緩衝區的大小默認爲100M，由io.sort.mb屬性控制）。當該緩衝區快要溢出時（默認爲緩衝區大小的80%，由io.sort.spill.percent屬性控制），會在本地文件系統中建立一個溢出文件，將該緩衝區中的數據寫入這個文件。

二、在寫入磁盤以前，線程首先根據reduce任務的數目將數據劃分爲相同數目的分區，也就是一個reduce任務對應一個分區的數據。這樣作是爲了不有些reduce任務分配到大量數據，而有些reduce任務卻分到不多數據，甚至沒有分到數據的尷尬局面。而後對每一個分區中的數據進行排序，若是此時設置了Combiner，將排序後的結果進行combine操做，這樣作能夠有效減小磁盤IO和網絡IO。

三、當map任務輸出最後一個記錄時，可能會有不少的溢出文件，這時須要將這些文件合併。合併的過程當中會不斷地進行排序和combine操做，這樣作是爲了儘可能減小每次寫入磁盤的數據量和儘可能減小下一複製階段網絡傳輸的數據量。最後合併成了一個已分區且已排序的文件。爲了減小網絡傳輸的數據量，這裏能夠將數據壓縮，只要將mapred.compress.map.out設置爲true就能夠了。

四、將分區中的數據拷貝給相對應的reduce任務。那麼分區中的數據如何知道它對應的reduce是哪一個呢？ ApplicationMaster保存了整個做業的宏觀信息，只要reduce任務向ApplicationMaster獲取對應的map輸出位置就能夠了。

 

Reduce階段：

一、Reduce會接收到不一樣map任務傳來的數據，而且每一個map傳來的數據都是有序的。若是reduce接受的數據量至關小，則直接存儲在內存中，若是數據量超過了該緩衝區大小的必定比例，則對數據合併後溢寫到磁盤中。

二、隨着溢寫文件的增多，後臺線程會將它們合併成一個更大的有序文件，這樣作是爲了給後面的合併節省時間。其實無論在map端仍是reduce端，MapReduce都是反覆地執行排序、合併操做，因此說排序是hadoop的靈魂。

三、在合併的過程當中會產生許多的中間文件（寫入磁盤了），但MapReduce會讓寫入磁盤的數據儘量地少，而且最後一次合併的結果並無寫入磁盤，而是直接輸入到reduce函數。