共计 6859 个字符，预计需要花费 18 分钟才能阅读完成。
DAS（Database Autonomy Service, 数据库自治服务）面向研发和 DBA，是一款为用户提供数据库性能剖析、故障诊断、平安治理等性能的数据库自治服务。DAS 利用大数据伎俩、机器学习、专家教训，帮忙用户打消数据库治理的复杂性及人工操作引发的服务故障，无效保障数据库服务的稳固和高效运行。本文次要讲述 DAS 的历史背景、演进策略、重要性能及实现思路，心愿能对从事相干开发的同学有所帮忙或者启发。
1 现状与问题
1.1 规模增长与运维能力倒退之间的不均衡问题凸显
随同着最近几年美团业务的疾速倒退，数据库的规模也放弃着高速增长。而作为整个业务零碎的“神经末梢”，数据库一旦呈现问题，对业务造成的损失就会十分大。同时，因数据库规模的快速增长，呈现问题的数量也大大增加，齐全依附人力的被动剖析与定位曾经不堪重负。下图是过后数据库实例近年来的增长趋势：
1.2 现实很饱满，事实很骨感
美团数据库团队以后面临的主要矛盾是：实例规模增长与运维能力倒退之间的不均衡，而主要矛盾体现在数据库稳定性要求较高与要害数据缺失。因为产品能力有余，只能依赖业余 DBA 手动排查问题，异样解决工夫较长。因而，咱们决定补齐要害信息，提供自助或主动定位问题的能力，缩短解决时长。
咱们复盘了过来一段时间内的故障和告警，深入分析了这些问题的根因，发现任何一个异样其实都能够按工夫拆分为异样预防、异样解决和异样复盘三阶段。针对这三阶段，联合 MTTR 的定义，而后调研了美团外部及业界的解决方案，咱们做了一张涵盖数据库异样解决计划的全景图。如下图所示：
通过比照，咱们发现：
- 每个环节咱们都有相干的工具撑持，但能力又不够强，相比头部云厂商大略 20%～30% 左右的能力，短板比拟显著。
- 自助化和自动化能力也有余，工具虽多，但整个链条没有买通，未造成合力。
那如何解决这一问题呢？团队成员通过深入分析和探讨后，咱们提出了一种比拟合乎以后倒退阶段的解决思路。
2 解决的思路
2.1 既解决短期矛盾，也立足久远倒退
从对历史故障的复盘来看，80% 故障中 80% 的工夫都花在剖析和定位上。解决异样剖析和定位效率短期的 ROI（投资回报率）最高。长期来看，只有欠缺能力幅员，能力继续一直地晋升整个数据库的稳定性及保障能力。因而，咱们过后的一个想法就是既要解决短期矛盾，又要立足久远倒退（Think Big Picture, Think Long Term）。新的计划要为将来留足足够的倒退空间，不能只是“头痛医头、脚痛医脚”。
在宏观层面，咱们心愿能将更多的性能做到主动定位，基于主动定位来自助或主动地解决变更，从而进步异样复原的效率，最终晋升用户体验。将异样解决效率进步和用户体验晋升后，运维人员（次要是 DBA）的沟通老本将会极大被升高，这样运维人员就有更多工夫进行技术投入，能将更多“人肉解决”的异样变成自助或主动解决，从而造成“飞轮效应”。最终达成高效的稳定性保障的指标。
在宏观层面，咱们基于已有的数据，通过结构化的信息输入，晋升可观测性，补齐要害数据缺失的短板。同时，咱们基于欠缺的信息输入，通过规定（专家教训）和 AI 的配合，提供自助或主动定位的能力，缩短解决时长。
2.2 夯实根底能力，赋能下层业务，实现数据库自治
有了明确的指导思想，咱们该采取怎么的倒退策略和门路呢？就过后团队的人力状况来看，没有同学有过相似异样自治的开发教训，甚至对数据库的异样剖析的能力都还不具备，人才构造不能满足产品的终极目标。所谓“天下大事必作于细，天下难事必作于易”。咱们思路是从小性能和容易的中央动手，先完指标监控、慢查问、沉闷会话这些简略的性能，再逐渐深刻到全量 SQL、异样根因剖析和慢查问优化倡议等这些简单的性能，通过这些根底工作来“借假修真”，一直晋升团队攻坚克难的能力，同时也能够为智能化打下一个良好的根底。
以下便是咱们依据过后人才构造以及将来指标设定的 2 年门路布局（实现数据自治指标布局在 2022 当前的启动，下图会省略掉这部分）：
2.3 建设迷信的评估体系，继续的跟踪产品质量
美国驰名治理学者卡普兰说过：“没有度量就没有治理”。只有建设迷信的评估体系，能力推动产品一直迈向更顶峰，怎么评估产品的品质并继续改善呢？之前咱们也做过很多指标，但都不可控，没有方法领导咱们的工作。比方，咱们最开始思考根因定位应用的是后果指标准确率和召回率，但后果指标不可控难以领导咱们的日常工作。这就须要找其中的可控因素，并一直改善。
咱们在学习亚马逊的时候，刚好发现他们有一个可控输出和输入指标的方法论，就很好地领导了咱们的工作。只有在正确的可控输出指标上一直优化和晋升，最终咱们的输入指标也可能失去晋升（这也印证了曾国藩曾说过的一句话：“在因上致力，但在果上随缘”）。
以下是咱们对于根因定位的指标设计和技术实现思路（在模仿环境一直晋升可控的局部，最终线上的实际效果也会失去晋升。次要包含“根因定位可控输出和输入指标设计思路”和“根因定位可控输出指标获取的技术实现思路”）。
根因定位可控输出和输入指标设计思路
根因定位可控输出指标获取的技术实现思路
在图 5 中，咱们通过场景复现形式，用技术手段来模仿一些用低成本就能实现的异样（绝大部份异样）。在对于复现老本比拟高的异样（极少局部），比方机器异样、硬件故障等，咱们目前的思路是通过“人肉经营”的形式，发现和优化问题，等到下次线上异样反复产生后，依据优化后诊断的后果，通过和预期比拟来确定验收是否通过。
将来咱们会建设回溯零碎，将产生问题时刻的异样指标保留，通过异样指标输出給回溯零碎后的输入后果，判断零碎改良的有效性，从而构建更加轻量和更广覆盖的复现形式。图 6 是复现零碎的具体技术实现思路。
有了指导思想，合乎以后倒退阶段的门路布局以及迷信的评估体系后，接下来聊聊技术计划的构思。
3 技术计划
3.1 技术架构的顶层设计
在技术架构顶层设计上，咱们秉承平台化、自助化、智能化和自动化四步走的演进策略。
首先，咱们要欠缺可观测的能力，通过要害信息的展现，构建一个易用的数据库监控平台。而后咱们依据这些要害信息为变更（比方数据变更和索引变更等）提供赋能，将一部分高频运维工作通过这些结构化的要害信息（比方索引变更，能够监测近期是否有拜访流量，来确保变更安全性）让用户自主决策，也就是自助化。接下来，咱们退出一些智能的元素（专家教训 +AI），进一步笼罩自助化的场景，并逐渐将局部低危险的性能自动化，最终通过零碎的不断完善，走到高级或齐全自动化的阶段。
为什么咱们将自动化放在智能化之后？因为咱们认为智能化的指标也是为了自动化，智能化是自动化的前提，自动化是智能化的后果。只有一直晋升智能化，能力达到高级或者齐全自动化。下图便是咱们的顶层架构设计（左侧是演进策略，右侧是技术架构的顶层设计以及 2021 年底的现状）：
顶层设计只是“万里长征第一步”，接下来咱们将自底向上逐渐介绍咱们基于顶层设计发展的具体工作，将从数据采集层的设计、计算存储层的设计和剖析决策层的设计逐渐开展。
3.2 数据采集层的设计
这下面的架构图里，数据采集层是所有链路的最底层和最重要的环节，采集数据的品质间接决定了整个零碎的能力。同时，它和数据库实例间接打交道，任何设计上的缺点都将可能导致大规模的故障。所以，技术计划上必须兼顾数据采集品质和实例稳定性，在二者无奈均衡的状况下，宁肯就义掉采集品质也要保障数据库的稳定性。
在数据采集上，业界都采取基于内核的形式，但美团自研内核较晚，而且部署周期长，所以咱们短期的形式是采纳抓包的形式做一个过渡，等基于内核的采集部署到肯定规模后再逐渐切换过去。以下是咱们基于抓包思路的技术计划调研：
| 计划 | 性能 | 通用性 | 备注 |
|---|---|---|---|
| pcap | 低 | 高 | 美团酒旅团队已线上实际 |
| pf_ring | 中 | 中 | 须要革新 MySQL |
| dpdk | 高 | 低 | 须要从新编译网卡驱动 |
从调研上咱们能够看到，基于 pf_ring 和 dpdk 的计划都有较大的依赖性，短期难以实现，之前也没有教训。然而，基于 pcap 的形式没有依赖，咱们也有过肯定的教训，之前美团酒旅团队基于抓包的形式做过全量 SQL 数据采集的工具，并通过了 1 年工夫的验证。因而，咱们最终采取了基于 pcap 抓包形式的技术计划。以下是采集层计划的架构图和采集品质以及对数据库性能带来的影响状况。
Agent 的技术设计
对数据库的影响
3.3 计算存储层的设计
因为美团整个数据库实例数量和流量微小，而且随着业务的疾速倒退，还呈现出快速增长的态势。所以，咱们的设计不仅要满足以后，还要思考将来 5 年及更长的工夫也可能满足要求。同时，对数据库故障剖析来说，数据的实时性和齐备性是疾速和高效定位问题的要害，而保证数据实时性和齐备性须要的容量老本也不容忽视。因而，联合上述要求和其余方面的一些思考，咱们对该局部设计提出了一些准则，次要包含：
- 全内存计算：确保所有的计算都在单线程内或单过程内做纯内存的操作，谋求性能跟吞吐量的极致。
- 上报原始数据：MySQL 实例上报的数据尽量维持原始数据状态，不做或者尽量少做数据加工。
- 数据压缩：因为上报量微小，须要保障上报的数据进行极致的压缩。
- 内存耗费可控：通过实践和理论压测保障简直不可能会产生内存溢出。
- 最小化对 MySQL 实例的影响：计算尽量后置，不在 Agent 上做简单计算，确保不对 RDS 实例生产较大影响。以下是具体的架构图：
全量 SQL（所有拜访数据库的 SQL）是整个零碎最具挑战的性能，也是数据库异样剖析最重要的信息之一，因而会就全量 SQL 的聚合形式、聚合和压缩的成果和弥补设计做一些重点的介绍。
3.3.1 全量 SQL 的聚合形式
因为明细数据微小，咱们采取了聚合的形式。生产线程会对雷同模板 SQL 的音讯按分钟粒度进行聚合计算，以“RDSIP+DBName+SQL 模版 ID+SQL 查问完结工夫所在分钟数”为聚合键。聚合健的计算公式为：Aggkey=RDS_IP_DBName_SQL_Template_ID_Time_Minute（Time_Minute 的值取自 SQL 查问完结工夫所在的“年、月、日、时、分钟”）
3.3.2 全量 SQL 数据聚合和压缩的成果
在数据压缩方面，遵循层层减流准则，应用消息压缩、预聚合、字典化、分钟级聚合的伎俩，保障流量在通过每个组件时进行递加，最终达到节俭带宽缩小存储量的目标。以下是相干的压缩环节和测试数据体现状况（敏感数据做了脱敏，不代表美团理论的状况）：
3.3.3 全量 SQL 数据弥补机制
如上所述，在数据聚合端是按一分钟进行聚合，并容许额定一分钟的音讯提早，如果音讯提早超过 1 分钟会被间接抛弃掉，这样在业务高峰期提早比较严重的场景下，会失落比拟大量的数据，从而对后续数据库异样剖析的准确性造成较大的影响。
因而，咱们减少了提早音讯弥补机制，对过期的数据发入弥补队列（采纳的是美团音讯队列服务 Mafka），通过过期数据弥补的形式，保障提早久的音讯也能失常存储，通过最终一致性保障了后续的数据库异样剖析的准确性。以下是数据弥补机制的设计方案：
3.4 剖析决策层的设计
在有了比拟全的数据之后，接下来就是基于数据进行决策，推断出可能的根因。这部分咱们应用了基于专家教训联合 AI 的形式。咱们把演进门路化分为了四个阶段：
第一阶段 ：齐全以规定为主，积攒畛域教训，摸索可行的门路。
第二阶段 ：摸索 AI 场景，但以专家教训为主，在大量低频场景上应用 AI 算法，验证 AI 能力。
第三阶段 ：在专家教训和 AI 上齐头并进，专家教训持续在已有的场景上迭代和延长，AI 在新的场景上进行落地，通过双轨制保障原有能力不进化。
第四阶段：实现 AI 对大部分专家教训的替换，以 AI 为主专家教训为辅，极致施展 AI 能力。
以下是剖析决策局部整体的技术设计（咱们参考了华为一篇文章：《网络云根因智荐的摸索与实际》）：
在决策分析层，咱们次要采取了专家教训和 AI 两者形式，接下来会介绍专家教训（基于规定的形式）和 AI 形式（基于 AI 算法的形式）的相干实现。
3.4.1 基于规定的形式
专家教训局部，咱们采取了 GRAI（Goal、Result、Analysis 和 Insight 的简称）的复盘方法论来领导工作，通过继续、大量、高频的复盘，咱们提炼了一些靠谱的规定，并通过继续的迭代，一直晋升准确率和召回率。上面例举的是主从提早的规定提炼过程：
3.4.2 基于 AI 算法的形式
异样数据库指标检测
数据库外围指标的异样检测依赖于对指标历史数据的正当建模，通过将离线过程的定期建模与实时过程的流检测相结合，将有助于在数据库实例存在故障或危险的状况下，无效地定位基本问题所在，从而实现及时无效地解决问题。
建模过程次要分为 3 个流程。首先，咱们通过一些前置的模块对指标的历史数据进行预处理，蕴含缺失数值填充，数据的平滑与聚合等过程。随后，咱们通过分类模块创立了后续的不同分支，针对不同类型的指标使用不同的伎俩来建模。最终，将模型进行序列化存储后提供 Flink 工作读取实现流检测。
以下是检测的设计图
根因诊断（构建中）
订阅告警音讯（基于规定或者异样检测触发），触发诊断流程，采集、剖析数据，推断出根因并筛选出无效信息辅助用户解决。诊断后果通过大象告诉用户，并提供诊断诊断详情页面，用户可通过标注来优化诊断准确性。
数据采集 ：采集数据库性能指标、数据库状态抓取、零碎指标、硬件问题、日志、记录等数据。
特征提取 ：从各类数据中提取特色，包含算法提取的时序特色、文本特色以及利用数据库常识提取的畛域特色等。
根因分类 ：包含特色预处理、特色筛选、算法分类、根因排序等局部。
根因扩大：基于根因类别进行相干信息的深刻开掘，进步用户解决问题的效率。具体包含 SQL 行为剖析、专家规定、指标关联、维度下钻、日志剖析等功能模块。
4 建设成绩
4.1 指标体现
咱们目前次要是通过“梳理触发告警场景 -> 模仿复现场景 -> 根因剖析和诊断 -> 改良打算 -> 验收改良品质 -> 梳理触发告警场景”的闭环办法（详情请参考前文 建设迷信的评估体系，继续的跟踪产品质量 局部），继续一直的进行优化和迭代。通过可控输出指标的晋升，来优化改善线上的输入指标，从而保证系统一直的朝着正确的方向倒退。以下是近期根因召回率和准确率指标体现状况。
用户告警根因反馈准确率
告警诊断剖析总体召回率
4.2 用户案例
在根因后果推送上，咱们和美团外部的 IM 零碎（大象）进行了买通，呈现问题后通过告警发现异常 -> 大象推送诊断根因 -> 点击诊断链接详情查看详细信息 -> 一键预案解决 -> 跟踪反馈解决的成果 -> 执行胜利或者回滚，来实现异样的发现、定位、确认和解决的闭环。以下是沉闷会话规定触发告警后根因剖析的一个案例。
主动拉群，并给出根因
点击诊断报告，查看详情
以下是呈现 Load 告警后，咱们的一个慢查问优化倡议推送案例（脱敏起因，采纳了测试环境模拟的案例）。
5 总结与将来瞻望
数据库自治服务通过 2 年左右的倒退，已根本夯实了根底能力，在局部业务场景上实现了初步赋能（比方针对问题 SQL，业务服务上线公布前自动识别，提醒潜在危险；针对索引误变更，工单执行前自动检测索引近期拜访流量，阻断误变更等）。接下来，咱们的指标除了在已实现工作上持续深耕，晋升能力外，重点会瞄准数据库自治能力。次要的工作布局将围绕以下 3 个方向：
（1）计算存储能力加强：随着数据库实例和业务流量的继续高速增长，以及采集的信息的不断丰富，亟需对现有数据通道能力进行加强，确保能撑持将来 3 - 5 年的解决能力。
（2）自治能力在少部分场景上落地：数据库自治能力上，会采取三步走的策略：
- 第一步：建设根因诊断和 SOP 文档的关联，将诊断和解决透明化；
- 第二步：SOP 文档平台化，将诊断和解决流程化；
- 第三步：局部低危险无人干涉，将诊断和解决自动化，逐渐实现数据库自治。
（3）更灵便的异样回溯零碎：某个场景根因定位算法在上线前或者改良后的验证十分要害，咱们会欠缺验证体系，建设灵便的异样回溯零碎，通过基于现场信息的回放来一直优化和晋升零碎定位准确率。
6 作者及团队
金龙，来自美团根底技术部 / 数据库研发核心 / 数据库平台研发组。
美团根底技术部 - 数据库技术核心诚招高级、资深技术专家，Base 上海、北京。美团关系数据库规模大，每年疾速的增长，每天承载数千亿的拜访流量。在这里能够体验高并发，高可用，高可扩展性的业务挑战，能够紧跟并开辟业界前沿技术，领会到技术提高带来的生产力晋升。欢送有趣味的同学投送简历至：edp.itu.zhaopin@meituan.com。
浏览美团技术团队更多技术文章合集
前端 | 算法 | 后端 | 数据 | 平安 | 运维 | iOS | Android | 测试
| 在公众号菜单栏对话框回复【2021 年货】、【2020 年货】、【2019 年货】、【2018 年货】、【2017 年货】等关键词，可查看美团技术团队历年技术文章合集。
| 本文系美团技术团队出品，著作权归属美团。欢送出于分享和交换等非商业目标转载或应用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者应用。任何商用行为，请发送邮件至 tech@meituan.com 申请受权。