读取hdfs文件之后repartition 避免数据倾斜

场景一：

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快