MapReduce Counter为我们提供了一个窗口：观察MapReduce job运行期的各种细节数据。今年三月份，我曾专注于MapReduce性能调优工作，是否优化的绝大多评估都是基于这些Counter的数值表现。MapReduce自带了许多默认Counter，可能有些朋友对它们有些疑问，现在我们分析下这些默认Counter的含义，方便大家观察job结果。
我的分析是基于Hadoop0.21,我也看过Hadoop其他版本的Counter展现，细节大同小异，如果有差异的地方，以事实版本为主。
Counter有"组group"的概念，用于表示逻辑上相同范围的所有数值。MapReduce Job提供的默认Counter分为五个组，下面逐一介绍。这里也拿我的一份测试数据做详细对比，他们会以表格的形式出现在各组描述中。
FileInputFormatCounters
这个group表示MapTask读取文件内容(总输入数据)的统计
|
Counter |
Map |
Reduce |
Total |
|
|
FileInputFormatCounters |
BYTES_READ |
1,109,990,596 |
0 |
1,109,990,596 |
BYTES_READ
MapTask的所有输入数据(字节)，等于各个MapTask的map方法传入的所有value值字节之和。
FileSystemCounter
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端这里的数据就表示MapTask往本地磁盘中共写了多少字节。与Map端相对应的是，reduce端在Shuffle时，会不断拉取Map端的中间结果，然后做merge并不断spill到自己的本地磁盘中。最终形成一个单独文件，这个文件就是reduce的输入文件。
HDFS_BYTES_READ
整个job执行过程中，只有map端运行时，才会从HDFS读取数据，这些数据不限于源文件内容，还包括所有map的split元数据。所以这个值应该比FileInputFormatCounter.BYTES_READ要略大些。
HDFS_BYTES_WRITTEN
Reduce的最终结果都会写入HDFS，就是一个Job执行结果的总量。
Shuffle Errors
这组内描述Shuffle过程中的各种错误情况发生次数，基本定位于Shuffle阶段copy线程抓取map端中间数据时的各种错误。
|
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 Counter
这个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为某些MapTask的执行保留了slot，总共保留的时间是多少。
FALLOW_SLOTS_MILLIS_REDUCES
与上面类似
SLOTS_MILLIS_MAPS
所有MapTask占用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,2,8,...]}
|
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
所有MapTask从HDFS读取的文件总数
Map output records
MapTask的直接输出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端抓去了多少的中间数据，表示各个MapTask最终的中间文件总和。
Shuffled Maps
每个reduce几乎都得从所有Map端拉取数据，每个copy线程拉取成功一个map的数据，那么增1，所以它的总数基本等于reduce number*map number
Spilled Records
spill过程在map和reduce端都会发生，这里统计的是总共从内存往磁盘中spill了多少条数据。
SPLIT_RAW_BYTES
与MapTask的split相关的数据都会保存于HDFS中，而在保存时元数据也相对应的存储着数据是以怎样的压缩方式放入的，它的具体类型是什么，这些额外的数据是MapReduce框架加入的，与job无关，这里记录的大小就是表示额外信息的字节大小。