Hadoop阅读笔记(四)——一幅图看透MapReduce机制
時至今日,已然看到第十章,似乎越是焦躁什么時候能翻完這本圣經的時候也讓自己變得更加浮躁,想想后面還有一半的行程沒走,我覺得這樣“有口無心”的學習方式是不奏效的,或者是收效甚微的。如果有幸能有大牛路過,請指教如何能以效率較高的方式學習Hadoop。
我已經記不清圣經《hadoop 實戰2》在我手中停留了多久,但是每一頁每一章的翻過去,還是在腦殼里留下了點什么。
一段時間以來,我還是通過這本書加深以及糾正了我對于MapReduce、HDFS乃至Hadoop的新的認識。本篇主要介紹MapReduce作業的工作機制,并介紹介于Map和Reduce過程中的Shuffle和排序過程。
為響應標題,我們今天談的MapReduce機制,切入點是一張圖。先上圖:
從圖中不難看出,整個MapReduce分為以下流程:代碼編寫->作業配置->作業提交->Map任務的分配和執行->處理中間結果->Reduce任務的分配和執行->作業完成
圖中:
1.運行作業
2.獲取作業ID
3.復制作業資源
4.提交作業
5.初始化作業
6.獲取輸入分割
7.心跳通信
8.獲取作業資源
9.發布
10.運行
以上過程主要涉及到的實體有客戶端(用于MR代碼的編寫,配置作業,提交作業);TaskTracker(保持與JobTracker通信,在分配的數據片段上執行Map或Reduce任務);HDFS(保存作業的數據、配置信息、作業結果等);JobTracker(初始化作業,分配作業,與TaskTracker通信,協調整個作業的執行)
?
提交作業
在提交作業前,我們需要對作業進行配置,主要包括:
(1)程序代碼
(2)Map和Reduce接口
(3)輸入輸出路徑
(4)其他配置,如InputFormat、OutputFormat等
?
提交作業的過程可以分為以下幾步:
(1)調用JobTracker對象的getNewJobId()方法從JobTracker處獲取當前作業的ID(見途中步驟2)
(2)檢查作業相關路徑,在運行代碼時,經常遇到報錯提示輸出目錄已存在,所以在運行代碼前要確保輸出目錄不存在
(3)計算作業的輸入劃分
(4)將運行所需資源(如jar文件、配置文件、計算所得輸入劃分等)復制到作業對于的HDFS上(見步驟3)
(5)調用JobTracker對象的submitJob()方法來真正提交作業,通知JobTracker作業準備執行(見步驟4)
?
初始化作業
JobTracker在客戶端調用其submitJob()方法后,會將此調用放入內部的TaskScheduler變量中,進行調度,默認調度方法為:JobQueueTaskScheduler即FIFO調度方式。
初始化作業分為如下幾個步驟:
(1)從HDFS中讀取作業對應的job.split(見步驟6),JobTracker從HDFS中作業對應的路徑獲取JobClient在步驟3中寫入的job.split文件,得到輸入數據的劃分信息,為后面初始化過程中Map任務的分配做好準備。
(2)創建并初始化Map任務和Reduce任務。
(3)創建兩個初始化Task,根據個數和輸入劃分已經配置的信息,并分別初始化Map和Reduce。
?
分配任務:
TaskTracker和JobTracker之間的通信和任務分配都是通過心跳機制完成的。TaskTracker會以一定間隔時間向JobTracker發送心跳,告訴自己是否存活,準備執行新任務;而JobTracker在接收到心跳信息后會查看是否有待分配任務,如果有,則會分配給TaskTracker。
?
執行任務:
當TaskTracker接收到新任務時就要開始運行任務,第一步就是將任務本地化,將任務所需的數據、配置信息、程序代碼從HDFS復制到TaskTracker本地(將步驟8)。該過程主要通過localizeJob()方法來實現任務的本地化,具體包括以下幾個步驟:
(1)將job.split復制到本地
(2)將job.jar復制到本地
(3)將job的配置信息寫入job.xml
(4)創建本地任務目錄,解壓job.jar
(5)調用launchTaskForJob()方法發布任務(見步驟9)
?
更新任務執行進度和狀態:
由MapReduce作業分割成的每個任務中都有一組計數器,他們對任務執行過程中的進度組成事件進行計數。如果任務要報告進度,它便會設置一個標志以表明狀態變化將會發送到TaskTracker上,另一個監聽線程檢查到這標志后,會告知TaskTracker當前的任務狀態。
?
完成作業:
所有TaskTracker任務的執行進度信息都匯總到JobTracker處,當JobTracker接收到最后一個任務的已完成通知后,便把作業的狀態設置為“成功”。
?
Shuffle和排序:
在Map和Reduce之間有一個叫做Shuffle的過程,主要的工作是將Map的輸出結果進行一定的排序和分割再交給Reduce,從某種程度上說,Shuffle過程的性能與整個MapReduce的性能直接相關。
Shuffle過程分為Map和Reduce端。Map端的Shuffle過程是對Map的結果進行劃分(partition)、排序(sort)和分割(spill),然后將屬于同一個劃分的輸出合并在一起(merge)并寫在磁盤上,同時按照不同的劃分將結果發送給對應的Reduce(Map輸出的劃分與Reduce的對應關系由JobTracker確定)。
Reduce端又會將各個Map送來的屬于同一個劃分的輸出進行合并(merge),然后對merge的結果進行排序,最后交給Reduce處理。
對于Hadoop等大數據技術有興趣的歡迎加群413471695交流討論^_^
本文鏈接:《Hadoop閱讀筆記(四)——一幅圖看透MapReduce機制》
?
友情贊助
如果你覺得博主的文章對你那么一點小幫助,恰巧你又有想打賞博主的小沖動,那么事不宜遲,趕緊掃一掃,小額地贊助下,攢個奶粉錢,也是讓博主有動力繼續努力,寫出更好的文章^^。
1. 支付寶 2. 微信
轉載于:https://www.cnblogs.com/bigdataZJ/p/hadoopreading4.html
總結
以上是生活随笔為你收集整理的Hadoop阅读笔记(四)——一幅图看透MapReduce机制的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: LocalReport Print wi
- 下一篇: android实现类似于支付宝余额快速闪