HIVE核心优化方案

目录

1.数据采样

2.join优化

3.Hive索引

4.数据倾斜

1.HIVE核心优化方案--数据采样

分桶表

分文件的, 在创建表的时候, 指定分桶字段, 并设置分多少个桶, 在添加数据的时候, hive会根据设置分桶字段 , 将数据划分到N个桶(文件)中, 默认情况采用HASH分桶方案 , 分多少个桶, 取决于建表的时候, 设置分桶数量, 分 了多少个桶最终翻译的MR也就会运行多少个reduce程序(HIVE的分桶本质上就是MR的分区操作).

作用

(1) 进行数据采样工作

(1.1) 当表的数据量比较庞大的时候, 在编写SQL语句后, 需要首先测试 SQL是否可以正常的执行, 需要在表中执 行查询操作, 由于表数据量比较庞大, 在测试一条SQL的时候整个运行的时间比较久, 为了提升测试效率, 可以整个表 抽样出一部分的数据, 进行测试

(1.2) 校验数据的可行性(质量校验)

(1.3) 进行统计分析的时候, 并不需要统计出具体的指标, 可能统计的都是一些相对性指标, 比如说一些比率(合 格率)问题, 此时可以通过采样处理

(2) 提升查询的效率(更主要是提升JOIN的效率) 可以减少JOIN次数, 从而提升效率

如何采样

• 采样函数: tablesample(bucket x out of y [on column])
• 使用位置:紧紧跟在表名的后面, 如果表名有别名, 必须放置别名的前面
• 说明: x: 从第几个桶开始进行采样; y: 抽样比例; column: 分桶的字段, 可以省略

2.HIVE核心优化方案--join优化

在reduce端Join操作, 存在那些弊端?

• 1- 可能会存在数据倾斜的问题 (某几个reduce接收数据量远远大于其他的reduce接收数据量)
• 2- 所有的数据处理的操作, 全部都压在reduce中进行处理, 而reduce数量相比Map来说少的多,导致整个reduce压 力比较大

思考: 如何提升Join的效率呢?

思路: 能否不让reduce做这个聚合处理的事情, 将这项工作尝试交给mapTask

Map join

Map Join: 每一个mapTask在读取数据的时候, 每读取一条数据, 就会和内存中小表数据进行匹配, 如果能匹配的上 , 将匹配上数据合并在一起, 输出即可

好处: 将原有reduce join 问题全部都可以解决

弊端:

• 1- 比较消耗内存
• 2- 要求整个 Join 中, 必须的都有一个小表, 否则无法放入到内存中 仅适用于: 小表 join 大表 | 大表 join 小表

Bucket Map Join

适用场景: 中型表 和 大表 join:

方案一: 如果中型表能对数据进行提前过滤, 尽量提前过滤, 过滤后, 有可能满足了Map Join 条件 (并不一定可用)

方案二: Bucket Map Join

SMB join

大表 和 大表 join

解决方案: SMB Join ( sort merge bucket map

3.HIVE索引

Row Group Index索引

条件:

(1) 要求表的存储类型为ORC存储格式

(2) 在创建表的时候, 必须开启 row group index 索引支持 'orc.create.index'='true'

(3) 在插入数据的时候, 必须保证需求进行索引列, 按序插入数据 适用于: 数值类型的, 并且对数值类型进行 > < = 操作

思路: 插入数据到ORC表后, 会自动进行划分为多个script片段, 每个片段内部, 会保存着每个字段的最小, 最大值, 这样, 当执行查询 > < = 的条件筛选操作的时候, 根据最小最大值锁定相关的script片段, 从而 减少数据扫描量, 提升效

Bloom Fliter Inde索引

条件:

(1) 要求表的存储类型为 ORC存储方案

(2) 在建表的饿时候, 必须设置为那些列构建布隆索引

(3) 仅能适合于等值过滤查询操作

思路: 在开启布隆过滤索引后, 可以针对某个列, 或者某几列来建立索引, 构建索引后, 会将这一列的数据的值存储在对应script片段的索引信息中, 这样当进行等值查询的时候, 首先会到每一个script片段的索引中, 判断是否有这个值, 如果没有, 直接跳过script, 从而减少数据扫描量, 提升效率

4.HIVE核心优化方案--数据倾斜

在前序讲解reduce 端 JOIN的时候, 描述过reduce 端Join的问题, 其中就包含reduce端Join存在数据倾斜的问题

解决方案一: 可以通过 Map Join Bucket Map Join 以及 SMB Join 解决

注意: 通过 Map Join,Bucket Map Join,SMB Join 来解决数据倾斜, 但是 这种操作是存在使用条件的, 如果无法满足这 些条件, 无法使用 这种处理方

解决方案二:

思路: 将那些产生倾斜的key和对应v2的数据, 从当前这个MR中移出去, 单独找一个MR来处理即可, 处理后, 和之前的 MR进行汇总结果即可 关键问题: 如何找到那些存在倾斜的key呢? 特点: 这个key数据有很多

两种解决方案: 运行期处理方案 和 编译期处理方

union all 优化方案

说明: 不管是运行期 还是编译期的join倾斜解决, 最终都会运行多个MR, 将多个MR结果通过union all 进行汇总, union all也是需要单独一个MR来处理

解决方案: 让每一个MR在运行完成后, 直接将结果输出到目的地即可, 默认 是各个MR将结果输出临时目录, 通过 union all 合并到最终目的地

开启此参数即可: set hive.optimize.union.remove=true;

Group by数据倾斜

解决方案一: 基于MR的 combiner(规约, 提前聚合) 减少数据达到reduce数量, 从而减轻倾斜

    方案二: 负载均衡的解决方案(需要运行两个MR来处理) (大combiner方案)