Hive优化

Posted 2022-11-02 ssqq5200936

Hive理论
1、Hive是什么？一个sql解析引擎，将SQL解析成MR，Hive本质就是MR
2、Hive不存数据的，数据实际存在HDFS上，元数据基本上都存在mysql上
3、Hive内容是读多写少，不支持数据的改写和删除
4、Hive的SQL和传统SQL区别：
可扩展性：用户自定义函数
1）UDF：用户自定义普通函数，例：map，一对一
2）UDAF：用户自定义聚合函数，例：groupByKey，多对一
3）UDTF：用户自定义表生成函数，例：flatMap，一对多
数据检查：
HQL（hive）：读时模式
加载load数据的速度非常快，加载过程中不需要对数据解析，仅仅涉及到文件的复制和移动
但读的时候慢
SQL（传统）：写时模式
加载数据的时候速度非常慢，但是读的时候快
5、Hive体系架构
1）用户接口Cli
2）语句转化Driver：将SQl转换成MR
3）数据存储：元数据（mysql）+实际数据（HDFS）
默认derby：本地，单用户模式
建mysql：多用户模式（本地+远程）

6、Hive数据管理：
1）Table：内部表
2）External Table：外部表
3）Partition：辅助查询，缩小查询范围，加快数据检索速度
4）Bucket：桶，reduce，采样，控制reduce的数量

7、Hive数据类型
1）原生类型int string bool double
2）复合类型

8、hive优化（mapreduce优化）
1）map优化
优化并发个数
block大小会影响并发度
hive.map.aggr=true ，相当于开启Combiner功能

2）reduce优化
优化并发个数
set mapred.reduce.tasks=10

3）mapreduce出现痛点：只有一个reduce的情况
1、没有group by
2、order by，建议用distribute by和sort by来替代
order by：全局排序，因此只有一个reduce，当输入数据规模较大时，计算时间消耗严重
sort by：不是全局排序，如果用sort by排序，并且设置多个reduce，
每个reduce输出是有序的，但是不保证全局排序
distribute by：控制map端的数据如果拆分给redcuce，可控制分区文件的个数
cluster by：相当于distribute by和sort by的结合，但是只默认升序排序

先在map阶段进行排序，再根据不同的key进行分发
例子1：select * from TableA distribute by userid sort by itemid;

例子2：
select * from TableA distribute by itemid sort by itemid asc；
select * from TableA cluster by itemid;
3、笛卡尔积
使用join的时候，尽量有效的使用on条件

 

4）mapreduce出现痛点：如何加快查询速度（横向尽可能多并发，纵向尽可能少依赖）
1、分区Partition
2、Map Join：指定表是小表，内存处理，通常不超过1个G或者50w记录
3、union all：先把两张表union all，然后再做join或者group by，可以减少mr的数量
union 和 union all区别：union相当记录合并，union all不合并，性能后者更优
4、multi-insert & multi group by
5、Automatic merge：为了多个小文件合并
6、Multi-Count Distinct
一个MR，拆成多个的目的是为了降低数据倾斜的压力
7、并行执行：set hive.exec.parallel=true

 

5）mapreduce出现痛点：如何加快join操作
1、语句优化：
多表连接：如果join中多个表的join key是同一个，则join会转化为单个mr任务
表的连接顺序：指定大、小表
Hive默认把左表数据放到缓存中，右边的表的数据做流数据
2、如果避免join过程中出现大量结果，尽可能在on中完成所有条件判断

SELECT a.val, b.val FROM a LEFT OUTER JOIN b ON (a.key=b.key) WHERE a.ds=‘2009-07-07‘ AND b.ds=‘2009-07-07‘

ASELECT a.val, b.val FROM a LEFT OUTER JOIN b ON (a.key=b.key AND b.ds=‘2009-07-07‘ AND a.ds=‘2009-07-07‘)

 执行顺序是，首先完成2表JOIN，然后再通过WHERE条件进行过滤，这样在JOIN过程中可能会 输出大量结果，再对这些结果进行过滤，比较耗时。可以进行优化，将WHERE条件放在ON后 ，在JOIN的过程中，就对不满足条件的记录进行了预先过滤。

 

6)并行实行：

– 同步执行hive的多个阶段，hive在执行过程，将一个查询转化成一个或者多个阶段。

某个特 定的job可能包含众多的阶段，而这些阶段可能并非完全相互依赖的，也就是说可以并行执行 的，这样可能使得整个job的执行时间缩短。

hive执行开启：set hive.exec.parallel=true

7）数据倾斜

mapreduce解决数据倾斜问题
1、大小表关联
2、大大表关联

操作

• Join

• Group by

• Count Distinct

• 原因

　　• key分布不均导致的

　　• 人为的建表疏忽

　　• 业务数据特点

• 症状

　　• 任务进度长时间维持在99%（或100%），查看任务监控页面，发现只有少量（1个或几个）reduce子任务未完成。 • 查看未完成的子任务，可以看到本地读写数据量积累非常大，通常超过10GB可以认定为发生数据倾斜。

• 倾斜度

　　• 平均记录数超过50w且最大记录数是超过平均记录数的4倍。

　　• 最长时长比平均时长超过4分钟，且最大时长超过平均时长的2倍。

• 万能方法 • hive.groupby.skewindata=true

 

H i v e 的优化——数据倾斜——大小表关联

• 原因

　　• Hive在进行join时，按照join的key进行分发，而在join左边的表的数据会首先读入内存，如果左边表的key相对 分散，读入内存的数据会比较小，join任务执行会比较快；而如果左边的表key比较集中，而这张表的数据量很大， 那么数据倾斜就会比较严重，而如果这张表是小表，则还是应该把这张表放在join左边。
• 思路

　　• 将key相对分散，并且数据量小的表放在join的左边，这样可以有效减少内存溢出错误发生的几率 • 使用map join让小的维度表先进内存。
• 方法

　　• Small_table join big_table