MapReduce Counter为提供咱们一个窗口:观察MapReduce job运行期的各类细节数据。今年三月份期间,我曾经专一于MapReduce性能调优工做,是否优化的绝大多评估都是基于这些Counter的数值表现。MapReduce自带了许多默认Counter,可能有些朋友对它们有些疑问,如今我分析下这些默认Counter的含义,方便你们观察job结果。
个人分析是基于Hadoop0.21,我也看过Hadoop其它版本的Counter展示,细节大同小异,若是有差别的地方,以事实版本为主。
Counter有"组group"的概念,用于表示逻辑上相同范围的全部数值。MapReduce job提供的默认Counter分为五个组,下面逐一介绍。这里也拿个人一份测试数据来作详细比对,它们会以表格的形式出如今各组描述中。
FileInputFormatCounters
这个group表示map task读取文件内容(总输入数据)的统计
网络
Counter | Map | Reduce | Total | |
FileInputFormatCounters | BYTES_READ | 1,109,990,596 | 0 | 1,109,990,596 |
BYTES_READ
Map task的全部输入数据(字节),等于各个map task的map方法传入的全部value值字节之和。
FileSystemCounters
MapReduce job执行所依赖的数据来自于不一样的文件系统,这个group表示job与文件系统交互的读写统计
框架
Counter | Map | Reduce | Total | |
FileSystemCounters | FILE_BYTES_READ | 0 | 1,544,520,838 | 1,544,520,838 |
FILE_BYTES_WRITTEN | 1,544,537,310 | 1,544,520,838 | 3,089,058,148 | |
HDFS_BYTES_READ | 1,110,269,508 | 0 | 1,110,269,508 | |
HDFS_BYTES_WRITTEN | 0 | 827,982,518 | 827,982,518 |
FILE_BYTES_READ
job读取本地文件系统的文件字节数。假定咱们当前map的输入数据都来自于HDFS,那么在map阶段,这个数据应该是0。但reduce在执行前,它的输入数据是通过shuffle的merge后存储在reduce端本地磁盘中,因此这个数据就是全部reduce的总输入字节数。
FILE_BYTES_WRITTEN
map的中间结果都会spill到本地磁盘中,在map执行完后,造成最终的spill文件。因此map端这里的数据就表示map task往本地磁盘中总共写了多少字节。与map端相对应的是,reduce端在shuffle时,会不断地拉取map端的中间结果,而后作merge并不断spill到本身的本地磁盘中。最终造成一个单独文件,这个文件就是reduce的输入文件。
HDFS_BYTES_READ
整个job执行过程当中,只有map端运行时,才从HDFS读取数据,这些数据不限于源文件内容,还包括全部map的split元数据。因此这个值应该比FileInputFormatCounters.BYTES_READ 要略大些。
HDFS_BYTES_WRITTEN
Reduce的最终结果都会写入HDFS,就是一个job执行结果的总量。
Shuffle Errors
这组内描述Shuffle过程当中的各类错误状况发生次数,基本定位于Shuffle阶段copy线程抓取map端中间数据时的各类错误。 oop
Counter | Map | Reduce | Total | |
Shuffle Errors | BAD_ID | 0 | 0 | 0 |
CONNECTION | 0 | 0 | 0 | |
IO_ERROR | 0 | 0 | 0 | |
WRONG_LENGTH | 0 | 0 | 0 | |
WRONG_MAP | 0 | 0 | 0 | |
WRONG_REDUCE | 0 | 0 | 0 |
BAD_ID
每一个map都有一个ID,如attempt_201109020150_0254_m_000000_0,若是reduce的copy线程抓取过来的元数据中这个ID不是标准格式,那么此Counter增长 性能
CONNECTION
表示copy线程创建到map端的链接有误
IO_ERROR
Reduce的copy线程若是在抓取map端数据时出现IOException,那么这个值相应增长
WRONG_LENGTH
map端的那个中间结果是有压缩好的有格式数据,全部它有两个length信息:源数据大小与压缩后数据大小。若是这两个length信息传输的有误(负值),那么此Counter增长
WRONG_MAP
每一个copy线程固然是有目的:为某个reduce抓取某些map的中间结果,若是当前抓取的map数据不是copy线程以前定义好的map,那么就表示把数据拉错了
WRONG_REDUCE
与上面描述一致,若是抓取的数据表示它不是为此reduce而准备的,那仍是拉错数据了。
Job Counters
这个group描述与job调度相关的统计 测试
Counter | Map | Reduce | Total | |
Job Counters | Data-local map tasks | 0 | 0 | 67 |
FALLOW_SLOTS_MILLIS_MAPS | 0 | 0 | 0 | |
FALLOW_SLOTS_MILLIS_REDUCES | 0 | 0 | 0 | |
SLOTS_MILLIS_MAPS | 0 | 0 | 1,210,936 | |
SLOTS_MILLIS_REDUCES | 0 | 0 | 1,628,224 | |
Launched map tasks | 0 | 0 | 67 | |
Launched reduce tasks | 0 | 0 | 8 |
Data-local map tasks
Job在被调度时,若是启动了一个data-local(源文件的幅本在执行map task的taskTracker本地)
FALLOW_SLOTS_MILLIS_MAPS
当前job为某些map task的执行保留了slot,总共保留的时间是多少
FALLOW_SLOTS_MILLIS_REDUCES
与上面相似
SLOTS_MILLIS_MAPS
全部map task占用slot的总时间,包含执行时间和建立/销毁子JVM的时间
SLOTS_MILLIS_REDUCES
与上面相似
Launched map tasks
此job启动了多少个map task
Launched reduce tasks
此job启动了多少个reduce task
Map-Reduce Framework
这个Counter group包含了至关多地job执行细节数据。这里须要有个概念认识是:通常状况下,record就表示一行数据,而相对地byte表示这行数据的大小是多少,这里的group表示通过reduce merge后像这样的输入形式{“aaa”, [5, 8, 2, …]}。 优化
Counter | Map | Reduce | Total | |
Map-Reduce Framework | Combine input records | 200,000,000 | 0 | 200,000,000 |
Combine output records | 117,838,546 | 0 | 117,838,546 | |
Failed Shuffles | 0 | 0 | 0 | |
GC time elapsed (ms) | 23,472 | 46,588 | 70,060 | |
Map input records | 10,000,000 | 0 | 10,000,000 | |
Map output bytes | 1,899,990,596 | 0 | 1,899,990,596 | |
Map output records | 200,000,000 | 0 | 200,000,000 | |
Merged Map outputs | 0 | 536 | 536 | |
Reduce input groups | 0 | 84,879,137 | 84,879,137 | |
Reduce input records | 0 | 117,838,546 | 117,838,546 | |
Reduce output records | 0 | 84,879,137 | 84,879,137 | |
Reduce shuffle bytes | 0 | 1,544,523,910 | 1,544,523,910 | |
Shuffled Maps | 0 | 536 | 536 | |
Spilled Records | 117,838,546 | 117,838,546 | 235,677,092 | |
SPLIT_RAW_BYTES | 8,576 | 0 | 8,576 |
Combine input records
Combiner是为了减小尽可能减小须要拉取和移动的数据,因此combine输入条数与map的输出条数是一致的。
Combine output records
通过Combiner后,相同key的数据通过压缩,在map端本身解决了不少重复数据,表示最终在map端中间文件中的全部条目数
Failed Shuffles
copy线程在抓取map端中间数据时,若是由于网络链接异常或是IO异常,所引发的shuffle错误次数
GC time elapsed(ms)
经过JMX获取到执行map与reduce的子JVM总共的GC时间消耗
Map input records
全部map task从HDFS读取的文件总行数
Map output records
map task的直接输出record是多少,就是在map方法中调用context.write的次数,也就是未通过Combine时的原生输出条数
Map output bytes
Map的输出结果key/value都会被序列化到内存缓冲区中,因此这里的bytes指序列化后的最终字节之和
Merged Map outputs
记录着shuffle过程当中总共经历了多少次merge动做
Reduce input groups
Reduce总共读取了多少个这样的groups
Reduce input records
若是有Combiner的话,那么这里的数值就等于map端Combiner运算后的最后条数,若是没有,那么就应该等于map的输出条数
Reduce output records
全部reduce执行后输出的总条目数
Reduce shuffle bytes
Reduce端的copy线程总共从map端抓取了多少的中间数据,表示各个map task最终的中间文件总和
Shuffled Maps
每一个reduce几乎都得从全部map端拉取数据,每一个copy线程拉取成功一个map的数据,那么增1,因此它的总数基本等于 reduce number * map number
Spilled Records
spill过程在map和reduce端都会发生,这里统计在总共从内存往磁盘中spill了多少条数据
SPLIT_RAW_BYTES
与map task 的split相关的数据都会保存于HDFS中,而在保存时元数据也相应地存储着数据是以怎样的压缩方式放入的,它的具体类型是什么,这些额外的数据是MapReduce框架加入的,与job无关,这里记录的大小就是表示额外信息的字节大小 线程
转自:http://langyu.iteye.com/blog/1171091code