MaxComputeSql性能调优

 转载自xiaorui
   
      部分用户(尤其对外输出)使用MaxCompute(原Odps)时,由于对产品的使用层面和执行层面了解程度不同,导致提交的任务执行时间过长、占用了较多集群资源;严重的会导致失败、不仅需要投入支持同学精力协助解决、也影响了用户正常业务。 合并整理部分性能提升方法方便支持用户查询和优化Sql,提高效率;部分需要原来手动调优的如mapjoin、ppd谓词下推注意分区位置等原有的调优设置在不断衍进的产品中都已实现了自动化调优、 不同阶段的产品调优参数和细节会有不一致、但是熟悉了调优思路和方法后可以做到举一反三、逐步深入。

一. 整体思路

      整体上,调优从底层到sql可以有多个层面的调优,随着产品的不断完善,部分调优已经实现了自动化。如果用户能熟悉常见的调优机制和执行原理,在开发执行sql、业务逻辑和相关参数设置调整来提高性能、可以做到事半功倍。
      1. 硬件及操作系统层面调优:包括磁盘I/O调优(多路复用等)、网络调优(缓冲区大小、连接数放大等)、内存调优(虚拟内存设置、内存控制等);
      2. 分布式计算平台及存储层面调优:存储格式设置、压缩格式设置、RPC调用设置、连接数控制设置、调度机制设置、block及分片设置、执行资源设置等;
      3. 业务逻辑层面及参数调整,除整体执行的调优外,对不同类型的操作进行参数级别的调优、针对聚合、连接、一读多写等修改为不同的sql或者设置不同的参数可以极大的提高性能;      
      4. Sql层面及应用层面的调优,重构sql写法、合并sql,大小表连接修改为mapjoin等,在odps2.0中已处理了自动mapjoin等、目前未升级用户及对外输出的用户仍需要修改sql来支持;
      不同层面调优及优缺点见下:
 

二. 场景及调优列举

1. 大小表关联修改为mapjoin,增加Mapjoin hint
方法及注意事项:

  • 所有指定的小表占用的内存总和不超过 512M
  • 多表Join时,最左边的两个表,不能同时是 Mapjoin 的表
  • 不同的关联方式(left/right/inner),对表的顺序有要求
    • left outer join 左表必须为大表
    • right outer join 右表必须为大表
    • inner join 左右表皆可为大表
  • full outer join 不能直接使用 mapjoin,修改为mapjoin + union all
  • 最新的发布版本上已经支持了automapjoin,可以根据join表的大小自动把小表转为mapjoin,对部分没有显示增加hint的sql和中间结果为小表的sql进行自动优化

2. 数据倾斜
数据倾斜表现:
任务进度长时间维持在99%,查看监控,只有少量 reduce 子任务未完成
单一 reduce 记录数与平均记录数差异多大,最长时长远大于平均时长
优化方法及注意事项:

  • 聚合倾斜,设置参数:set odps.sql.groupby.skewindata=true
  • 关联倾斜,设置参数:set odps.sql.skewinfo=tab1:(col1,col2)[(v1,v2),(v3,v4),...|(v1,v2),(v3,v4),...];set odps.sql.optimize.skewjoin=true
  • 关联倾斜,同时大小表,考虑修改为mapjoin
  • 具体问题具体分析:因为聚合key值null引起的数据倾斜,可以修改null为随机值,打撒数据分发到不同的instance执行

3. Map 端一读多写
场景及优化:
多次读取同一张物理表,执行不同操作,写入多张表;考虑与multiinsert 的联系和区别,是否合适做修改
建立临时表,实现临时表的并行化
注意事项:

  • 优点:大大节省了集群的计算资源和磁盘I/O资源
  • 缺点:写的次数非常多时,可能导致性能问题,影响任务整体执行效率

4 分区裁剪
场景:事实表很多分区,数据量大
优化:避免全表扫描,减少资源浪费;关注分区裁剪有无生效,见下注意事项:从表设计、使用上注意,尽量让分区裁剪生效
注意事项:

  • 过滤条件中的分区列上有UDF 则分区裁剪生效
  • 表关联时关联条件中包含分区列:
    • 出现在 on 条件中,分区裁剪生效
    • 出现在 where 条件中,主表分区裁剪生效,其余可能失败

5. SQL 合并
场景:
1. 多次读取相同的数据且源数据数据量大、性能差、费用高
2. 统一业务流程前后关联sql或统计多种指标、筛选不同数据的sql
优化方法及注意事项:通过修改sql,合并为1个sql执行,尽量减少对相同数据源的读取次数,达到一次扫描计算多个基础统计量,一次扫描,处理多个筛选条件;以下调整列举:

  • CASE … WHEN…:合并相同数据源的不同子查询的关联
  • 动态分区&多路插入等:将满足不同条件的会员统计信息插入到不同的表或表分区中去
  • 前后流程sql合并为1个sql执行

6 使用窗口函数优化SQL
窗口函数:
1. 可以进行灵活的分析处理工作
2. 使用 partition by 开窗,order by 排序
3. 可以用 rows 指定开窗范围
4. 丰富的开窗函数

优化及注意事项:合理使用窗口函数,可以减少Join次数,提高运行性能;不用窗口函数处理需要写复杂sql的功能,用开窗函数可以高效执行得到预期结果。

官方文档:https://help.aliyun.com/document_detail/27834.html

欢迎加入MaxCompute钉钉群讨论

时间: 2024-10-03 21:57:54

MaxComputeSql性能调优的相关文章

oracle数据库性能调优技术:深入理解单表执行计划

一.概述 这篇文章是数据库性能调优技术的第二篇.上一篇讲解的索引调优是数据库性能调优技术的基础.这篇讲解的深入理解单表执行计划,是数据库性能调优的有力工具. 查询语句可以有多种可选执行计划,如何选择效率最高的执行计划?达梦数据库.oracle数据库.sql server数据库都是采用基于成本的查询优化,对备选执行计划进行打分,选择大家最小的执行计划进行执行.这些内容,我会在后续的几篇文章中进行详细的描述.在此之前,我们首先需要掌握如何理解数据库执行计划.这篇文章讲解只涉及单表操作的执行计划. 达

Liferay前端性能调优(1) 测评工具YSlow

最近我们团队要问Liferay做前端页面调优,当然了,测评工具是最重要的,为了看具体的页面加载时间等 ,我们首选当然是Chrome浏览器的诊断工具,但是总感觉不专业,基于我已有的经验,我还是推荐了YSlow,它 会对于页面的各项指标进行打分,然后最终获得总分然后评级,一般级别有A,B,C,D,E,F6个级别. 如何安 装和测试YSlow: (1) 从Firefox的Add-on上下载 "YSlow" (2)重启Firefox检查是否YSlow 已经被正确的安装 (3)到我们要测试的页面

数据库性能调优技术

一.概述 随着数据库在各个领域的使用不断增长,越来越多的应用提出了高性能的要求.数据库性能调优是知识密集型的学科,需要综合考虑各种复杂的因素:数据库缓冲区的大小.索引的创建.语句改写等等.总之,数据库性能调优的目的在于使系统运行得更快. 调优需要有广泛的知识,这使得它既简单又复杂. 说调优简单,是因为调优者不必纠缠于复杂的公式和规则.许多学术界和业界的研究者都在尝试将调优和查询处理建立在数学基础之上. 称调优复杂,是因为如果要完全理解常识所依赖的原理,还需要对应用.数据库管理系统.操作系统以及硬

可预见的Oracle应用程序的性能调优

这篇技巧性文章是由"国际Oracle用户组"(IOUG)提供的,它是一个由用户组成的组织,这个组织通过提供高质量的信息.培训.网络和支持,来提高Oracle数据库专家和数据库开发者的水平.这篇文章摘自由David Welch所写的论文<可预见的Oracle应用程序性能调优>.点击这里成为"国际Oracle用户组"的一员,从而获得成千上万的由Oracle用户写的技巧性文章和科技文献. 引言 我们见到过很多带有巨大性能问题的Oracle应用程序和电子商务套件

oracle数据库性能调优技术:索引调优

一.概述 随着数据库在各个领域的使用不断增长,越来越多的应用提出了高性能的要求.数据库性能调优是知识密集型的学科,需要综合考虑各种复杂的因素:数据库缓冲区的大小.索引的创建.语句改写等等.总之,数据库性能调优的目的在于使系统运行得更快. 调优需要有广泛的知识,这使得它既简单又复杂. 说调优简单,是因为调优者不必纠缠于复杂的公式和规则.许多学术界和业界的研究者都在尝试将调优和查询处理建立在数学基础之上. 称调优复杂,是因为如果要完全理解常识所依赖的原理,还需要对应用.数据库管理系统.操作系统以及硬

oracle数据库性能调优技术:深入理解嵌套循环执行计划

一.概述 这篇文章是数据库性能调优技术的第三篇.上一篇文章讲解了深入了解单表执行计划,单表执行计划是理解多表执行计划的基础. 两张表的连接有三种执行方式:1)嵌套循环连接:2)散列连接:3)归并连接.两张表连接时选择这三种中的哪一种呢?这取决于索引.以及连接的代价.在该系列的第三篇(本文)文章中讲解嵌套循环连接,第四篇文章中讲解散列连接,第五篇文章中讲解归并连接.在第六篇以后会分析IN子查询以及EXISTS子查询. 达梦数据库.oracle数据库.sql server数据库在数据库执行计划方面并

oracle数据库性能调优技术:深入理解散列连接执行计划

一.概述 这篇文章是数据库性能调优技术系列的第四篇.上一篇文章讲解了深入理解嵌套循环连接执行计划. 上一篇文章中提到两张表的连接有三种执行方式:1)嵌套循环连接:2)散列连接:3)归并连接.散列连接是很重要的连接方式,包含比较多的内容,这篇文章中讲解为什么需要散列连接?如何理解散列连接? 和前三篇文章一样,本文讲解的是些比较抽象的内容,不拘泥于具体的数据.所以本文中使用的代价评估模型也是抽象的,假设了数据库缓冲区大小只有一个页,新页的读取必然导致旧页的释放.读完本文之后应该能够读懂达梦数据库.o

Java EE应用程序在Glassfish上的性能调优案例分析

Java EE应用的性能问题对严肃的项目和产品来说是一个非常重要的问题.特别是企业级的应用,并发用户多,数据传输量大,业务逻辑复杂,占用系统资源多,因此性能问题在企业级应用变得至关重要,它和系统的稳定性有着直接的联系.更加重要的是,性能好的应用在完成相同任务的条件下,能够占用更少的资源,获得更好的用户体验,换句话说,就是能够节省费用和消耗,获得更高的利润. 要获得更好的性能,就需要对原来的系统进行性能调优.对运行在Glassfish上的JavaEE应用,调优是一件相对复杂的事情.在调优以前必须要

Java程序性能调优的基本知识和JDK调优

一 基本知识 1.1 性能是什么 在性能调优之前,我们首先来了解一下性能是什么?关于性能,我想每个学习过Java的人都能列出几点,甚至可以夸夸其谈.在<Java TM Platform Performance>一书中,定义了如下五个方面来作为评判性能的标准: 1) 运算的性能--哪一个算法的执行性能最好? 2) 内存的分配--程序运行时需要耗费多少内存? 3) 启动的时间--程序启动需要多长时间?这在Web项目中的影响不大,但要注意部分程序需要部署或运行在客户端时的情形(比如applet程序)