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