MapReduce源码阅读笔记

Jobhistory

保存了集群运行过的历史Job信息数据。粒度较细的监控服务，能够分析集群中特点节点机器上哪个task异常,导致拖垮整个集群的运作效率。

JobHistory用来记录已经finished的mapreduce运行日志，日志信息存放于HDFS目录中，默认情况下没有开启此功能，需要在mapred-site.xml、yarn-site.xml配置，并手动启动。

MapReduce有三层调度模型，即Job——>Task——>TaskAttempt，并且：

1、通常一个Job存在多个Task，这些Task总共有Map Task和Redcue Task两种大的类型（为简化描述，Map-Only作业、JobSetup Task等复杂的情况这里不做考虑）；

2、每个Task可以尝试运行1-n此，而且通常很多情况下都是1次，只有当开启了推测执行原理且存在拖后腿Task，或者Task之前执行失败时，Task才执行多次。

而TaskImpl中存在一个成员变量attempts，用来存储Task所包含TaskAttempt中TaskAttemptId与TaskAttempt的映射关系

launcher

环形缓冲区的特性：

当一个数据元素被用掉后，其余数据元素不需要移动其存储位置。相反，一个非圆形缓冲区（例如一个普通的队列）在用掉一个数据元素后，其余数据元素需要向前搬移。
换句话说，圆形缓冲区适合实现FIFO先进先出缓冲区，而非圆形缓冲区适合后进先出缓冲区。
适合于事先明确了缓冲区的最大容量的情形。扩展一个圆形缓冲区的容量，需要搬移其中的数据。因此一个缓冲区如果需要经常调整其容量，用链表实现更为合适。

Timeline

timeline是什么？

Timeline Server是YARN的一个公用组件，它可以以更通用的方式来检索YARN中当前运行的、以及历史运行的作业。YARN Timeline Server是一个不依赖于任何应用的——基于YARN的Job History。

它能存储和检索应用当前和历史信息在yarn配置的地址里，它有两个特性：持久化应用特定信息和保存已完成应用的相关信息

timeline能做什么

1. 持久化应用特定信息：

它能收集和检索应用或者框架的完整信息。

例如：

hadoop的MapReduce框架它包含的信息像多少个map tasks，reduce tasks，counters等等

应用开发者发布的指定的信息到timeline server通过在application master or application的containers里的timeline client

这些信息可以通过rest api可查询，以便由特定应用程序或者框架的uis进行渲染

2. 保存已完成应用的相关信息：

jobhistory仅支持MapReduce作业的任务，随着timeline server的出现，应用的history将只是timeline server的一部分通用信息包括应用层数据，比如：

· 队列名
· 用户信息以及应用的上下文信息
· 运行任务的尝试列表
· 每一个应用尝试的信息
· 每一个尝试信息下container列表
· 每个container信息

一般数据由yarn resourcemanager发布到timeline store和由其web ui来显示有关已完成应用程序的信息

timeline结构

Timeline Domain（时间轴域）

Timeline域为Timeline服务器提供了一个命名空间，允许用户托管多个实体，将它们与其他用户和应用程序隔离开来。时间轴服务器安全性在此级别定义。

“域”主要存储所有者信息、读取和写入ACL信息、创建和修改的时间戳信息。每个域由ID标识，该ID在yarn集群中的所有用户中必须是唯一的。

Timeline Entity（时间线实体）

时间线实体包含概念实体及其相关事件的元信息。实体可以是应用程序、应用程序尝试、容器或任何用户定义的对象。它包含将用于索引时间线存储中的实体的主筛选器。因此，用户/应用程序应仔细选择要存储的信息作为主筛选器。剩余的数据可以存储为未索引的信息。每个实体由实体id和实体类型唯一标识。

Timeline Events（时间线事件）

时间线事件描述与应用程序的特定时间线实体相关的事件。

用户可以自由定义事件的含义，例如启动应用程序、分配容器、操作失败或其他被认为与用户和群集操作员相关的信息。

ACLs:

DFS支持POSIXAccess Control Lists（ACL），也就是传统的POSIX权限控制。通过提供一种方式来设置特定用户或用户组指定为不同权限的HDFS文件ACL访问控制，类似于Linux文件系统权限.

Metrics

在应用程序中，通常会记录日志以便事后分析，在很多情况下是产生了问题之后，再去查看日志，是一种事后的静态分析。在很多时候，我们可能需要了解整个系统在当前，或者某一时刻运行的情况，比如一个系统后台服务，我们可能需要了解一些实时监控的数据例如

一个图片压缩服务：

1. 每秒钟的请求数是多少（TPS）？
2. 平均每个请求处理的时间？
3. 请求处理的最长耗时？
4. 等待处理的请求队列长度？

又或者一个缓存服务：

1. 缓存的命中率？
2. 平均查询缓存的时间？
3. 请求处理的响应的直方图？
4. 请求处理正确响应率？
5. 查看整个系统的的CPU使用率、内存占用、jvm运行情况；以及系统运行出错率等等一系列的实时数据采集时，最简单的方法就是在系统的入口、出口和关键位置设置埋点，然后将采集到的信息发送到实时监控平台或者存入到缓存和DB中做进一步的分析和展示。

基本上每一个服务、应用都需要做一个监控系统，这需要尽量以少量的代码，实现统计某类数据的功能。

以 Java 为例，目前最为流行的 metrics 库是来自 Coda Hale 的 dropwizard/metrics，该库被广泛地应用于各个知名的开源项目中。例如 Hadoop，Kafka，Spark，JStorm 中。

Metrics作为一款监控指标的度量类库，提供了许多工具帮助开发者来完成各项数据的监控。

详见官方文档：https://metrics.dropwizard.io/3.1.0/manual/core/

uber模式：

当任务小的时候就会启动一个JVM运行MapReduce作业，这在MapReduce1中是不允许的；这样的作业在YARN中成为uber作业，通过设置mapreduce.job.ubertask.enable设置为false使用；那什么是小任务呢?当小于10个mapper且只有1个reducer且输入大小小于一个HDFS块的任务。

小任务适合的模式, 不再申请新的Container, 所有的Mapper和Reducer都在该Container中运行

判断一个任务是否按照Uber模式运行的条件如下:

1. map数量小于mapreduce.job.ubertask.maxmaps 默认是9
2. reduce数量小于mapreduce.job.ubertask.maxreduces 默认是1
3. 输入文件小于mapreduce.job.ubertask.maxbytes 默认是一个block
4. map+reduce所需要的资源量小于AM能申请资源的上限