Hive（5）高级应用

视图

逻辑窗口、视图

1. 特性

• 只有逻辑视图，没有物化视图
• 视图只能查询，不能load/insert数据
• 视图在创建的时候，只是保存了一份元数据，当查询视图的时候，才开始执行视图对应的那些子查询

2. 优点

• 通过引入视图机制，用户可以将注意力集中在其关心的数据上（而非全部数据），这样就大大提高了用户效率与用户满意度，而且如果这些数据来源于多个基本表结构，或者数据不仅来自于基本表结构，还有一部分数据来源于其他视图，并且搜索条件又比较复杂时，需要编写的查询语句就会比较烦琐，此时定义视图就可以使数据的查询语句变得简单可行
• 定义视图可以将表与表之间的复杂的操作连接和搜索条件对用户不可见，用户只需要简单地对一个视图进行查询即可，故增加了数据的安全性，但不能提高查询效率

4. 实例

• 创建视图

hive> create view student_view as select * from student where age>15;
OK
Time taken: 0.522 seconds

• 查看视图

hive> desc student_view;
OK
id                  	int                 	                    
name                	string              	                    
age                 	int                 	                    
Time taken: 0.144 seconds, Fetched: 3 row(s)
hive> select * from student_view;
OK
1005	bob	24
1006	mark	23
1007	leo	22
1011	JACK	23
1014	JAMES	24
Time taken: 0.209 seconds, Fetched: 5 row(s)
hive> show tables;
OK
stu
stu2
stu_buck
stu_mess
stu_mess_part
stu_mess_part_buck
stu_message
student
student2
student3
student5
student_buck
student_view			//刚刚创建的视图
students
Time taken: 0.042 seconds, Fetched: 14 row(s)

• 删除视图

hive> drop view student_view;
OK
Time taken: 0.711 seconds
hive> show tables;
OK
stu
stu2
stu_buck
stu_mess
stu_mess_part
stu_mess_part_buck
stu_message
student
student2
student3
student5
student_buck
students
Time taken: 0.034 seconds, Fetched: 13 row(s)

索引

3.0版本以后没有

索引概述

• Hive索引的目标是提高表的某些列的查询查询速度。如果没有索引，带有谓词的查询（如’WHERE tab1.col1 = 10’）会加载整个表或分区并处理所有行。但是如果col1存在索引，则只需要加载和处理文件的一部分
• 索引可以提供的查询速度的提高是以创建索引和存储索引的磁盘空间的额外处理为代价的

使用场景

适用于不更新的静态字段。以免总是重建索引数据。每次建立、更新数据后，都要重建索引以构建索引表

索引机制

• hive在指定列上建立索引，会产生一张索引表（Hive的一张物理表），里面的字段包括，索引列的值、该值对应的HDFS文件路径、该值在文件中的偏移量
• v0.8后引入bitmap索引处理器，这个处理器适用于排重后，值较少的列（例如，某字段的取值只可能是几个枚举值）
• 因为索引是用空间换时间，索引列的取值过多会导致建立bitmap索引表过大

创建索引

创建索引

hive> create index student_index on table student(id) as 'compact' with deferred rebuild;
OK
Time taken: 1.931 seconds
hive> show index on student;
OK
student_index       	student             	id                  	yr__student_student_index__   compact             	
Time taken: 0.162 seconds, Fetched: 1 row(s)
hive> select * from yr__student_student_index__;
OK
Time taken: 0.401 seconds

构建索引

hive> alter index student_index on student rebuild;

hive> select * from yr__student_student_index__;
OK
//索引里的内容：{值，HDFS文件位置，偏移量的数组（可能有多个）}
1005	hdfs://master:9000/user/hive/warehouse/yr.db/student/student2.txt	[0]
1006	hdfs://master:9000/user/hive/warehouse/yr.db/student/student2.txt	[12]
1007	hdfs://master:9000/user/hive/warehouse/yr.db/student/student2.txt	[25]
1011	hdfs://master:9000/user/hive/warehouse/yr.db/student/student2.txt	[37]
1014	hdfs://master:9000/user/hive/warehouse/yr.db/student/student2.txt	[50]
Time taken: 0.091 seconds, Fetched: 5 row(s)

显示格式化（带列名称）

hive> show formatted index on student;
OK
idx_name            	tab_name            	col_names           	idx_tab_name        	idx_type            	comment             
	 	 	 	 	 
	 	 	 	 	 
student_index       	student             	id                  	yr__student_student_index__	compact             	
Time taken: 0.073 seconds, Fetched: 4 row(s)

删除索引

hive> drop index student_index on student;
OK
Time taken: 0.947 seconds
hive> show tables;
OK
stu
stu2
stu_buck
stu_mess
stu_mess_part
stu_mess_part_buck
stu_message
student
student2
student3
student5
student_buck
students
Time taken: 0.173 seconds, Fetched: 13 row(s)

• 位图索引

hive> create index student_index on table student(name) as 'bitmap' with deferred rebuild;
OK
Time taken: 0.652 seconds
hive> show tables;
OK
stu
stu2
stu_buck
stu_mess
stu_mess_part
stu_mess_part_buck
stu_message
student
student2
student3
student5
student_buck
students
yr__student_student_index__
Time taken: 0.043 seconds, Fetched: 14 row(s)
hive> select * from yr__student_student_index__
    > ;
OK
Time taken: 0.127 seconds
hive> alter index student_index on student rebuild;

hive> show formatted index on student;
OK
idx_name            	tab_name            	col_names           	idx_tab_name        	idx_type            	comment             
	 	 	 	 	 
	 	 	 	 	 
student_index       	student             	name                	yr__student_student_index__	bitmap              	
Time taken: 0.075 seconds, Fetched: 4 row(s)
hive> drop index student_index on student;
OK
Time taken: 0.218 seconds

• 在新表中创建索引、删除

create index student_index on table student(age) as 'compact' with deferred rebuild in table student_index_table;

drop index student_index on student;

• 创建存储为rcfile的索引

create index student_index on table student(name) as 'compact' with deferred rebuild stored as rcfile;

drop index student_index on student;

• 创建存储为textfile的索引

CREATE INDEX student_index ON TABLE student (age) AS 'COMPACT' with deferred rebuild ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t' STORED AS TEXTFILE;

drop index student_index on student;

• 使用索引属性创建索引

CREATE INDEX student_index ON TABLE student (age) AS 'COMPACT' with deferred rebuild IDXPROPERTIES ("prop1"="value1", "prop2"="value2");

drop index student_index on student;

• 使用表属性创建索引

CREATE INDEX student_index ON TABLE student (age) AS 'COMPACT' with deferred rebuild TBLPROPERTIES ("prop3"="value3", "prop4"="value4");

drop index student_index on student;

数据倾斜

数据倾斜是进行大数据计算时最经常遇到的问题之一。当我们在执行HiveQL或者运行MapReduce作业时候，如果遇到一直卡在map100%,reduce99%一般就是遇到了数据倾斜的问题。
数据倾斜其实是进行分布式计算的时候，某些节点的计算能力比较强或者需要计算的数据比较少，早早执行完了，某些节点计算的能力较差或者由于此节点需要计算的数据比较多，导致出现其他节点的reduce阶段任务执行完成，但是这种节点的数据处理任务还没有执行完成。
由于数据分布不均匀，造成数据大量的集中到一点，造成数据热点

• Hadoop框架的特性
  1.不怕数据大，怕数据倾斜
  2.Jobs 数比较多的作业运行效率相对比较低，如子查询比较多
  3.SUM,COUNT,MAX,MIN 等聚集函数，不会有数据倾斜问题

• 数据倾斜的主要表现
  任务进度长时间维持在 99% 或者 100% 的附近， 查看任务监控页面，发现只有少量（1个或者几个） reduce 子任务未完成， 因为其处理的数据量和其他的 reduce 差异过大。 单一 reduce 处理的记录数和平均记录数相差太大，通常达到3倍甚至更多，最长时间远大于平均时长

• 会发生数据倾斜的情况
  1.小表join超大表
  2.group by不和聚集函数（sum、count等）搭配使用的时候
  3.数据量大的情况下，count(distinct)容易数据倾斜，因为count(distinct)是按group by字段分组，按distinct字段排序
  

• 产生数据倾斜的具体原因
  key 分布不均匀，少量的key 对应大量value
  业务数据本身的特性
  建表考虑不周全
  某些 HQL 语句本身就存在数据倾斜

1.空值产生的数据倾斜
遇到需要进行join的但是关联字段有数据为空，如表一的id需要和表二的id进行关联

• 场景说明
  在日志中，常会有信息丢失的问题， 比如日志中的 user_id，如果取其中的 userid 和用户表中的 userid 相关联，就会碰到数据倾斜的问题

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

SELECT * FROM log a 
JOIN user b 
ON a.user_id IS NOT NULL 
AND a.user_id = b.user_id 
UNION ALL
SELECT * FROM log c WHERE c.user_id IS NULL;

• 解决方案 2： 赋予空值新的 key 值

SELECT * FROM log a 
LEFT OUTER JOIN user b 
ON CASE WHEN a.user_id IS NULL THEN CONCAT('hive',RAND())
ELSE a.user_id END = b.user_id;

• 总结
  方法 2 比方法 1 效率更好， 不但 IO 少了，而且作业数也少了，方案 1 中， log 表读了两次， jobs 肯定是 2，而方案 2 是 1。 这个优化适合无效 id（比如-99， ‘’， null）产生的数据倾斜， 把空值的 key 变成一个字符串加上一个随机数，就能把造成数据倾斜的数据分到不同的 reduce 上解决数据倾斜的问题

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

• 场景说明
  用户表中 user_id 字段为 int， log 表中 user_id 为既有 string 也有 int 的类型。当按照两个表的 user_id 进行 Join 操作的时候，默认的 hash 操作会按照 int 类型的 id 来进行分配， 这样就会导致所有的 string 类型的 id 就被分到同一个 reducer 当中
• 解决方案
  把数字类型 id 转换成 string 类型的 id

SELECT * FROM user a 
LEFT OUTER JOIN log b 
ON b.user_id = CAST(a.user_id AS STRING);

3.大小表关联查询

• 解决方案
  使用 MapJoin 解决小表关联大表造成的数据倾斜问题
• MapJoin 概念
  将其中的某个表（全量数据）分发到所有 Map 端进行 Join，从而避免了reduce，前提要求是内存足以装下该全量数据
• 总结
  以大表 a 和小表 b 为例，所有的 MapTask 节点都装载小表 b 的所有数据，然后大表 a 的一个数据块数据比如说是 a1, 去跟 b 全量数据做连接， 就省去了 reduce 来做汇总的过程
  所以相对来说，在内存允许的条件下使用 MapJoin 比直接使用 MapReduce 效率还高些，当然这只限于做 Join 查询的时候
  如果是大大表关联呢？那就大事化小，小事化了。把大表切分成小表，然后分别 MapJoin

4.group by

• 场景说明
  当按照类型进行group by的时候，会将相同的group by字段的reduce任务需要的数据拉取到同一个节点进行聚合，而当其中每一组的数据量过大时，会出现其他组的计算已经完成而这里还没计算完成，其他节点的一直等待这个节点的任务执行完成，所以会看到一直map 100% reduce 99%的情况。
• 解决方法：
  set hive.map.aggr=true
  set hive.groupby.skewindata=true

原理：hive.map.aggr=true 这个配置项代表是否在map端进行聚合

hive.groupby.skwindata=true 当选项设定为 true，生成的查询计划会有两个 MR Job。第一个 MR Job 中，Map 的输出结果集合会随机分布到 Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中，从而达到负载均衡的目的；第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中（这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中），最后完成最终的聚合操作。

5.map和reduce优化

1）当出现小文件过多，需要合并小文件。
通过set hive.merge.mapfiles=true来解决。

2）单个文件大小稍稍大于配置的block块的大写，此时需要适当增加map的个数。
解决方法：set mapred.map.tasks个数

3）文件大小适中，但map端计算量非常大，如select id,count(*),sum(case when…),sum(case when…)…需要增加map个数。
解决方法：set mapred.map.tasks个数，set mapred.reduce.tasks个数

6.当HiveQL中包含count（distinct）时

• 场景说明
  如果数据量非常大，执行如select a,count(distinct b) from t group by a;类型的SQL时，会出现数据倾斜的问题。

• 解决方法：使用sum…group by代替。如select a,sum(1) from (select a, b from t group by a,b) group by a;