MapReduce:默认Counter的含义

本文深入解析MapReduceCounter的作用与意义,详细介绍MapReduce自带的多种默认Counter及其含义,帮助读者理解如何通过Counter进行MapReduce性能调优。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

[size=medium]
MapReduce Counter为提供我们一个窗口:观察MapReduce job运行期的各种细节数据。今年三月份期间,我曾经专注于MapReduce性能调优工作,是否优化的绝大多评估都是基于这些Counter的数值表现。MapReduce自带了许多默认Counter,可能有些朋友对它们有些疑问,现在我分析下这些默认Counter的含义,方便大家观察job结果。

我的分析是基于Hadoop0.21,我也看过Hadoop其它版本的Counter展现,细节大同小异,如果有差异的地方,以事实版本为主。

Counter有"组group"的概念,用于表示逻辑上相同范围的所有数值。MapReduce job提供的默认Counter分为五个组,下面逐一介绍。这里也拿我的一份测试数据来做详细比对,它们会以表格的形式出现在各组描述中。

[b]FileInputFormatCounters[/b]
这个group表示map task读取文件内容(总输入数据)的统计
[table]
||Counter|Map|Reduce|Total
|FileInputFormatCounters|BYTES_READ|1,109,990,596|0|1,109,990,596
[/table]
[color=blue]BYTES_READ[/color]
Map task的所有输入数据(字节),等于各个map task的map方法传入的所有value值字节之和。


[b]FileSystemCounters[/b]
MapReduce job执行所依赖的数据来自于不同的文件系统,这个group表示job与文件系统交互的读写统计
[table]
||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
[/table]
[color=blue]FILE_BYTES_READ[/color]
job读取本地文件系统的文件字节数。假定我们当前map的输入数据都来自于HDFS,那么在map阶段,这个数据应该是0。但reduce在执行前,它的输入数据是经过shuffle的merge后存储在reduce端本地磁盘中,所以这个数据就是所有reduce的总输入字节数。

[color=blue]FILE_BYTES_WRITTEN[/color]
map的中间结果都会spill到本地磁盘中,在map执行完后,形成最终的spill文件。所以map端这里的数据就表示map task往本地磁盘中总共写了多少字节。与map端相对应的是,reduce端在shuffle时,会不断地拉取map端的中间结果,然后做merge并不断spill到自己的本地磁盘中。最终形成一个单独文件,这个文件就是reduce的输入文件。

[color=blue]HDFS_BYTES_READ[/color]
整个job执行过程中,只有map端运行时,才从HDFS读取数据,这些数据不限于源文件内容,还包括所有map的split元数据。所以这个值应该比FileInputFormatCounters.BYTES_READ 要略大些。

[color=blue]HDFS_BYTES_WRITTEN[/color]
Reduce的最终结果都会写入HDFS,就是一个job执行结果的总量。


[b]Shuffle Errors[/b]
这组内描述Shuffle过程中的各种错误情况发生次数,基本定位于Shuffle阶段copy线程抓取map端中间数据时的各种错误。
[table]
||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
[/table]
[color=blue]BAD_ID[/color]
每个map都有一个ID,如attempt_201109020150_0254_m_000000_0,如果reduce的copy线程抓取过来的元数据中这个ID不是标准格式,那么此Counter增加

[color=blue]CONNECTION[/color]
表示copy线程建立到map端的连接有误

[color=blue]IO_ERROR[/color]
Reduce的copy线程如果在抓取map端数据时出现IOException,那么这个值相应增加

[color=blue]WRONG_LENGTH[/color]
map端的那个中间结果是有压缩好的有格式数据,所有它有两个length信息:源数据大小与压缩后数据大小。如果这两个length信息传输的有误(负值),那么此Counter增加

[color=blue]WRONG_MAP[/color]
每个copy线程当然是有目的:为某个reduce抓取某些map的中间结果,如果当前抓取的map数据不是copy线程之前定义好的map,那么就表示把数据拉错了

[color=blue]WRONG_REDUCE[/color]
与上面描述一致,如果抓取的数据表示它不是为此reduce而准备的,那还是拉错数据了。


[b]Job Counters[/b]
这个group描述与job调度相关的统计
[table]
||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
[/table]

[color=blue]Data-local map tasks[/color]
Job在被调度时,如果启动了一个data-local(源文件的幅本在执行map task的taskTracker本地)

[color=blue]FALLOW_SLOTS_MILLIS_MAPS[/color]
当前job为某些map task的执行保留了slot,总共保留的时间是多少

[color=blue]FALLOW_SLOTS_MILLIS_REDUCES[/color]
与上面类似

[color=blue]SLOTS_MILLIS_MAPS[/color]
所有map task占用slot的总时间,包含执行时间和创建/销毁子JVM的时间

[color=blue]SLOTS_MILLIS_REDUCES[/color]
与上面类似

[color=blue]Launched map tasks[/color]
此job启动了多少个map task

[color=blue]Launched reduce tasks[/color]
此job启动了多少个reduce task


[b]Map-Reduce Framework[/b]
这个Counter group包含了相当多地job执行细节数据。这里需要有个概念认识是:一般情况下,record就表示一行数据,而相对地byte表示这行数据的大小是多少,这里的group表示经过reduce merge后像这样的输入形式{“aaa”, [5, 8, 2, …]}。
[table]
||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
[/table]

[color=blue]Combine input records[/color]
Combiner是为了减少尽量减少需要拉取和移动的数据,所以combine输入条数与map的输出条数是一致的。

[color=blue]Combine output records[/color]
经过Combiner后,相同key的数据经过压缩,在map端自己解决了很多重复数据,表示最终在map端中间文件中的所有条目数

[color=blue]Failed Shuffles[/color]
copy线程在抓取map端中间数据时,如果因为网络连接异常或是IO异常,所引起的shuffle错误次数

[color=blue]GC time elapsed(ms)[/color]
通过JMX获取到执行map与reduce的子JVM总共的GC时间消耗

[color=blue]Map input records[/color]
所有map task从HDFS读取的文件总行数

[color=blue]Map output records[/color]
map task的直接输出record是多少,就是在map方法中调用context.write的次数,也就是未经过Combine时的原生输出条数

[color=blue]Map output bytes[/color]
Map的输出结果key/value都会被序列化到内存缓冲区中,所以这里的bytes指序列化后的最终字节之和

[color=blue]Merged Map outputs[/color]
记录着shuffle过程中总共经历了多少次merge动作

[color=blue]Reduce input groups[/color]
Reduce总共读取了多少个这样的groups

[color=blue]Reduce input records[/color]
如果有Combiner的话,那么这里的数值就等于map端Combiner运算后的最后条数,如果没有,那么就应该等于map的输出条数

[color=blue]Reduce output records[/color]
所有reduce执行后输出的总条目数

[color=blue]Reduce shuffle bytes[/color]
Reduce端的copy线程总共从map端抓取了多少的中间数据,表示各个map task最终的中间文件总和

[color=blue]Shuffled Maps[/color]
每个reduce几乎都得从所有map端拉取数据,每个copy线程拉取成功一个map的数据,那么增1,所以它的总数基本等于 reduce number * map number

[color=blue]Spilled Records[/color]
spill过程在map和reduce端都会发生,这里统计在总共从内存往磁盘中spill了多少条数据

[color=blue]SPLIT_RAW_BYTES[/color]
与map task 的split相关的数据都会保存于HDFS中,而在保存时元数据也相应地存储着数据是以怎样的压缩方式放入的,它的具体类型是什么,这些额外的数据是MapReduce框架加入的,与job无关,这里记录的大小就是表示额外信息的字节大小

[/size]
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值