开发者学堂课程【数据仓库 ACP 认证课程：【视频】云原生数据仓库 AnalyticDB PG 解析与实践（下）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/928/detail/14627
【视频】云原生数据仓库 AnalyticDB PG 解析与实践（下）
内容介绍：
一、数据同步: ADBPG DTS 同步链路
二、数据同步监控—用户侧
三、数据同步：链路典型的问题排查
四、控制台监控
五、云监控预警
六、SQL 性能调优: Cascade 框架 SQL 优化器
七、SQL 性能调优：向量化计算引擎
八、SQL 性能调优：SQL 诊断
九、SQL 性能调优：执行计划两种收集模式
十、SQL 性能调优：执行计划
十一、SQL 性能调优：可视化执行计划
十二、SQL 性能调优：如何发现问题
十三、SQL 性能调优：通过索引提升查询性能
十四、SQL 性能调优：消除 Redistribute Motion
十五、SQL 性能调优：避免下盘
十六、SQL 性能调优：锁的检测及处理
十七、SQL 性能调优：空间回收
十八、SQL 性能调优;避免数据倾斜
十九、SQL 性能调优：数据倾斜-用户控制台排查
二十、SQL 性能调优：数据倾斜-SQL 排查
二十一、SQL 性能调优：数据倾斜的原因和解决
二十二、演示1：通过 DTS 做数据同步
二十三、演示2：增加监控报警规则
二十四、演示3：排查解决数据倾斜
二十五、真题讲解
本次介绍的是核心功能解析与实践的后半部分的几个功能，主要包括第一部分是数据同步，第二部分是监控报警使用和监控巡检，第三部分是SQL的调优。第四部分会对上面的功能进行演示，第五部分会把一些相关的真题进行讲解，最后可以自由提问。
一、数据同步: ADBPG DTS 同步链路
ADBPG数据同步主要使用DTS，DTS是阿里云的数据同步的服务，同步的数据源来自于上游的数据库系统，一般是RDS或mysql RDSPG这种关系型数据库，一般ADBPG作为数据仓库，它是作为目的库来进行同步的。
DTS完成的主要是订阅和捕捉源数据库全量和增量的数据，并且能够转换为目的库ADBPG所能使用的语法。然后把这些数据插入到目的库里，当然为了优化性能它在内部进行自动攒批，会调用一些copy或者insert命令进行批量写入。
ADB PG使用同步链路的目标场景需要重点关注一下:数据在线迁移（源库和目的库都是在线的）、实时同步（比如说源库的数据有业务系统在进行数据的变更，它可以基本无延时的情况下同步到目的库（ADBPG库）），还有一个场景就是异地灾备(读写分离、双活)，主要是把两个库之间进行一个串联。此处重点关注ADBPG里面需要注意的一些方面。
l 每个表列数最多1600列
l 每个表行数最多2^48行
l 部分支持修改字段类型
如int- > bigint
如bigint- > decimal
l 非法值（ADBPG不能识别的值，会导致链路报错）不支持写入(如2020-05-00 00:00:00、 100:00:00等)
l 不支持的类型同步数据不可使用(如GEOMETRY、POINT、LINESTRING、 POLYGON等类型)
l 列/表/数据库名称最长63个字符
l 不支持unsigned类型
其他详细参考ADBPG内核限制( https://help.aliyun.com/document detail/157891.html )
DTS使用限制( https://help.aliyun.com/document._detail/149450.html )
简单介绍一下DTS内部原理，它是在内部进行自动攒被，对于存在大量Update delete场景，由于无法进行自动攒被，内部转化成copy命令进行入库会变成insert。
这样会影响性能，尤其是在包括热点行更新的情况下，性能会大幅度下降，所以这会在使用的时候需要特别注意，尽量让数据能够批量进入。
二、数据同步监控—用户侧
介绍一下如何对数据链路进行监控。在DTS侧有专门的控制台进行监测，这里重点是在ADBPG一侧控制台界面的监控报警菜单里面，这个界面可以看到，实例运行状态、性能负载，包括协调节点的连接数，存储的总的水位。
还有计算节点的个数，还包括存储空间，重点关注计算节点的连接数和协调节点的连接数。
协调节点连接数之前是有比较大规模的一个入库，导致连接数有急剧的上升，图像上能看出明显的波峰，通过这个界面可以很好的对DTS链路的情况进行监控。尤其还要关注CPU的使用率和吞吐率，一般来说如果是单纯利用DTS进行数据同步的场景，那么master的连接数包括CPU的数量都是相对比较恒定的，它和在线业务是不太一样的，一旦有链路建立成功之后，它的变化是非常少的。
但如果突然连接数或者CPU的利用率发生了比较大的波动，那么就需要关注这里面出现的状况，尤其是CPU的利用率大规模降低的时候，需要检查一下数据链路是否工作正常。
三、数据同步：链路典型的问题排查
1.热点行更新
现象:监测到CPU利用率有了大幅度的下降，出现了明显的波谷，这个时候上流没有达到限流,入库RT时间不高,节点负载也不高,但是速度就是不提不上来的现象。
这个时候就要对其进行系统性的排查，先检查master到DTS的链路有没有明显变化，从业务的上游系统监控来看，如果负载没有明显变化，那么就要怀疑是否存在热点行的更新，需要做进一步的排查。通过一系列视图排查发现是否出现有针对热点的锁和锁的等待这种情况。
如果无法通过视图直接观察，也可能是冲突情况不明显，这就需要询问源库的客户，是不是有热点行更新的现象，也可以找后台的值班去观察一下后台数据库的日志，包括一些审计的日志，它有没有出现频繁的update/delete现象。
如果一旦确定是热点行引起的，从DTS的话它是无法避免的，也无法彻底的从DTS工具层进行解决，如果确定那就需要去关注整体性能，并且建议客户把热点行更新，把这个场景从同步对象中删除，或者集中到某一个时间点进行集中化处理，这是针对链路典型问题的排查方法。
2.排查方式
执行任务诊断,非常严重的热点行更新是会被诊断到的
咨询客户源库是否有热点行更新的情况
此问题排查较复杂,可以找DTS值班同学协助排查
3.优化方式
目前DTS没有很好的处理方式，一旦确认源库有热点行更新情况,并且关注整体性能，建议客户把热点行更新的表从同步对象中去掉。
四、控制台监控
控制台监控可以从数据库Master（协调节点）和计算节点两个方面,对用户数据库实例的CPU 、内存、磁盘IO和空间,连接数实现监控。具体如下:
●控制台监控提供最近7天的监控数据。
●监控汇总提供master的监控信息，包括CPU和内存利用率、总连接数、I0吞吐和磁盘空间监控
●计算节点监控提供计算节点的监控信息,包括CPU和内存利用率,读写IOPS ,磁盘空间
控制台可以看到每一个节点的运行状况，对节点设置标签可以方便用户对节点进行过滤和监控，如果master节点和CPU利用率比较高，就要排查具体升高的原因，不排除是节点故障原因导致的。
另外需要关注的是从监控控制台关注的是一个存储的水位，存储的水位会随着业务的增加而缓慢增加，如果存储水位升到一定的比例，按现在来说就是90%以上的时候，整个集群会进入到一个只读模式，这样就会影响写入业务，进入只读模式是为了保护数据库磁盘不会达满。当达到90%的时候，就需要进行处理，可以删除一些历史数据，或者是提前联系厂商对集群进行扩容，可以考虑这两个方法。
