Hadoop中MapReduce中的counter的意义

女爷i 2022-06-11 08:55 230阅读 0赞

MapReduce Counter为提供我们一个窗口：观察MapReduce job运行期的各种细节数据。今年三月份期间，我曾经专注于MapReduce性能调优工作，是否优化的绝大多评估都是基于这些Counter的数值表现。MapReduce自带了许多默认Counter，可能有些朋友对它们有些疑问，现在我分析下这些默认Counter的含义，方便大家观察job结果。  
  
我的分析是基于Hadoop0.21，我也看过Hadoop其它版本的Counter展现，细节大同小异，如果有差异的地方，以事实版本为主。  
  
Counter有"组group"的概念，用于表示逻辑上相同范围的所有数值。MapReduce job提供的默认Counter分为五个组，下面逐一介绍。这里也拿我的一份测试数据来做详细比对，它们会以表格的形式出现在各组描述中。  
  
**FileInputFormatCounters**  
这个group表示map task读取文件内容(总输入数据)的统计

<table> 
 <tbody> 
  <tr> 
   <td>&nbsp;</td> 
   <td>Counter</td> 
   <td>Map</td> 
   <td>Reduce</td> 
   <td>Total</td> 
  </tr> 
  <tr> 
   <td>FileInputFormatCounters</td> 
   <td>BYTES_READ</td> 
   <td>1,109,990,596</td> 
   <td>0</td> 
   <td>1,109,990,596</td> 
  </tr> 
 </tbody> 
</table>

BYTES\_READ  
Map task的所有输入数据(字节)，等于各个map task的map方法传入的所有value值字节之和。  
  
  
**FileSystemCounters**  
MapReduce job执行所依赖的数据来自于不同的文件系统，这个group表示job与文件系统交互的读写统计

<table> 
 <tbody> 
  <tr> 
   <td>&nbsp;</td> 
   <td>Counter</td> 
   <td>Map</td> 
   <td>Reduce</td> 
   <td>Total</td> 
  </tr> 
  <tr> 
   <td>FileSystemCounters</td> 
   <td>FILE_BYTES_READ</td> 
   <td>0</td> 
   <td>1,544,520,838</td> 
   <td>1,544,520,838</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>FILE_BYTES_WRITTEN</td> 
   <td>1,544,537,310</td> 
   <td>1,544,520,838</td> 
   <td>3,089,058,148</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>HDFS_BYTES_READ</td> 
   <td>1,110,269,508</td> 
   <td>0</td> 
   <td>1,110,269,508</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>HDFS_BYTES_WRITTEN</td> 
   <td>0</td> 
   <td>827,982,518</td> 
   <td>827,982,518</td> 
  </tr> 
 </tbody> 
</table>

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端中间数据时的各种错误。

<table> 
 <tbody> 
  <tr> 
   <td>&nbsp;</td> 
   <td>Counter</td> 
   <td>Map</td> 
   <td>Reduce</td> 
   <td>Total</td> 
  </tr> 
  <tr> 
   <td>Shuffle Errors</td> 
   <td>BAD_ID</td> 
   <td>0</td> 
   <td>0</td> 
   <td>0</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>CONNECTION</td> 
   <td>0</td> 
   <td>0</td> 
   <td>0</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>IO_ERROR</td> 
   <td>0</td> 
   <td>0</td> 
   <td>0</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>WRONG_LENGTH</td> 
   <td>0</td> 
   <td>0</td> 
   <td>0</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>WRONG_MAP</td> 
   <td>0</td> 
   <td>0</td> 
   <td>0</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>WRONG_REDUCE</td> 
   <td>0</td> 
   <td>0</td> 
   <td>0</td> 
  </tr> 
 </tbody> 
</table>

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调度相关的统计

<table> 
 <tbody> 
  <tr> 
   <td>&nbsp;</td> 
   <td>Counter</td> 
   <td>Map</td> 
   <td>Reduce</td> 
   <td>Total</td> 
  </tr> 
  <tr> 
   <td>Job Counters</td> 
   <td>Data-local map tasks</td> 
   <td>0</td> 
   <td>0</td> 
   <td>67</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>FALLOW_SLOTS_MILLIS_MAPS</td> 
   <td>0</td> 
   <td>0</td> 
   <td>0</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>FALLOW_SLOTS_MILLIS_REDUCES</td> 
   <td>0</td> 
   <td>0</td> 
   <td>0</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>SLOTS_MILLIS_MAPS</td> 
   <td>0</td> 
   <td>0</td> 
   <td>1,210,936</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>SLOTS_MILLIS_REDUCES</td> 
   <td>0</td> 
   <td>0</td> 
   <td>1,628,224</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>Launched map tasks</td> 
   <td>0</td> 
   <td>0</td> 
   <td>67</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>Launched reduce tasks</td> 
   <td>0</td> 
   <td>0</td> 
   <td>8</td> 
  </tr> 
 </tbody> 
</table>

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, …\]\}。

<table> 
 <tbody> 
  <tr> 
   <td>&nbsp;</td> 
   <td>Counter</td> 
   <td>Map</td> 
   <td>Reduce</td> 
   <td>Total</td> 
  </tr> 
  <tr> 
   <td>Map-Reduce Framework</td> 
   <td>Combine input records</td> 
   <td>200,000,000</td> 
   <td>0</td> 
   <td>200,000,000</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>Combine output records</td> 
   <td>117,838,546</td> 
   <td>0</td> 
   <td>117,838,546</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>Failed Shuffles</td> 
   <td>0</td> 
   <td>0</td> 
   <td>0</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>GC time elapsed (ms)</td> 
   <td>23,472</td> 
   <td>46,588</td> 
   <td>70,060</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>Map input records</td> 
   <td>10,000,000</td> 
   <td>0</td> 
   <td>10,000,000</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>Map output bytes</td> 
   <td>1,899,990,596</td> 
   <td>0</td> 
   <td>1,899,990,596</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>Map output records</td> 
   <td>200,000,000</td> 
   <td>0</td> 
   <td>200,000,000</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>Merged Map outputs</td> 
   <td>0</td> 
   <td>536</td> 
   <td>536</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>Reduce input groups</td> 
   <td>0</td> 
   <td>84,879,137</td> 
   <td>84,879,137</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>Reduce input records</td> 
   <td>0</td> 
   <td>117,838,546</td> 
   <td>117,838,546</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>Reduce output records</td> 
   <td>0</td> 
   <td>84,879,137</td> 
   <td>84,879,137</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>Reduce shuffle bytes</td> 
   <td>0</td> 
   <td>1,544,523,910</td> 
   <td>1,544,523,910</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>Shuffled Maps</td> 
   <td>0</td> 
   <td>536</td> 
   <td>536</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>Spilled Records</td> 
   <td>117,838,546</td> 
   <td>117,838,546</td> 
   <td>235,677,092</td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td>SPLIT_RAW_BYTES</td> 
   <td>8,576</td> 
   <td>0</td> 
   <td>8,576</td> 
  </tr> 
 </tbody> 
</table>

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无关，这里记录的大小就是表示额外信息的字节大小