【视频】云原生数据仓库 AnalyticDB PG 解析与实践（下）｜学习笔记（二）

开发者学堂课程【数据仓库 ACP 认证课程：【视频】云原生数据仓库 AnalyticDB PG 解析与实践（下）】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/928/detail/14627

【视频】云原生数据仓库 AnalyticDB PG 解析与实践（下）

五、云监控预警

目前云监控的报警,则分为阈值报警和事件报警。

云监控的两种报警,都需要您手动配置才会生效;

这是类似订阅机制,只有创建了报警,才会订阅相关的事件;

云监控预警是平台的主动预警方式，原来APP有两种资源模式，它有两种资源模式，一个是存储预留版本，一个是存储弹性版本，现在主流的都是弹性版本。

以资源弹性版本为例，通过云监控控制台，弹出对话框，打开对话框之后会出现小铃铛，打开这个小铃铛就进入了监控预警配置的界面。配置之后就相当于订阅了某种事件/某种消息，CPU占用率超过90%会发一个告警到微信或者邮箱短信通知给云用户，具体页面如下图

打开之后要选择要关联的资源，要是从实例界面进入以后它会直接的关联到当前ADB实例。如果通过云监控预警的总控接口进来以后，需要选择具体的实例，包括先选地域，再选实例。

在设置报警规则下面，需要设置规则的名称，设置一些对规则的描述，例如，把规则描述为【资源弹性】节点CPU使用率一分钟周期（可以选择）持续一个周期平均值＞＝等于阀值，达到持续的周期就是说，达到事件以后，需要满足什么样的条件。比如说默认平均值如果填90%，就是在一分钟周期内，CPU使用率大于90%的情况会触发报警规则。

可以配置沉默周期和生效的时间，其他产品也可以参考。配置好以后，就会再从的页面里显示有哪些规则，在填写完报警规则之后，会产生一个通知信息，通过手机短信也可以收到告警通知，配置好以后可以在历史界面里面显示规则。有两条规则，第一是如果内存使用率超过5%会产生报警，第二是CPU使用时间超过10%产生报警。报警信息如下面例子所示（短信）：

【阿里云】尊敬的sqrea** *16:23您的分析型数据库PostgreSQL版实例

hostname=ap-southeast-1.i-

t4n9nv7e19wvnb4gz4d5,

instance_ component=master，

instanceld=gp-t4n59074603xv0p6i

【资源弹性】节点CPU使用率平均值超过10百分比，规则: cpu使用率超过10%，请登录云监控关注。

 

六、SQL 性能调优: Cascade 框架 SQL 优化器

新一代cascade框架的SQL优化器,面向全并行执行架构,代价优化CBO和规则优化RBO相结合,实现复杂SQL免调优。

SQL语言是一种相对于用户比较友好的语言，但是它可以写的很复杂.SQL语言能否进行高效的执行首先考验的是数据库优化器的能力，要看优化器能否在很短的时间内找到一个合适的执行路径，本质上是一个np问题，所以基于传统的代价优化，肯定不能找到最优路径，而是只能找到接近于最优路径的路径，传统的优化器是一个自定义向上的优化器。

●Top-Down路径搜索框架,搜索和路径选择更全面精准,避免出现局部查询路径最优解

●子查询自动改写为分布式JOIN ,实现并行计算,规避手工改写调优

●SQL优化阶段定义动态分区裁剪,即支持确定性过滤条件,也支持参数化的过滤条件,减少I/O

再好的对优化器也需要人工进行改写和干预，所以以上都是在一定程度内减少SQL优化的工作。

 

七、SQL 性能调优：向量化计算引擎

新一代计算引擎Odyssey ,消除火山模型碎片化内存分配

采用LLVM进行动态代码生成( CodeGen) , 提升表达式计算性能

利用CPU的SIMD技术,指令级并行,进一步提升性能

 

八、SQL 性能调优：SQL 诊断

pg_ stat_activity是一个非常有用的视图,通过其找到有用的 SQL。试想如下场景，在一个正常生产活动中突然发现，原来能够处理的任务数下降了，那么就需要定位到底是什么原因导致现在的处理水平比正常的处理水平有所降低，那么就先通过pg_stat_activity这个视图可以分析排查当前运行的SQL任务以及一些异常问题。

pg_stat_ activity 每行展示的是一个"process" 的相关信息 ,这里的"process" 可以理解为一个用户连接。

通过pg_ stat. activity视图查看当前耗时较长的SQL

通过runtime对其进行一定的过滤，过滤出耗时较长的SQL，SQL对应的query是具体执行的语句，对于执行较长的语句会进行截断。

重点是提取语句的特征，提取特征之后，还需要联系业务方，去通过后台日志找到更加完整的SQL，去查看具体的原因。

 

查看耗时较长的查询

select current_ timestamp - query_ start as runtime, datname, usename, query from pg. stat_ activity where state != 'idle'order by 1 desc;

九、SQL 性能调优：执行计划两种收集模式

SQL性能调优的最普遍的方法，就是要分析耗时的原因，就是要看执行计划是否正确，主要是通过explain和explain analyze两种方式。二者区别如下

Ø Explain

显示执行计划,不真正执行语句,在计划中显示优化器估算信息

Ø explain analyze

显示执行计划,并且真正执行语句,在计划中显示真实执行信息和估算信息

Ø 执行计划中常用的算子

l 扫描算子Scan

Seq Scan,Index Scan,Bitmap IndexScan + BitmapHeap Scan

l 关联算子Join

Hash Join,Nested LoopJoin, MergeJoin

l 聚合算子Aggregate

Hash Aggregate,Group Aggregate

l 数据重分布算子Motion（对数据进行重分布）

RedistributeMotion,BroadcastMotion, Gather Motion

l 其他算子

Hash, Sort,Limit, Append,etc.

 

十、SQL 性能调优：执行计划

 

 

十一、SQL 性能调优：可视化执行计划

可视化执行计划可以更加完整的展示出执行计划数，执行计划数如下图所示。包括每个算子的名称，执行的时间，看起来非常清晰，通过链接http://tatiyants.com/pev/#/plans/new传进去以后生成可视化的执行计划。

explain (format json, analyze true) select count(*) from test, testr where test.num1 =testr.num2;

 

十二、SQL 性能调优：如何发现问题

1.自上而下，梳理痛点

自上而下梳理计划，确定时间开销大的算子

2.查看代价，对比行数

查看比较代价估算的异常，对比估算行数和实际执行行数差异大的情况，比如估算的是1行，但是实际执行的时候是1000万，这就导致算子选择的不准确，使得出现偏差。

3.耗时算子，尽量避免(在查看执行计划的时候，需要对比较耗时的算子要敏感)

AP场景很少需要NestLoop、Sort+GroupByAgg

4.具体算子，是否合理

Motion :是否有不必要的Motion(motion算子通过网络进行传输肯定不如从走内存或者本地磁盘来读取更合适一些)

Join:内外表顺序

有没有在执行过程中出现下盘或者落盘情况，下盘就是有些可以在内存里面进行的任务，有时候因为代价估算的问题，它把排序内容放到了磁盘或者禁用磁盘上来扩充内存。

由于磁盘的性能远远不如内存，出现下盘之后，整体的执行性能也不会高，当然有的时候数据量较大，下盘也是不可避免的，重点还是要关注下盘是否合理，如果不合理就要作适当调整，这就是发现问题的步骤和手段。

Scan :是否可以使用索引

5.内存信息，调整参数

查看下盘情况，分析后适当调整statement_mem参数