作者 | 阿里云技术专家 殷征
在智能化管控数据库的探索与实践过程当中，对数据库SQL的诊断/根因定位是我们一直以来需要面对的问题，从阿里巴巴集团到阿里云数据库，我们管控的实例数从几万规模扩大到几十万规模，DBA在面对数据库性能问题的时往往需要反复观察性能数据、日志数据、会话信息等，耗费较多的分析时间。大部分难以被发现的故障往往都是在海量慢SQL中的慢SQL，规则式的排序也许可以解决80%的问题，但是总会有边界条件导致故障无法被发现或者定位。
通过自动化的方式，我们可以通过一些规则将一些主要的现象分类，而我们经常遇到数据库现象和根因如何定位的问题，多个现象的情况总是会同时发生，规则会越来越复杂，越来越难以维护，所以通过规则很难解决这类场景的问题。所以通过集团和云上的故障case的沉淀和探索，我们尝试通过标准化的Pipeline来帮助我们未知问题的分类，实现从"Automation"to "Autonomous"的演进。
一、论文介绍
通过本文题目展开如下关键词介绍：
DiagnosingRoot Causes of Intermittent Slow Queries in Cloud Databases
- Cloud Databases
2）Slow Queries
3）Diagnose
Cloud Databases
随着云数据库的快速发展，越来越多的企业将数据库迁移到云上，当数据库遇到了云，两者的特性会碰撞出何种火花。
云的本质是各种资源高效的池化，计算机的本质就是计算+存储，而数据库的本质是数据在生产、处理、存储、消费的过程。当Cloud遇到Database，可以通过计算分析一体化来减少数据的移动，通过存储计算分离实现资源池化和解耦，形成了云原生+分布式为基础云数据库的发展生态。
Slow Queries
慢SQL与iSQ (Slow Queries & Intermittent SlowQueries)
传统慢SQL的方式往往会包含本身执行很慢的SQL，例如一个全表扫描查询，或者复杂的嵌套查询，或是没有加入索引的查询，这一类SQL往往可以通过我们自治场景SQL优化的方式来优化这类SQL，当然一些SQL本身也没有什么优化空间但执行时间大于1s，DBA在排查问题的时候往往会收到这些慢SQL的干扰。
而在众多慢SQL当中，有一类SQL的执行时间比他历史执行时间要慢的多，这时候我们就应该引起注意了，同样的SQL为什么会执行变慢？我们发现很多故障的前兆都伴随这种SQL的出现，所以我们尝试给这类SQL下一个统一的定义。
大部分iSQ都会影响用户体验，站在用户视角，他们本身执行的SQL突然变慢了，用户是可以感知到的。但是为什么不用其他指标取衡量呢？
Tcp-RT是一个不错的指标，他也可以反应查询的RT，但是SQL模板是细粒度的指标，而RT是全局维度的指标，很多场景下，当用户QPS升高的时候，Tcp-RT是下降的；某些场景下，整体RT没有变慢而某类SQL模板执行变慢了；所以全局维度指标往往是有局限性的，这就是为什么我们需要通过下钻进行根因定位。
因此，对比慢SQL的定义，我们给出了iSQ的定义，并相信通过iSQ方式筛选出来的SQL更能体现出数据库运行的状态。通过SQL执行时间>1s,这个规则并不能帮助用户很好的筛选真正的问题SQL。这里我们通过概率的方式比较简单了定义了iSQ，当然我们未来也会根据SQL执行的更多特征，借助更多"数据驱动"的方式筛选出iSQ。
Autonomous Diagnose
因此我们找到了一个根因定位的一个切入点，通过找到iSQ产生的根因来诊断数据库的性能问题。我们发现传统慢SQL的定义是通过阈值来定义的，这种规则驱动的方式并不能很好的帮助用户缩小全量SQL的范围，我们发现当数据库出现比较阻塞，密集型Workload，锁问题的时候，常常会出现iSQ(iSQ Intermittent Slow Queries，云数据库发生故障的时候，iSQ往往会提前出现，由于iSQ在其他时间段内执行时间并不慢，SQL的执行时间返回突然增长会导致业务的巨大变化,或者是由于业务变化受影响的）通过对于iSQ的根因定位，我们可以对数据库常用的故障进行跟细粒度的根因定位，只有将数据库的现象进行分类，我们后面的自修复/自优化Actions才可以减少action执行的冲突，合理的schedule我们的自治action，有效的给用户提供合理的自治建议并发出自治action，形成闭环。
二、挑战
Anomaly Diversity
在与DBA排查问题的过程中，我们发现排查问题，DBA往往要浏览超过20个指标，通过监控页面的对比，以及多指标的时序特征来确定大致的原因。例如尖刺/均值漂移是DBA最关注的特征，当然例如周期性和趋势线的特征也是DBA关注的。
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沉淀经验的成本。
三、方案
iSQUAD Overview
我们设计了iSQUAD这套框架并嵌入到DAS算法服务DASMind当中，方案分为离线和在线两条链路。
离线：通过对历史iSQ数据的探测，来触发异常抽取模块，抽取异常的特征，在通过过滤重复指标，将每个iSQ对应的pattern进行聚类，获得丰富的cluster，这些cluster通过BCM模块的特征子空间的抽取后，用来给DBA进行标注，标注的样本沉淀出pattern的模型，并提供给在线实时根因定位模块做分析，这样在线链路从之前了1-5-10(1分钟发现异常，5分钟定位分类，10分钟发出action)的方式得到了升级，我们把异常发现和根因定位分类这6分钟时间压缩到了1分钟以内，做到了实时根因定位。
对于整体iSQAUD的在线诊断效果，我们对比了SIGMOD 2016 Dbsherlock: A performancediagnostic tool for transactional databases。
image
本方案系统图，分为4个模块：
1) 异常检测模块(Anomaly Extract)：
通过对多指标时序序列异常检测，通过 Robust Threshold 鲁棒性的阈值预测方法，结合时序序列周期性的方法，生成动态阈值，来判定每个指标的上限边界，并解析出相应特征是否为spike/meanshift/,此方法对比T-Test等传统方法对更加实用和快速的判断指标波动方向，下图与传统T-Test方法对比：
image
在实际业务场景中 Robust Threshold，对于稳定的时序序列可以很好检测出spike/meanshift 特征，但是业务场景往往是复杂的，对于Additive Model/Multiplicative Model/Weak-Seasonality, 我们DAS产品采用更加丰富异常检测算法库去识别多个不同的时序特征，关于异常检测的方法将在后续文章详细展开。本paper着重对spike和meanshift特征进行了检测。
2) 关联分析, 指标依赖关系过滤模块(Dependencies cleaning)：
多指标存在依赖，通过大量历史数据关联分析，把异常方向总是波动相同的指标清理掉，留下关键指标，对比DBA经常关注的指标，有一定的相似性通过A异常/B异常的关联性推导出，AB两个指标是否关联，此类关联分析方法用很多，并未对此方法单独和传统方法作对比：
image
3) 异常序列聚类模块(TOPIC)：
通过异常指标的相似度聚类完成iSQ1和iSQ2的相似度匹配，如果两个iSQ的相似度匹配很高，认定为一类异常序列相似度算法Sij表示iSQ i与iSQ j的相似度， T表示指标类别，|Kit,Kjt| 表示每个指标之间的相似度。
关联匹配的算法如下，通过KDTree的加速，结合层次聚类完成多指标异常序列的相似度匹配，相似度的阈值参数调整可以基于海量数据分类获得。
聚类方法我们同时也进行了多个方法做了对比，Topic表现较好。同时也对异常抽取模块，和关联分析模块的作用同时做了相应的对比：
4) 贝叶斯案例模型模块 BCM illustration
BCM作为基于实例的方法主要是通过一些代表性的样本来解释聚类/分类结果的方法。通过观察代表性的样本，我们可以直观得获得其对应族类的样本宏观特征。通过Topic对异常序列的聚类产出的结果还需要增加序列的可解释性，通过BCM进行相关数据的整合，进而将异常序列(Patterns)进行整合。
下图是DBA标注时候的案例，通过标注历史的案例，来对现有的iSQ进行判定：
例如 mysql.cpu_usage +,mysql.select_ps+, mysql.qps+ 异常，BCM可以通过相似指标序列产出，CPUIntensiveWorkload, 这样的聚类结果，当异常序列不在我们已知聚类序列里面时，通过DBA的标注，可以标注出更多的异常序列，我们的后端案例库会越来越丰富，聚类效果会越来越明显，总分类如下图。
我们最终实现了从根因分类到Solution的初步映射，DAS的决策中心会根据不同根因和其现象的patterns，来分发自治Action消息到各个自治业务模块，摆脱了单纯依靠规则驱动的方式，通过数据在各业务场景的内循环，我们的模型也同时在不断更新和迭代，当新的根因和场景出现时，我们的分类会越来越细，同时可以适应多种业务场景和自治场景的根因定位。
四、AutonomousDiagnose的实践
我们HA的SQL是一个比较典型的场景，我们通常使用探活SQL去探测数据库实例的心跳去保证数据库的可用性。
但是当这个探活SQL变为iSQ的时候，数据库通常会出现严重潜在的问题。对于数据库无征兆"突然挂掉"的问题，我们很难通过数据来推算出时间，HA通常通过探活SQL来解决"突然挂掉"的问题，但是在review阿里集团和阿里云大量的故障case后，我们往往很难取判断数据库"半死不活"的场景，因为探活RT的连接还是可用的，但是SQL的RT会变慢，而传统基于规则的监控时很难能检测出这一类问题的，我们这两年线上很多故障都是这种现象，而一直没有很好的解决办法。通过探活SQL变为iSQ的检测，我们可以站在用户视角第一时间发现SQL请求变慢的现象，一个"监控检测"的问题就转化成了一个"预测性维护"的问题, 提前发现潜在问题并定位根因发起自治action。
探活HASQL -> DASMind感知层感知到iSQ-> 通过iSQUAD定位根因 -> 发起决策Action -> 沉淀模型和知识图谱-> 通过自动/手动标注和迭代更新模型形成闭环
引入探活iSQ更好的帮助我们，定位流量突增对其他表的影响，下图是一个探活RT异常的案例，我们发现 16：03的时候，探活SQL的RT有异常。
image
探活 iSQ 很敏感，通过 16:03 发现异常而慢SQL在16:04发现异常，原因也很简单，其他慢SQL需要花更长的时间才返回，而探活的iSQ在更短的SQL返回时间内发现了异常
iSQUAD发现指标Patterns的异常，cpu/active_session/DML执行次数都有一定突增，由于CPU密集型workload造成了session的堆积，同时SQL执行时间变慢产生iSQ，而探活SQL变成iSQ这个现象帮助我们发现这类影响数据库性能的问题，进而帮助我们定位到阻塞性workload流量，很大程度上帮助我们精准定位该类型的异常。
后续SQL自动限流action会根据Pattern得出的异常分析结论，属于CPU Intensive Workload 分类。
根据分类，后端会拉取全量SQL，将关联指标和SQL提取，发起发出SQL限流建议，同时我们外置CBO优化器会给问题SQL做相应的索引推荐，也可通过用户的设置，进行弹性扩缩容。下面的例子是DAS自治中心通过通过根因定位后，产生相应自治操作的实例。我们会根据指标的异常patterns和分类做出，自动SQL限流，自动SQL优化以及Auto-scale的自治操作。
image
image
五、成果&未来
作为新基建的重要基础设施，数据库的完全自治对于企业数字化转型，高效、安全地管理多种多样数据库产品有这重大的意义，最大程度地降低数据库不可用时间，通过自治服务提高数据库性能和消除人工操作可能带来错误，进一步解放生产力。面对不断扩张的数据规模，选择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 形成可持续的数据流闭环，通过数据来驱动数据库的自动驾驶。我们相信在汽车实现自动驾驶之前，我们必然在数据库智能化管控领域首先实现数据库领域的自动驾驶。
作者简介：殷征，阿里云技术专家，多年在通信行业与互联网行业从事数据挖掘/AIOPS相关工作，相信通过数据驱动的方式可以化解各行各业复杂系统系统的不确定性，优化资源配置效率。
文章来源：CSDN
网友评论