hive使用注意事项

1.Hadoop 和 Hive 都是用 UTF-8 编码的，所以, 所有中文必须是 UTF-8 编码, 才能正常使用
备注：中文数据 load 到表里面, 如果字符集不同，很有可能全是乱码需要做转码的, 但是 hive 本身没有函数来做这个

2.hive.exec.compress.output 这个参数, 默认是 false，但是很多时候貌似要单独显式设置一遍否则会对结果做压缩的，如果你的这个文件后面还要在 hadoop 下直接操作, 那么就不能压缩了

3.count(distinct)

当前的 Hive 不支持在一条查询语句中有多 Distinct。如果要在 Hive 查询语句中实现多Distinct，需要使用至少 n+1 条查询语句（ n 为 distinct 的数目），前 n 条查询分 别对 n 个列去重，最后一条查询语句对 n 个去重之后的列做 Join 操作，得到最终结果。

4JOIN

只支持等值连接

5.DML 操作
只支持 INSERT/LOAD 操作，无 UPDATE 和 DELTE

6.HAVING
不支持 HAVING 操作。如果需要这个功能要嵌套一个子查询用 where 限制

7.子查询
Hive 不支持 where 子句中的子查询

8.SQL 标准中，任何对 null 的操作（数值比较，字符串操作等）结果都为 null。 Hive 对 null
值处理的逻辑和标准基本一致，除了 Join 时的特殊逻辑。这里的特殊逻辑指的是， Hive 的 Join 中，作为 Join    key 的字段比较， null=null 是有意义的，且返回值为 true。检查以下查询：
select u.uid, count(u.uid) from t_weblog l join t_user u on (l.uid = u.uid) group by u.uid;
查询中， t_weblog 表中 uid 为空的记录将和 t_user 表中 uid 为空的记录做连接，即 l.uid    =    u.uid=null 成立。
如果需要与标准一致的语义，我们需要改写查询手动过滤 null 值的情况：
select u.uid, count(u.uid)
from t_weblog l join t_user u
on (l.uid = u.uid and l.uid is not null and u.uid is not null)
group by u.uid;
实践中，这一语义区别也是经常导致数据倾斜的原因之一。

9.分号字符

分号是 SQL 语句结束标记，在 HiveQL 中也是，但是在 HiveQL 中，对分号的识别没有那么智
慧，可以推断， Hive 解析语句的时候，只要遇到分号就认为语句结束，而无论是否用引号包含
起来。解决的办法是，使用分号的八进制的 ASCII 码进行转义

如：
 

select	concat(cookie_id,concat(';',’zoo’))	from	c02_clickstat_fatdt1	limit	2;

改为：
 

select	concat(cookie_id,concat('\073','zoo'))	from	c02_clickstat_fatdt1	limit	2;

10.优化的常用手段

好的模型设计事半功倍。
• 解决数据倾斜问题。
• 减少 job 数。
• 设置合理的 map    reduce 的 task 数，能有效提升性能。 (比如， 10w+级别的计算，用
160 个 reduce，那是相当的浪费， 1 个足够)。
• 了解数据分布，自己动手解决数据倾斜问题是个不错的选择。 set    
hive.groupby.skewindata=true;这是通用的算法优化，但算法优化有时不能适应特定业
务背景，开发人员了解业务，了解数据，可以通过业务逻辑精确有效的解决数据倾
斜问题。
• 数据量较大的情况下，慎用 count(distinct)， count(distinct)容易产生倾斜问题。
• 对小文件进行合并，是行至有效的提高调度效率的方法，假如所有的作业设置合理
的文件数，对云梯的整体调度效率也会产生积极的正向影响。
• 优化时把握整体，单个作业最优不如整体最优

11.sort by 和 order by 之间的区别
Hive支持使用 sort by 排序。
sort by 和 order by的区别是前者给每一reducer上的所有行进行排序，后者保证在数据结果上都有序。也就是说，如果使用超过一个reducer，使用sort by可能给出部分有序的结果。

12.JOIN 原则
在使用写有 Join 操作的查询语句时有一条原则：应该将条目少的表/子查询放在 Join 操作符的左边。原因是在 Join 操作的 Reduce 阶段，位于 Join 操作符左边的表的内容会被加载进内存，将条目少的表放在左边，可以有效减少发生OOM 错误的几率。

13.Map    Join    
Join 操作在 Map 阶段完成，不再需要 Reduce，前提条件是需要的数据在 Map的过程中可以访问到。

 

 

14数据倾斜

(1)空值数据倾斜：

场景： 如日志中，常会有信息丢失的问题，比如全网日志中的 user_id，如果取其中的 user_id
和 bmw_users 关联，会碰到数据倾斜的问题。

解决方法 1： user_id 为空的不参与关联

（2）不同数据类型关联产生数据倾斜

场景： 一张表 s8 的日志，每个商品一条记录，要和商品表关联。但关联却碰到
倾斜的问题。 s8 的日志中有字符串商品 id,也有数字的商品 id,类型是 string
的，但商品中的数字 id 是 bigint 的。猜测问题的原因是把 s8 的商品 id 转成数
字 id 做 hash 来分配 reduce，所以字符串 id 的 s8 日志，都到一个 reduce 上了，
解决的方法验证了这个猜测。
解决方法： 把数字类型转换成字符串类型

（3）大表 Join 的数据偏斜

MapReduce 编程模型下开发代码需要考虑数据偏斜的问题， Hive 代码也是一样。数据
偏斜的原因包括以下两点：
1.    Map 输出 key 数量极少，导致 reduce 端退化为单机作业。
2.    Map 输出 key 分布不均，少量 key 对应大量 value，导致 reduce 端单机瓶颈。60
Hive 中我们使用 MapJoin 解决数据偏斜的问题，即将其中的某个表（全量）分发到所有
Map 端进行 Join，从而避免了 reduce。这要求分发的表可以被全量载入内存。
极限情况下， Join 两边的表都是大表，就无法使用 MapJoin。
这种问题最为棘手，目前已知的解决思路有两种：
1.     如果是上述情况 1，考虑先对 Join 中的一个表去重，以此结果过滤无用信息。这样
一般会将其中一个大表转化为小表，再使用 MapJoin 。
一个实例是广告投放效果分析，例如将广告投放者信息表 i 中的信息填充到广告曝光日
志表 w 中，使用投放者 id 关联。因为实际广告投放者数量很少（但是投放者信息表 i 很大），
因此可以考虑先在 w 表中去重查询所有实际广告投放者 id 列表，以此 Join 过滤表 i，这一结
果必然是一个小表，就可以使用 MapJoin。
2.     如果是上述情况 2，考虑切分 Join 中的一个表为多片，以便将切片全部载入内存，
然后采用多次 MapJoin 得到结果。
一个实例是商品浏览日志分析，例如将商品信息表 i 中的信息填充到商品浏览日志表 w
中，使用商品 id 关联。但是某些热卖商品浏览量很大，造成数据偏斜。例如，以下语句实
现了一个 inner    join 逻辑，将商品信息表拆分成 2 个表：

select * from
(
select w.id, w.time, w.amount, i1.name, i1.loc, i1.cat
from w left outer join i sampletable(1 out of 2 on id) i1
)
union all
(
select w.id, w.time, w.amount, i2.name, i2.loc, i2.cat
from w left outer join i sampletable(1 out of 2 on id) i2
) )
;

以下语句实现了 left    outer    join 逻辑：

select t1.id, t1.time, t1.amount,
coalease(t1.name, t2.name),
coalease(t1.loc, t2.loc),
coalease(t1.cat, t2.cat)
from (
select w.id, w.time, w.amount, i1.name, i1.loc, i1.cat
from w left outer join i sampletable(1 out of 2 on id) i1
) t1 left outer join i sampletable(2 out of 2 on id) t2;

上述语句使用 Hive 的 sample    table 特性对表做切分。