SQL优化示例

友情链接

分布式计算框架系列文章(一)MR框架工作流程以及框架限制

分布式计算框架系列文章(二)数据倾斜现象诱因、原理、影响,以及星环对此的应对策略

分布式计算框架系列文章(三)星环科技计算引擎针对数据倾斜现象的保护机制

分布式计算框架系列文章(四)当出现数据倾斜时如何应对--倾斜key单独处理/MapJoin/星环SkewJoin的原理及使用方法

Task的数量是如何决定的

示例一

原sql

select ... from A join B on A.key = B.key
 where A.userid>10
 and B.userid<10 and A.dt='20120417'and B.dt='20120417';

优化后sql

select .... from (select .... from A where dt='201200417'and userid>10) a
join
(select .... from B where dt='201200417'and userid < 10) b
on a.key = b.key;

优化原因

尽量尽早地过滤数据,减少每个阶段的数据量,对于分区表要加分区,同时只选择需要使用到的字段

示例二

优化背景

如日志中,常会有信息丢失的问题,比如全网日志中的user_id,如果取其中的user_id和bmw_users关联,就会碰到数据倾斜的问题。

原sql

select * from log a join bmw_users b
on a.user_id = b.user_id

优化后sql

解决方法1

select * from log a join bmw_users b
on a.user_id is not null
and a.user_id = b.user_id
union all
select * from log a
where a.user_id is null

解决方法2

select * from log a
left outer join bmw_users b
on case when a.user_id is null then concat('dp_hive',rand())
else a.user_id end = b.user_id;

优化原因

2比1效率更好,不但io少了,而且作业数也少了。

1方法log读取两次,jobs是2。

2方法job数是1 。

这个优化适合无效id(比如-99,'',null等)产生的倾斜问题。把空值的key变成一个字符串加上随机数,就能把倾斜的数据分到不同的reduce上 ,解决数据倾斜问题。因为空值不参与关联,即使分到不同的reduce上,也不影响最终的结果。

附上hadoop通用关联的实现方法(关联通过二次排序实现的,关联的列为paritionkey,关联的列c1和表的tag组成排序的group key,根据parition key分配reduce。同一reduce内根据group key排序)

示例三

优化背景

比如推广效果表要和商品表关联,效果表中的auction id列既有商品id,也有数字id,和商品表关联得到商品的信息。

建议写法

select * from effect a
join (
select auction_id as auction_id from auctions
union all
select auction_string_id as auction_id from auctions
) b
on a.auction_id = b.auction_id

优化原因

这样写的好处,1个MR作业,商品表只读取一次,推广效果表只读取一次。把这个sql换成MR代码的话,map的时候,把a表的记录打上标签a,商品表记录每读取一条,打上标签b,变成两个<key ,value>对,<b,数字id>,<b,字符串id>。所以商品表的hdfs读只会是一次

示例四

优化背景

先join生成临时表,在union all还是写嵌套查询

原sql

select * from (
   select * from t1
   union all
   select * from t4
   union all
   select * from t2
   join t3
   on t2.id = t3.id
   )

优化后sql

insert overwrite table t5
select * from t2
 join t3
 on t2.id = t3.id;
select * from (t1 union all t4 union all t5) ;

优化原因

inceptor在union all优化上可以做得更智能(把子查询当做临时表),这样可以减少开发人员的负担。出现这个问题的原因应该是union all目前的优化只局限于非嵌套查询。如果写MR程序这一点也不是问题,就是multi inputs。

示例五

优化背景

使用map join解决数据倾斜的常景下小表关联大表的问题,但如果小表很大,怎么解决

原sql

select * from log a
left outer join members b
on a.memberid = b.memberid    members有600w+的记录

优化后sql

select /*+mapjoin(x)*/* from log a
 left outer join (
  select /*+mapjoin(c)*/ d.*
    from (
     select distinct memberid from log
      ) c
    join members d
   on c.memberid = d.memberid
    )x
 on a.memberid = b.memberid

优化原因

先根据log取所有的memberid,然后mapjoin 关联members取今天有日志的members的信息,然后在和log做mapjoin。

假如,log里memberid有上百万个,这就又回到原来map join问题。所幸,每日的会员uv不会太多,有交易的会员不会太多,有点击的会员不会太多,有佣金的会员不会太多等等。所以这个方法能解决很多场景下的数据倾斜问题。

其他优化建议

尽量原子化操作,尽量避免一个SQL包含复杂逻辑,可以使用中间表来完成复杂的逻辑;

join操作,小表要注意放在join的左边(目前TCL里面很多都小表放在join的右边)。否则会引起磁盘和内存的大量消耗;

相关推荐
时差95337 分钟前
MapReduce 的 Shuffle 过程
大数据·mapreduce
奶糖趣多多40 分钟前
Redis知识点
数据库·redis·缓存
kakwooi2 小时前
Hadoop---MapReduce(3)
大数据·hadoop·mapreduce
数新网络2 小时前
《深入浅出Apache Spark》系列②:Spark SQL原理精髓全解析
大数据·sql·spark
CoderIsArt2 小时前
Redis的三种模式:主从模式,哨兵与集群模式
数据库·redis·缓存
师太,答应老衲吧4 小时前
SQL实战训练之,力扣:2020. 无流量的帐户数(递归)
数据库·sql·leetcode
阡之尘埃5 小时前
Python数据分析案例61——信贷风控评分卡模型(A卡)(scorecardpy 全面解析)
人工智能·python·机器学习·数据分析·智能风控·信贷风控
Channing Lewis5 小时前
salesforce case可以新建一个roll up 字段,统计出这个case下的email数量吗
数据库·salesforce
前端青山6 小时前
Node.js-增强 API 安全性和性能优化
开发语言·前端·javascript·性能优化·前端框架·node.js
毕业设计制作和分享6 小时前
ssm《数据库系统原理》课程平台的设计与实现+vue
前端·数据库·vue.js·oracle·mybatis