群里共享了一本hive调优的书记，名叫《hive tunning》，就忍不住开始看了，也顺便记录一下自己学到的东西，备忘！
首先，这是hive的数据摘要，别问我什么意思，我也没看懂。
好，我们正式开始，首先是连接的问题，我们都知道连接耗时长，但是连接无法避免，那hive又是怎么处理连接操作的呢？
下面是hive的连接策略:
hive有<b>三种类型的连接策略</b>:
（1）shuffle join ： 这种类型的是通过map/reduce 来实现连接操作的，优点是不需要考虑数据的大小和分布，缺点是消耗大量的资源而且是最慢的。
（2）broadcast join：这种类型的方式是把一个小的表在所有节点中加载到内容当中，然后用mapper来扫描大表进行连接，速度非常快，但是其中一个表必须可以加载到内存当中。
（3）sort-merge-bucket join：mapper可以协同定位keys去进行高效的连接，速度很快，不需要考虑表的大小，但是数据必须先排序和整理。
<b>shuffle join:</b>
我们以这个销售订单这个例子来做演示，可以看到其中的图，它们是通过customer.id=order.cid来做连接的，首先map把两个表中的数据处理成以连接字段为key，其他字段为value的作为输出，然后把两个表中id和cid相同的数据传递到同一个reducer中，从网络使用率上看是很奢侈的。
<b>broadcast join：</b>
这种方式比较复杂一点，首先它使用足够小的维度表来存放在所有的节点当中，单独扫描大表，然后根据模式匹配进行连接。
当两个表都很大的情况下：
第一步，首先按照连接字段排序，所有可能的匹配的都在硬盘的同一块区域。
第二步，把所有的值都移到同一个节点下面进行等值连接，不需要再进行shuffle。
<b>bucketing:</b>
– hash partition values into a configurable number of buckets.
– usually coupled with sorting.
• skews:
– split values out into separate files.
– used when certain values are frequently seen.
• replication factor:
– increase replication factor to accelerate reads.
– controlled at the hdfs layer.
• sorting:
– sort the values within given columns.
– greatly accelerates query when used with orcfilefilter pushdown.
这里就不解释了，自己看吧，这和下面的图是对应的，针对不同大小的表，hive有多种处理模式。
（1）小表，经常要用的数据，建议使用replication factor，可能是缓存的意思，具体是什么意思，等我清楚了再给大家解释。
（2）任意大小的表，有很多要精确查询的列，建议先按照最常使用的列进行排序再进行查询。
（3）大表但是又需要和另外的的大表做连接，建议先通过连接列做排序和bucket。
（4）大表，但只是利用到其中某些常用的值，可以把常用的值弄个单独的skew中。
（5）大表但是有一些自然边界，比如日期的，建议利用日期进行分区。
<b>map join开启</b>
我们可以启用连接自动转换来帮助我们转换，在执行语句之前设置一下即可。它是经过优化的map join，无reducer。
<b>skew join</b>
真实数据中数据倾斜是一定的, hadoop 中默认是使用
也就是每个节点的reduce 默认是处理1g大小的数据，如果你的join 操作也产生了数据倾斜，那么你可以在hive 中设定
hive 在运行的时候没有办法判断哪个key 会产生多大的倾斜，所以使用这个参数控制倾斜的阈值，如果超过这个值，新的值会发送给那些还没有达到的reduce, 一般可以设置成你
（处理的总记录数/reduce个数）的2-4倍都可以接受.
倾斜是经常会存在的，一般select 的层数超过2层，翻译成执行计划多于3个以上的mapreduce job 都很容易产生倾斜，建议每次运行比较复杂的sql 之前都可以设一下这个参数. 如果你不知道设置多少，可以就按官方默认的1个reduce 只处理1g 的算法，那么 skew_key_threshold = 1g/平均行长. 或者默认直接设成250000000 (差不多算平均行长4个字节)
<b>sort-merge-bucket join</b>
如果表已经排序并且已经bucketed，可以启用smb joins