美团数据库自治服务平台建设

美团数据库自治服务平台建设 演讲人：沈裕锋 个人介绍 沈裕锋数据库自治服务平台负责人 曾就职于IBM、微软数据库平台组，有多年的关系型数据库跟大数据平台研发经验。 2019年加入美团，目前深耕于数据库自治服务领域，负责公司数据库研 发中心数据库自治服务平台的相关工作。 平台简介 演进策略 异常发现与诊断 SQL性能优化与治理 自动化故障处理 未来展望 平台简介 数据库自治服务平台是一种基于大数据技术、专家经验以及AI算法来实现数据库的异常发现、故障分析与处理以及SQL性能优化与 治理的自治数据库服务平台，目标是实现数据库领域的自动驾驶。 运维效率 1.分析定位难度高，以人为主，工具为辅 2.工具之间联动少，单点之间来回切换 3.处理过程不透明，协同沟通成本高 业务稳定性 1.故障处理周期长，小问题容易变成大故障 2.故障出现频次高，新业务故障持续不断发生 业务规模增长与运维能力发展之间的不平衡问题凸显 平台简介 演进策略 异常发现与诊断 SQL优化建议与治理 自动化预案处理 未来展望 演进策略 整个平台的演进路线分为数据库“可观测性建设”、“异常发现”、“智能诊断”以及“SQL优化与故障预案处理”几个大的阶段进行。 各层功能介绍 接口与展示：展示平台的功 能以及对外提供平台的服务。 业务逻辑层：使用采集到的数据来提供异常诊断、SQL性能优化与治理等业务功能。 计算存储层：通过实时计算跟大数据平台对采集的数据进行计算跟存储。 数据采集层：采集异常诊断跟性能优化的关键数据，为业务层服务。 平台简介 演进策略 异常发现与诊断 SQL性能优化与治理 自动化预案处理 未来规划 异常类型与处理生命周期 数据库系统发生异常时，需要快速发现异常、根因定位以及快速解决问题，防止异常造成的影响被进一步放大。 关键指标异常 异常类型 •活跃会话突增 •主从延迟增加 •慢查询数量突增 •…………… 异常发现、诊断、处理的全生命周期 诊断面临挑战 •造成异常的原因众多 •全方位的信息获取困难 •排查经验难以传承 异常发现策略 异常发现策略分为传统的静态阀值、基于数理统计的动态阀值的策略，动态阀值是根据不同的指标历史变化规律，构建不同的模型进行异常检测，根据历史的时序数据分布来预测未来的指标走势。 异常发现算法基于模型的实时异常指标发现 异常诊断策略 •学习专家经验：咨询DBA同学，学习行业专家的经验； •内核源码分析：深入研究MySQL内核代码，了解SQL执行的明细步骤，从最底层的逻辑来判断异常发生的根源； •AI算法诊断：学习业界知名公司异常诊 断方面论文，做一些技术上的创新。 例子：活跃会话异常诊断分析规则树 分析 复盘 提炼 总结 规则生成 内核可观测性-基于内核源码分析 有些case的诊断很有挑战性（尤其内核层面的Mutex锁造成SQL阻塞，比如binlog清理、BP空闲内存不足、DICT_SYS锁或者硬件故障问题等），因为缺少那部分的关键数据，我们从源码角度出发整理了整个SQL的明细执行步骤，跟公司MySQL内核团队合作，输出了100多个在内核中执行的关键步骤的耗时情况，为疑难杂症的Case打下坚实的基础。 内核可观测性-内核建设 根据分析结果，公司内MySQL内核团队对整个SQL的执行流水中涉及的关键执行步骤的耗时打点，把性能相关的打点数据输出至本地文件后通过平台的agent组建传至后端进行SQL的性能分析与根因诊断。 MySQL内核数据打点、上报的总体架构 自治服务平台 部分内核指标列表 •BPWaitFreeTime •SchemaWaitTime •BinlogRotateTime •RecLockTime •PageReadTime •LockTime •CommTime •PageWriteTime •TableWaitTime •TableHoldTime •SchemaHoldTime •…………………… 诊断系统架构设计与产品展示 根据专家经验跟内核可观测性功能总结出的诊断规则，同时结合AI算法进行异常指标的根因诊断分析。 基于规则的根因诊断处理流程基于规则诊断给出根因（基于页面的产品展示） 基于AI算法的根因诊断处理流程 基于AI诊断给出根因（基于IM的产品展示） 平台简介 演进策略 异常发现与诊断 SQL性能优化与治理 自动化预案处理 未来规划 SQL治理系统 •针对给出的方案，有风险SQL通过手工或自动化的方式进行治理。 SQL优化建议系统 •对于有性能问题的SQL给出如何添加索引 的优化方案。 治理风险 给出方案 SQL性能优化&治理-背景 性能问题相关的风险SQL对应用程序系统的稳定性造成很大的挑战，我们的目标是及时的发现、分析跟处理掉风险 SQL，防患于未然。 SQL请求耗时分布 服务耗时组成 SQL性能问题可能的原因 SQL忽快忽慢 SQL突然变慢 SQL逐渐变慢 SQL恒定很慢 访问数据库耗时 其他组件耗时 GC耗时 业务逻辑耗时 网络耗时 发现问题 SQL执行可观测性 •通过慢查询SQL跟全量SQL系统，发现有性能问题的SQL。 SQL性能优化&治理-治理阶段 对SQL执行的整个生命周期进行监控，分为事前、事中、事后三阶段来进行风险SQL的发现、分析以及治理。 治理阶段拆解 事前（审核）事中（实时发现） 事后（治理） SQL发布生 产环境前 SQL生产环境执行过程中 SQL生产环境执行过后 防患于未然，把问题 SQL扼杀于在摇篮里 实时发现正在执行的问题SQL，快速止损 基于整体维度进行SQL治理 风险SQL发现-全量SQL与慢查询系统 通过采集并且上报全量SQL以及慢查询日志信息（日志包含SQL文本、锁等待、执行耗时等信息），发送至平台后端用来进行 SQL相关的性能排查、优化建议以及数据安全审计等场景。 全量SQL系统架构 慢查询系统架构 系统挑战 序号 挑战项 设计原则 1 QPS特别高（达到数千万/秒） 高并发、高吞吐、可扩展 2 数量存储容量特别大（PB级别/天） 低成本 3 业务需求变化频繁 灵活性 4 采集程序频繁更新，对MySQL实例影响大 低风险 5 后端处理逻辑复杂 可扩展 索引优化建议-系统设计 通过SQL可观测性能力发现有性能问题的SQL后，如何给出最佳的索引建议来提升SQL性能是一个具有挑战性的问题，因为 加或者不加索引根据经验比较难判断眼，完全是由数据分布来决定。 索引优化建议总体架构 基于贪心算法的索引选择 SQL： selectc1,c2fromt1wherec3=123andc4>10groupbyc5 候选索引： c1、c2、c3、c4、c5的排列组合 索引选择过程： c1、c2、c3、c4、c5->[c3]c1、c2、c4、c5->[c3、c1] c2、c4、c5->[c3、c1、c5] c2、c4->[c3、c1、c5、c4] c2->[c3、c1、c5、c4、c2] 索引优化建议-基于workload优化建议 我们知道索引并不是越多越好，最好的方案尽可能使用最少的索引数量，同时能取得整个数据库系统的最大的性能提升，这方面我们参照业界的论文进行了基于workload的索引优化建议。 核心思路 1.通过上节基于贪心算法来选择针对单个 query最佳的索引（从单列开始） 2.进行索引的合并，主要是去除掉一些索引之间列有交集的索引 3.通过贪心算法Greedy(m,k)来选择k个需要的索引（因为存储空间有限）； 4.在m个最优索引（排列组合）的基础上使用贪心算法Greedy(m,k)选择总共k个需要的索引的基础上，通过MC_LEAD（添加的列都是可索引列）算法来添加多列索引； 5.重复步骤1、2、3跟4。 索引优化建议-生态建设 通过索引优化建议服务给出优化建议后，需要在真正添加索引前后，进行事前的性能评估以及事后的性能跟踪，让用户事前放心的添加索引，事后量化的感知优化的真实效果。 优化建议生态系统 索引添加前，让用户放心的添加平台给的索引优化建议索引添加后，让用户量化的感知添加索引带来的性能提升 索引优化建议-产品效果展示 索引推荐&一键审批添加索引添加索引优化前后，SQL执行时间效果对比 SQL审核（事前） 程序发布之前，在公司的CI/CD平台集成流水线，增设SQL审核卡控，尽量防止风险SQL被带到生产环境引发故障，起防患于未然的作用。 程序发布时SQL审核进行卡点（数据来源于全量SQL）产品展示审核结果，风险提示跟建议 实时风险SQL发现（事中） 程序发布之前，在公司的CI/CD平台集成流水线，增设SQL审核卡控，杜绝风险SQL被带到生产环境引发故障，起防患于未然的作用。 风险SQL耗时分布图 耗时突增耗时波动耗时渐增非风险SQL耗时分布图 耗时平稳耗时渐降耗时突减 间歇性慢查询SQL发现系统架构 全表扫描、新增慢查询风险SQL发现系统架构 SQL治理（事后） 通过批量分析已执行过的慢查询SQL跟全量SQL日志，给可优化的SQL提供索引优化建议，来推送给用户进行风险SQL的治理（这里的分析包括基于workload的索引优化建议等）。 SQL治理总体架构 通过全量SQL&慢查询SQL日志获取SQL治理对象。 基于优化建议服务给出索引优化建议，通过风险治理系统进行风险治理。24 平台简介 演进策略 异常发现与诊断 SQL性能优化与治理 自动化预案处理 未来展望 诊断平台与预案处理平台结合 数据库自治服务系统给出故障的根因或者SQL索引优化建议后，我们通过一键化或者自动化的方式调用预案处理系统处理异常或故障，让系统快速、安全、可靠的从故障中恢复。 数据库自治服务：提供精确的故障根因，根据诊断结果来快速、安全、可靠的执行某些操作恢复故障是一个挑战，借助兄弟团队预案处理系统解决问题。 预案处理系统：为自治服务等平台接入提供便利，助力提升上述系统的一键化、自动化水平，降低治人工介入成本。 产品展示 下面为系统诊断出根因后，调用预案处理系统的预案接口来对SQL进行限量、Kill阻塞者SQL或者添加索引的方式让系统快速从异常中恢复。 平台简介 演进策略 异常发现与诊断 SQL性能优化与治理 自动化预案处理 未来展望 未来展望-LLM在数据库场景的应用 随着ChatGPT的持续火热，也带来了我们对LLM在数据库场景应用的探索，经过我们初步的测试，发现无论是OpenAI的GPT序列模型还是业界开源的LLM比如Bert、T5模型都在Q&A、QueryRewrite、IndexAdviser及Text2SQL等数据库场景都有不错的表现。 未来展望-LLM在数据库场景的应用 使用开源LLM模型Bert跟T5在SQL索引建议（也适用SQLRewrite）跟Q&A方面的微调跟推理进行初步的探索 T5基于MLM（掩码语言模型）模式的预训练 SQL格式化后通过调优后的T5模型推理给出索引 Bert微调过程中学习Start跟End两个Vector 根据学来的S跟E的Vector进行推理，提取答案 未来展望-平台演进 当前平台已经具备了数据库故障自助能力跟一定的自治能力，但是自治化、智能化程度需要进一步提升，没有完全形成闭环，数据库自治服务的下一个目标实现完全的自感知、自分析、自优化与修复的数据库自动驾驶服务平台，同时随着ChatGPT的兴起，我们也在探索LLM（大语言模型）在智能运维方面的场景落地。 手工 工具化 平台化 通过手工输入命令，进行故障排查、性能优化 通过开源工具进行故障排查、性能优化 海量数据的采集、分析、给出故障根因、优化建议 自治化&智能化 自动弹性伸缩、自动索引维护、自动参数优化、自动空间优化、LLM（大语言模型）在智能运维方向探索。 平台演进阶段 已实现进行中 32 THANKYOU!