Hive的Join操作、Hive解决数据倾斜问题、Hive优化、Hive的分桶表、JDBC、体系结构、工程流程

Hive的Join操作

order表数据：
1 20180710 P001 20
2 20180710 P002 14
3 20180710 P001 35
4 20180710 P002 40
5 20180710 P001 10
6 20180710 P003 20
7 20180710 P004 12

product表数据：
P001 xiaomi 2999
P002 huawei 3999
P005 chuizi 4000

建表：
1）create external table order_t (id string,time string,pid string,amount int) row format delimited fields terminated by ’ ’ location ‘/order’;
2）create external table product_t (pid string,name string,price int) row format delimited fields
terminated by ’ ’ location ‘/product’;

查询：
select * from product_t join order_t on product_t.pid=order_t.pid;
注意：把小表写在前面，hive底层自动做map side join.

inner join
select * from product_t inner join order_t on product_t.pid=order_t.pid;

left join
select * from product_t left join order_t on product_t.pid=order_t.pid;

right join
select * from product_t right join order_t on product_t.pid=order_t.pid;

Full outer join
select * from product_t full outer join order_t on product_t.pid=order_t.pid;

left semi join
select * from product_t left semi join order_t on product_t.pid=order_t.pid;

这种join解决的是exist in（是否存在） 的问题
a表里哪些数据在b表中出现过

Hive解决数据倾斜问题

概述
什么是数据倾斜以及数据倾斜是怎么产生的？
简单来说数据倾斜就是数据的key 的分化严重不均，造成一部分数据很多，一部分数据很少的局面。举个 word count 的入门例子，它的map 阶段就是形成 （“aaa”,1）的形式，然后在reduce 阶段进
行 value 相加，得出 “aaa” 出现的次数。若进行 word count 的文本有100G，其中 80G 全部是 “aaa” 剩下 20G 是其余单词，那就会形成 80G 的数据量交给一个 reduce 进行相加，其余 20G 根据 key 不同分散到不同 reduce 进行相加的情况。如此就造成了数据倾斜，临床反应就是 reduce 跑到 99%然后一直在原地等着 那80G 的reduce 跑完。
如此一来 80G 的 aaa 将发往同一个 reducer ，由此就可以知道 reduce 最后 1% 的工作在等什么了。为什么说数据倾斜与业务逻辑和数据量有关？
从另外角度看数据倾斜，其本质还是在单台节点在执行那一部分数据reduce任务的时候，由于数据量大，跑不动，造成任务卡住。若是这台节点机器内存够大，CPU、网络等资源充足，跑 80G 左右的数据量和跑10M 数据量所耗时间不是很大差距，那么也就不存在问题，倾斜就倾斜吧，反正机器跑的动。所以机器配置和数据量 存在一个合理的比例，一旦数据量远超机器的极限，那么不管每个key的数据如何分布，总会有一个key的数据量超出机器的能力，造成 reduce 缓慢甚至卡顿。

业务逻辑造成的数据倾斜会多很多，日常