Hive中的基本优化 + 索引优化 + 数据倾斜优化

怼烎@ 2024-04-07 11:56 81阅读 0赞

#### 数据倾斜 ####

*  1. 基础优化
 *   *  1.1 并行编译优化
     *  1.2 并行执行优化
     *  1.3 小文件合并
     *  1.4 矢量化查询
     *  1.5 读取零拷贝 ZeroCopy
 *  2. 索引优化
 *   *  2.1 原始索引
     *  2.2 行组索引 row group（大小对比索引）-------用于数值查询
     *  2.3 布尔索引------用于等值查询 （=或in）
 *  3. 数据倾斜优化
 *   *  3.1 概述
     *   *  何为数据倾斜
         *  导致的问题
     *  3.2 优化
     *   *  group by 数据倾斜
         *  join 数据倾斜

## 1. 基础优化 ##

**前提：**  
并行优化的前提是要服务器有足够的资源，如果没有资源则不会执行； 在SMBmapjoin中，资源不够导致运行很慢；

### 1.1 并行编译优化 ###

Hive在同一时间只能编译一段HiveSQL，而工作环境有多个会话窗口，如果有多个HiveSQL并行执行，就会锁住，排队执行；需要开启并行执行；

开启：  
![在这里插入图片描述][5d77881e341d4d089f997d77e7648615.png]  
![在这里插入图片描述][f0a0079505654db589314429924d1a5d.png]

### 1.2 并行执行优化 ###

在运行SQL时，这个SQL的执行计划中，可能被拆分为多个 `Stage` 阶段，**当各个阶段之间没有依赖关系的函数，可以尝试让多个阶段并行执行**，提升执行效率；

带set的，即在会话窗口中配置，而没有set的在 Cloudera Manager中通用配置来配置；  
![在这里插入图片描述][ccdb9516b660431aa07ea631f6828afa.png]

### 1.3 小文件合并 ###

**小文件过多有什么影响？**

MR角度：  
每个文件单独切片，一个切片对应一个MapTask，**会产生多个MapTask**，每个MapTask都需要资源，而每个MapTask只处理很少的数据，导致资源浪费；

HDFS角度：  
每个小文件都会有**元数据**，元数据太多，使得NameNode内存过大，一旦NameNode内存满了，即使DataNode有空间，也无法存数据！

**开启**：  
![在这里插入图片描述][af0b81e58ab34eabac696803afedf6fe.png]是否开启map端小文件合并，适用于使用map没有reduce的时候，即map输出就是结果；  
![在这里插入图片描述][5622eec31929442dbf34f083f1301766.png]是否开启Reduce端文件合并操作；  
![在这里插入图片描述][440f8519df51461898e82707a0534520.png]合并后输出文件的最大值，默认128mb；  
![在这里插入图片描述][641e64b6287b4e16abcac4c8ea939e35.png]判定平均输出文件大小，当小于设置值时，认为出现了小文件问题，会按照最大值来进行合并；

### 1.4 矢量化查询 ###

Hive默认查询执行引擎默认一次处理一行，而矢量化查询执行是一种hive特性，目的是按照**每批 1024行读取数据**！ 而且一次性对整个记录整合（而不是对单条记录）应用操作；

**开启**： set 即在会话中开启；  
![在这里插入图片描述][699efa4c412a4d649a4a10f86d185e25.png]

### 1.5 读取零拷贝 ZeroCopy ###

**前提**：ORC存储  
在 `ORC` 存储格式下，在hive读取数据时，只需要读取跟SQL相关的列的数据即可，没有在SQL中使用的列，不进行读取！从而减少读取数据，提升效率；

**开启**：  
![在这里插入图片描述][0a8c20bc09cb49a1abc302f8f5ff79a5.png]  
**总结**：hive中很多优化都是围绕减少读取数据来进行的，比如读取零拷贝， 分区表，索引的优化…都是为了减少数据的扫描量，减少数据扫描量是显著的提升效率的方案；

## 2. 索引优化 ##

### 2.1 原始索引 ###

在【Hive3.0】以上已经不再使用 ×  
原始索引不能自动更新！需要手动更新---- 重建索引，效率很差！

### 2.2 行组索引 row group（大小对比索引）-------用于数值查询 ###

对**所有的数据**建索引；  
`ORC`文件按行分段**stripes** ，每个片段又按照列存储；  
每个**stripe**片段包含了每个列的 min、max索引数据，当查询时有< > =时，会根据min/max值，跳过扫描那些不包含的片段！

**要求**：  
①必须是`ORC`的存储格式；  
②在创建表的时候必须要开启行组索引 ；  
![在这里插入图片描述][501339f9710a4e878bf869b6b09a79bb.png]

③为了让行组有效，在向表中加载数据时，**必须对需要使用索引的字段进行排序**！否则min max就没有意义；  
④主要应用在＞ ＜ = ，数值型数据；

**例**:  
![在这里插入图片描述][b09515d65d974b2e8fd83944d0903dac.png]  
例：  
![在这里插入图片描述][78335d03c1784edab00433910aa945e4.png]

### 2.3 布尔索引------用于等值查询 （=或in） ###

针对**某一字段**构建索引；  
在对指定的字段建立索引时，会在【每个stripe片段中】，索引字段是相同的；  
当查询条件中包含对字段的 =号过滤的时候，先从布尔索引获取一下是否包含该值，如果不包含则跳过stripe；

**要求**：  
①必须是ORC格式存储  
②对哪个字段进行等值查询，就将字段设置为布尔索引  
③仅适合于等值查询，不局限于数值类型；  
④建表时要指定哪些字段开启索引：![在这里插入图片描述][09340bcc191043d1a2e6c6df4ab0bdf2.png]

例：  
![在这里插入图片描述][496e09da5644456aa2fe107082dcb857.png]

例：  
![在这里插入图片描述][4812ee6b34fa49a89eff65eb8de16fd0.png]

**使用**：  
1）对于行组索引，建议常开  
载入数据时，任意载入，在原始数据某些字段本来就是有序时，就可以使用行组索引；

2）主要对用于等值连接的字段开启索引即可，主要是指的是join的关联字段；

## 3. 数据倾斜优化 ##

### 3.1 概述 ###

#### 何为数据倾斜 ####

运行的过程当中，有多个**Reduce**，每个Reduce拿到的数据不均匀，其中有一个或几个拿到的数据远远大于其他reduce拿到的数量，此时任务出现了数据倾斜；

#### 导致的问题 ####

1.  **执行效率下降**（整个reduce时间，就看最后一个reduce结束时间）；
2.  由于reduce长时间运行不完，导致**资源长期被占用**，一旦超时，YARN会强制回收资源，导致运行失败
3.  **导致节点宕机**；

### 3.2 优化 ###

#### group by 数据倾斜 ####

*  **方案一：Combiner预聚合**  
    一个MR，在【每一个MapTask】使用Combiner预聚合，将聚合之后的结果发往Reduce，这样在Reduce接收到的数据就少了，从而解决数据倾斜；
    
    配置：  
    ![在这里插入图片描述][5e7040c2020c4411bcf097743ad7dca9.png]  
    开启map端提前聚合 ；
 *  **方案二： 负载均衡（大Combiner**） **skew**  
    采用**两个MR**来解决，  
    **第一次MR**负责将**数据均匀落在不同的reduce上进行聚合统计**，形成一个局部的结果；  
    **第二个MR，读取第一个MR的局部结果**，按照相同的key发往同一个reduce，完成统计；
    
    配置：  
    ![在这里插入图片描述][28041429dc0148829d40e4114a6fce05.png]  
    注意：  
    当使用负载均衡时间，不支持在多列上去重，会报错；

#### join 数据倾斜 ####

*  **方案一**： **Map join**、**Bucket map join**、 **SMB map join**  
    将ruduce端的join操作移到到【MapTask的内存】，直接将倾斜排除，因为**map一般不会有数据倾斜问题，map是根据切片来读取文件，切片block(128mb) 是均匀切的**；
    
    但是三种map join都需要满足相关条件，如分桶的数量要整数倍/相同，分桶字段相同；但是很多时候不满足这些条件！
    
    **注意**：在map join之前，还有两个**通用方法**：  
    ①空Key过滤：筛选掉无用字段  
    ②空Key转换：null值太多时将其随机赋值打散，以免数据倾斜；`nvl(n.id,rand())`
 *  **方案二： 在Reduce端解决（无条件） skew join**  
    建议开启 **union**优化，以减少二次读写，减少union输出的额外扫描；整体效率更高；
    
    **思路**：  
    **将容易产生倾斜的key的值从整个环境中排除掉**，将倾斜的数据单独找一个MR来处理，，算完后返回结果；  
    如何知道哪个值导致的倾斜？  
    **①编译（建表）期解决** （**明确知道key值的倾斜问题时**）  
    明确知道key值有倾斜问题，一般采用编译器解决，在建表的时候，提前设置好对应值有倾斜即可，执行时，hive会将这些倾斜的key从这个MR排除，单独找一个MR来处理； 最后底层用union all合并；  
    ![在这里插入图片描述][f2c3afec13464f0d8ad64f8443727f79.png]
    
    **②**运行期解决\*\*（**当不知道哪个key导致倾斜时**，**设定阀值**，**动态检测**）  
    执行时，hive会**记录每个key出现的次数，当key的次数达到特定的阀值，就认为key导致数据倾斜**，将key的数据排除掉，单独用MR去处理；最后底层用union all合并；  
    ![在这里插入图片描述][73c7e56d34494db9ad081eb614ad842c.png]  
    一般设置阀值为平均key个数的3~10倍，认为会产生数据倾斜；

[5d77881e341d4d089f997d77e7648615.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/53914592401d459b8f507cab11a07a2e.png
[f0a0079505654db589314429924d1a5d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/63e0dfac821b471e9824f05b9005613e.png
[ccdb9516b660431aa07ea631f6828afa.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/08436f6b6d984f8f8d9baee9efebe9c8.png
[af0b81e58ab34eabac696803afedf6fe.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/7ad227566bd540a381330ed9a7735e51.png
[5622eec31929442dbf34f083f1301766.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/3bcb6e9c89da43c08d65e1a70aa17779.png
[440f8519df51461898e82707a0534520.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/4eff4ebfaa78481ca90bff53e31e2d2f.png
[641e64b6287b4e16abcac4c8ea939e35.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/6e3f4ba6a83c4c35a96a5dc545335a63.png
[699efa4c412a4d649a4a10f86d185e25.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/03d9cbd078a74d24a3174c0383e47c74.png
[0a8c20bc09cb49a1abc302f8f5ff79a5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/b591e898db044e79af295445571562b6.png
[501339f9710a4e878bf869b6b09a79bb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/bdca46732971497aa8997c1c08cb3164.png
[b09515d65d974b2e8fd83944d0903dac.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/787e3a5d453d4f6bbe3d9dc83d55a7a1.png
[78335d03c1784edab00433910aa945e4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/8e05b07873eb4a709e4e91947962e2c7.png
[09340bcc191043d1a2e6c6df4ab0bdf2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/1f554dcc3e894fdbb9173ec49b4d070f.png
[496e09da5644456aa2fe107082dcb857.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/b31a1096964f43959c4a0cf3c339586b.png
[4812ee6b34fa49a89eff65eb8de16fd0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/00afeb1ba647402bb250b533f8db3be1.png
[5e7040c2020c4411bcf097743ad7dca9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/52fe15f063374443ae1624cfdf391bb9.png
[28041429dc0148829d40e4114a6fce05.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/9f5efeef40244fc5aa8df980775ce3a1.png
[f2c3afec13464f0d8ad64f8443727f79.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/299500a982604a7e82b42adff8316d07.png
[73c7e56d34494db9ad081eb614ad842c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/0ddd38bc315b45b2b9a079611e7c2222.png