当数据库遇上"自动驾驶"，阿里云 DAS 在自治诊断的突破

p_wdn

发布于 2022-5-20 18:24

浏览

0收藏

在智能化管控数据库的探索与实践过程当中，对数据库SQL的诊断/根因定位是我们一直以来需要面对的问题，从阿里巴巴集团到阿里云数据库，我们管控的实例数从几万规模扩大到几十万规模，DBA在面对数据库性能问题的时往往需要反复观察性能数据、日志数据、会话信息等，耗费较多的分析时间。大部分难以被发现的故障往往都是在海量慢SQL中的慢SQL，规则式的排序也许可以解决80%的问题，但是总会有边界条件导致故障无法被发现或者定位。

通过自动化的方式，我们可以通过一些规则将一些主要的现象分类，而我们经常遇到数据库现象和根因如何定位的问题，多个现象的情况总是会同时发生，规则会越来越复杂，越来越难以维护，所以通过规则很难解决这类场景的问题。所以通过集团和云上的故障case的沉淀和探索，我们尝试通过标准化的Pipeline来帮助我们未知问题的分类，实现从"Automation"to "Autonomous"的演进。

1
论文介绍
通过本文题目展开如下关键词介绍：

DiagnosingRoot Causes of Intermittent Slow Queries in Cloud Databases
1) Cloud Databases
2）Slow Queries
3）Diagnose
Cloud Databases
随着云数据库的快速发展，越来越多的企业将数据库迁移到云上，当数据库遇到了云，两者的特性会碰撞出何种火花。

当数据库遇上"自动驾驶"，阿里云 DAS 在自治诊断的突破-鸿蒙开发者社区

云的本质是各种资源高效的池化，计算机的本质就是计算+存储，而数据库的本质是数据在生产、处理、存储、消费的过程。当Cloud遇到Database，可以通过计算分析一体化来减少数据的移动，通过存储计算分离实现资源池化和解耦，形成了云原生+分布式为基础云数据库的发展生态。
Slow Queries
慢SQL与iSQ (Slow Queries & Intermittent SlowQueries)
传统慢SQL的方式往往会包含本身执行很慢的SQL，例如一个全表扫描查询，或者复杂的嵌套查询，或是没有加入索引的查询，这一类SQL往往可以通过我们自治场景SQL优化的方式来优化这类SQL，当然一些SQL本身也没有什么优化空间但执行时间大于1s，DBA在排查问题的时候往往会收到这些慢SQL的干扰。
当数据库遇上"自动驾驶"，阿里云 DAS 在自治诊断的突破-鸿蒙开发者社区
而在众多慢SQL当中，有一类SQL的执行时间比他历史执行时间要慢的多，这时候我们就应该引起注意了，同样的SQL为什么会执行变慢？我们发现很多故障的前兆都伴随这种SQL的出现，所以我们尝试给这类SQL下一个统一的定义。
当数据库遇上"自动驾驶"，阿里云 DAS 在自治诊断的突破-鸿蒙开发者社区
大部分iSQ都会影响用户体验，站在用户视角，他们本身执行的SQL突然变慢了，用户是可以感知到的。但是为什么不用其他指标取衡量呢？
Tcp-RT是一个不错的指标，他也可以反应查询的RT，但是SQL模板是细粒度的指标，而RT是全局维度的指标，很多场景下，当用户QPS升高的时候，Tcp-RT是下降的；某些场景下，整体RT没有变慢而某类SQL模板执行变慢了；所以全局维度指标往往是有局限性的，这就是为什么我们需要通过下钻进行根因定位。
当数据库遇上"自动驾驶"，阿里云 DAS 在自治诊断的突破-鸿蒙开发者社区
因此，对比慢SQL的定义，我们给出了iSQ的定义，并相信通过iSQ方式筛选出来的SQL更能体现出数据库运行的状态。通过SQL执行时间>1s,这个规则并不能帮助用户很好的筛选真正的问题SQL。这里我们通过概率的方式比较简单了定义了iSQ，当然我们未来也会根据SQL执行的更多特征，借助更多"数据驱动"的方式筛选出iSQ。
当数据库遇上"自动驾驶"，阿里云 DAS 在自治诊断的突破-鸿蒙开发者社区
Autonomous Diagnose
因此我们找到了一个根因定位的一个切入点，通过找到iSQ产生的根因来诊断数据库的性能问题。我们发现传统慢SQL的定义是通过阈值来定义的，这种规则驱动的方式并不能很好的帮助用户缩小全量SQL的范围，我们发现当数据库出现比较阻塞，密集型Workload，锁问题的时候，常常会出现iSQ(iSQ Intermittent Slow Queries，云数据库发生故障的时候，iSQ往往会提前出现，由于iSQ在其他时间段内执行时间并不慢，SQL的执行时间返回突然增长会导致业务的巨大变化,或者是由于业务变化受影响的）通过对于iSQ的根因定位，我们可以对数据库常用的故障进行跟细粒度的根因定位，只有将数据库的现象进行分类，我们后面的自修复/自优化Actions才可以减少action执行的冲突，合理的schedule我们的自治action，有效的给用户提供合理的自治建议并发出自治action，形成闭环。

2
挑战
Anomaly Diversity
在与DBA排查问题的过程中，我们发现排查问题，DBA往往要浏览超过20个指标，通过监控页面的对比，以及多指标的时序特征来确定大致的原因。例如尖刺/均值漂移是DBA最关注的特征，当然例如周期性和趋势线的特征也是DBA关注的。
当数据库遇上"自动驾驶"，阿里云 DAS 在自治诊断的突破-鸿蒙开发者社区
Labeling Overheads
DBA 在标注case的时候要花大量的时间，而标注往往是case by case，所以我们case的沉淀往往是通过故障文档或者工单，所以我们想到几个突破点：

是否可以通过模型来沉淀我们的case，通过大量的故障case来沉淀我们的算法模型，通过数据驱动的方式来划分我们的根因分类？
是否可以减少DBA在标注过程中的标注时间？
Interpretable Models
模型的可解释性是我们需要关注的，不同现象对应这不同根因，如何平衡根因定位准确率与根因定位可解释性也是我们需要关注的。
Large-scale
从集团到阿里云，我们管控的实例数从几万到超过50万实例，我们对离线计算链路与实时计算链路有巨大的挑战，这里我们把算法部署到我们DASMind算法服务，底层借助与函数计算的弹性扩展能力，最大程度的节省资源和保障我们流计算的稳定性。
Multiple Database Engines
我们目前已经支持MySQL/PolarDB 等关系型数据库，也要支持Redis/Mongo 等NoSQL数据库，我们希望通过一个具有鲁棒性的方式，来沉淀DBA的经验，而不是针对每一个数据库单独设计一套规则式的根因定位方法，尽可能的降低我们跨引擎标注case沉淀经验的成本。

3
方案
iSQUAD Overview

我们设计了iSQUAD这套框架并嵌入到DAS算法服务DASMind当中，方案分为离线和在线两条链路。
离线：通过对历史iSQ数据的探测，来触发异常抽取模块，抽取异常的特征，在通过过滤重复指标，将每个iSQ对应的pattern进行聚类，获得丰富的cluster，这些cluster通过BCM模块的特征子空间的抽取后，用来给DBA进行标注，标注的样本沉淀出pattern的模型，并提供给在线实时根因定位模块做分析，这样在线链路从之前了1-5-10(1分钟发现异常，5分钟定位分类，10分钟发出action)的方式得到了升级，我们把异常发现和根因定位分类这6分钟时间压缩到了1分钟以内，做到了实时根因定位。
当数据库遇上"自动驾驶"，阿里云 DAS 在自治诊断的突破-鸿蒙开发者社区
对于整体iSQAUD的在线诊断效果，我们对比了SIGMOD 2016 Dbsherlock: A performancediagnostic tool for transactional databases。

本方案系统图，分为4个模块：
1) 异常检测模块(Anomaly Extract)：
当数据库遇上"自动驾驶"，阿里云 DAS 在自治诊断的突破-鸿蒙开发者社区
通过对多指标时序序列异常检测，通过 Robust Threshold 鲁棒性的阈值预测方法，结合时序序列周期性的方法，生成动态阈值，来判定每个指标的上限边界，并解析出相应特征是否为spike/meanshift/,此方法对比T-Test等传统方法对更加实用和快速的判断指标波动方向，下图与传统T-Test方法对比：
当数据库遇上"自动驾驶"，阿里云 DAS 在自治诊断的突破-鸿蒙开发者社区

在实际业务场景中 Robust Threshold，对于稳定的时序序列可以很好检测出spike/meanshift 特征，但是业务场景往往是复杂的，对于Additive Model/Multiplicative Model/Weak-Seasonality, 我们DAS产品采用更加丰富异常检测算法库去识别多个不同的时序特征，关于异常检测的方法将在后续文章详细展开。本paper着重对spike和meanshift特征进行了检测。

2) 关联分析, 指标依赖关系过滤模块(Dependencies cleaning)：
当数据库遇上"自动驾驶"，阿里云 DAS 在自治诊断的突破-鸿蒙开发者社区
多指标存在依赖，通过大量历史数据关联分析，把异常方向总是波动相同的指标清理掉，留下关键指标，对比DBA经常关注的指标，有一定的相似性通过A异常/B异常的关联性推导出，AB两个指标是否关联，此类关联分析方法用很多，并未对此方法单独和传统方法作对比：
当数据库遇上"自动驾驶"，阿里云 DAS 在自治诊断的突破-鸿蒙开发者社区

3) 异常序列聚类模块(TOPIC)：
当数据库遇上"自动驾驶"，阿里云 DAS 在自治诊断的突破-鸿蒙开发者社区
通过异常指标的相似度聚类完成iSQ1和iSQ2的相似度匹配，如果两个iSQ的相似度匹配很高，认定为一类异常序列相似度算法Sij表示iSQ i与iSQ j的相似度， T表示指标类别，|Kit,Kjt| 表示每个指标之间的相似度。
当数据库遇上"自动驾驶"，阿里云 DAS 在自治诊断的突破-鸿蒙开发者社区
关联匹配的算法如下，通过KDTree的加速，结合层次聚类完成多指标异常序列的相似度匹配，相似度的阈值参数调整可以基于海量数据分类获得。

聚类方法我们同时也进行了多个方法做了对比，Topic表现较好。同时也对异常抽取模块，和关联分析模块的作用同时做了相应的对比：
当数据库遇上"自动驾驶"，阿里云 DAS 在自治诊断的突破-鸿蒙开发者社区

4) 贝叶斯案例模型模块 BCM illustration
当数据库遇上"自动驾驶"，阿里云 DAS 在自治诊断的突破-鸿蒙开发者社区
BCM作为基于实例的方法主要是通过一些代表性的样本来解释聚类/分类结果的方法。通过观察代表性的样本，我们可以直观得获得其对应族类的样本宏观特征。通过Topic对异常序列的聚类产出的结果还需要增加序列的可解释性，通过BCM进行相关数据的整合，进而将异常序列(Patterns)进行整合。
下图是DBA标注时候的案例，通过标注历史的案例，来对现有的iSQ进行判定：
当数据库遇上"自动驾驶"，阿里云 DAS 在自治诊断的突破-鸿蒙开发者社区
例如 mysql.cpu_usage +,mysql.select_ps+, mysql.qps+ 异常，BCM可以通过相似指标序列产出，CPUIntensiveWorkload, 这样的聚类结果，当异常序列不在我们已知聚类序列里面时，通过DBA的标注，可以标注出更多的异常序列，我们的后端案例库会越来越丰富，聚类效果会越来越明显，总分类如下图。
我们最终实现了从根因分类到Solution的初步映射，DAS的决策中心会根据不同根因和其现象的patterns，来分发自治Action消息到各个自治业务模块，摆脱了单纯依靠规则驱动的方式，通过数据在各业务场景的内循环，我们的模型也同时在不断更新和迭代，当新的根因和场景出现时，我们的分类会越来越细，同时可以适应多种业务场景和自治场景的根因定位。
当数据库遇上"自动驾驶"，阿里云 DAS 在自治诊断的突破-鸿蒙开发者社区

4
AutonomousDiagnose的实践
我们HA的SQL是一个比较典型的场景，我们通常使用探活SQL去探测数据库实例的心跳去保证数据库的可用性。
但是当这个探活SQL变为iSQ的时候，数据库通常会出现严重潜在的问题。对于数据库无征兆"突然挂掉"的问题，我们很难通过数据来推算出时间，HA通常通过探活SQL来解决"突然挂掉"的问题，但是在review阿里集团和阿里云大量的故障case后，我们往往很难取判断数据库"半死不活"的场景，因为探活RT的连接还是可用的，但是SQL的RT会变慢，而传统基于规则的监控时很难能检测出这一类问题的，我们这两年线上很多故障都是这种现象，而一直没有很好的解决办法。通过探活SQL变为iSQ的检测，我们可以站在用户视角第一时间发现SQL请求变慢的现象，一个"监控检测"的问题就转化成了一个"预测性维护"的问题, 提前发现潜在问题并定位根因发起自治action。
探活HASQL -> DASMind感知层感知到iSQ-> 通过iSQUAD定位根因 -> 发起决策Action -> 沉淀模型和知识图谱-> 通过自动/手动标注和迭代更新模型形成闭环
当数据库遇上"自动驾驶"，阿里云 DAS 在自治诊断的突破-鸿蒙开发者社区
引入探活iSQ更好的帮助我们，定位流量突增对其他表的影响，下图是一个探活RT异常的案例，我们发现 16：03的时候，探活SQL的RT有异常。

探活 iSQ 很敏感，通过 16:03 发现异常而慢SQL在16:04发现异常，原因也很简单，其他慢SQL需要花更长的时间才返回，而探活的iSQ在更短的SQL返回时间内发现了异常
iSQUAD发现指标Patterns的异常，cpu/active_session/DML执行次数都有一定突增，由于CPU密集型workload造成了session的堆积，同时SQL执行时间变慢产生iSQ，而探活SQL变成iSQ这个现象帮助我们发现这类影响数据库性能的问题，进而帮助我们定位到阻塞性workload流量，很大程度上帮助我们精准定位该类型的异常。
当数据库遇上"自动驾驶"，阿里云 DAS 在自治诊断的突破-鸿蒙开发者社区
后续SQL自动限流action会根据Pattern得出的异常分析结论，属于CPU Intensive Workload 分类。
根据分类，后端会拉取全量SQL，将关联指标和SQL提取，发起发出SQL限流建议，同时我们外置CBO优化器会给问题SQL做相应的索引推荐，也可通过用户的设置，进行弹性扩缩容。下面的例子是DAS自治中心通过通过根因定位后，产生相应自治操作的实例。我们会根据指标的异常patterns和分类做出，自动SQL限流，自动SQL优化以及Auto-scale的自治操作。
当数据库遇上"自动驾驶"，阿里云 DAS 在自治诊断的突破-鸿蒙开发者社区
5
成果&未来
作为新基建的重要基础设施，数据库的完全自治对于企业数字化转型，高效、安全地管理多种多样数据库产品有这重大的意义，最大程度地降低数据库不可用时间，通过自治服务提高数据库性能和消除人工操作可能带来错误，进一步解放生产力。面对不断扩张的数据规模，选择DAS数据库自治服务，你可以轻松搞定这一切。
在今天，当数据的产生速度已经远远超过了手动数据管理和处理的速度，数据库规模增长的速度远远超过对数据本身的分析和洞察的速度。借助数据库自动驾驶的特性，数据库自治服务可提供众多传统数据库无法企及的优势。
未来，越来越多的企业数据库将迁移到云上，随着云原生生态的日渐丰富, 通过数据库自治服务的诊断能力，巩固和提高竞争优势，让 IT 部门专注于创新而不是数据库管理。通过智能化和数据驱动的方式让数据库运行的更快/更稳/更安全，这也是阿里云DAS(DatabaseAutonomy Service)产品一直的期望和愿景。借助AutonomousDiagnose的进展，今年我们底层DASMind算法服务支持全网 50w+(MySQL, PolarDBMySQL, Redis)实例的异常原因分析，从1-5-10（1分钟发现问题，5分钟定位问题-10分钟发起自治action）演进到（1分钟发现并定位问题-5分钟内发起自治action)，帮助DAS产品实现自动SQL限流、自动SQL优化、Auto-scale等自治服务，距离实现L5 Full-automation更进一步，未来的方向会从局部的自治逐步演进到全局的完全自治。
2020年，我们开始尝试完善感知层与诊断层的算法，借助更多自动驾驶领域图像算法、感知层算法、构建Autonomous Anomaly Detection/AutonomousForecast/Autonomous Diagnose/Autonomous/Simulation 自治服务的整个pipeline 形成可持续的数据流闭环，通过数据来驱动数据库的自动驾驶。我们相信在汽车实现自动驾驶之前，我们必然在数据库智能化管控领域首先实现数据库领域的自动驾驶。