Hive调优-压缩,分区分桶,表的优化

有没有掌握hive调优,是判断一个数据工程师是否合格的重要指标

1.数据的压缩与存储格式

MR支持的压缩编码
在这里插入图片描述

性能比较
在这里插入图片描述
①bzip2的压缩率高,但是压缩/解压速度慢
②LZO的压缩率相对低一些,但是压缩/解压速度很快
③注:LZO是供Hadoop压缩数据用的通用压缩编解码器。其设计目标是达到与硬盘读取速度相当的压缩速度,因此速度是优先考虑的因素,而不是压缩率。与Gzip编解码器相比,它的压缩速度是Gzip的5倍,而解压速度是Gzip的2倍。同一个文件用LZO压缩后比用Gzip压缩后大50%但比压缩前小25%~ 50%。这对改善性能非常有利,Map阶段完成时间快4倍。

2.合理利用分区分桶

分区针对的是数据的存储路径;分桶针对的是数据文件。
分区是将表的数据在物理上分成不同的文件夹,以便于在查询时可以精准指定所要读取的分区目录,从来降低读取的数据量。
分桶是将表数据按指定列的hash散列后分在了不同的文件中,将来查询时,hive可以根据分桶结构,快速定位到一行数据所在的分桶文件,从来提高读取效率。

3.Hive参数优化7

// 让可以不走mapreduce任务的,就不走mapreduce任务
hive> set hive.fetch.task.conversion=more;

// 开启任务并行执行
set hive.exec.parallel=true;
// 解释:当一个sql中有多个job时候,且这多个job之间没有依赖,则可以让顺序执行变为并行执行(一般为用到union all的时候)

// 同一个sql允许并行任务的最大线程数
set hive.exec.parallel.thread.number=8;

// 设置jvm重用,JVM重用对hive的性能具有非常大的 影响,特别是对于很难避免小文件的场景或者task特别多的场景,这类场景大多数执行时间都很短。jvm的启动过程可能会造成相当大的开销,尤其是执行的job包含有成千上万个task任务的情况。
set mapred.job.reuse.jvm.num.tasks=10;

// 合理设置reduce的数目
// 方法1:调整每个reduce所接受的数据量大小
set hive.exec.reducers.bytes.per.reducer=500000000; (500M)
// 方法2:直接设置reduce数量
set mapred.reduce.tasks = 20

// map端聚合,降低传给reduce的数据量
set hive.map.aggr=true

// 开启hive内置的数倾优化机制
set hive.groupby.skewindata=true

4.优化SQL

① 移动where的位置,使得where的执行在map端而不是reduce端
② 不必要的情况下,使用union all+group by 而不是union
③ 不要使用count(distinct)
④ 用in代替join
⑤ 优化子查询,减少子查询里面的group by、count(distinct),max,min等,可以减少job的数量
⑥ join优化。
使用map join让小的维度表(1000条以下的记录条数)先进内存。在map端完成reduce。

5.数据倾斜

数据倾斜:任务进度长时间维持在99%(或100%),查看任务监控页面,发现只有少量(1个或几个)reduce子任务未完成。因为其处理的数据量和其他reduce差异过大。
(1)sql本身导致的数据倾斜
① 设置合理的Map数,map数并不是越多越好,一个map任务启动和初始化的时间远远大于逻辑处理的时间,过多的map数就会造成很大的资源浪费。
② 合并小文件:在map执行前合并小文件,减少map数:CombineHiveInputFormat具有对小文件进行合并的功能(系统默认的格式)。
③ 复杂文件增大map数。当input的文件都很大,任务逻辑复杂,map执行非常慢的时候,可以考虑增加Map数,来使得每个map处理的数据量减少,从而提高任务的执行效率。

7.查看SQL的执行计划

学会查看sql的执行计划,优化业务逻辑 ,减少job的数据量。对调优也非常重要!
explain sql

猜你喜欢

转载自blog.csdn.net/Cxf2018/article/details/109288976