HIVE优化浅谈
HIVE优化浅谈
作者:邓力,entobit技术总监,八年大数据从业经历,由一代HADOOP入坑,深耕云计算应用领域,由从事亚马逊EMR和阿里云EMR应用开发逐步转入大数据架构领域,对大数据生态及框架应用有深刻理解。
引言
随着商务/运营同学执行的HQL越来越多,整体HIVE执行效率变低,本文从HIVE切入,分析HQL面临的问题和待优化部分,结合其他大数据框架来解决实际问题。以下内容没有针对业务代码提供优化建议.
常见的HQL
select型
设置hive.fetch.task.conversion=none会以集群模式运行,无论是否有limit。在数据量小时建议使用hive.fetch.task.conversion=more,此时select配合limit以单机执行获取样本数据,执行更快
常见的select配合order by/group by等基本操作不在此赘述
注:
select查询可以通过split.maxsize和split.minsize控制并发MAPPER数量
insert型
分为两种
- insert into
- insert overwrite
配合分区可以达到重写分区或者在分区追加数据的目的。还可以配合动态分区模式插入对应分区
开启动态分区:
// 开启动态分区模式 set hive.exec.dynamic.partition=true; // 开启动态分区非严格模式(多分区时首分区支持动态分区必要条件,首分区为静态分区可以不设置) set hive.exec.dynamic.partition.mode=nonstrict; // 单节点上限 set hive.exec.max.dynamic.partitions.pernode=100; // 集群上限 set hive.exec.max.dynamic.partitions=1000;
开启之后可以利用SQL达到动态插入的目的:
// 根据分区day动态插入数据 insert into table default.test partition(day) select id,day from orginal
CTAS
全称CREATE TABLE AS SELECT语句,语法和MYSQL类似,可以指定存储/压缩包等
// 采用parquet存储已准备配合SparkSQL使用 create table default.parquet_test stored as parquet as select * from default.test // 同时可以指定压缩格式 create table default.parquet_test stored as parquet TBLPROPERTIES ( 'orc.compress'='SNAPPY') as select * from default.test // 指定OSS作为存储(推荐) create table default.parquet_test stored as parquet location 'oss:xxx:yyy/parquet/test'
JOIN优化
上面提到了常见的不同HQL类型,实际在执行的HQL中更可能变慢的时JOIN部分,以下会根据不同的场景来分析
大表x小表
这里可以利用mapjoin,SparkSQL中也有mapjoin或者使用广播变量能达到同样效果,此处描述HQL
// 开启mapjoin并设定map表大小 set hive.auto.convert.join.noconditionaltask = true; set hive.auto.convert.join.noconditionaltask.size = 10000000; // 大表 join 小表 select * from big_table join small_table on big_table.id=small_table.id
原理:将小表加载进入节点容器内存中,大表可以直接读取节点容器内存中的数据进行匹配过滤
大表x大表
小表可以放进内存,大表则不行。尽量避免大表x大表的执行需求。如果确认有此需求,可以参考以下方法
-
尝试将大右表自我join成为一张宽表
// 利用右表的唯一属性自我join select id, case when type='food' then 0 else 1 as type_tag,case when sale_type='city' then sales else null as sale_amount from group by id
-
尝试先将大表按照主键分桶后join
create table new_left as select * from left_table cluster by id create table new_right as select * from right_table cluster by id select * from new_left join new_right on new_left.id=new_right.id
-
根据数据大小量级合理增加reduce数量,reduce不宜设置过大
// hadoop1代 set mapred.reduce.tasks= 200; // hadoop2代 set mapreduce.job.reduces=200;
-
利用ORC bloomfilter, 大幅度提高join效率
注:parquet bloomfilter在开发中// 建立orc表 create table default.right_orc stored as orcfile TBLPROPERTIES ('orc.compress'='SNAPPY', 'orc.create.index'='true', 'orc.bloom.filter.columns'='id') as select * from right_table // 使用新表join select * from left_orc join right_orc on left_orc.id=righ_orc.id
-
调整内存限制
join时容易造成节点OOM,导致任务失败,可以尝试以下方法:- map阶段OOM,适当增加map阶段内存 set mapreduce.map.memory.mb=3096
- reduce阶段OOM,适当增加reduce阶段内存 set mapreduce.reduce.memory.mb=4096
注: 默认执行引擎为mr,如果是TEZ,参考tez优化部分
- 善用explain/analyze
使用explain和analyze分析HQL语句和表,试图从中找出实际数据中可以优化的部分,这里和数据强关联,需要根据实际数据考量 - 数据预处理。将部分join放入离线计算任务,减少业务join的时间
更多思考
- 文件压缩后仍然很大:可以使用GZIP压缩代替SNAPPY,但是性能比SNAPPY差很多
- HQL队列拥挤:可以参考队列抢占式资源调度策略,对小任务支持更好
- HIVE作为数据仓库/交互式查询的优秀手段之一,是否有更好的计算框架可以替代:EMR SparkSQL可以替代大部分HIVE应用场景,并且3.22版本relational cache带来了极强的性能优化。推荐使用
总结
HIVE本身确实是数据仓库和交互式查询的优秀框架,但随着数据的增多,join的复杂度和性能问题,需要花时间和精力解决性能优化的问题。除了基于HIVE本身优化,还可以接入计算性能更好的框架,SparkSQL relational cache对使用者透明,开发不需要关心底层优化逻辑,可以将更多精力放入业务设计开发中。后续将针对SparkSQL部分提供个人经验供参考。
欢迎对EMR及相关技术感兴趣的同学进钉钉群一起讨论 :)
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
列式存储系列(二): Vertica
作者:辛庸,阿里巴巴计算平台事业部 EMR 技术专家。Apache Hadoop,Apache Spark contributor。对 Hadoop、Spark、Hive、Druid 等大数据组件有深入研究。目前从事大数据云化相关工作,专注于计算引擎、存储结构、数据库事务等内容。 本文是列式存储系列的第二篇。在上一篇,我们介绍了C-Store,一个列式存储数据库。在本篇,我们讲述 C-Store 的继任者——Vertica。C-Store 是一个概念原型,在这个概念原型提出并发表后,Stonebraker 着手建立了一家公司研发商用的列式分析型数据库,公司名字就叫 Vertica。2011 年 Vertica 被惠普公司收购。2012 年,Vertica 公布了它的论文:《The Vertica Analytic Database:
- 下一篇
技术人的灵魂3问,阿里工程师如何解答? | 8月28号栖夜读
点击订阅云栖夜读日刊,专业的技术干货,不容错过! 阿里专家原创好文 1.技术人的灵魂3问,阿里工程师如何解答? 在业务团队做事的工程师摸爬滚打了一段时间后,一定会有所疑问。团队同学在最初的一段时间都提出这样的疑惑:如何在业务中发现有技术价值的问题?发现问题后如何思考和发起再到解决?最后的技术结果跟业务结果如何衔接?很多时候我们听别人说“思考是不够的/要多思考”,其实都是在说这几点。接下来,阿里高级前端技术专家氐宿谈一谈遇到这三个问题时,他是如何解决的?阅读更多》》 2.Timestream开发最佳实践 Timestream模型是针对时序场景设计的特有模型,可以让用户快速完成业务代码的开发,实现相关业务需求。但是,如果业务系统不仅想实现基础的相关业务功能,还要达到最佳的性能,并且兼顾到未来的扩展性的话,就不是一件特别容易的事情。本文会以共享汽车管理平台为例,介绍一系列的timestream最佳设计和使用,给业务设计和使用提供一些参考。关于共享汽车管理平台的场景,细节请参考:《基于Tablestore的共享汽车管理平台》。阅读更多》》 3.基于宜搭的《T恤尺码收集》应用搭建 宜搭:人人搭建...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- Mario游戏-低调大师作品
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Red5直播服务器,属于Java语言的直播服务器
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS8编译安装MySQL8.0.19
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS6,CentOS7官方镜像安装Oracle11G
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装