数据库顶会VLDB论文解读：阿里数据库智能参数优化的创新与实践

前言

一年一度的数据库领域顶级会议VLDB 2019于美国当地时间8月26日-8月30日在洛杉矶召开。在本届大会上，阿里云数据库产品团队多篇论文入选Research Track和Industrial Track。

本文将对入围Research Track的论文《iBTune: Individualized Buffer Tuning for Largescale Cloud Databases》进行详细解读，以飨读者。

注：本文由阿里云智能事业群艾奥、池院、洪林、谭剑、祺星、铁赢共同撰写。

一、背景

大概五六年前，阿里数据库团队开始尝试如何将DBA的经验转换成产品，为业务开发提供更高效，更智能的数据库服务。从14年CloudDBA开始为用户提供自助式智能诊断优化服务，通过四年的持续探索和努力，18年进化到CloudDBA下一代产品 —— 自治数据库平台SDDP(Self-Driving Database Platform)。

SDDP是一个赋予多种数据库无人驾驶能力的智能数据库平台，让运行于该平台的数据库具有自感知、自决策、自恢复、自优化的能力，为用户提供无感知的不间断服务。自治数据库平台涵盖了很是多的能力，包括物理资源管理，实例生命周期管理，诊断优化，安全，弹性伸缩等，而其中自动异常诊断与恢复和自动优化是自治数据库平台最核心的能力之一。

2017年末，SDDP开始对全网数据库实例进行端到端的全自动优化，除了常见的自动慢SQL优化和自动空间优化外，还包含了本文重点介绍的大规模数据库自动参数优化。

基于数据驱动和机器学习算法的数据库参数优化是近年来数据库智能优化的一个热点方向，但也面临着很大的技术挑战。要解决的问题是在大规模数据库场景下，如何对百万级别运行不一样业务的数据库实例完成自动配置，同时权衡性能和成本，在知足SLA的前提下资源成本最低，该技术对于CSP(Cloud Service Provider)有重要价值。

学术界近一两年在该方向有一些研究(好比CMU的OtterTune)，但该算法依赖于一些人工先验经验且在大规模场景下不具有可扩展性。据了解, 其余云厂商Azure SQL Database以及AWS该方向都有投入，目前还没有看到相关论文或产品发布。

从18年初开始咱们开始数据库智能参数优化的探索，从问题定义，关键算法设计，算法评估及改进，到最终端到端自动化流程落地，多个团队通力合做完成了技术突破且实现了大规模落地。

由谭剑、铁赢、飞刀、艾奥、祺星、池院、洪林、石悦、鸣嵩、张瑞共同撰写的论文《iBTune: Individualized Buffer Tuning for Largescale Cloud Databases》被VLDB 2019 Research Track接受，这是阿里巴巴在数据库智能化方向的重要里程碑事件。

这项工做不只在数据库智能参数优化理论方面提出了创新想法，并且目前已经在阿里集团~10000实例上实现了规模化落地，累计节省~12%内存资源，是目前业界惟一一家真正实现数据库智能参数优化大规模落地的公司。

二、问题定义

参数优化是数据库优化的重要手段，而数据库参数之多也增长了参数调优的难度，好比最新版本的MySQL参数超过500，PostgreSQL参数也超过290。一般数据库调优化主要关心性能相关的参数，而其中对性能影响最大的是Buffer Pool的设置。

目前集团环境多个数据库实例共享主机的部署方式致使常常出现主机内存严重不足，但CPU和存储资源还有较多剩余，形成了机器资源浪费，所以内存资源紧张成为影响数据库实例部署密度的关键瓶颈。

Buffer Pool是内存资源消耗的最大头，如何实现Buffer Pool最优配置是影响全网机器成本的关键，同时也是影响数据库实例性能的关键，所以咱们将智能参数优化重点放在了Buffer Pool参数优化。

对于大规模数据库场景，挑战在于如何为每一个数据库实例配置合理的Buffer Pool Size，能够在不影响实例性能的前提下，Buffer Pool Size最小。传统大规模数据库场景为了方便统一管控，一般采用静态配置模板的配置数据库实例参数。

以阿里集团数据库场景为例，集团内提供了10种BufferPool规格的数据库实例供业务方选择。开发同窗在申请实例时，因为不清楚本身的业务对BP的需求是什么，一般会选用默认配置规格或者较高配置规格。这种资源分配方式，带来了严重的资源浪费。

另外业务多样性和持续可变性使得传统依赖DBA手工调优方式在大规模场景下彻底不可行，所以基于数据驱动和机器学习算法来根据数据库负载和性能变化动态调整数据库Buffer Pool成为一个重要的研究问题。

三、问题分析

从问题自己来看，缓存的大小（BP）与缓存命中率（hit ratio）是存在直接关系的。设想一下，若是能够找到一个公式BP=Function(hit_ratio)，而后从业务方或者DBA的视角找到一个业务可接受的缓存命中率，就能够下调BP且不影响业务。

通过调研，咱们发如今操做系统的Cache研究领域中，研究者已经对buffer size和hit ratio的对应关系有了不少研究，其中有研究代表在数据长尾部分这两者的关系服从Power Law分布，即：

在集团DBA同窗开发的Frodo工具帮助下，咱们针对集团内的几个重要OLTP场景（例如购物车场景、交易支付场景）进行了不一样BP配置的压测实验。实验结果也印证了前面的理论结果，在长尾部分MySQL的缓存确实是符合Power Law分布假设的。

寻找合适的miss ratio

阿里巴巴集团中有3w+的数据库实例主节点，咱们考虑从这3w+的数据库中寻找与待调整实例类似的实例，而后利用这些类似实例的miss ratio来找到待调整实例的目标miss ratio.

特征选择上，咱们选用了CPU usage, logical read, io read, miss ratio, response time 等性能指标来描述一个业务workload，并对这些特征选取了几个统计量（如mean、media、70th percentile、90th percentile）做为具体的特征数值。

为了下降工做日、周末对数据的影响，咱们选取了跨度4周的性能数据来作类似度计算，下图为两对类似实例的示例。

四、算法挑战

通过前部分的处理，公式、参数和目标mr都有了，已经能够代入公式计算出目标BP，接下来须要解决算法在工程落地过程当中所面临的问题。

因为hit ratio这个指标并不能直接的反应数据库对业务的影响，致使业务方和DBA都没有直接的体感，而且该指标也不能用来直接衡量数据库业务稳定性。所以，受限于稳定性要求，该算法在没法给出对业务影响的量化数值状况下，尚不能落地具体业务。

针对这个问题，通过与DBA和业务方的屡次讨论，咱们发现业务方和DBA最关心的是数据库的Response Time（RT），尤为是数据库实例对应用服务时的最大RT。

设想一下，若是能够预测出BP调整后的数据库实例RT的最差值，也就是RT的上界RT upperbound，那么就能够量化的描述出调整BP以后对业务的影响，也就消除了业务方与DBA对该参数优化的担心，算法就具有了落地生产环境的必要条件。因而，咱们对数据库实例RT upperbound进行了算法预测。

RT预测模型

针对RT预测问题，咱们提出了一个pairwise的DNN模型，具体的结构如图：

该DNN网络模型中采用了全链接形式，激活函数为ReLU，隐藏层节点数分别为100，50，50。

实验

在预测RT的实验中，咱们对比了包括线性回归模型（LR）、XGBoost、RANSAC、决策树（DTree）、ENet、AdaBoost线性回归（Ada）、GBDT、k近邻回归（KNR）、bagging Regressor（BR）、extremely randomized trees regressor (ETR)、随机森林（RF）、sparse subspace clustering (SSC)等回归算法，DNN模型、添加了embedding层进行instance-to-vector转换的DNN（I2V-DNN）模型，以及pairwise DNN模型等深度学习算法。

I2V-DNN的结构如图：

为了证实该算法的普适性，咱们从集团数据库的几个重要业务场景中选择了1000个实例，覆盖了不一样读写比的示例，包括只读示例、只写实例、读写均衡实例等状况。

在评价算法效果方面，咱们主要采用了以下3个评价指标：

其中，AMRAE能够评估出RT预测结果的偏差比例，MAE用于衡量RT预测的平均偏差，UMAE用于衡量RT预测值低估的状况。

在实验数据集上，RT预测结果对好比图：

由上图看出，PW-DNN模型在AMRAE这一指标上对比其余算法优点比较明显，综合其余指标，PW-DNN模型的算法效果最好，因此咱们最终选择用来预测RT的算法是PW-DNN。

实际效果

为了更加直观的观察实例变动BP先后的变化，咱们随机选择了10个实例来展现调整BP先后数据库各项指标，数据如图：

从上图中能够看出，不一样规格实例在调整BP以后的RT与调整以前的RT相差不大（实例1除外）。经过QPS、CPU usage能够看出，调整先后的业务访问量相差不大，而且资源消耗很接近，但节省了不一样幅度的内存。

在实例1中出现了调整后RT大幅上升的状况，通过对该case的仔细排查发现，该业务的平常QPS很是低，耗时占比最高的只有一个query，在调整后该query查询的值不同，致使logical read和physical read升高不少，所以最终平均RT的值也升高不少。可是调整后RT的绝对值并不大，没有发生慢SQL异常，对业务来讲是能够接受的，所以没有触发回滚操做。

五、落地

咱们实现了一个端到端的算法落地流程，从数据采集到BP优化指令的执行。该系统包含4个主要模块，分别是指标采集、数据处理、决策和执行，模块设计如图：

• 指标采集：数据库管控平台已经实现对集团内所有数据库实例的指标数据采集，覆盖了算法所使用的各项指标；
• 数据处理：采集后的指标通过流式处理进行不一样窗口维度的统计汇总，并存储在odps中供算法使用；
• 决策：本文算法的具体实现部分，读取odps中存储的指标统计数据，经算法模型计算获得待优化实例调整后的BP值；
• 执行：数据库管控平台对BP优化指令进行专项实现，并调度该优化操做的具体执行时间窗口，在符合发布约束的前提下高效执行该操做。

稳定性挑战

因为下降BufferPool配置的这个操做是个会下降稳定性的操做，一旦操做不当，轻则给DBA带来额外工做，重则引起业务故障。所以，该项目受到了BU内DBA和各稳定性相关同窗的挑战和压力。

咱们主要采起了多项措施来确保业务稳定性，具体包括：

1. 算法模型： 调整BufferPool大小与缓存命中率映射关系的敏感系数αα，使调整结果较为保守；
2. 在线调整：咱们仅针对可online调整参数的实例进行调整，避免因MySQL内核缘由致使MySQL crash的状况；
3. 灰度策略：全网规模化参数调整采用了严格的灰度策略，最开始由业务DBA根据算法给出的BP大小进行少许实例调整，确保业务稳定；而后经过较多实例的白名单机制，仅对白名单中的实例自动调整BufferPool大小，在指定范围内实例上进行灰度；最后，在业务DBA确认过非核心实例上，严格按照发布流程和管控流程进行规模化全自动操做，并严格限制每次操做的数量。
4. 流程闭环：从数据采集，BP大小决策、自动化BP调整到调整后的量化跟踪，以及回滚机制，整个流程闭环，天天发出调整后的统计分析报告。

六、成果

通过算法探索和端到端自动Buffer Pool优化流程建设，FY2019集团内全网最终优化 ~10000 个实例，将总体内存使用量从 217T内存缩减到 190T内存，节省 12.44%内存资源(27TB)。

七、将来

• 业务方面，FY2020咱们一方面继续扩大BP优化的实例范围以节省更多的内存资源；另外一方面将继续优化该算法模型经过HDM产品输出到公有云，为云上用户提供数据库实例规格建议。
• 技术方面，咱们将从Buffer Pool参数优化扩展到数据库其余性能参数优化，探索多性能参数之间的关系及影响，创建基于数据库负载和性能关系影响模型，从整个数据库实例视角进行统一数据库参数优化。

 

本文做者： Roin

原文连接

本文为云栖社区原创内容，未经容许不得转载。