Hadoop 中 mapreduce 作业日志是如何生成的

摘要：本篇博客介绍了 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 进行处理的。

​​点击关注，第一时间了解华为云新鲜技术~