hive优化

最新推荐文章于 2024-03-18 04:30:26 发布

原创最新推荐文章于 2024-03-18 04:30:26 发布 · 176 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#hive优化

数仓专栏收录该内容

7 篇文章

订阅专栏

本文围绕Hive优化展开，介绍了整体架构优化，如按日期分区、数据压缩、中间表保存方式；MR优化，涉及map和reduce个数设置；job优化，如mapjoin的使用；SQL优化，包括去除多余列、提前过滤、利用分区信息、调整Join顺序等策略，以提升Hive性能。

1hive整体架构的优化

（1）根据日期进行分区
进行动态分区参数：hive.exec.dynamic.partition=ture
（2）为了减少数据磁盘的存储及i/o的次数
将数据进行压缩：各种压缩进行对比

textfile：160M
（1）hive数据表的默认格式，存储方式：行存储 。
（2） 可使用Gzip,Bzip2等压缩算法压缩,压缩后的文件不支持split
SequenceFile：186M
（1）Hadoop API提供的一种二进制文件，以<key,value>的形式序列化到文件中。存储方式：行存储。
（2）支持三种压缩选择：NONE，RECORD，BLOCK。Record压缩率低，一般建议使用BLOCK压缩。
（3）优势是文件和hadoop api中的MapFile是相互兼容的
RCFile：130M
（1）存储方式：数据按行分块，每块按列存储。结合了行存储和列存储的优点：
（2）首先，RCFile 保证同一行的数据位于同一节点，因此元组重构的开销很低
（3）其次，像列存储一样，RCFile 能够利用列维度的数据压缩，并且能跳过不必要的列读取
ORCFile：同时启动snappy的压缩模式 34M
存储方式：数据按行分块 每块按照列存储
压缩快 快速列存取
效率比rcfile高,是rcfile的改良版本

所以在数据仓库的建设过程当中尽量的使用orc的这种模式再加上压缩模式。一方面减少磁盘的使用量，一方面可以实现数据的split（分布式计算），实现查询速度加快
对于其他方式进行数据的压缩
在插入之前对表的压缩模式进行设定
set hive.exec.compress.output=true;
set mapred.output.compress=true;
set mapred.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec;
set io.compression.codecs=org.apache.hadoop.io.compress.GzipCodec;

（3）中间表以SequenceFile保存，可以节约序列化和反序列化的时间

相关参数设置：
hive.query.result.fileformat=SequenceFile

2 mr的优化
主要是在 map个数的设置和 reduce个数的设置
reduce切割算法：

相关参数设置，默认为：
hive.exec.reducers.max=999
hive.exec.reducers.bytes.per.reducer=1G
reduce task num=min{reducers.max,input.size/bytes.per.reducer}，可以根据实际需求来调整reduce的个数。

3job优化

mapjoin

默认mapjoin是打开的， hive.auto.convert.join.noconditionaltask.size=10MB

装载到内存的表必须是通过scan的表（不包括group by等操作），如果join的两个表都满足上面的条件，/mapjoin/指定表格不起作用，只会装载小表到内存，否则就会选那个满足条件的scan表。

4 SQL优化

整体的优化策略如下：
去除查询中不需要的column
Where条件判断等在TableScan阶段就进行过滤
利用Partition信息，只读取符合条件的Partition
Map端join，以大表作驱动，小表载入所有mapper内存中
调整Join顺序，确保以大表作为驱动表
对于数据分布不均衡的表Group by时，为避免数据集中到少数的reducer上，分成两个map-reduce阶段。第一个阶段先用Distinct列进行shuffle，然后在reduce端部分聚合，减小数据规模，第二个map-reduce阶段再按group-by列聚合。
在map端用hash进行部分聚合，减小reduce端数据处理规模。