groupByKey和combineByKey算子底層都是調(diào)用了combineByKeyWithClassTag方法，區(qū)別在于各自方法的傳入的參數(shù)mapSideCombine 不同，改參數(shù)不同的區(qū)別在于是否在map端進行聚合；
groupByKey 的參數(shù)mapSideCombine = false
combineByKey的參數(shù)mapSideCombine = true
兩者各自的使用不多介紹，網(wǎng)上可以看到很多，這里簡單分享一個使用兩者時遇到的問題
(1)圖1所示，在使用groupByKey時，關(guān)注stage3 到stage5過程，stage3輸出數(shù)據(jù)大小為：45.2M；再關(guān)注一個時間:stage3的Duration為4s；
(2)圖2所示，在使用combineByKey時，同樣關(guān)注stage3到stage5的過程，此時stage3的輸出數(shù)據(jù)大小為：24.0M；再關(guān)注stage的Duration為3s；
簡單分析：
對比兩者可以發(fā)現(xiàn)stage3階段輸出數(shù)據(jù)量減少了21.2M，運行時間少了1s；stage5 shuffle read 耗時減少了2s，這在發(fā)生shuffle大量讀取時，使用combineByKey性能會比groupByKey好；一個提前聚合，避免了shuffle 傳輸量，第二個是shuffle read 后可能會減少數(shù)據(jù)分析量，減少對內(nèi)存的消耗；
問題：
其中在自定義combineByKey的3個函數(shù)時，第一次使用ObjectIterator作為返回對象時，stage3的shuffle write 數(shù)據(jù)大小為26.2M；第二次改用了Iterable作為返回對象時，stage3的shuffle write 數(shù)據(jù)大小為24M，減少了2.2M，俗話說fastutil的API不是優(yōu)化的么，為什么shuffle write 會增加了呢？
