一个简单的HQL优化

简介:

线上做Job迁移:从GP迁移到Hadoop,发现有些Job原来跑了2-3分钟到Hadoop上跑到10分钟左右,这样的话会影响到迁移的效果;一个明显的Query如下:

Insertinto table_big partition(dt=today) select xxx from table_hour_incrementala,table_big b where a.id=b.id and b.dt=yesterday;

查看一下grace:

142236756.png


显然瓶颈集中在第二个MAP上,reduceshuffle time执行了207秒,计算了300s不到;这个table_big是个外部表,查看一下文件发现是一个250MB左右的gz文件,原因基础上清楚了,在该Job设置了一下mapred.reduce.tasks=8就可以解决了:

首先是降低每个reduce的计算时间,其次是today分区的文件增加进而增加MAP数,这个要明天才能看到效果了:P

142310482.png

可以看到每个reduce的计算时间已经降到30秒;同时,产生today分区的文件也是830MB的小文件,为接下来增加MAP做好准备


本文转自MIKE老毕 51CTO博客,原文链接:http://blog.51cto.com/boylook/1301072,如需转载请自行联系原作者


相关文章
|
7月前
|
SQL 关系型数据库 MySQL
探索Gorm - Golang流行的数据库ORM框架
探索Gorm - Golang流行的数据库ORM框架
|
7月前
|
SQL 缓存 关系型数据库
一次sql改写优化子查询的案例
在生产环境中,一个MySQL RDS实例遭遇了高CPU使用率问题,原因是执行了一条复杂的UPDATE SQL语句,该语句涉及一个无法缓存的子查询(UNCACHEABLE SUBQUERY),导致子查询需要针对每一行数据重复执行,极大地影响了性能。SQL语句的目标是更新一行数据,但执行时间长达30秒。优化方法是将子查询转换为内连接形式,优化后的语句执行时间降低到毫秒级别,显著减少了CPU消耗。通过示例数据和执行计划对比,展示了优化前后的时间差异和执行效率的提升。
255 2
|
SQL 存储 负载均衡
工作常用之Hive 调优【四】HQL 语法优化
列裁剪就是在查询时只读取需要的列,分区裁剪就是只读取需要的分区。当列很多或者数据量很大时,如果 select * 或者不指定分区,全列扫描和全表扫描效率都很低。
303 0
工作常用之Hive 调优【四】HQL 语法优化
|
SQL 存储 并行计算
SQL调优指南—SQL调优进阶—查询改写与下推
下推是查询改写的一项重要优化,利用PolarDB-X的拆分信息来优化执行计划,使得算子尽量下推以达到提前过滤数据、减少网络传输、并行计算等目的。
134 0
SQL调优指南—SQL调优进阶—查询改写与下推
|
Java 数据库连接
HQL数据查询(Hibernate推荐)
HQL数据查询(Hibernate推荐)
128 0
|
SQL XML 缓存
HQL的使用
HQL(Hibernate Query Language) 是面向对象的查询语言, 它和 SQL 查询语言有些相似. 在 Hibernate 提供的各种检索方式中, HQL 是使用最广的一种检索方式
346 0
|
存储 缓存 Java
Java 堆外内存、零拷贝、直接内存以及针对于NIO中的FileChannel的思考(上)
Java 堆外内存、零拷贝、直接内存以及针对于NIO中的FileChannel的思考(上)
Java 堆外内存、零拷贝、直接内存以及针对于NIO中的FileChannel的思考(上)
|
SQL 机器学习/深度学习 Oracle