文章目錄

MR的原理和運行流程Map的運行過程Reduce處理過程Shuffle過程MR運行過程Yarn && Job

MR的原理和運行流程
Map的運行過程

以HDFS上的文件作為默認輸入源為例（MR也可以有其他的輸入源）

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-419qFeIb-1589376928673)(https://github.com/jiaoqiyuan/163-bigdate-note/raw/master/%E6%97%A5%E5%BF%97%E8%A7%A3%E6%9E%90%E5%8F%8A%E8%AE%A1%E7%AE%97%EF%BC%9AMR/img/Map%E8%BF%90%E8%A1%8C%E8%BF%87%E7%A8%8B.png “”)]

block是HDFS上的文件塊，split是文件的分片（邏輯劃分，不包含具體數據，只包含這些數據的位置信息）。一個split包含一個或多個block，默認是一對一的關系。一個split不包含兩個文件的block， 不會跨越file邊界，也就是說一個split是不會跨文件進行劃分的。當分片完成后，MR程序會將split中的數據以K/V（key/value）的形式讀取出來，然后將這些數據交給用戶自定義的Map函數進行處理。一個Map處理一個split。用戶用Map函數處理完數據后將處理后，同樣將結果以K/V的形式交給MR的計算框架。MR計算框架會將不同的數據劃分成不同的partition，數據相同的多個partition最后會分到同一個reduce節點上面進行處理，也就是說一類partition對應一個reduce。Map默認使用Hash算法對key值進行Hash計算，這樣保證了相同key值的數據能夠劃分到相同的partition中，同時也保證了不同的partition之間的數據量時大致相當的，參考鏈接一個程序中Map和Reduce的數量是有split和partition的數據決定的。

Reduce處理過程

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-yDsRinfZ-1589376928676)(https://github.com/jiaoqiyuan/163-bigdate-note/raw/master/%E6%97%A5%E5%BF%97%E8%A7%A3%E6%9E%90%E5%8F%8A%E8%AE%A1%E7%AE%97%EF%BC%9AMR/img/Reduce%E5%A4%84%E7%90%86%E8%BF%87%E7%A8%8B.png “”)]

Map處理完后，reduce處理程序在各個Map節點將屬于自己的數據拷貝到自己的內存緩沖區中 最后將這些數據合并成一個大的數據集，并且按照key值進行聚合，把聚合后的value值作為一個迭代器給用戶使用。 用戶使用自定義的reduce函數處理完迭代器中的數據后，一般把結果以K/V的格式存儲到HDFS上的文件中。

Shuffle過程

在上面介紹的MR過程中，還存在一個shuffle過程，發生與Map和Reduce之中。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-nXBx9zAU-1589376928679)(https://github.com/jiaoqiyuan/163-bigdate-note/raw/master/%E6%97%A5%E5%BF%97%E8%A7%A3%E6%9E%90%E5%8F%8A%E8%AE%A1%E7%AE%97%EF%BC%9AMR/img/shuffle%E8%BF%87%E7%A8%8B.png “”)]

Map中的shuffle

Collec階段鍵數據放在環形緩沖區，喚醒緩沖區分為數據區和索引區。 sort階段對在統一partition內的索引按照key值排序。 spill（溢寫）階段根據拍好序的索引將數據按順序寫到文件中。 Merge階段將Spill生成的小文件分批合并排序成一個大文件。 Reduce中的shuffleCopy階段將Map段的數據分批拷貝到Reduce的緩沖區。Spill階段將內存緩沖區的數據按照順序寫到文件中。Merge階段將溢出文件合并成一個排好序的數據集。 Combine優化整個過程中可以提前對聚合好的value值進行計算，這個過程就叫Combine。Combine在Map端發生時間在數據排序后，溢寫到磁盤前，相同key值的value是緊挨在一起的，可以進行聚合運算，運行一次combiner。再合并溢出文件輸出到磁盤前，如果存在至少3個溢出文件，則運行combiner，可以通過min.num.spills.for.combine設置閾值。Reduce端在合并溢出文件輸出到磁盤前，運行combiner。Combiner不是任何情況下都適用的，需要根據業務需要進行設置。

MR運行過程

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-RJX3RjGX-1589376928682)(https://github.com/jiaoqiyuan/163-bigdate-note/raw/master/%E6%97%A5%E5%BF%97%E8%A7%A3%E6%9E%90%E5%8F%8A%E8%AE%A1%E7%AE%97%EF%BC%9AMR/img/MR%E8%BF%90%E8%A1%8C%E8%BF%87%E7%A8%8B.png “”)]

一個文件分成多個split數據片。 每個split由多一個map進行處理。 Map處理完一個數據就把處理結果放到一個環形緩沖區內存中。 環形緩沖區滿后里面的數據會被溢寫到一個個小文件中。 小文件會被合并成一個大文件，大文件會按照partition進行排序。 reduce節點將所有屬于自己的數據從partition中拷貝到自己的緩沖區中，并進行合并。 最后合并后的數據交給reduce處理程序進行處理。 處理后的結果存放到HDFS上。 MR運行在集群上：YARN（Yet Another Resource Negotiator）

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-gxnQd48w-1589376928686)(https://github.com/jiaoqiyuan/163-bigdate-note/raw/master/%E6%97%A5%E5%BF%97%E8%A7%A3%E6%9E%90%E5%8F%8A%E8%AE%A1%E7%AE%97%EF%BC%9AMR/img/YARN%E6%A1%86%E6%9E%B6.png “”)]
__ ResourceManager負責調度和管理整個集群的資源__

• 主要職責是調度，對應用程序的整體進行資源分配

• Nodemanager負責節點上的計算資源，內部包含Container， App Master，管理Container生命周期，資源使用情況，節點健康狀況，并將這些信息回報給RM。

  • Container中包含一些資源信息，如cpu核數，內存大小
  • 一個應用程序由一個App Master管理，App Master負責將應用程序運行在各個節點的Container中，App Master與RM協商資源分配的問題。

  • MapReduce On Yarn

  1
  2
  3
  4
  5

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-nCnd4etj-1589376928688)(https://github.com/jiaoqiyuan/163-bigdate-note/raw/master/%E6%97%A5%E5%BF%97%E8%A7%A3%E6%9E%90%E5%8F%8A%E8%AE%A1%E7%AE%97%EF%BC%9AMR/img/MRonYarn.png “”)]

• MR程序在客戶端啟動，客戶端會向RM發送一個請求。

• RM收到請求后返回一個AppID給客戶端。

• 然后客戶端拿著AppID，用戶名，隊列，令牌向RM發出資源請求。

• 客戶端這時會將程序用到的jar包，資源文件，程序運行中需要的數據等傳送到HDFS上。

• RM接收到客戶端的資源請求后，分配一個container0的資源包，由NodeManager啟動一個AppMaster。

• RM將集群的容量信息發送給AppMaster，AppMaster計算這個程序需要的資源量后，根據需要想RM請求更多的container。

• 最后由各個NodeManager在節點上啟動MapTask和ReduceTask。

  1
  2
  3
  4
  5
  6
  7

Yarn && Job

上面的 Yarn 管理 MR 任務是不是比較粗略，下面我將介紹比較詳細的處理流程：

這也是今日頭條的一個面試題，引發的思考：

MR 任務為例,講一下 Yarn 的整個過程。

Yarn 中的主要組件包括：Resourcemanager,ApplicationMaster, NodeManager。

Resourcemanager：每個Hadoop集群只會有一個ResourceManager（如果是HA的話會存在兩個，但是有且只有一個處于active狀態），啟動每一個 Job 所屬的 ApplicationMaster,另外監控ApplicationMaster 以及NodeManager 的存在情況，并且負責協調計算節點上計算資源的分配。ResourceManager 內部主要有兩個組件：

Scheduler:這個組件完全是插拔式的，用戶可以根據自己的需求實現不同的調度器，目前YARN提供了FIFO、容量以及公平調度器。這個組件的唯一功能就是給提交到集群的應用程序分配資源，并且對可用的資源和運行的隊列進行限制。Scheduler并不對作業進行監控； ApplicationsManager :這個組件用于管理整個集群應用程序的 application masters，負責接收應用程序的提交；為application master啟動提供資源；監控應用程序的運行進度以及在應用程序出現故障時重啟它。

ApplicationMaster：每個 Job 都有對應一個 ApplicationMaster ，并且負責運行 mapreduce 任務，并負責報告任務的狀態。ApplicationMaster是應用程序級別的，每個ApplicationMaster管理運行在YARN上的應用程序。YARN 將 ApplicationMaster看做是第三方組件，ApplicationMaster負責和ResourceManager scheduler協商資源，并且和NodeManager通信來運行相應的task。ResourceManager 為 ApplicationMaster 分配容器，這些容器將會用來運行task。ApplicationMaster 也會追蹤應用程序的狀態，監控容器的運行進度。當容器運行完成， ApplicationMaster 將會向 ResourceManager 注銷這個容器；如果是整個作業運行完成，其也會向 ResourceManager 注銷自己，這樣這些資源就可以分配給其他的應用程序使用了。

NodeManager：負責啟動和管理節點的容器。NodeManager是YARN中每個節點上的代理，它管理Hadoop集群中單個計算節點，根據相關的設置來啟動容器的。NodeManager會定期向ResourceManager發送心跳信息來更新其健康狀態。同時其也會監督Container的生命周期管理，監控每個Container的資源使用（內存、CPU等）情況，追蹤節點健康狀況，管理日志和不同應用程序用到的附屬服務（auxiliary service）。

Container: Container是與特定節點綁定的，其包含了內存、CPU磁盤等邏輯資源。不過在現在的容器實現中，這些資源只包括了內存和CPU。容器是由 ResourceManager scheduler 服務動態分配的資源構成。容器授予 ApplicationMaster 使用特定主機的特定數量資源的權限。ApplicationMaster 也是在容器中運行的，其在應用程序分配的第一個容器中運行。

必須牢記yarn只是一個資源管理的框架，并不是一個計算框架，計算框架可以運行在yarn上。我們所能做的就是向RM申請container,然后配合NM一起來啟動container。

下面是請求資源和分配資源的流程：

1.客戶端向 ResourceManager 發送 job 請求，客戶端產生的 RunJar 進程與 ResourceManager 通過 RPC 通信。
2.ResourceManager 向客戶端返回 job 相關資源的提交路徑以及 jobID。
3.客戶端將 job 相關的資源提交到相應的共享文件夾下。
4.客戶端向 ResourceManager 提交 job
5.ResourceManager 通過__調度器__在 NodeManager 創建一個容器，并且在容器中啟用MRAppmaster 進程，該進程由 ResourceManager 啟動。
6.該 MRAppmaster 進程對作業進行初始化，創建多個對象對作業進行跟蹤。
7.MRAppmaster 從文件系統獲取計算得到輸入分片，只獲取切片信息，不需要jar等資源，為每個分片創建一個 map 以及指定數量的 reduce 對象，之后 MRAppmaster 決定如何運行構成 mapreduce 的各個任務。
8.若作業很大，MRAppmaster 為所有的 map 任務和reduce 任務向 ResourceManger 發起申請容器的請求，請求中包含 map 任務的數據本地化信息以及數據分片等信息。
9.ResourceManager 為任務分配了容器之后，MRAppmaster 就通過 與 NodeManger 通信啟動容器，由 MRAppmaster 負責分配在哪些 NodeManager 負責分配在哪些 NodeManager 上運行map （即 yarnchild 進程）和reduce 任務。
10.運行 mao 和 reduce 任務的 NodeManager 從共享系統中獲取 job 的相關縣，包括 jar 文件，配置文件等。
11.關于查詢狀態，不經過 reourcemanager ，而是任務周期性的 MRAppmaster 匯報狀態以及進度，客戶端每秒通過查詢一次 MRAppmaster 來更新狀態和信息。

上面可以很亂，重點是輔助理解細節，認知到位了，無關細節了吧。

下面總結一下，大概的流程：

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-X10IXJnE-1589376928689)(https://cdn.nlark.com/yuque/0/2018/png/199648/1544534623921-5cd78e48-8181-404c-a67b-41898ca4574a.png “”)]

流程大致如下：
· client客戶端向yarn集群(resourcemanager)提交任務
· resourcemanager選擇一個node創建appmaster
· appmaster根據任務向rm申請資源
· rm返回資源申請的結果
· appmaster去對應的node上創建任務需要的資源（container形式，包括內存和CPU）
· appmaster負責與nodemanager進行溝通，監控任務運行
· 最后任務運行成功，匯總結果。
其中Resourcemanager里面一個很重要的東西，就是調度器Scheduler，調度規則可以使用官方提供的，也可以自定義。

總結

以上是生活随笔為你收集整理的MR详细运行原理及过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。