Hive优化相关设置
参数
hive.optimize.cp=true:列裁剪
hive.optimize.prunner:分区裁剪
hive.limit.optimize.enable=true:优化LIMIT n语句
hive.limit.row.max.size=1000000:
hive.limit.optimize.limit.file=10:最大文件数
1. 本地模式(小任务):
需要满足以下条件:
1.job的输入数据大小必须小于参数:hive.exec.mode.local.auto.inputbytes.max(默认128MB)
2.job的map数必须小于参数:hive.exec.mode.local.auto.tasks.max(默认4)
3.job的reduce数必须为0或者1
hive.exec.mode.local.auto.inputbytes.max=134217728
hive.exec.mode.local.auto.tasks.max=4
hive.exec.mode.local.auto=true
hive.mapred.local.mem:本地模式启动的JVM内存大小
2. 并发执行:
hive.exec.parallel=true ,默认为false
hive.exec.parallel.thread.number=8
3.Strict Mode:
hive.mapred.mode=true,严格模式不允许执行以下查询:
分区表上没有指定了分区
没有limit限制的order by语句
笛卡尔积:JOIN时没有ON语句
4.动态分区:
hive.exec.dynamic.partition.mode=strict:该模式下必须指定一个静态分区
hive.exec.max.dynamic.partitions=1000
hive.exec.max.dynamic.partitions.pernode=100:在每一个mapper/reducer节点允许创建的最大分区数
DATANODE:dfs.datanode.max.xceivers=8192:允许DATANODE打开多少个文件
5.推测执行:
mapred.map.tasks.speculative.execution=true
mapred.reduce.tasks.speculative.execution=true
hive.mapred.reduce.tasks.speculative.execution=true;
6.Single MapReduce MultiGROUP BY
hive.multigroupby.singlemar=true:当多个GROUP BY语句有相同的分组列,则会优化为一个MR任务
7. 是否提供虚拟列
hive.exec.rowoffset:是否提供虚拟列
8. 分组
两个聚集函数不能有不同的DISTINCT列,以下表达式是错误的:
INSERT OVERWRITE TABLE pv_gender_agg SELECT pv_users.gender, count(DISTINCT pv_users.userid), count(DISTINCT pv_users.ip) FROM pv_users GROUP BY pv_users.gender;
SELECT语句中只能有GROUP BY的列或者聚集函数。
9.
hive.map.aggr=true;在map中会做部分聚集操作,效率更高但需要更多的内存。
hive.groupby.mapaggr.checkinterval:在Map端进行聚合操作的条目数目
10.
hive.groupby.skewindata=true:数据倾斜时负载均衡,当选项设定为true,生成的查询计划会有两个MRJob。第一个MRJob 中,
Map的输出结果集合会随机分布到Reduce中,每个Reduce做部分聚合操作,并输出结果,这样处理的结果是相同的GroupBy Key
有可能被分发到不同的Reduce中,从而达到负载均衡的目的;第二个MRJob再根据预处理的数据结果按照GroupBy Key分布到
Reduce中(这个过程可以保证相同的GroupBy Key被分布到同一个Reduce中),最后完成最终的聚合操作。
11.Multi-Group-By Inserts:
FROM test
INSERT OVERWRITE TABLE count1
SELECT count(DISTINCT test.dqcode)
GROUP BY test.zipcode
INSERT OVERWRITE TABLE count2
SELECT count(DISTINCT test.dqcode)
GROUP BY test.sfcode;
12.排序
ORDER BY colName ASC/DESC
hive.mapred.mode=strict时需要跟limit子句
hive.mapred.mode=nonstrict时使用单个reduce完成排序
SORT BY colName ASC/DESC :每个reduce内排序
DISTRIBUTE BY(子查询情况下使用 ):控制特定行应该到哪个reducer,并不保证reduce内数据的顺序
CLUSTER BY :当SORT BY 、DISTRIBUTE BY使用相同的列时。
13.合并小文件
hive.merg.mapfiles=true:合并map输出
hive.merge.mapredfiles=false:合并reduce输出
hive.merge.size.per.task=256*1000*1000:合并文件的大小
hive.mergejob.maponly=true:如果支持CombineHiveInputFormat则生成只有Map的任务执行merge
hive.merge.smallfiles.avgsize=16000000:文件的平均大小小于该值时,会启动一个MR任务执行merge。
14.map/reduce数目
减少map数目:
set mapred.max.split.size
set mapred.min.split.size
set mapred.min.split.size.per.node
set mapred.min.split.size.per.rack
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat
增加map数目:
当input的文件都很大,任务逻辑复杂,map执行非常慢的时候,可以考虑增加Map数,来使得每个map处理的数据量减少,从而提高任务的执行效率。
假设有这样一个任务:
select data_desc, count(1), count(distinct id),sum(case when …),sum(case when ...),sum(…) from a group by data_desc
如果表a只有一个文件,大小为120M,但包含几千万的记录,如果用1个map去完成这个任务,肯定是比较耗时的,这种情况下,我们要考虑将这一个文件合理的拆分成多个,这样就可以用多个map任务去完成。
set mapred.reduce.tasks=10;
create table a_1 as select * from a distribute by rand(123);
这样会将a表的记录,随机的分散到包含10个文件的a_1表中,再用a_1代替上面sql中的a表,则会用10个map任务去完成。每个map任务处理大于12M(几百万记录)的数据,效率肯定会好很多。
reduce数目设置:
参数1:hive.exec.reducers.bytes.per.reducer=1G:每个reduce任务处理的数据量
参数2:hive.exec.reducers.max=999(0.95*TaskTracker数):每个任务最大的reduce数目
reducer数=min(参数2,总输入数据量/参数1)
set mapred.reduce.tasks:每个任务默认的reduce数目。典型为0.99*reduce槽数,hive将其设置为-1,自动确定reduce数目。
15.使用索引:
hive.optimize.index.filter:自动使用索引
hive.optimize.index.groupby:使用聚合索引优化GROUP BY操作
关注公众号
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
-
上一篇
单表千亿电信大数据场景,使用Spark+CarbonData替换Impala案例
背景介绍 国内某移动局点使用Impala组件处理电信业务详单,每天处理约100TB左右详单,详单表记录每天大于百亿级别,在使用impala过程中存在以下问题: 1、详单采用Parquet格式存储,数据表使用时间+MSISDN号码做分区,使用Impala查询,利用不上分区的查询场景,则查询性能比较差。 2、在使用Impala过程中,遇到很多性能问题(比如catalog元数据膨胀导致元数据同步慢等),并发查询性能差等。 3、Impala属于MPP架构,只能做到百节点级,一般并发查询个数达到20左右时,整个系统的吞吐已经达到满负荷状态,在扩容节点也提升不了吞吐量。 4、资源不能通过YARN统一资源管理调度,所以Hadoop集群无法实现Impala、Spark、Hive等组件的动态资源共享。给第三方开放详单查询能力也无法做到资源隔离。 解决方案 针对上面的一系列问题,移动局点客户要求我们给出相应的解决方案,我们大数据团队针对上面的问题进行分析,并且做技术选型,在这个过程中,我们以这个移动局点的几个典型业务场景作为输入,分别对Spark+CarbonData、Impala2.6、HAWQ、Gre...
-
下一篇
首次公开!单日600PB的计算力--阿里巴巴EB级大数据平台的进击
作者:阿里巴巴计算平台 高级技术专家 迎辉 MaxCompute作为阿里巴巴的主力计算平台,在2018年的双11中,再次不负众望,经受住了双11期间海量数据和高并发量的考验。为集团的各条业务线提供了强劲的计算力,不愧是为阿里巴巴历年双11输送超级计算力的核武器。 本文为大家介绍,MaxCompute基于多集群部署的几万台服务器,如何为集团急剧增长的业务提供护航和保障。 挑战 每年的双11之前,也是MaxCompute各种乾坤大挪移落定的时候,因为双11就是各种大折腾项目的自然deadline。在今年双11之前,一路向北迁移和在离线混部项目,将杭州集群除蚂蚁外整体迁移到张北,涉及了绝大部分的业务project、数据存储和计算任务,为今年双十一大数据计算服务的保障带来了挑战。 体量 现在MaxCompute包括在离线混部集群在内有几万台服务器,
相关文章
文章评论
共有0条评论来说两句吧...

微信收款码
支付宝收款码