前沿探索：腾讯云数据库自治服务最佳实现（上

小提示：您能找到这篇{前沿探索：腾讯云数据库自治服务最佳实现（上}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的前沿探索：腾讯云数据库自治服务最佳实现（上内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

导语|虽然数据库上云解决了传统数据库很多问题，但如何让云数据库发挥最优的效能，依然充满极大挑战。为解决这一难题，高速发展的云数据库正在走向“自治”。本文是对腾讯云数据库高级产品经理刘迪在云+社区沙龙online的分享整理，为大家带来腾讯云在数据库自治服务领域的探索和实践，希望与大家一同交流。

< font-size: 16px; color: rgb(31, 73, 125);">一、数据库自治的演进

< font-size: 16px; color: rgb(31, 73, 125);">

上图所示是一张关于数据库自治的宏观视图。

业内普遍定义的石器时代大概是在十几、二十年前，刚刚进入数据库发展的快速轨道，当时的技术方案和对于数据库的认知都处于一个初级的阶段。

经历了后续的工具时代、专家时代，现在数据库自治已经到达了智能时代。在智能时代中，我们享受到了数据库自治在数据库性能优化、管理、服务等红利。

很多人都有疑惑，这条时代发展的时间线到底是怎么演进的？其实这个问题不难理解，大家在日常工作中也能体会到，时代的更替、技术的诞生，往往跟业务的需求有关，也跟现有的技术能力有关。

无论是业务驱动还是技术驱动，最终的结果就是使得数据库自治从石器时代到工具时代、专家时代、智能时代，这样一个井然有序的发展过程。

我们所谓的石器时代、工具时代、专家时代、智能时代其实不仅仅是指代时间的迭代，更多的是指技术的发展和趋势的迭代。所以有些公司现在可能依然处于石器时代，有些公司可能很早就进入了专家或者智能时代。

1.石器时代

首先我们来看石器时代解决了什么样的问题？石器时代数据库运维和服务领域关注的问题是什么？

最明显的一个特征，石器时代关注的问题就是“没有问题”，也就是保证业务不出问题，没有问题就是最大的成功。

因为在石器时代，运维依靠的主要是纯手工的人力，靠数据库运维工程师没日没夜进行手工的运维操作。

在这个阶段，往往是有经验的DBA带一些刚刚入门或者刚刚毕业的同学，传帮接代的进行知识传递。这样造成的结果就是整个团队的资质水平参差不齐，但整个团队还是可以承担起公司业务线数据库运维的重任。

石器时代最大的目标、最大的收益，就是知识的积累，但积累的大部分是碎片化、零星化的知识。

2.工具时代

在工具时代，关注的焦点从“不出问题”，转变为“在不出问题的前提下如何提高效率”。工具时代不再是原来的手工录入代码、手工处理问题，而是开始把经验、知识沉淀成脚本或者工具。

目前大部分公司的数据库运维有可能是专人专岗，也可能是由研发同学兼职，他们会用自己写的工具或者网上开源的工具进行运维工作。这个工具可能是一个很简单的脚本，也可能是非常复杂的命令集合，这是数据库运维中一个必不可少的过程。

在这个时代中，大家关注的焦点是怎样用工具去很好的满足业务的需求。

除了人和工具之外，能帮助大家提高效率的还有流程管理。在工具时代，看重的一点是流程管理如何把人和工具结合在一起，提高数据库运维的效率。

在这个阶段会出现大量审核的系统、流程和服务，每个审核都有着非常规范的流程来进行数据库的运维。

3.专家时代

当工具时代的积累达到了一定的程度，就到达了专家时代。

在这个时期，大家发现之前的脚本虽然很多但很杂乱，用了各种各样的编程语言、运行在各种不同的环境中，没有统一的管理平台，也没有统一的归类整理。数据库运维的水平往往取决于写这个脚本的运维工程师的个人能力，很难很好继承下去。

所以专家时代更多的是想把脚本标准化，用服务平台代替杂乱无章的脚本，从而将脚本规范化、标准化，变成一个可以实现自动化运维的平台。

通过这个平台，无论是有资历的工程师还是刚刚入门的研发同学，都可以井然有序的根据平台化的服务进行数据库管理。

把专家的经验转变为可复制的能力工具，是专家时代运维最显著的特点。

4.云数据库时代

随着近几年云数据库时代的到来，很多企业从自建DB迁移到了云上，也开始认知到云带给大家的好处。

数据库从本地部署到云上，可以自建云服务器，也可以直接使用云上提供的PaaS服务。这部分无论是关系型数据库还是非关系型数据库或者是NewSQL，大家都开始逐渐享受到云数据库时代的红利。

在数据库上云后，很多人会问云厂商提供的服务是不是可以保证数据库的运维没有任何的问题了？就不再需要去思考、不需要拥有之前一代代继承下来的经验？

其实并不是这样。数据库上云解决的只是基础的管控服务，比如备份、监控、故障切换等等，云上提供的是相应的PaaS能力、高可用能力和数据可靠性的能力。

但其实云服务的到来，对数据库的运维服务反而提出了更多的挑战。这里我们可以举几个例子。

首先是资源的评估，这是在上云、多云的使用中会经常遇到的问题。本地使用的是4核16G的物理机，那么在云上要购买哪种型号的服务器？购买哪种规格的PaaS数据库服务？绝大多数没有经历过云迁移的同学在这个阶段会认为最好的方法是平移，这样一定不会出现问题。其实不然，在某些环节出现的问题有可能会导致业务性能出现故障。

其次在上云之后，大家会认为云的弹性伸缩促使了业务的快速发展。近两年来很多的电商业务量、访问流量都呈几何倍数增长，各种各样的大促节日让业务部门、数据库运维部门面临更重的数据库保障任务。这时要如何保障资源评估的准确率，以及快速处理突发事件就成了要解决的问题。

同样对于云上的数据库，最大的变化就是上云之后变成了黑盒。这种黑盒现象使得在故障诊断、分析和恢复数据库问题时不能快速的定位问题、发现问题、解决问题。

所以云上数据库时代到来以后，对数据库运维同学其实是提出了更高的要求。对于非专业的运维同学，如何通过云上成千上百的异常指标来发现问题、找出规律，是面临的一个大问题。

最后，云时代还对性能提出了新的考验。如何利用经验帮助提高数据库的性能，并且持续不断的进行优化？随着数据量的积累和业务的增长，甚至一些数据的变化导致的数据分布不均衡，都会导致数据库出现问题，所以数据库性能的优化在云上有着更大的挑战。

5.智能时代

正因为上面讲到的原因，促使运维从原来平台化运维，不得不推进进入智能时代的发展。智能时代大家不再是人和工具的结合，而是人、云资源、以及自治服务的结合，从而提供更好的数据库运维服务能力。

这个阶段的目标是数据库能力和专家经验的共享，能够把之前已经积累好、沉淀好的数据库处理经验自动化，能够让数据库自己处理一些简单的问题，不需要人工干预。面对复杂问题的时候能够提供非常充足的建议，通过专家的干预进行最后的处理。

在云时代也要通过自治服务帮助大家获取数据库目前存在的看不见、摸不到的隐患。比如查询操作，当一个表只有十行数据的时候，无论怎样查询返回速度都会非常快、CPU消耗也会非常小，但一旦并发上来，比如数据量增长到十万、百万量级的时候，原来看起来非常快的SQL就都变慢了。

在故障没有发生前，如何通过自治服务帮助用户在隐患阶段就能解决数据库的潜在问题，这就是数据库智能时代主要关注的焦点。

类比自动驾驶的等级，我们把数据库自治运维也切分成Level 0~Level 4这几个阶段。

最开始所有操作都需要人工部署、人工干预，而后期人只是作为辅助，一些简单的工作、没有成长、重复的劳动都可以交给数据库自治服务统一完成。

经危机的危机公关公关常有人会问，数据库自治服务是否会取代人工？取代数据库运维？取代DBA？我可以很明确的告诉大家，数据库自治目的是为了提高处理问题的效率、提高业务的稳定性、降低业务的故障导致的损失，而并不是为了取代DBA。

DBA在数据库各个发展时代的核心价值，从会写自动命令到会编写脚本，处理线上的故障、会排查日志，再到会做一些监控和管控平台。到了数据库自治时代，数据库运维核心价值应该是能够贴近业务，在业务层面发挥更多的价值。能够通过积累、通过对业务的理解和数据库的理解，帮助业务在架构设计、附表设计、整体的业务架构上面做更多的工作。

所以数据库自治服务是放大了数据库运维的核心价值，而不是取代了数据库运维。

< color: rgb(31, 73, 125); font-size: 18px;">二、腾讯在数据库自治中的探索与实践

< color: rgb(31, 73, 125); font-size: 18px;">

腾讯在数据库自治中的探索跟整个行业的历史发展一样，同样是从简单的运维系统雏形，到后面随着业务体量越来越大，包括微信、腾讯视频、红包业务、腾讯游戏产业、腾讯体育这些大业务不断的扩张，使得人工操作遇到了瓶颈，成本也到了需要转型的阶段，因此数据库自治平台从内部开始逐渐孵化。

因为腾讯自身业务的行业属性非常多，有内容线的行业属性，有社杭州市公关公司交类的、有文体类的等等，根据不同的使用场景不断打磨后，去年开始对外发布——数据库智能管家DBbrain，这是腾讯对外发布的一款强大的数据库自治产品。

1.DBbrain产品能力解读

DBbrain服务在云上是免费的，大家可以进行免费的试用。DBbrain提供的自治服务涵盖三个方面：

• 性能优化：利用机器学习、大数据手段快速复制资深数据库管理员的成熟经验，将大量数据库问题的诊断优化工作自动化，服务于云上和云下企业。

• 安全防护：提供从用户行为安全、SQL安全到数据存储加密安全等多项数据安全服务，公安部认证的等保合规性安全产品。

• 数据库管理：提供免安装、免运维、即开即用、多种数据库类型与多种环境统一的web数据库管理终端。

数据库智能管家DBbrain与传统数据库管理工具的区别在于，它不仅仅作为辅助运维工具供DBA使用，而是面向所有用户，包括运维团队、开发团队、运营团队。其核心思想是通过智能运维平台为应用部门提供标准化和自动化的数据库运维服务。

2.DBbrain系统架构解读

数据库智能管家DBbrain提供的自治服务是跨数据库引擎的，是通过多数据库引擎插件式方式提供的，不仅支持MySQL，也支持NoSQL、Redis等。

之前大家在网上听过Oracle有自治数据库、微软也有自治服务，但他们的服务是在特有引擎上进行数据库自治，并不是多引擎的的服务平台。

我们认为数据库自治既然是为了帮助数据库运维同学减轻工作的压力、提高运维的效率，应该是具备涵盖数据库运维所涉及的尽可能多的数据库引擎，因为一个业务可能不止会用到单一的数据库，比如常见的MySQL+Redis组合等。

在数据的采集层，以MySQL为例，我们会根据不同数据采集监控指标、比如主机监控指标、网络监控指标、数据库监控指标，通过秒级监控的指标以及采集的日志信息，帮助用户发现更广的问题面，不仅仅是数据库层面的故障、主机层面和管控任务的故障都可以有丰富的源数据的记录。

在数据的计算和加工层的模块，模块通过流式计算平台提取出特征数据。这个地方并不需要人工进行分类，而是通过特征提取和加工来识别出异常信息、异常的数据，再进行异常指标和异常趋势的预测。

这个模型我们自身已经训练出了涵盖比较多指标和比较多情况的通用引擎，另一方面，也通过了现网用户对数据库使用情况和对于问题的反馈来进行监督式学习，不断增强模型训练，做到模型对业务是千人千面，而不是一套通用模型面对所有的数据库业务。

在实时诊断模块中，通过计算模块给出的结果、识别出的异常信息，以及内置的专家智能服务来为大家提供诊断优化的建议，同时会调用一些运维工具类处理的模块，比如慢日志分析模块、延迟主备切换分析等等，以工具类的模块进行辅助诊断，给到用户非常精准的数据库问题的诊断结果和对应分析以及优化定义。

在功能和输出交互层面也提供了多终端的访问，不仅仅是PC端的访问，也提供了小程序、移动端、公众号、订阅号一体化的输出，帮助用户有各种各样的体验，在任何地方都可以享受数据库自治服务带来的红利和便利。

3.用户级监控告警全链路

接下来和大家分享这几广告大全视频年我们做了哪些工作，有了哪些沉淀积累。

数据库自治服务首先关注的是故障，故障具体关注的是告警和监控，DBbrain提供了宏观用户级别的监控和告警，让用户第一时间内能够发现故障、发现异常，可以了解整个自己负责的所有数据库的情况。

这部分采用的是二八原则，产品基本上为80%以上的”小白”设计，涵盖80%常见的数据库异常问题和监控指标，所以门槛非常低。

监控页面给用户呈现出来的易读性非常高，不需要从几百个监控指标中找出哪个有问题，我们会帮助用户筛选、聚合出相同问题触发的监控指标。

最后是过程+结果的导向，DBbrain的全景视图是联动的，所有都是结果导向，不仅仅让用户看得到实际上出现什么问题，也可以在监控告警层面给大家展示故障发生过程中的变化，性能变更趋势、其他指标变化趋势等等。不仅是在结果侧方面给出反馈，在过程方面也会给用户清晰的呈现。

4.7*24小时异常诊断

7x24小时异常诊断，就相当于不间断的DBA值班一样，只不过是通过数据库自治服务来提供。

在之前的专家时代、工具时代，没有办法做到7x24小时的异常诊断，主要有三个原因：

• 信息分析难

• 信息获取难

• 性能优化难

数据库自治服务可以帮助大家克服掉这三座大山，提供自治的闭环服务，帮助大家识别各种各样的数据库问题。这里我们可以举几个例子：

比如在线教育行业由于疫情的原因，在晚上八点到十点会是一个业务高峰；而交易类、金融类的业务在早上和下午会是高峰，在某一个点可能会出现峰值，所以具备一个周期性的变化。

变更是指原来的业务变化是有规律的，但是突然有一天出现业务的变更，这很可能是业务进行了功能上的发布或者调整。

通过这些特征提取以及采集到的多维度秒级监控进行相互的配合，能够帮助识别出每一类业务自有、特有的规律，使得在做归因分析和自我优化过程中，可以屏蔽掉由于自身业务特性带来的并非是故障的高峰点，帮助用户识别“伪高峰”。

5.异常框架诊断

数据库自治服务诊断的框架分三部分——假说生成、证据评分、决策计算。

在假说生成时，我们会把各种关系模型进行1-N个关联，取到非常多的相关指标和异常，通过决策候选集的筛选，利用证据模型通过证据链进行筛选。最后通过决策支持度向量，进入决策计算模块。

决策计算模块会进行判断，决策是否为最优，如果不是最优会重新进行证据评分。

6.SQL优化

相信SQL优化是绝大多数DBA或者研发同学都很感兴趣的话题，也是大家用的最频繁的功能之一。

DBbrain提供的SQL优化，特点在于代价和成本。不仅提供索引的建议，还会提供语句的改写和排序字段的选择。

DBbrain在索引分析方面考虑的更为全面。比如在增加索引时，会考虑是否有冗余索引，是否有现成的索引可以使用或者修改。其次在索引更新后，还会评估对于用户已有的SQL是否会有影响，从而使得数据库性能下降等？

此外像大家比较关注的SQL模板聚合统计、耗时区间统计等多维度的信息统计，DBbrain也会提供相应的能力。

7.基于cost的分析引擎

基于cost的分析引擎也是我们今年的重点之一。首先的出发点是增加用户对于DBbrain提供的索引建议的可信度。

往往我们要判断一个索引、一个优化建议好不好，最简单的方法是理论上一定是可行的，二是实践，如果加上去真的变快了，我们就认为这个处理得好。如果加上去没改变就不行。

但是通过基于cost的分析引擎，我们能够在用户没有执行优化建议之前就把优化的结果告诉大家，从而在优化前就可以清楚的看到预期的优化效果。

cost值不等同于耗时，减少的cost不能等比例的计算耗时。这里我们会考虑三个方面：

• 在Server层中主要的开销是计算符合条件的行的代价

• 在engine层中主要的开销是从磁盘读数据的代价

  
  

  

  
  

• 在Jion计算时不仅要考虑condition,还要考虑condition上的filter

我们会将这些综合到cost引擎中，帮助用户更好的在优化之前看到优化的预期效果。

8.数据库审计与分析

这个功能也是DBbrain提供的非常前沿的功能，也是非常实用的功能。

具体就是我们之前有些操作很可能是瞬间的操作，在回溯问题时发现不了；有些SQL由于记录的原因记录不全，导致分析问题时没有参考。

通过SQL审计与分析服务，可以帮助用户记录所有在数据库层面执行的SQL，不仅仅是变更的操作，查询操作也可以被记录下来。可以理解为类似于原生的log。首先对性能消耗做了严格的测试，每条SQL执行完以后会进行审计规则的识别和过滤，将命中审计规则的SQL写入到内存中，批量的进行刷盘，它的性能整体损耗在做压缩以后，得出数据是低于5%。

各个厂商都在做审计类的服务，评测报告也是网上可以查询到的，5%的消耗是业内很领先的水平。

针对审计全量SQL能够做的事非常多，能够贡献所有SQL任意时刻的快照以及执行的趋势。很多时候一条SQL可能就执行十秒，但其中等了20秒，所以SQL执行时间很短，但是这条SQL结束的时间跨度非常长。对于这种SQL如果没有全量时间的快照就很难发现这样的问题，这帮助我们在排除疑难杂症的时候有更多的支持，能够帮助我们把整个数据库执行轨迹更加精确的梳理出来。

< font-size: 16px; color: rgb(31, 73, 125);">9.数据库健康评估策略解读

除了精确到SQL层面的优化，数据库自治服务在宏观上对整个数据库也有一套健康评估策略，主要通过五个方面进行评估，如下图所示：

首先是可用性，可用性是指服务正常还是不正常。业务最明显的感知就是业务是不是挂了，是不是可以正常的使用。

第二是数据可靠性。什么情况下会影响数据可靠性？除了故障数据、丢数据、人为的操作导致数据的不一致以外，有时候正常的业务逻辑中也会出现数据可靠性的问题。比如数据延迟增加，一旦出现故障如果主库的数据无法找回、起不来，备库的数据就会出现数据丢失的情况，很可能是由于binlog还没有传输过去、或者主库事务没有结束的情况。

性能是指是不是存在慢SQL、是不是存在并发数导致CPU资源消耗过于明显，是不是使用率非常高、发挥功能不足或者是cache比较低等等导致的性能问题，也是数据库健康评估策略非常关注的一点。

还有就是隐患、超大表或者是表数量的不合理，没有及时进行分步、分表，或者是采用分布式底层存储的架构，导致在做大量数据的排序查询时性能会随着数据量逐渐增大，聚合的消耗会越来越大，这也是隐患项。还有一个隐患是权限是否合理、是否有过多的授权，这些都会涉及到数据库的隐患，我们也会在健康评估策略中特别的强调出来。

变化我们在7x24小时的异常诊断中提到过，业务趋势的变更、突增、变化，与之前业务消耗和业务资源使用情况不一致的情况，我们都会识别出来告诉用户，帮助大家不仅能够掌握整个业务的使用情况，也可以对业务资源消耗画像有所了解。通过健康评估报告，更能够知道各种业务是否合理。

10.时间序列模型Porphet在资源预测上的应用

刚刚我们提到，我们结合了一些算法进行了一些预测，预测模型是采用前几年Facebook开源的Porphet算法，应用累加回归的模型，通过时间、趋势以及循环变更的规律来帮助业务预测资源的使用情况。

最简单的是根据历史使用趋势预测磁盘使用量，能够帮助用户提早知道什么时候该扩容、什么时候缩容、什么时候需要购买更多的设备、什么时候需要清理数据，同样也可以帮助用户预测CPU、内存性能指标在后续趋势中的变动，帮助用户在大促前、一些活动之前、一些重要敏感操作之前，知道业务什么时候是低峰、什么时候需要拓展多少资源，这种预测模型对用户和云厂商有非常大的价值。

对于云厂商而言，对于资源调度、资源的管理以及帮助用户进行资源合理的分配，有非常大的价值。

对于客户而言，云上的资源评估、资源的管理工作，借助预测模型可以预先启动这些工作，不用每次都措手不及。想要扩容的时候马上申请资源是来不及的，虽然云上是弹性的伸缩，但是特殊情况下，比如出现大促的时候，电商客户都在这一天发起扩容，很可能就会出现资源洪峰，用户可能不能够按时拿到想要的资源。

11.自动性能优化系统CDBTune

CDBTune是一个新的前沿技术，去年我们在SIGMOD以论文的形式进行了发布。产品化的过程也在进行逐步的完善。

大家都知道数据库参数很多，那么要如何调参？很多人表示网上有很多万能模板，但到底适不适合你的业务，其实是不知道的，可能无法发挥数据库最大的性能。

如果对这些参数进行手动调参，有经验的DBA可能对其中的某些参数有自己的经验，但对于各种不同特征业务或者不断变更的业务，CDBTune就可以帮助很好的解决这个问题。

我们可以通过深度学习算法通过自调优的方式，得到与自身业务相匹配的参数配置。调优的时间也比其他的要快，调优的结果经过测试，已经达到了很高的水平。

12.容易被忽略的数据库安全防护

绝大多数的数据库运维对于这部分的内容要不然是接触的很少，要不然就是会被忽略掉。大部分的数据库运维往往认为只要保证业务不出性能问题、不出故障就可以，但很少会关注数据库的安全防护。

数据库自治服务作为一个全方位的服务，必然要在大家忽略或者没有关注到的地方提供相应的价值，这样才能为客户更好的提供数据库的稳定性和安全性。

这里我们主要提供了三个功能：

• 合规审计：提供符合国家等保要求的安全审计，对企业网络中的数据库各类会话信息、访问操作、SQL语句进行安全审计，可挖掘数据库运行过程中各类潜在风险和隐患，为数据库安全运行保驾护航。

• 安全治理：可对数据资产、数据内容、访问信息进行中心化管理。并依托先进的AI引擎与敏感数据发现算法，将针对企业核心数据的异常操作进行筛选告警，实现企业数据保护。

• 数据脱敏：以处理数据库文件的方式，对数据库中敏感数据进行在线屏蔽、变形、字符替换、随机替换等脱敏操作，达到企业核心数据保密效果。