Hadoop中mapreduce作業日誌是如何生成的

語言: CN / TW / HK
摘要:本篇部落格介紹了hadoop中mapreduce型別的作業日誌是如何生成的。主要介紹日誌生成的幾個關鍵過程,不涉及過多細節性的內容。

本文分享自華為雲社群《hadoop中mapreduce作業日誌是如何生成的》,作者:mxg。

我們知道hadoop分為三大塊:HDFS,Yarn,Mapreduce。其中mapreduce相關的核心程式碼都在hadoop-mapreduce-project子工程中。

其中比較重要的功能模組有:MRAppMaster, JobHistory,以及mapreduceClient,分別對應上面的app,hs和jobclient。當然還有一些公共的工具類這裡不再細表。

MRAppMaster:作為一個yarn application執行的第一個Container,用於為所屬的mapreduce job申請task資源,並且監控task的執行狀態。

注意這裡引入了名詞:yarn application和mapreduce job,其實是同一個事物兩種不同層面下的叫法。Yarn裡面執行的所有的應用都稱之為application,而job是一個mapreduce型別的application在mapreduce框架下的叫法,在其他計算框架下可能又有別的叫法,總之一點,無論在計算框架側怎麼叫,在yarn這裡都是yarn application。

記住這些開源社群既定的名詞有助於我們理解程式碼,例如當看到job相關的介面,潛意識就要反應過來,這是jobhistory或者MRAppMaster的介面,如果是Application相關的介面,那麼這肯定是ResourceManager的介面。

HistoryServer:我們知道yarn application 在AM執行的時候,預設會將這個job的執行日誌上傳到hdfs路徑:/tmp/hadoop-yarn/staging,當然也可以使用引數:yarn.app.mapreduce.am.staging-dir配置成任何想要的路徑。甚至可以跨域檔案系統,例如不在hdfs上面儲存。AM日誌最終會組織成一個特定的格式jhist,HistoryServer會去解析,並通過web頁面友好的展示出來。

jobclient:提供一些介面用於用於job的管理,例如作業的提交。

下面介紹下一個mapreduce job的AM日誌生成的幾個階段。其中設計三個重要的引數:
1-執行完的mr作業的臨時日誌目錄;
mapreduce.jobhistory.intermediate-done-dir:/mr-history/tmp
2-執行完的mr作業的最終目錄
mapreduce.jobhistory.done-dir: /mr-history/done
3-AM執行過程中的日誌持久化目錄
yarn.app.mapreduce.am.staging-dir: /tmp/hadoop-yarn/staging

下面介紹AM日誌在job執行的不同階段在上面的三個目錄中是如何轉移的。

Phase1
AM的執行日誌會存放到hdfs路徑:/tmp/hadoop-yarn/staging,並且在job執行的過程中一直動態更新.

Phase2
Job執行完成之後,AM會將/tmp/hadoop-yarn/staging路徑下面的job日誌拷貝到/mr-history/tmp路徑下(包含:jhist檔案,summary檔案以及conf.xml檔案),剛拷貝過去的時候這些檔案均已.tmp為字尾;
完全拷貝成功之後才會將tmp字尾的檔案全部重新命名為正常的檔名;

Phase3
JobHistoryServer程序中有一個JobHistory型別的Service(參考JHS的初始化過程以及服務介紹章節)
而JobHistory這個Service功能很簡單:

1-定時將phase2生成的/mr-history/tmp目錄下的完成job的日誌拷貝到/mr-history/done目錄下,當然拷貝完之後即刪除/mr-history/tmp下面的日誌檔案;
2-定時掃描/mr-history/done目錄下的job日誌檔案,將超過生存週期的全部刪掉,即刪掉之後的job資訊將不能在JobHistoryServer 的web頁面中看到了。

因此對於一個已經執行結束的mapreduce job,我們從JobHistoryServer的web頁面上可以正常訪問其job日誌以及每一個task的日誌。其實就是訪問了/mr-history/done和/tmp/logs/日誌。

其中/mr-history/done/裡面記錄了job的一些配置以及task的基本概況資訊(多少map,多少reduce,多少成功,多少失敗等)。

其中/tmp/logs種記錄了application中所有的container(即task)的詳細日誌,從job頁面跳轉到task頁面的資料就是從這裡獲取的。

細心的小夥伴可能已經注意到了,phase2的AM日誌截圖中不難看出,在作業執行完成之後,日誌拷貝到intermediate-dir之前,首先設定了這個job日誌的連結。這個連結其實就是jobhistoryServer web服務的地址。

一個典型的正在執行的application在yarn的原生頁面中的資訊如下圖所示。其連結為:https://{RESOURCEMANAGER_IP}:{PORT}/Yarn/ResourceManager/45/proxy/application_1636508815320_0003/。

顯然,這時候訪問的還是resourceManager,也就是說在執行的過程當時還和jobhistoryServer沒有什麼關係。

類似的,如果我們要檢視一個執行過程中的job的某些已經執行結束的task的詳細日誌資訊,那麼將會訪問相應的nodemanager獲取,如下圖所示。

從連結資訊中也不難看出,這裡訪問的是nodemanager,該過程也和jobhistoryServer沒有什麼關係。

然而當一個yarn application執行結束的之後,application概覽頁面的History連結就不再是上面的ResourceManager連結了,轉而變成了JobHistoryServer連結。

也即是說對於一個執行過程中的job,頁面上的所有日誌訪問請求都是yarn承接的,而對於已經執行結束的job,除了yarn的application 頁面概覽之外,之後的所有請求都會跳轉到JobHistoryServer來處理。

一個執行結束的job的連線可能是這樣:https://{RESOURCEMANAGER_IP}:{PORT}/Yarn/ResourceManager/45/proxy/application_1636508815320_0003/

同樣,對於一個已經執行完成的job,檢視其某一個task/container日誌的時候也是由JobHistoryServer進行處理的。

 

點選關注,第一時間瞭解華為雲新鮮技術~