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