Hadoop中counter的使用和默认counter的含义<转>

来源：互联网发布：ansys mac 编辑：程序博客网时间：2024/04/27 18:59

1.在0.20.x版本中使用counter很简单,直接定义即可，如无此counter，hadoop会自动添加此counter.

Counter ct = context.getCounter("INPUT_WORDS", "count");

ct.increment(1);

2.在0.19.x版本中,需要定义enum

enum MyCounter {INPUT_WORDS };

reporter.incrCounter(MyCounter.INPUT_WORDS, 1);

RunningJob job = JobClient.runJob(conf);

Counters c = job.getCounters();

long cnt = c.getCounter(MyCounter.INPUT_WORDS);

3.默认counter的含义

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

    BYTES_READ
         Map task的所有输入数据(字节)，等于各个map task的map方法传入的所有value值字节之和。

FileSystemCounters
    MapReduce job执行所依赖的数据来自于不同的文件系统，这个group表示job与文件系统交互的读写统计

Counter

Map

Reduce

Total

FileSystemCounters

FILE_BYTES_READ

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

HDFS_BYTES_WRITTEN

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

Counter

Map

Reduce

Total

Shuffle Errors

BAD_ID

CONNECTION

IO_ERROR

WRONG_LENGTH

WRONG_MAP

WRONG_REDUCE

    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

FALLOW_SLOTS_MILLIS_MAPS

FALLOW_SLOTS_MILLIS_REDUCES

SLOTS_MILLIS_MAPS

1,210,936

SLOTS_MILLIS_REDUCES

1,628,224

Launched map tasks

Launched reduce tasks

    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

Combine output records

117,838,546

Failed Shuffles

GC time elapsed (ms)

23,472

46,588

70,060

Map input records

10,000,000

Map output bytes

1,899,990,596

Map output records

200,000,000

Merged Map outputs

536

Reduce input groups

84,879,137

Reduce input records

117,838,546

Reduce output records

84,879,137

Reduce shuffle bytes

1,544,523,910

Shuffled Maps

536

Spilled Records

117,838,546

235,677,092

SPLIT_RAW_BYTES

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

4.分析counter和reporter的

http://blog.sina.com.cn/s/blog_61ef49250100uxwh.html

5.其他

Hadoop: The Definitive Guide 第8章hadoop features

http://blog.sina.com.cn/s/blog_61ef49250100uxwh.html

http://lintool.github.com/Cloud9/docs/content/counters.html

http://langyu.iteye.com/blog/1171091