Hive参数层面常用优化

1、hive数据仓库权限问题:

set hive.warehouse.subdir.inherit.perms=true;

2、HiveServer2的内存

连接的个数越多压力越大,可以加大内存;可以通过-Xmx设置,在脚本中设置:-Xmx=2048m 甚至 -Xmx=4g

3、关闭推测式任务:默认是打开的

set hive.mapred.reduce.tasks.speculative.execution=false;
set mapreduce.reduce.speculative=false; 

4、客户端: 默认是关闭的

显示当前数据库:

set hive.cli.print.current.db = true; 

显示头信息:

set hive.cli.print.header = true;

5、并行执行

每个查询被hive转化成一个或者多个stage,一个stage就是一个mapreduce作业;如果一个job有多个stage,并且每个stage是依赖的,那么这个job就不可以并行执行;如果stage之间关联性不大,则可以并行化执行,减少执行时间。并行书视集群而定,越大越好。

set hive.exec.parallel=true;    //默认是关闭的
set hive.exec.parallel.thread.number=16;   //默认是8 

对比执行时间:

set hive.exec.parallel=false;
select t1.event_time,t2.event_time,t3.event_time from(
select ordernumber, max(event_time) as event_time from order_created group by ordernumber
) t1
left outer join (
select ordernumber, max(event_time) as event_time from order_picked group by ordernumber
) t2 on t1.ordernumber = t2.ordernumber
left outer join (
select ordernumber, max(event_time) as event_time from order_shipped group by ordernumber
) t3 on t1.ordernumber = t3.ordernumber;

一共5个mr job,job一个个的按顺序执行,一共花费94.974s

set hive.exec.parallel=true;
set hive.exec.parallel.thread.number=16;
select t1.event_time,t2.event_time,t3.event_time from(
select ordernumber, max(event_time) as event_time from order_created group by ordernumber
) t1
left outer join (
select ordernumber, max(event_time) as event_time from order_picked group by ordernumber
) t2 on t1.ordernumber = t2.ordernumber
left outer join (
select ordernumber, max(event_time) as event_time from order_shipped group by ordernumber
) t3
on t1.ordernumber = t3.ordernumber;

一共5个mr job,其中有3个job同时启动并行执行,一共花费47.32s

7、Local Mode:小表在本地执行,最好是关闭

set hive.exec.mode.local.auto=true;

8、通过explain查看执行计划,查看有几个stage以及执行流程

explain select * from page_views;
explain extended select * from page_views;

9、队列设置:往指定的队列提交任务

set mapred.queue.name = hive
set mapred.job.queue.name = hive

有些版本需要两个都设置才好用,设置一个还不好使

设置任务的优先级别:

set mapred.job.priority = HIGH

10、JVM重用

测试用例:3台虚拟机,内存512M,5000个小文件大小约8G,不重用JVM耗时约1个小时,重用JVM耗时约35分钟;

结论:对于大量小文件的job,开启JVM重用可减少运行时间;

set mapred.job.reuse.jvm.num.tasks = 15;

每个jvm执行多少个task,默认为1表示一个jvm运行一个task后就销毁,-1表示无限制;该参数也不是越大越好,建议设置到15-20个就够了;

11、分桶

set hive.enforce.bucketing=true;
set hive.enforce.sorting=true;
时间: 2024-08-05 19:34:27

Hive参数层面常用优化的相关文章

Hive参数层面优化之一控制Map数

1.Map个数的决定因素 通常情况下,作业会通过input文件产生一个或者多个map数: Map数主要的决定因素有: input总的文件个数,input文件的大小和集群中设置的block的大小(在hive中可以通过set dfs.block.size命令查看,该参数不能自定义修改): 文件块数拆分原则:如果文件大于块大小(128M),那么拆分:如果小于,则把该文件当成一个块. 举例一: 假设input目录下有1个文件a,大小为780M,那么hadoop会将该文件a分隔成7个块(6个128m的块和

Hive参数层面优化之二控制Reduce数

Reduce数决定中间或落地文件数,文件大小和Block大小无关. 1.Reduce个数的决定因素 reduce个数的设定极大影响任务执行效率,不指定reduce个数的情况下,Hive会猜测确定一个reduce个数,基于以下两个设定: 参数1:hive.exec.reducers.bytes.per.reducer(每个reduce任务处理的数据量,默认为1000^3=1G) 参数2:hive.exec.reducers.max(每个作业最大的reduce数,默认为999) 计算reducer数

Hive架构层面优化之四 常用复杂/低效的统计从源上给出,以避免上层作业过多计算

案例一:trackinfo,基础表处理常用的低性能UDF 背景描述:日志信息10分钟加载一次到实时日志表trackreal中(按小时分区),为了保证实时性,在加载的过程中并没有做任何的过滤处理,加载到trackreal表后再过滤非法数据.爬虫数据等,生成按天增量日志表trackinfo,然后根据不同的page_type来统计流量. 解决方案如下: select '首页', count(*) pv, #每条记录就是一条pv count(distinct session_id) uv #根据sess

Hive调优(语法与参数层面优化)

一.简介 作为企业Hadoop应用的核心产品,Hive承载着FaceBook.淘宝等大佬 95%以上的离线统计,很多企业里的离线统计甚至全由Hive完成,如我所在的电商.Hive在企业云计算平台发挥的作用和影响愈来愈大,如何优化提速已经显得至关重要. 好的架构胜过任何优化,好的Hql同样会效率大增,修改Hive参数,有时也能起到很好的效果. 有了瓶颈才需要优化 1.Hadoop的主要性能瓶颈是IO负载,降IO负载是优化的重头戏. 2.对中间结果的压缩 3.合理设置分区,静态分区和动态分区 二.H

Hive语法层面优化之四count(distinct)引起的数据倾斜

当该字段存在大量值为null或空的记录,容易发生数据倾斜: 解决思路: count distinct时,将值为空的情况单独处理,如果是计算count distinct,可以不用处理,直接过滤,在最后结果中加1: 如果还有其他计算,需要进行group by,可以先将值为空的记录单独处理,再和其他计算结果进行union. 案例: select count(distinct end_user_id) as user_num from trackinfo; 调整为: select cast(count(

Hive架构层面优化之一分表

场景:某个日志表数据量很大,而且访问该表的作业比较多,造成耗时比较长: 解决方案:将用的比较少/不常用的字段剥离出去: 案例: 日志表trackinfo,每天约有2亿数据量,有5000个作业按天访问,每天的日志数据量有可能会继续添加下去,那么很可能就满足不了要求(每添加10%的数据量作业大概要添加20分钟):如何解决数据的增长呢? 方案: 将邮件营销EDM,网盟Union从trackinfo表中剥离出来,trackinfo表大概能降到1.5亿左右,这样作业的执行时间大概可以减少40-50分钟时间

Hive语法层面优化之一数据倾斜介绍

数据倾斜:数据分布不均匀,造成数据大量的集中到一点,造成数据热点: 由于数据并不是平均分配的,会导致各个节点上处理的数据量是不均衡的,所以数据倾斜是无法避免的: 造成数据倾斜的最根本原因:key分发不均匀造成的: 常见的数据倾斜的症状 1)  Map阶段快,reduce阶段非常慢: 2)  某些map很快,某些map很慢: 3)  某些reduce很快,某些reduce很慢: 4)  任务进度长时间维持在99%(或100%),查看任务监控页面,发现只有少量(1个或几个)reduce子任务未完成,

Hive语法层面优化之五分析执行计划追踪导致数据倾斜的原因

count(distinct key)案例 explain select count(distinct session_id) from trackinfo where ds=' 2013-07-21' ; STAGE DEPENDENCIES: Stage-1 is a root stage Stage-0 is a root stage STAGE PLANS: Stage: Stage-1 Map Reduce Alias -> Map Operator Tree: trackinfo T

Hive架构层面优化之二合理利用中间结果集(单Job)

是针对单个作业,针对本job再怎么优化也不会影响到其他job: Hadoop的负载主要有两部分:CPU负载和IO负载: 问题:机器io开销很大,但是机器的cpu开销较小,另外map输出文件也较大,怎么办? 解决办法:通过设置map的中间输出进行压缩就可以了,这个不会影响最终reduce的输出. 集群中的机器一旦选定了,那么CPU就没的改变了,所以集群的最主要的负载还是IO负载: 压缩技术虽然可以降低IO负载,但是同时也加重了CPU负载,治标不治本,CPU加重了,整体性能还是上不去:如果当前CPU