SQL请求行为识别新功能，帮助解决异常SQL检测之大海捞针问题

简介：对于异常SQL中存在的业务属性的类似性以及错综复杂的影响与被影响的关系，理清楚问题SQL与各类资源的异常现象的传播关系是具备挑战的。DAS团队仍然在如何找到异常SQL这个课题上继续进行了研究和探索，在探索的过程当中咱们提供了一个新的分析功能SQL请求行为识别帮助用户更好的定位SQL问题。

业务背景:

DAS(Database autonomy service)为上百万数据库实例的稳定运行保驾护航，其中精准定位数据库运行过程当中的异常SQL是DAS最基本的功能。数据库90%以上的问题都来源于数据库的异常请求，不管是双十一的集团海量交易请求行为，仍是用户业务变化的请求行为，每时每刻都影响着数据库的性能。自动驾驶汽车经过感知路况图像变化的行为来掌握车的方向，而自动驾驶数据库经过感知和识别用户请求行为来不断修复优化数据库的各类问题，为云数据库保驾护航。如何从海量数据库中的海量请求定位出不一样数据库引擎不一样场景的问题是多年以来困扰DBA的难题。在推荐领域，经过分析用户的行为习惯代替了机械式网页展现精准推荐给用户指望的文字/视频/产品，提高用户体验和产品转化率，一样下一代数据库自动驾驶平台也须要分析用户请求行为，用户开发业务行为，推荐出相应优化修复扩容等操做，提高自动驾驶数据库的效率，让数据库更快更稳更安全。因此从用户请求行为和业务行为出发，在海量数据库实例的海量请求中进行数据挖掘是一个很是值得深刻研究的课题，同时也是数据库自动驾驶平台很是依赖的底层技术能力, 向上支撑DAS数据库自治服务各个场景的自治能力。

DAS这这些年提供了多个对SQL数据进行分析的L2功能包括：专业版SQL洞察，全量SQL，慢日志， 一键诊断， 锁分析，会话等。每个功能沉淀了DBA在不一样角度分析不一样问题的方法，不一样实例，不一样业务诊断问题的方法略有不一样。对于并非很熟悉DB运维的用户来讲，DAS在提供一个统一高效简单的方式去帮助用户去定位问题。咱们结合SQL变慢的多指标特征，提出一种基于特征类似度匹配的方法 VLDB 2020 沉淀到自治中心功能当中, 但对于异常SQL中存在的业务属性的类似性以及错综复杂的影响与被影响的关系，理清楚问题SQL与各类资源的异常现象的传播关系是具备挑战的问题，DAS团队仍然在如何找到异常SQL这个课题上继续进行了研究和探索，在探索的过程当中咱们提供了一个新的分析功能SQL请求行为识别帮助用户更好的定位SQL问题。

问题描述:

如下图为例，实例CPU出现尖刺突增的现象，数据库有cpu打满潜在风险，当用户的请求量较少或者请求的SQL模式较少的时候，经过指标的排序筛选是很容易找到问题SQL的，但当用户的全量SQL模板超过上万甚至上亿条，用户经过当前DAS页面没法快速定位异常SQL，咱们须要经过更多数据提供更高效的方式，来定位异常请求。

当用户使用DAS专业版SQL洞察的功能的时候，即便咱们将全量SQL流水，压缩聚合成模板，模板的数量也是惊人的，咱们能够看到大量特征趋势相近的模板。因此若是咱们根据SQL的请求行为将模板进一步压缩，这样用户能够更好的定位异常SQL的问题

目前DAS产品功能和业界AWS Azure等其余产品都有初步的异常SQL定位能力，经过对采集的SQL数据在各个维度的排序，让用户本身定位数据库问题，这种方式对于80%以上简单的数据库问题是有效的，可是在复杂业务场景和DBA都很难定位的数据库问题效果是不好的。以阿里云内部管控的元数据库集群实例为例，今年平均每个月发生10屡次的CPU打满问题，整年发生数次性能相关的故障问题，可是每次的问题都不一样，有时候DBA只能找到现象，难以快速定位问题根因。因此经过对用户请求行为的分析，会更好的迭代DAS数据库自治服务产品，解决咱们复杂场景的数据库性能问题，提升整个数据库各个引擎的稳定性，易用性，效率。

业界产品:

AWS: RDS： Performance Insight

和目前DAS产品功能同样，采集的数据维度相似，经过Top N ranking的方式进行异常SQL定位，没有SQL请求行为分析功能

Azure: Query Performance Insight

经过取Top N的方式对SQL请求进行定位，能够定位到60%的明显问题，可是没法定位SQL请求复杂业务的数据库问题，没有SQL请求行为分析功能

腾讯云：DB Brain功能，和目前DAS现有功能相似，没有SQL请求行为分析功能

华为云：Database Admin Service，和目前DAS现有功能相似，没有SQL请求行为分析功能

挑战&难点

Challenges:

规模化挑战:

The sea of performance issues in the sea of queries from the sea of the databases

用户的业务请求丰富，如何从海量数据库实例中的海量请求中定位多种数据库引擎的性能问题。

监控诊断挑战：

7*24 real time anomaly detection => 7*24 root cause analysis in near real time

针对潜在的SQL请求致使的数据库性能问题，根因定位须要作到近实时问题定位。

繁杂的数据库异常现象：

异常指标一般与多条SQL请求有关，没法用单条SQL来解释异常缘由且多个业务的SQL请求之间相互影响，关联的问题包括全表扫描/索引/锁问题/缓存击穿/内核问题等。多个问题在指标现象存在类似性和不一样Motivations:

人工根因定位：

帮助DBA或用户解决性能问题，工单问题

帮助后端开发人员合理安排请求查询的流程，尽可能让资源密集型请求从业务角度打散

帮助DBA找到不一样请求之间在业务层面直接和间接的关系。

赋能自治服务：

更加精细化的限流: Limit anomalous SQL more meticulous

更加准确对workload预测: Forecast workload more accurate

更好的划分workload: Workload can be well-partitioned

更好的预估自治操做的资源收益: Estimate the SQL Resource Cost for autonomous actions

在第一时间解决潜在的性能问题：Crack the potential performance issue at the first place

DAS解决方案:

启发思路：

在不少后端应用开发的过程当中，后端架构设计每每会保证接口的幂等性，例如项目中为了解决timeout问题，一般会引入重试机制，有时候会请求重复数据，消费消息有时候读重复数据之类的幂等性问题。例如屡次insert或update可能会形成数据错误。

为了解决这些幂等性的方法，后端一般会使用这些方式例如 先select再insert，加悲观锁/乐观锁/分布式锁，或者根据状态机来管理有状态的业务。

支付场景状态机示例：

......

update \`bill\` set status=1 where id=520 and status=0;

下单行为 SQL A

update \`bill\` set status=2 where id=520 and status=1;

支付行为 SQL B

update \`bill\` set status=3 where id=520 and status=2;

取消订单行为 SQL C

.....

因此同一个业务流程会伴随这多个SQL请求，串行或并行，这就意味着这些SQL在执行趋势上存在这关联性，这种关联性和业务有关。当咱们发现业务异常的时候，同时伴随这指标异常，因此当咱们定位异常SQL的时候，同一业务下的SQL都会有异常现象，因此经过这些SQL的趋势特征咱们能够将海量SQL数据进行经过算法进行聚类。因此咱们想到经过分析SQL的同源性，站在业务视角来定位异常SQL，能够更有效率的定位异常SQL

流程框架：

感知过程：

在诊断的过程当中，DAS后端首先从统一数据层(DataSet Layer)请求，性能数据(Perf Data)和SQL请求数据（SQL Query Data），性能数据经过多指标异常检测(MTS Anomaly Detection)/特征提取(Feature Extraction)

异常请求定位过程：

示例：

模板集合X:{sql\_a , sql\_b, sql\_c} ==> 影响了 mysql.cpu\_usage 指标变化 

         ==>sql 集合的影响程度 (推算cpu\_time占比)

模板集合Y: {sql\_i , sql\_j, sql\_k } ==> 影响了 mysql.active\_session 指标变化 

         ==> sql 集合的影响程度 (推算session占比)

感知层感知到时序指标异常后，经过全量SQL通过模板化处理后的数据，运用Graph Based的聚类方法，将海量的SQL按照请求行为的特征进行划分，最后根据聚合后请求行为的贡献度评分进行排序(Query Behavior Ranking)，检测异常请求及其做用于性能指标的现象.

根因分析过程：

示例：

烂SQL模板 sql\_i --> 形成了锁等待现象---> 影响了mysql.rows\_lock\_wait\_time指标 

               --> 形成模板Y集合的SQL被阻塞 -->  形成session的突增 

               --> 被阻塞的Y集合中X集合中的CPU密集型SQL被阻塞 --> 形成了CPU突增 

经过SQL解释了指标异常现象以后，还有不少故障问题咱们没法精肯定位，例如主备延迟,锁问题,OOM,内核问题等，这些问题可能致使了执行SQL的耗时增长，反过来，SQL也有可能产生这些问题的现象。

(Anomaly Propagation Analysis )帮助咱们对这些现象之间，进行传播关系的分析。这里的分析咱们经过时间前后关系结合咱们历史案例数据综合进行比对, 最后将得出的异常传播链和整个DAS分析过程和建议并添加到后端的case库并更细case model。Case Model会根据反馈不断叠加调整匹配参数，给出更精准的建议。

基于请求行为识别的异常SQL定位案例:

定位会话(active\_session)突增尖刺问题：

下图数据库实例活跃会话有异常的尖刺，这种尖刺持续时间过长，对一些敏感业务会有形成潜在的问题，咱们想要定位尖刺的缘由，首先DAS的实时异常检测能够检测出多指标的异常时间段。对于CPU，活跃会话异常的检测会透传出黄色异常事件的提示。

活跃会话一般和总执行耗时强相关，经过SQL请求行为分析选择对应指标，并点击分析

找到和会话类似的指标，并点击查看，按照总耗时排序，能够找到对会话异常"贡献"最大的异常SQL，

点击对应SQL\_ID 查看详情，经过趋势行为ranking的结果，能够清楚的看到这个SQL变慢了和历史趋势相比变慢了。经过执行趋势能够看到异常趋势和历史趋势彻底不一样，且与活跃会话异常的趋势相吻合

最终定位：这条SQL执行次数突增(从1000次执行超过8000屡次)，致使其余SQL执行耗时变慢，形成了活跃会话堆积产生了active\_session指标突增现象

CPU打满(cpu\_usage)突增问题：

下图数据库实例CPU被打满，

除了SQL设计CPU密集型计算诸如join，等比较昂贵的操做外，绝大部分状况，CPU和扫描行数成正相关，在SQL请求行为分析选择，cpu\_usage和总扫描行数,

咱们比较容易定位到和CPU关联的指标

最终定位：这条全表扫描的SQL，形成了CPU被打满从而致使了会话的堆积

将来计划

DAS会支持更多引擎的实时检测和异常定位，专业版结合用户的全量SQL帮助更多用户定位更多类型的数据库实例问题。不只让专业DBA更好的使用DAS管控数据库实例，也让数据库领域的初学者无门槛的管控数据库，真正保证数据库实例自感知，自优化，自修复。

**相关阅读：
**

数据库自治服务DAS发布年度新版本：1-5000，”数据库自动驾驶“进入规模化时代

深度技术揭秘 | 大促狂欢背后，如何有效评估并规划数据库计算资源？

重磅 | 数据库自治服务DAS论文入选全球顶会SIGMOD，领航“数据库自动驾驶”新时代

功能更新｜DAS推出全局Workload优化功能，实现SQL自动诊断

干货｜一文读懂阿里云数据库Autoscaling是如何工做的

本文内容由阿里云实名注册用户自发贡献，版权归原做者全部，阿里云开发者社区不拥有其著做权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。若是您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将马上删除涉嫌侵权内容。