TDW是基于Hadoop生态圈研发的大数据处理平台，MapReduce计算引擎在TDW平台中承担了所有的离线数据计算，是TDW最重要的底层支撑平台之一。在TDW 平台中，除了MR程序会生成MapReduce作业外，被广泛应用的Hive、tPig等计算框架最终也会把查询语言翻译成MapReduce作业来进行计算，因此对MapReduce作业运行信息进行收集并提供给开发人员查询分析，是他们定位业务问题的最重要手段。不仅仅如此，基于收集的MapReduce作业运行信息，还能建立众多的监控指标来对整个MapReduce计算引擎的健康度进行监控。因此，收集MapReduce作业的运行信息对整个Hadoop平台的使用和稳定运行都是十分必要的。
HadoopDoctor介绍
HadoopDoctor，是TDW专门收集MapReduce作业运行信息的系统。HadoopDoctor不需要对集群的Hadoop代码进行修改，是TDW的外围系统，独立运行，与Hadoop自带的HistoryServer服务相比，HadoopDoctor支持作业信息的多维度查询和支持统计分析。
TDW的MapReduce计算引擎经历了MapReduce V1 -> Corona -> MapReduce V2三个阶段。从Corona开始，MapReduce架构便发生了巨大的变化，JobTracker不再是单点，新架构把集群资源调度和作业管理分开，实现了JobTracker的分散化。同样，HadoopDoctor的实现架构也经历了相应的变化。
HadoopDoctor的基本架构主要包括作业信息采集与存储、数据冷备、数据使用：
作业信息采集与存储
1、MapReduce V1架构下的HadoopDoctor
MapReduce V1是Master-Slaves架构，主节点JobTracker负责集群资源调度和作业运行管理，每道MR作业执行完成后会生成JobConf文件和JobHisotry文件在JobTracker的本地磁盘上，MapReduce V1架构下的HadoopDoctor作业信息采集是在JobTracker部署一个doctorparser程序，定时对各个作业的JobConf和JobHistory文件进行解析，将解析后的数据写到tPG数据库（tPG作为腾讯商业数据库的替代方案，基于开源软件PostgreSQL进行扩展，拥有与商业数据库类似的特性）。
2、Corona/MapReduce V2架构下的HadoopDoctor
从Corona架构开始，MapReduce便实现了JobTracker分散化功能，集群资源调度由ClusterManager（简称CM）实现，JobTracker作为进程运行在子节点CoronaTaskTracker（简称CTT）上面，只负责监控一个MR作业的运行管理。MapReduce V2也是实现了JobTracker分散化功能，集群的资源调度由ResourceManager（简称RM）实现，JobTracker抽象成ApplicaitonMaster（简称AM）作为一个Container运行在子节点NodeManager（简称NM）上面，只负责监控一个MR作业的运行管理。Corona/Mapreduce V2的MR作业同样会产生JobConf和JobHistory文件，但由于JobTracker分散化后，这两个文件也分布到各个子节点上面，因此作业信息采集需要分布到各个子节点上面进行。
新架构下的HadoopDoctor引入DoctorMaster新角色，其职责是从CM/RM获取子节点列表，定时、分批次地拉起子节点的doctorparser程序对作业的JobConf和JobHistory进行解析写到tPG，有效控制tPG的写并发量。
数据冷备
目前TDW每天运行的MR作业数超过1百万，Map Task超过7千万，Reduce Task超过8百万，如此庞大的数据会使得tPG服务器的存储压力过大，HadoopDoctor的历史数据必须要实现冷备功能。而TDW本身是数据仓库，因此用它来做HadoopDoctor的历史数据存储是最合适不过了。把历史数据从tPG导入到TDW的Hive表，不仅仅实现了数据冷备功能，还可以使用TDW-IDE编写SQL语句对数据进行统计分析。
数据使用
- 提供前台页面供用户查询作业的详细信息。
- 建立指标检测MapReduce计算引擎的健康度。
参考链接：http://mta.qq.com/mta/bigdata/?p=633