hive调优
1 建表优化
1.1 分区表
分区表可以减少全表的扫描,查询时先基于分区过滤,再进行查询。
对于大型数据集,可以将表划分为多个分区,每个分区包含一定的数据,可以提高效率,因为查询只需要扫描需要的分区
1.2 分桶表
按照join字段进行分桶,这样join的时候就不会进行全局join,而是桶与桶之间的join
分区表和分桶表的区别 :
分区表就是分目录,一个目录代表一个分区,可以避免全表扫描
分桶表根据分桶字段的hash值,对桶的个数取余运算,最后得到数据决定应该放在哪个桶中
回到正题,二者的区别:
- 创建语句不同,分区表的创建语句是 partition by ,分桶表是clustered by
- 字段要求不同: 分区字段不能是表中已经存在的字段,分桶字段一定是表中存在的字段
- 表现形式不同:分区表是为了分目录而存放数据,分桶表是将一个文件拆分成很多个文件进行存放
1.3 选择合适的文件格式
- 文本格式:hive默认使用文本格式来存储数据,简单易用但是不支持压缩和索引,查询效率低
- ORC格式: 基于列式存储,以二进制的方式存储,可以大幅度减少磁盘空间和IO操作,支持数据压缩和索引,可以提高查询性能
- Parquet:基于列式存储,以二进制的方式存储,能有有效的压缩数据
- sequenceFile:以二进制的方式存储,支持数据的分割和序列化
1.4 选择合适的压缩方式
当选择压缩格式时,需要考虑以下几个方面:
- 压缩比
不同的压缩格式在压缩比方面有所不同。通常来说,压缩比越高,数据存储空间占用就越小,但解压缩速度就越慢。因此,在选择压缩格式时需要根据实际的数据存储需求来权衡压缩比和解压缩速度。
- 压缩速度
压缩和解压缩速度也是选择压缩格式时需要考虑的因素。快速压缩格式如 Snappy 和 LZO 可以在数据处理时提供快速的压缩和解压缩速度,可以用于需要快速处理实时数据的场景。而其他压缩格式如 Gzip 和 Bzip2 的压缩和解压缩速度相对较慢,适用于数据存储需求更高的场景。
- 数据流处理
不同的压缩格式对数据流处理的支持也不同。像 Snappy 和 LZO 这样的快速压缩格式可以支持数据流处理,即可以进行实时查询和流式处理。而像 Gzip 和 Bzip2 这样的压缩格式需要先解压缩后才能进行数据处理,不支持数据流处理。
- CPU 消耗
不同的压缩格式对 CPU 消耗也不同。压缩和解压缩速度较快的格式如 Snappy 和 LZO 消耗相对较低,而压缩比较高的格式如 Gzip 和 Bzip2 消耗相对较高。
2 语法优化
2.1 单表查询优化
2.1.1 分区优化
根据分区进行查询,避免加载整个表的数据
2.1.2 group by
- 开启map端聚合
- 开启负载均衡:生成的查询计划会有两个MR job,一个是局部聚合(加随机数),另一个是全局聚合(删随机数)
2.2 多表查询优化
2.2.1 CBO优化
选择代价最小的执行计划,自动优化hive SQL中多个join的顺序,选择合适的join
2.2.2 谓词下推
将SQL语句中的where谓词逻辑都尽可能提前执行,减少下游处理的数据量
2.2.3Mapjoin
将join双方比较小的表,直接分发到各个map进程的内存中,不用reduce了,从而提高效率
2.2.4 SMB join
将大表转换为很多小标,分别进行join,最后union到一起
2.3 job优化
2.3.1 map优化
- 对于复杂的文件,增加map的数量
- 进行小文件合并
- map端聚合
2.3.2 reduce优化
合理设置reduce的数量,过多的启动和初始化reduce会消耗时间和资源,同时,有多少个reduce就会有多少个输出文件,小文件过多会产生小文件过多的问题
本文介绍了Hive的优化方法,包括使用分区和分桶表来减少数据扫描,选择合适的文件格式如ORC和Parquet以提升查询效率,以及采用不同的压缩方式平衡存储和CPU消耗。此外,还讨论了语法优化,如单表查询中的分区利用和多表查询中的CBO、MapJoin等策略,以提升整体性能。
1371

被折叠的 条评论
为什么被折叠?



