关于spark落盘到hdfs的文件分发规则及处理总结

近期又遇到了不少有关spark/hive表落盘到hdfs的问题，借此机会系统性的记录下学习过程。

此次记录的核心语句就是之前老生常谈的distribute by命令，其后跟的规则不同 会产生截然不同的效果

首先回顾下落盘的过程，每一个reducer都会往某一指定路径下写一个文件，有时候一个reducer只写一个路径，有时候会写多个路径，但核心点在于 每一个reducer只会在某一路径下写一个文件。

我们经常会遇到的小文件过多的问题，以及脚本运行很慢甚至卡死的情况（数据倾斜），其实大多数情况下都和落盘的过程有关。

来看下最基本的两种情况，先假设有50个reducer，数据分为pdate= 01,02,03三个分区

1. distribute by rand

2.distribute by 某一固定值，如distribute by 1

这是非常经典的两个场景：

对于1，结果集的每一条记录都会打上一个随机数的标签，相同的随机数会被分到同一个reducer进行计算以及落盘，显而易见，比如pdate01的数据会近乎被均分为50份，分发到50个reducer上，同时每个reducer都会往pdate01对应的hdfs路径下写一个文件，这样01分区下总共会有50个文件，同理02，03也为50个文件

对于2，所有分区的所有数据，均会被打上同一个标签，这意味着所有的数据都会分发到同一个reducer上，然后这个reducer分别往01，02，03三个分区下的路径下各自写一个文件，这样01，02，03分区路径下，分别都有1个文件。

从过程中可以得出结论，1的情况可以达到高并发，但由于每个分区都生成大量的文件，对于数据分布不均匀的分区，可能会出现大量的小文件问题；2的情况恰恰相反，由于只有一个reducer工作，解决了小文件的问题，但丧失了多个reducer高并发的优势，任务的效率大大降低。

那接下来，如何综合1和2的优点，使任务既可以做到多个reducer高并发处理，又可以避免小文件的问题呢，下面是第三种情况

3. distribute by pdate ，也就是根据某个分