當Client申請作業後，Resource Scheduler會進行排程，同時開啟Map Task 和Reduce Task

測試一：mapper->reducer

　　##資料量<80Mb,在mapper端不設定combiner

　　若不設定combiner，經過map之後的檔案資料將直接到達reduce

　　程式碼如下：

public void analyzeByBrowserAndEvent() throws IOException, ClassNotFoundException, InterruptedException {
        final String[] params = {
                "192.168.142.192","/tmp/test/mylog1.log","/tmp/browser2"
        };
        Configuration conf = new Configuration();
        conf.set("fs.defaultFS",MessageFormat.format("hdfs://{0}:9000",params[0]));

        deleteOnExist(conf,params[2]);

        Job job = Job.getInstance(conf,"countByBrowserAndEvent");
        job.setMapperClass(EBMapper.class);
        job.setReducerClass(EBReducer.class);

        job.setOutputKeyClass(Text.class);
        job.setOutputValueClass(IntWritable.class);

        FileInputFormat.addInputPath(job,new Path(params[1]));
        FileOutputFormat.setOutputPath(job,new Path(params[2]));

        System.out.println(job.waitForCompletion(true));
    }

　　測試結果：

結論：即使不設定combiner進行歸併排序，在reduce端也會進行一次歸併排序的過程

測試二：mapper端設定combiner

　　#資料量<80Mb

　　結果如下：

結論：當mapper端設定了combiner之後，資料的歸併與排序將在mapper端完成，而reduce的作用為落盤

測試三：mapper端設定combiner且檔案片的大小大於80Mb

　　#由於檔案大於80Mb，經過環形緩衝區後溢位的小檔案數量將至少2個

　　結果如下：

發現在設定了combiner之後，reduce端還是會進行一次歸併，證明經過了環形緩衝區後溢位的檔案數量不為1時，歸併是不完全的

查詢資料，分析如下：

　　Combiner是在Map端被執行，共有兩個時機會被觸發：

① 從環形緩衝器溢寫分割槽檔案的時候

② 合併溢寫分割槽檔案的時候

　　第一次為檔案從環形緩衝區溢位的時候，由於環形緩衝區的預設size:100M,當到達80%就會進行溢位，對於每一個溢位的小檔案，可以進行一次歸併排序，但是對於只有一條記錄的情況，combiner將不會被觸發

　　原始碼如下：

　　第二次為合併所有的溢位分割槽檔案時，當溢位的檔案數量小於規定的數量時，亦不滿足第二次的combiner觸發條件

　　原始碼如下：

結論：本次測試，雖然設定了combiner，但是隻能滿足第一個觸發條件，即對每一個溢位的檔案進行了歸併，但是當合並所有的溢位分割槽檔案時，並沒有進行第二次合併

參考部落格：https://www.iteye.com/blog/heipark-1992419