ps:
在map和reduce的過程中,可以通過設置Context.setStatus()來隨時設置狀態,這個底層也是使用reporter來設置的
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 |
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端中間數據時的各種錯誤。
|
|
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無關，這里記錄的大小就是表示額外信息的字節大小
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