場景一：
api：
textFile("hfds://....").map((key,value)).reduceByKey(...).map(實際的業務計算邏輯)
場景：hdfs的某個文件有183個block，他們的大小分布非常不均勻時，比如有的是200M，有的是1M，有的是10K。此時spark計算非常非常慢，通過web ui監視發現，有的task處理了好幾百M的數據，有的
task之處理了幾k，導致嚴重的數據傾斜。
其中stage0階段有183個task，這個階段幾乎沒有什么計算任務，主要就是從hdfs上讀取數據，stage0一共讀取了5.4G的壓縮后的lzo數據，耗時在9.3Min左右。
讓人痛苦的是，在reduceByKey時，reduce數量也是183個，從這里噩夢就開始了，耗時在2個多小時還沒有計算完畢。
原因：默認情況下，spark 的初始rdd的partition數量和hdfs的block 數量大小一致，在上面這個場景下，初始rdd的partition個數就是183，並且后面的reduceByKey等都是183，可以通過在textFile之后
repartition一下，可以將次數設置的小一點，這樣那些小的block就會聚合到一個parttion了。
2.場景2，groupByKey要比reduceByKey快