概述
最近几年，特别是随着云计算的发展，出现了行业向后重叠和推动的情况。数据库龙头企业Oracle最近几年重点转而向云的变革，它全力以赴在做的一件事情就是把所有的产品和服务转移到云上来。云技术改变了数据库领领域的竞争格局，而云时代的DBA，则面临着自后向前置的运维变化。
数据库管理系统（简称 DBMS）无疑是任何数据密集型应用程序当中最为重要的组成部分，其肩负着处理大量数据以及高复杂性工作负载的重任。然而，数据库管理系统本身却往往难于管理，因为其中通常包含数百种配置“旋钮”，用于控制诸如缓存内存分配量以及存储介质数据写入频率等要素。各类企业一般需要聘请专业人士以协助相关调配工作，但对于大多数企业而言，此类专业人才的开价亦相当高昂。而实际上，DBA所面临的挑战还远不止这些。
而今天一则名为“OtterTune”的机器学习DBMS系统刷爆了朋友圈。那么，这个由亚马逊和卡内基梅隆大学一起开发的DBMS系统究竟是什么呢？能提供什么服务呢？其实OtterTune并不是多么惊奇的系统，不过是自动化方式识别出最适当当前数据库管理系统配置需求的设置组合。OtterTune 与其它 DBMS 配置工具之间的主要差别在于，其能够利用自此前 DBMS 部署工作当中积累到的知识指导新系统的配置工作。这一设计思路显然降低了新 DBMS 部署方案在调整当中所需要的时间与资源投入。而为了实现这一目标，OtterTune 专门建立起一套数据库，用以收集从此前调节会话中提取到的重要信息。其利用这部分数据建立机器学习（简称 ML）模型，用以捕捉 DBMS 在面对不同配置方案时作出怎样的响应。OtterTune 还利用这些模型以指导新型应用程序的配置实验，并提供推荐设置以提升目标运作效果（例如减少延迟或者提高数据吞吐量）。
虽然OtterTune只是一个结合了机器学习(建模、调参数、获取系统反应、学习、产生最优参数；典型的临床学)，可用于参数优化的小软件(实际上DBA的工作远不止这些)，但是已经代表了一个方向，未来越来越多的活（枯燥的活）可能会被AI取代。但是现阶段很多DBA很多离不开人的干预。
人类DBA VS机器DBA
首先，我们看看DBA的工作有哪些？DBA的工作实际上都是围绕数据库展开，包含但不限于这些工作：
- 数据库、主机、操作系统、交换机、存储选型，预算，架构设计，部署，参数优化；
- 数据库备份、恢复、容灾、HA、新老硬件更替；
- 数据库SQL审计、SQL优化、异常问题诊断、性能优化、巡检、健康诊断；
- 数据库扩容、缩容、迁移；
- 数据库版本升级、补丁修复；
- 数据库开发规范、管理规范的指定和执行；
- 数据库监控、专家、审核系统的开发与建立；
- 数据库代码覆盖率测试、功能测试、建模、压测、profiling；
- 数据库读写分离、sharding、MPP系统的构建；
- 数据库开发、管理、设计、规范培训；
- 数据库在垂直行业应用的架构设计（例如OLAP、GIS、时序、流计算、图式搜索、文本搜索、图搜索、化学、基因、等）；
- 异构数据、同构数据源的数据同步、ETL；
- 数据库与其他系统的联动；
- 数据库云产品化、DOCKER化、虚拟化等相关的工作；
- 数据库内核的研究、BUG上报、结合业务提出对内核的功能、性能提升等需求；
- 关注不同数据库产品的roadmap、优缺点、适应场景、不适应场景；
- 关注数据库行业的发展，进行预研性研究，储备技术；
- 与技术社区保持紧密联系，从参与、了解同行、到分享，从商业产品到开源社区；
- 技术为业务服务，从本质触发，深入行业，了解业务、行业的发展，抓住核心点，更好的服务于业务。
可以看到DBA的工作还是有蛮多的，AI要完全取代这些工作，还有非常漫长的过程。
OtterTune工作原理
以下示意图用于解释 OtterTune 中的各组件与工作流：
在开始一轮新的调节会话时，用户首先需要告知 OtterTune 此番优化的具体目标（例如面向延迟抑或数据吞吐量）。其客户端控制器将接入目标 DBMS 并收集其 Amazon EC2 实例类型与当前配置等相关信息。
在此之后，该控制器会开始第一轮观察周期，在此期间其将观察 DBMS 以及与既定目标相关之各项记录。在此轮观察周期结束后，控制器将从 DBMS 当中收集各类内部指标，例如 MySQL 自磁盘处读取之页面以及向磁盘中写入之页面计数。该控制器随后会将目标信息与内部指标发送回调节管理器当中。
当 OtterTune 的调节管理器接收到这些指标后，其会将相关数据存储在自有存储库内。OtterTune 利用这些结果计算出控制器应在目标 DBMS 上安装的下一套配置方案。具体配置方案由调节管理器交付至控制器处，同时确定运行后的预期改进效果。这时，用户即可决定继续抑或中止当前调节会话。
OtterTune 为其支持的每个 DBMS 版本皆设立有一套调节黑名单。此份黑名单中囊括了各类无法调整的项目（例如 DBMS 存储文件的路径名称）或者可能引发严重乃至隐藏后果的选项（例如可能导致 DBMS 遭遇潜在数据丢失）。每开始一项调节会话时，OtterTune 即可弹出黑名单提示，用以提醒用户添加各项不希望由 OtterTune 进行调节的具体条目。
机器学习管道
上图显示了，数据在通过OtterTune的机器学习管道传输时如何加以处理。
OtterTune 首先会将观察结果交付至 Workload Characterization 组件当中。此组件负责识别其中一小部分 DBMS 指标，从而更好地把握性能差异以及不同工作负载之间的区别性特征。
接下来，Knob Indetification 组件会生成一份与可调节项目相关之排名清单，其具体排序根据对 DBMS 性能之影响力而定。OtterTune 随后会将全部信息馈送至 Automatic Tuner 当中。此组件负责将目标 DBMS 的工作负载与现有数据存储库内最为相似的工作负载进行映射，而后利用对应工作负载数据以生成更适用的配置方案。
下面让我们深入了解机器学习管道中的组件。
Workload Characterization: OtterTune 利用 DBMS 的各内部运行时指标以表征某一工作负载的行为方式。这些指标能够对工作负载作出准确表示，因为其能够确切捕捉到其运行时行为当中的各项细节。然而，亦有许多度量完全不必要存在：其中一部分属于不同单元记录当中的同一量度结果，另一些不必要指标则代表着某些数值存在高度互关联性的 DBMS 独立组件。因此，对其中的冗余度量进行排除将非常重要，这将有效帮助我们降低机器学习模型的复杂性水平。为此，我们将面向 DBMS 对相关模型的度量进行收敛。此后，我们将从每个群集当中选择出一个代表性度量，并确保其为最靠近群集中心的度量。机器学习管道当中的后续组件将对这些度量加以使用。
Knob Identification: DBMS 可以拥有数百项可调节项目，但其中只有一个子集会对 DBMS 性能造成实际影响。OtterTune 利用当前流行趋势 特性选择技术 Lasso 以确保哪个条目会对系统的整体性能造成严重影响。通过此项技术，OtterTune 将能够利用其存储库内的数据对各 DBMS 可调节项目的重要性进行排序。
Automatic Tuner: Automated Tuning 组件通过在每轮观察周期之后执行两项分析步骤以确定 OtterTune 的推荐配置方案。
首先，该系统利用确定自 Workload Characterization 组件中识别指标的性能数据从原有存储库内找到最能体现目标 DBMS 工作负载特征的原有调节会话。其会将两项会话间的指标进行比较，旨在了解如何对不同调节选项进行变动以实现类似的工作负载指标量化结果。
在此之后，OtterTune 会选择另一套调节配置进行尝试。这套新的配置方案切合当前统计模型所收集到的实际数据，即以此数据为基础从存储库当中查找类似的工作负载。这套模型允许 OtterTune 预测 DBMS 在各类潜在配置下的实际运行效果 OtterTune 会对下一套配置进行优化，从而将探索（即收集集团以改进模型）转化为实际利用（尽可能带来更出色的目标度量）。
实现
OtterTune 以 Python 语言编写而成。对于 Workload Characterization 与 Knob Identification 两种组件，运行时性能并非我们的关注重点，因此我们使用 scikit 以实现相应的机器学习算法。这些算法在后台进程当中运行，并使用来自 OtterTune 存储库的新数据。
对于 Automatic Tuner，这些机器学习算法则变得更为关键。其需要在每一轮观察周期后运行，同时结合新数据以确保 OtterTune 能够选择一项对应调节条目进行下一步尝试。在这一流程中，由于性能成为更加重要的考量因素，因此我们使用 TensorFlow 以实现这些算法。
为了收集与 DBMS 硬件、调节配置以及运行时性能指标相关的数据，我们将 OtterTune 控制器同 OLTP-Bench 基准测试框架进行了整合。
实验评估
为了完成评估，我们利用 OtterTune 所给出的以下最佳配置选项对 MySQL 及 Postgres 性能进行了比较。在评估前我们要满足以下条件：
Default: DBMS 所提供的配置方案
Tuning : 由一款开源调节建议工具生成的配置方案
DBA: 由人类数据库管理员选定的配置方案
RDS: 针对 Amazon RDS 管理并部署在同一 EC2 实例类型之上的
DBMS 进行定制化的配置方案
我们在 Amazon EC2 现货实例之上进行了全部实验。我们分别在两套实例之上执行实验过程：其一作为 OtterTune 控制器，其二则作为目标 DBMS 部署系统。我们在这里分别使用了 m4.large 与 m3.xlarge 实例类型。我们将 OtterTune 的调节管理器与数据存储库部署在一套本地服务器之上，其配置为 20 计算核心与 128 GB 内存。
我们还用到了 TPC-C 工作负载，其属于业界标准的在线事务处理（简称 OLTP）系统性能评估工作负载类型。
评估方式
对于我们在实验当中所使用的 MySQL 与 Postgres 两套数据库，我们分别对其延迟水平与数据吞吐量进行了观察。以下图表给出了对应结果。第一份图表所示为第 99 百分位处的延迟水平，意味着“最坏情况”下完成事务处理所需要的时长。第二份图表则显示了数据吞吐量结果，即每秒完成的平均事务数量。
MySQL 测试结果
将 OtterTune 所生成的最佳配置与 Tuning 以及 RDS 相关配置进行比较可以发现，MySQL 在延迟水平方面降低了约 60%，而数据吞吐量则在 OtterTune 配置的帮助下提升 22% 到 35% 之间。与此同时，OtterTune 的生成的配置方案在实际效果上与人类数据库管理员几乎不相上下。
Postgres 测试结果
在延迟方面，OtterTune、调节工具、数据库管理员以及 RDS 所给出的配置建议全部优于 Postgres 的默认设置，且提升效果基本类似。我们可以将这一结果归结于 OLTP-Bench 客户端与 DBMS 之间的往返路由造成了巨大的性能影响。在数据吞吐量方面，Postgres 在使用 OtterTune 建议配置时，实际效果较数据库管理员及 Tuning 配置选项大约提升 12%，而与 RDS 间的比较优势更是达到 32%。
与 MySQL 类似，只有少数几个调节选项会对 Postgres 性能产生显著影响。OtterTune、数据库管理员、Tuning 以及 RDS 所生成的配置都对这些条目进行了修改，且其中多数能够带来相当不错的设置效果。
总结
OtterTune 能够以自动化方式为 DBMS 各配置选项找到良好的设置方式。为了对新的 DBMS 部署系统进行调整，OtterTune 会使用以往调优会话当中收集到的训练数据。由于 OtterTune 并不需要在每次生成操作当中再次利用初始数据集进行机器学习模型训练，因此整个调节时间周期得到大幅缩减。
