Hive优化(面试宝典)
1.1 hive的随机抓取策略
理论上来说,Hive中的所有sql都需要进行mapreduce,但是hive的抓取策略帮我们 省略掉了这个过程,把切片split的过程提前帮我们做了。 set hive.fetch.task.conversion=none; (一旦进行这么设置,select字段名也是需要进行mapreduce的过程,默认是more)
Fetch抓取的模式 可以通过 set hive.fetch.task.conversion查看,有以下3种模式: none:所有涉及hdfs的读取查询都走mapreduce任务; mininal:在进行简单的select *,简单的过滤或涉及分区字段的过滤时走mr; more:在mininal模式的基础上,增加了针对查询语句字段进行一些别名的计算操作。 以下HQL,mininal模式与more模式下都不会走mr任务: SELECT sale_ord_id, store_id FROM test_table where dt = '2021-01-01' limit 10; 以下HQL,mininal模式会走mr任务,more模式不会: SELECT sale_ord_id, store_id, if(store_id > 20,1,0) as store_id_new FROM test_table where dt = '2021-01-01' limit 10;
查看怎么将一个sql转化成一个MR任务的 explain sql语句 例如: explain select count(*) from stu_dy1_1; 更加详细的查看,例如: explain extended select count(*) from stu_dy1_1; 当你输入一个sql语句的时候,hive会将对其关键字进行截串,截完串之后,变成 都是一些TOK开头的一些东西,然后经过这样的抽象语法树,再转成具体的查询块, 最后变成逻辑查询计划
1.2 本地运行模式
大多数的 Hadoop Job 是需要 Hadoop 提供的完整的可扩展性来处理大数据集的。不过, 有时 Hive 的输入数据量是非常小的。在这种情况下,为查询触发执行任务消耗的时间可能 会比实际 job 的执行时间要多的多。对于大多数这种情况, Hive 可以通过本地模式在单台机 器上处理所有的任务。对于小数据集,执行时间可以明显被缩短。 用户可以通过设置 hive.exec.mode.local.auto 的值为 true ,来让 Hive 在适当的时候自动 启动这个优化。 本地模式运行比集群模式块很多,33秒的任务降到2秒 更改为本地模式: hive> set hive.exec.mode.local.auto=true 注意: hive> set hive.exec.mode.local.auto.inputbytes.max=134217728 ---> 128M (默认值就是128) 表示加载文件的最大值,若大于该配置仍然会以集群的方式去运行。 97万行数据,50MB 当我们开发或者测试阶段,可以去使用本地模式进行运行,默认是集群模式 但是,这里有个问题,当我们去更改为本地模式的时候,在8088的页面上就看不到 任务的执行情况了。 测试:select count(*) from emp group by deptno;
1.3 并行计算
通过设置以下参数开启并行模式(默认是false) set hive.exec.parallel=true; 注意:hive.exec.parallel.thread.number (一次SQl计算中允许并行执行的job个数最大值,默认是8个) 举例: select t1.n1,t2.n2 from (select count(ename) as n1 from emp) t1,(select count(dname) as n2 from dept) t2; 注意,有时候开启并行计算运行时间并没有不开启的快,那是因为,资源的问题。 需要两套资源,资源申请会浪费点时间,最多可以并行8个,默认是8个。 所以,并行的越多,不一定是越快,因为它涉及到一个资源申请的策略。
1.4 严格模式(理解为增加一些限制)
1.什么是Hive的严格模式 hive中的一种模式,在该模式下禁止一些不好SQL的执行。
2.Hive的严格模式不允许哪些SQL执行 2.1 禁止分区表全表扫描 分区表往往数据量大,如果不加分区查询会带来巨大的资源消耗 。例如以下分区表 SELECT DISTINCT(planner_id) FROM fracture_ins WHERE planner_id=5;
报错如下: FAILED: Error in semantic analysis: No Partition Predicate Found for Alias “fracture_ins” Table "fracture_ins
解决如下: SELECT DISTINCT(planner_id) FROM fracture_ins WHERE planner_id=5 AND hit_date=20120101;
2.2 禁止排序不加limit 排序最终是要都进到一个Reduce中操作,防止reducer额外执行很长一段时间 SELECT * FROM fracture_ins WHERE hit_date>2012 ORDER BY planner_id; 出现如下错误 FAILED: Error in semantic analysis: line 1:56 In strict mode,limit must be specified if ORDER BY is present planner_id 解决方案就是增加一个limit关键字: hive> SELECT * FROM fracture_ins WHERE hit_date>2012 ORDER BY planner_id LIMIT 100000;
2.3 禁止笛卡尔积 笛卡尔积是什么: A={a,b}, B={0,1,2},则 A×B={(a, 0), (a, 1), (a, 2), (b, 0), (b, 1), (b, 2)}
SELECT * FROM fracture_act JOIN fracture_ads; 解决方法 SELECT * FROM fracture_act JOIN fracture_ads WHERE fracture_act.planner_id = fracture_ads.planner_id;
3.Hive的严格模式怎样开启
// 查看当前严格模式的状态 set hive.mapred.mode; // 设置为严格模式 set hive.mapred.mode=strict; // 设置为非严格模式 set hive.mapred.mode=nonstrict;注意,这里的严格模式和动态分区的那个严格模式半毛钱关系没有) 通过设置以下参数开启严格模式: set hive.mapred.mode=strict; (默认为:nonstrict非严格模式) 查询限制: 1、对于分区表,必须添加where对于分区字段的条件过滤 2、order by 语句必须包含limit输出限制 3、限制执行笛卡尔积的查询 这些限制是帮助我们提高查询效率的。
1.5 Hive排序(掌握distribute by和sort by) 回顾
order by 对于查询结果做全局排序,只允许有一个reduce处理 (注意:它会把我们所有的字段或者查询结果全部放在一个reduce里进行处理 当数据量较大时候,有可能reduce执行不完,所以,我们以后把这个给弃用掉) ** sort by 对于单个reduce进行排序 但是我们将每个reduce里面进行排序,没有考虑到 每个reduce之间的排序。所以我们引出下一个 ** distribute by 分区排序,通常结合sort by一起使用 (distribute by column sort by column asc|desc) cluster by 相当于distribute by + sort by (注意,虽然是两个结合,但是我们也不去用它 原因很简单,cluster by不能通过asc desc的方式指定排序方式规则)
1.6 Hive join数据倾斜(相当重要,记住这块,面试到hive数据倾斜稳过)
1、小表join小表 不管他
2、小表join大表 map-join
假如1000000条数据,a对应999999条数据,b对应1条数据 则其中一个reduce压力过大
3、大表join大表 map-side
考虑会不会发生reduce,并且考虑reduce压力是否大(是否会出现某个reduce数据量庞大的情况)
join计算的时候,将小表(驱动表)放在join的左边 Map join:在Map端完成join 两种实现方式: 1、sql方式,在sql语句中添加Mapjoin标记(mapjoin hint) >>语法: select /*+MAPJOIN(smallTable)*/ smallTable.key bigTable.value from smallTable join bigTable on smallTable.key=bigTable.key; 2、自动开启mapjoin 通过修改以下配置启用自动的mapjoin: set hive.auto.convert.join=true; (注意:该参数为true的时候,Hive自动对左边的表统计量,如果 是小表,就加入到内存,即对小表使用Mapjoin) 相关配置参数 hive.mapjoin.smalltable.filesize;(默认25M,大表小表判断的阈值,如果表的大小小于该值则会被加载到内存中运行。) hive.ignore,mapjoin.hint;(默认值:true;是否忽略mapjoin hint的标记) hive.auto.convert.join.noconditionaltask;(默认值:true;将普通的join转换为mapjoin时,是否将多个mapjoin转化为一个mapjoin) hive.auto.convert.join.noconditionaltask.size;(将多个mapjoin转化为一个mapjoin时,这个表的最大值) 3、尽可能使用相同的连接键,如果不同,多一个join就会多开启一个mapreduce,执行速度变得慢。 4、大表join大表(当两个都是大表的时候,只能发生reduce了,但是这里有两个优化策略)(面试的时候说,加分) a: 空key过滤: 有时join超时是因为某些key对应的数据太多,而相同key对应的数据都会发送到相同的 reducer上,从而导致内存不够。 此时我们应该仔细分析这些异常的key,很多情况下,这些key对应的数据是异常数据,我们需要在SQL语句中进行过滤。 但是这个的前提条件是异常数据,但是我们一般拿到的数据都是经过ETL数据清洗过后的,一般影响不大,面试的时候可以说。 b: 空key转换: 有时虽然某个key为空对应的数据很多,但是相应的数据不是异常数据,必须要包含在join的结果中, 此时我们可以表a中key为空的字段赋随机的值,使得数据随机均匀地分不到不同的 reducer上。(加盐) 但是我们一般拿到的数据都是经过ETL数据清洗过后的,规则数据,一般影响不大,面试的时候可以说。 5、Map-Side聚合 通过设置以下参数开启在Map端的聚合 set hive.map.aggr=true;(一定要进行开启,虽然进行了两个mapreduce,但是当数据倾斜发生的时候,很多时候会根本跑不出结果,卡死在99%或者100%,慢总比出不来结果要好)!!!!!!! 相关配置参数 hive. groupby mapaggr. checkinterval; map端 igroup by执行聚合时处理的多少行数据(默认:10000 hive.map.aggr.hash.min.reduction;比例(若聚合之后的数据100大该0.5,map端聚合使用的内存的最大值 hive.mapaggr.hashforce.flush.memory.threshold;map端做聚合操作是has表的最大可用内容,大于该值则会触发fush hive.groupby.skewindata-是否对 GroupBy产生的数据倾斜做优化,默认为false(十分重要!!!) 6、数据倾斜,尽可能地让我们的数据散列到不同的reduce里面去,负载均衡
1.7 合并小文件
Hive优化 合并小文件 文件数目小,容易在文件存储端造成压力,给hdfs造成压力,影响效率 设置合并属性 是否合并map输出文件: hive.merge.mapfiles=true 是否合并reduce输出文件: hive.merge.mapredfiles=true 合并文件的大小: hive.merge.size.per.task=256*1000*1000 去重统计 数据量小的时候无所谓,数据量大的情况下,由于 COUNT DISTINCT操作需要用一个 Reduce Task来完成, 这一个 Reduce需要处理的数据量太大,就会导致整个JOb很难完成,一般 COUNT DISTINCT使用先 GROUP BY再COUNT的方式替换
1.8 控制map和reduce的数量(一般情况下我们不去动它)
控制Hive中Map以及 Reduce的数量 Map数量相关的参数 mapred.max.split.size;一个split的最大值,即每个map处理文件的最大值 mapred.min.split.size.per.node个节点上split的最小值 mapred.min.split.size.per.rack一个机架上spit的最小值 Reduce数量相关的参数 mapred.reduce.tasks;强制指定reduce任务的数量 hive.exec.reducers.bytes.per.reducer每个reduce任务处理的数据量 hive.exec.reducers.max每个任务最大的reduce数
1.9 JVM重用
当我们的小文件个数过多,task个数过多,需要申请的资源过多的时候,我们可以先申请一部分资源,全部执行完毕后再释放, 比我们申请一个释放一个要快。 通过 set mapred.job.reuse.jvm.num.tasks=n;来设置 (n为task插槽个数) 缺点: 设置开启后,task插槽会一直占用资源,无论是否有task进行,直到所有的task, 即整个job全部执行完毕后,才会释放所有的task插槽,所以我们要合理地设置这个n (比如,我们设置申请了10个,但是现在来了6个,剩下4个插槽会在job全部执行完毕之前一直占用资源)
mapreduce叫懒加载,当执行任务需要资源的时候再去申请资源