近期又遇到了不少有关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 ，也就是根据某个分区key值
这样的分发情况是这样的：同一个分区的数据，会分发到同一个reducer上进行处理，每一个reducer往对应的分区路径下写一个文件，最终，01，02，03分区各自会有1个文件，这样既可以做到高并发，又避免了小文件的问题
补充，如果文件大小过大，可以后面跟个随机数，比如
distribute by pdate, cast(rand()*N as int)
这样同一个pdate分区的数据，会进一步细分为N，从由1个reducer处理，变为由N个reducer处理，这样最后每个分区路径下，会生成N个文件
但是，对于3，同样存在一系列的问题，比如数据倾斜
比如，01分区的数据特别多，02特别少，那对应处理01分区的reducer压力就会非常大，造成任务一直卡死在这个reducer上，解决数据倾斜的方法非常多，就不一一细说，这里列举一个只从distribute by的角度解决的case
4. distribute by case when pdate=01 then cast(rand()*N as int) else 1 end
可以看出，当pdate=01，数据量特别大的时候，采用N个reducer处理，其余情况，直接由单个reducer处理
简单的个人学习总结，若有错误，欢迎各位大佬指出~
