场景一：
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快