专栏名称: 机器学习研究会
机器学习研究会是北京大学大数据与机器学习创新中心旗下的学生组织,旨在构建一个机器学习从事者交流的平台。除了及时分享领域资讯外,协会还会举办各种业界巨头/学术神牛讲座、学术大牛沙龙分享会、real data 创新竞赛等活动。
目录
相关文章推荐
机器之心  ·  万字长文解读Scaling ... ·  15 小时前  
爱可可-爱生活  ·  【[5星]VolumetricSMPL:让3 ... ·  21 小时前  
量子位  ·  首个OpenAI免费推理模型o3-mini发 ... ·  23 小时前  
爱可可-爱生活  ·  本文提出了 ... ·  4 天前  
爱可可-爱生活  ·  【[287星]Ethersync:让本地文本 ... ·  5 天前  
51好读  ›  专栏  ›  机器学习研究会

阿里在数据库智能优化路上,做了哪些探索与实践?

机器学习研究会  · 公众号  · AI  · 2017-08-22 23:09

正文

阿里妹导读:近期,2017中国应用性能管理大会(简称APMCon 2017)圆满落幕。阿里巴巴数据库事业部高级技术专家乔红麟发表了题为《数据库智能优化系统的探索与实践》的演讲,现场解读了过去几年阿里巴巴数据库团队在面对数据库规模急速增长以及业务变化越来越快的情况下在智能数据库诊断优化方面的一些探索和实践经验。


以下为演讲实录:



乔红麟:谢谢主持人,大家下午好。今天给大家分享一下我们团队在数据库优化方面做的一些事情。阿里的数据库场景与其他公司可能会有一些不同,所以今天的分享更多是基于阿里的场景和规模所做的一些思考和实践。

 

先简单介绍一下我自己。我在2015年加入阿里,目前负责阿里数据库智能优化产品CloudDBA的开发。我今天的分享主要有这几方面:


 

首先讲一下在阿里对数据库优化服务的诉求。我相信大家在数据库性能优化方面都有很多的经验教训,不同公司对优化的具体做法也不太一样。在方式上大部分企业应该还是重人工模式,就是由数据库能力比较强的人,比如DBA,来解决数据库性能问题。但阿里今天的数据库规模非常大,不管我们有多少DBA,我们的人员增长速度都无法跟上业务发展的速度,单纯依赖DBA已经无法满足业务发展需求。

 

第二方面讲一下我们的CloudDBA是如何做的,里面涉及到哪些技术,希望把这些技术分享给大家。如果大家所在的公司也在做类似的事情,希望能够提供一些参考和帮助。

 

第三方面大概讲一下目前正在探索的一些事情。现在人工智能技术比较火,数据库相对来说是比较传统的领域。如果我们将机器学习、深度学习这样的技术引入到数据库领域,它到底能做些什么,具体到数据库优化领域又能做什么,这是我们正在探索的一些事情。

   

一、阿里数据库优化服务诉求


第一部分、业务诉求



首先从整个阿里数据库的角度看一下对于数据库优化服务的业务诉求,这也是我们做这个产品最大的驱动力。

 

1、服务产品化。阿里业务发展速度远远超过了DBA团队发展的速度,单独依靠DBA重人工支持模式变得越来越困难,因此我们在几年前开始尝试通过产品来完成DBA人工做的一些工作。通过产品解决DBA人工服务的扩展性问题,是我们最直接的诉求,希望能把DBA人工服务产品化。

 

2、全局规模优化。站在全局角度来看,数据库规模迅速增大的同时也带来了巨大的成本压力。成本这块怎么理解呢?只要业务有需求,理论上可以通过增加更多的机器来满足业务需求。但是从另外一个角度来讲,这些机器是不是一定要加,是不是有一些机器可以通过优化节省下来给新的业务服务。当规模非常大的时候,所做的一小点规模化优化,所节省的成本可能都是很可观的。因此我们需要有全局规模优化的能力,仅仅一个数据库实例内部做的优化都是一些局部优化,以全局角度来看是不够的。

 

3、主动诊断。从运维的角度来看,阿里同其它公司一样,就是要尽量避免故障的发生。在阿里的业务场景下,大部分业务跟数据库有着非常紧密的关系。数据库一个微小的抖动,都可能对业务造成非常大的影响,所以如何让数据库更稳定是非常重要的业务诉求。比如一个最常见的情况,有很多线上SQL性能是有问题的,这些SQL会给业务稳定性带来一定的风险。那么我们能不能通过产品主动对线上有问题的SQL进行主动诊断,提前做优化,而不是SQL引起故障后才去优化。


4、智能异常发现。线上业务负载不断地变化,业务行为、用户行为也在不断地变化。传统基于阈值设置报警的方式无法可靠、及时地发现数据库故障或者异常。如何可靠地去发现数据库异常,甚至是提前预测到故障的发生并进行及时干预,是有很强的业务需求的,但同时也有非常大的技术挑战,尤其是在阿里这么大数据库规模场景下。


5. 容量预估。还有一些业务诉求是容量预估的需求。比如什么时候需要扩容,如何更精准地对数据库容量做出预估,这些方面后面我会稍微展开一下。

 

第二部分、用户诉求



另外一部分诉求是使用数据库这些人的诉求,也就是我们的开发人员。每个公司数据库服务方式有所不同。这里我列了一些开发人员经常会问到的一些问题,这些问题背后的诉求让我们思考我们的产品站在开发者的角度,要解决什么问题。在业务发生异常的时候,需要快速定位到整个链路到底哪块出了问题。之前DB对于开发者来说是一个黑盒,不管是信息透明方面,还是大家对数据库领域的知识方面,对于DB的了解程度可能都不够,不知道DB是什么状态,发生了什么问题。具体来讲用户诉求主要有:

 

1、信息透明,自助优化。我们期望用户能够自助发现和解决数据库的性能问题,并非发现问题先去找DBA,这样整个流程会比较长,时间成本也比较高。但做到自助化,首先用户能够全面了解数据库的运行情况。


2、持续优化。只要业务在线上运行就会不断的变化,业务负载不断变化、用户行为也会不断变化。所以数据库优化是个持续的过程,并不是今天发现一个问题解决了,以后就不出现问题了。尤其是互联网的应用,持续优化尤其重要。


3、量化跟踪,流程闭环。开发人员经常会问到一个问题,上次帮他做的优化,结果到底怎么样。我们知道并不是每个优化都是实际有效的,因为很多优化方案是基于当时的信息和场景做的一个判断,实际优化结果只有当应用之后才能真正去做评估、做衡量,所以我们要提供量化跟踪和评估的能力。另外,我们期望整个优化流程,从发现问题到最终解决问题在产品内能够闭环,开发人员能够自己完全自助化走完整个流程,而不需要DBA的参与。流程闭环也是产品必须具备的能力。


4、输出产品,而不是人。不断有新的业务上线,而我们的DBA就这么多人,并且每个人有不同的侧重。对于一些快速发展的业务,在早期我们可能没有DBA去做特别支持的,但这些业务的数据库反而是容易出问题的。开发人员如果能够通过产品解决问题,而不是凡事都去找DBA,解决问题的效率会更高。将我们DBA的能力通过产品进行输出,更好去支持我们的业务。

 

所以今天我们做CloudDBA产品,是希望我们能够通过产品的方式把DBA专家服务提供给业务开发同学,实现DBA人力的扩展。同时我们需要具备全局规模优化能力,这是在阿里对数据库优化服务的业务诉求和用户诉求,也是我们做CloudDBA这个产品的动机。

 

二、CloudDBA关键技术



首先简单介绍下CloudDBA在阿里的发展历程。早期我们团队有很多非常牛的DBA,经常是一个人当千军万马的感觉,那个阶段优化更多依赖于DBA人工完成。之后我们开发了一些工具,让工具来完成简单的优化操作。几年前我们的理念转变为所有数据库服务都应该由产品来做,所以我们在数据库运维,管理,优化等方面都有相应的产品,开始进入自动化阶段。


未来数据库优化服务会从自动化发展到智能化,这是我的判断。今天仍然有很多问题是解决不了的比如精确的容量预估,智能的异常发现,故障提前预警等。现在我们有非常多的数据,也有数据加工分析的技术,所以我们开始进行一些探索,通过数据分析和机器学习等技术手段来解决之前解决不了的问题。比如最简单的容量预估,每年都会做预算,做容量预估。至少我现在还没有看到特别多的公司去用很科学的方式,完全基于业务目标以及历史数据的分析来做容量预估。很多时候容量预估是靠拍脑袋决定的,但是今天有了大量的数据和加工数据的技术手段,我们是不是可以做更精准的容量预估。举这个例子来说明一下,未来很多的优化应该向智能化方向去思考,去探索。

 

CloudDBA在阿里大概是这样的一个发展历程,我们今天还处于自动化阶段,但同时也有一些智能化的实践。未来我的判断是我们一定向智能化去走,后面会在这方面尝试更多的探索。

 

说了这么多,那么CloudDBA到底是什么?PPT上面有一句话,“CloudDBA是一个数据库智能优化产品,面向开发人员提供自助化诊断优化服务,致力于成为用户身边的数据库专家。 CloudDBA不是给DBA开发的工具,CloudDBA从一开始我们的用户定义就很明确。我们是面向使用数据库的开发人员提供这种自助化的诊断优化服务,我们的用户不是DBA,而是真正使用数据库的开发同学。面向DBA和面向开发同学对产品来讲是完全不同的概念。比如开发同学没有太多数据库背景知识,我们即使做简单的信息透明,也需要做一些翻译,能够让开发同学理解。用户定义不同,数据的加工、分析以及最终的呈现,都是完全不一样的。

 


接下来讲一下CloudDBA到底能做什么。这是我们简化版的整体架构,涉及的面比较广。从下到上分为四层:


1、最下面是我们的采集层。对所有数据库进行实时的秒级数据采集,包括性能指标,日志数据、SQL流水,DB内部的一些信息等等


2、采集完之后数据到达计算层,计算层分两大块。一部分是实时计算,对于SQL流水,监控指标等,都会做实时计算和展示。另一部分是离线分析,比如性能基线,读写热点,统计报表等。


3、再往上就是数据库诊断服务层。如果大家做过系统的数据库优化,就清楚数据库优化会涉及到很多方面。最常见的就是SQL优化,SQL是不是很慢、有没有走到最优路径、SQL写法是否合理等等。SQL相关问题是我们开发经常会遇到的。还有其他一些问题,比如说空间,会话,锁,安全,配置等,CloudDBA能够对DB的每一个方面提供相应的专家诊断服务。


4、最上面是接入层,在阿里内部通过企业数据库服务平台iDB作为入口向开发同学提供数据库优化服务。



接下来跟大家分享一下我们做这个产品的一些产品设计原则。如果大家也在做类似的产品,希望能够给大家一些参考。


之前我们数据库优化主要是DBA来做,但DBA人工优化不具备扩展性,CloudDBA第一个设计原则就是要提供自助化服务,希望整个优化过程只有开发参与,并且整个优化流程能在CloudDBA里实现闭环。

由于业务负载会不断地变化,需要对所有线上数据库进行持续的主动诊断,及时发现和解决数据库性能问题。


另外这个产品需要有全局的视角,能够从全局角度发现规模优化点,具备规模优化能力,并且能够量化规模优化的收益。


还有最后两点非常重要,首先就是数据驱动。从我个人理解,今天要做这样一个优化产品,首先要有足够的数据,然后用数据分析和挖掘的技术手段,再结合数据库领域知识,给出更合理的诊断优化建议。智能化是我们对于数据库优化产品未来发展方向的判断,也是我们一直在坚持探索的。

 

时间关系今天无法全部展开,接下来重点展开几个方面。一个是CloudDBASQL优化怎么做的,还有一个是空间优化,另外就是CloudDBA全量SQL采集和分析。最后会分享一下我们在智能化方向的探索。


转自:阿里技术