版本
spark2.1.0
现象
继续上一章，利用effective_time字段进行重新分区导致了任务执行的倾斜
本章就要针对这个问题进行处理。
问题定位
首先看下repartition是如何进行重分区的。
由partitionExprs.map(_.expr)可以得知，代码根据列最终返回的key进行map分区，而根据接口注释，可以得知，该接口根据传入partitionExprs将数据重新进行map划分到numPartitions个分区中，这效果类似于hivesql 中的distribute by。
Returns a new Dataset partitioned by the given partitioning expressions into `numPartitions`. The resulting Dataset is hash partitioned.
This is the same operation as "DISTRIBUTE BY" in SQL (Hive QL).
hive利用 Distribute By将相同key划分到同一分区下
Hive uses the columns in Distribute By to distribute the rows among reducers. All rows with the same Distribute By columns will go to the same reducer. However, Distribute By does not guarantee clustering or sorting properties on the distributed keys.
这就回到了分区的划分字段effective_time上来。统计一下该字段的数据分布情况
可以看到，各月份之间的数据非常不均匀，差距在10W级别，而且null值数据达到了1000多万条，一开始我直接把null设置为了2020年1月，显然是人为造成了数据倾斜，这个时候就需要对划分依据进行调整。
解决方式
一、使用固定分区大小
直接指定固定的分区大小，DataSet的repartition根据hashRepartition会将记录直接分布到指定数量的分区中。
可以看到task分配相对均衡，总用时也由30分钟缩短到了26分钟。
二、根据列动态划分，调整业务列，直接使用oracle的rownum。因为repartitionByRange使用rangeRepartition自spark 2.3.0起才支持，这里使用的依旧是hash分区。使用rownum的话，总数5000万条记录被划分到N个分区中，只要n远远小于总数记录，这个时候的划分理论上还是比较平均的。
