创新，才能不被淘汰-机器学习时代，运维将何去何从？

我们曾经分享过一篇文章，云时代的DBA，何去何从？，在文中我们讨论了Oracle最近几年重点转而向云的变革，它全力以赴在做的一件事情就是把所有的产品和服务转移到云上来。

云技术改变了数据库领领域的竞争格局，而云时代的DBA，则面临着自后向前置的运维变化。

而今天，一条被刷爆了朋友圈的帖子让我们看到，DBA所面临的挑战还远不止这些。如果说DevOps只是让运维人员的工作有所创新和改变，而机器学习则是带来了方向性的变革。

最近亚马逊和卡内基梅隆大学一起开发了一套名叫“OtterTune”的机器学习自动化调整DBMS的系统，并公布起设计论文和开源项目，重点解决DBMS长期存在的一些问题：1.对管理人员专业性要求高；2.管理成本高；3.无法实现配置资源最优化等一系列问题。 这无疑是让那些经验丰富待遇丰厚的DBA人员直接失业呀！

传统DBMS对管理人员要求专业性高，成本也很高！数据库管理系统（DBMS）是任何数据密集型应用程序中最重要的组件。它可以处理大量的数据和复杂的负载工作。但是却难以管理，因为它们具有数百个配置选项，用于控制诸如用于缓存的内存量以及将数据写入存储器等因素。企业经常聘请这方便的专家来协助管理，但是专家对许多企业来说成本太高。

OtterTune是由卡内基·梅隆大学数据库小组（http://db.cs.cmu.edu/projects/autotune/）的学生和研究人员开发的一种新工具，它能自动为DBMS的配置按钮找到合适的设置。目的在于让任何人都更容易部署DBMS，甚至是数据库管理方面毫无专长的那些人。

OtterTune有别于其他的DBMS配置工具，原因在于它充分利用从调优之前部署的DBMS获得的知识来调优新部署的DBMS。这大大减少了调优新部署的DBMS所需要的时间和资源。为此，OtterTune维护一个资料库，包含从之前的调优会话收集而来的调优数据。它使用该数据来构建机器学习模型，这些模型采集了DBMS对不同配置作出反应的信息。OtterTune使用这些模型来指导用户针对新的应用程序进行尝试，建议使用改善特定目标（比如缩短延迟或提高吞吐量）的设置。

我们在本文中探讨了OtterTune的机器学习管道的每个组件，并演示了它们彼此如何联系，从而调优DBMS的配置。之后，我们评估了OtterTune对MySQL和Postgres的调优效果：将其最佳配置的性能与数据库管理员（DBA）及其他自动调优工具选择的配置作了一番比较。

OtterTune是由卡内基·梅隆大学数据库小组的学生和研究人员开发的一种开源工具。所有代码都放在GitHub上（https://github.com/cmu-db/ottertune），采用了Apache License 2.0这种许可证来发行。

OtterTune的工作原理

下面这张图显示了OtterTune的组件及工作流程。

在新的调优会话的开始阶段，用户告诉OtterTune优化哪个特定目标（比如延迟或吞吐量）。客户端控制器连接至目标DBMS，并收集Amazon EC2实例类型和当前目标。

然后，控制器开始了第一个观察期，在此期间它观察DBMS，并记录特定目标。观察期结束后，控制器收集来自DBMS的内部度量指标，比如MySQL针对从磁盘读取的页面和写入到磁盘的页面的计数。控制器将特定目标和内部度量指标都返回给调优管理器。

OtterTune的调优管理器收到度量指标后，将它们存储在资料库中。OtterTune使用结果来计算控制器应安装到目标DBMS上的下一个配置。调优管理器将该配置返回给控制器，并通过实际运行来估计预期的改进。用户可以决定继续调优会话，还是终结调优会话。

说明

OtterTune为它支持的每个DBMS版本维护一份按钮黑名单。该黑名单包括没必要调优的按钮（比如DBMS存储文件的路径名称），或者可能有严重后果或隐性后果的按钮（比如可能会引起DBMS丢失数据）。在每次调优会话的开始阶段，OtterTune向用户提供黑名单，那样用户就能添加他们想要OtterTune避免调优的其他任何按钮。

OtterTune作出某些假设，可能会限制其对一些用户而言的用处。比如说，它假设用户拥有管理员权限，让控制器可以修改DBMS的配置。如果用户没有管理员权限，那么他们可以将数据库的第二个副本部署到其他硬件上，以便OtterTune的调优试验。这要求用户重放工作负载跟踪，或者转发来自生产级DBMS的查询。想了解假设和限制方面的完整讨论，请参阅我们的论文（http://db.cs.cmu.edu/papers/2017/tuning-sigmod2017.pdf）。

机器学习管道

下面这张图显示了数据在通过OtterTune的机器学习管道传输时如何加以处理。所有观察结果都放在OtterTune的资料库中。

OtterTune先把观察结果传送到Workload Characterization组件。该组件识别一小批最准确地采集性能变化和不同工作负载独特特点的DBMS度量指标。

接下来，Knob Identification组件生成一份按钮排序表，列出了对DBMS的性能影响最大的按钮。然后，OtterTune将所有这些信息馈送给Automatic Tuner。该组件将目标DBMS的工作负载与数据资料库中最相似的工作负载对应起来，并重复使用该工作负载数据，生成更合适的配置。

现在不妨深入探究机器学习管道中的每一个组件。

Workload Characterization：OtterTune使用DBMS的内部运行时度量指标来描述工作负载的行为特点。这些度量指标准确地表述了工作负载，因为它们采集了运行时行为的许多方面。然而，许多度量指标是冗余的：一些是以不同单位记录的同一个度量值，另一些表示DBMS中数值高度关联的独立部分。精简冗余的度量指标很重要，因为这降低了使用它们的机器学习模型的复杂性。为此，我们基于关联模式，将DBMS的度量指标分成聚类（cluster）。然后，我们从每个聚类中选择一个代表性度量指标，具体来说是最靠近聚类中心的那个度量指标。机器学习管道中的后续组件使用这些度量指标。

Knob Identification：DBMS可能有数百个按钮，但只有一小批按钮影响DBMS的性能。OtterTune使用一种流行的特征选择技术（名为Lasso），决定哪些按钮显著影响系统的整体性能。通过将这种技术运用于资料库中的数据，OtterTune可识别DBMS的按钮重要性次序。

随后，OtterTune得决定在建议配置时使用多少个按钮。使用太多的按钮大大增加了OtterTune的优化时间。使用太少的按钮又让OtterTune无法找到最佳配置。为了使这个过程实现自动化，OtterTune使用了一种增量方法。它逐步增加用于调优会话中的按钮数量。这种方法让OtterTune得以为一小批最重要的按钮探究和优化配置，然后扩大范围、考虑其他按钮。

Automatic Tuner：Automated Tuning组件通过在每个观察期之后执行分两步走的分析，决定OtterTune应该建议使用哪个配置。

首先，系统使用针对Workload Characterization组件中识别的度量指标的性能数据，从最能表示目标DBMS工作负载的之前调优会话识别工作负载。它将会话的度量指标与来自之前工作负载的度量指标进行比较，看看哪些对不同的按钮设置有类似的反应。

然后，OtterTune选择另一个按钮配置来试一试。它使统计模型适合已收集的数据，以及来自资料库中最相似的工作负载的数据。该模型让OtterTune可以预测DBMS使用每一种可能的配置会有怎样的性能。OtterTune优化下一个配置，在探索（收集信息来改善模型）和利用（尽可能在特定度量指标方面表现不俗）之间求得平衡。

实现

OtterTune是用Python编写的。

就Workload Characterization和Knob Identification这两个组件而言，运行时性能并不是担心的主要问题，于是我们用scikit-learn实现了对应的机器学习算法。这些算法在后台进程中运行，一旦OtterTune的资料库中有了新的数据，就会整合新数据。

至于Automatic Tuner，机器学习算法位于关键路径上。它们在每次观察期后运行，整合新数据，那样OtterTune可以选择一个按钮配置接下来尝试。由于性能是个考量因素，我们使用TensorFlow实现了这些算法。

为了收集DBMS硬件方面的数据、按钮配置和运行时性能度量指标，我们将OtterTune的控制器与OLTP-Bench基准测试框架整合起来。

尝试设计

为了评估，我们针对MySQL和Postgres的性能，将OtterTune选择的最佳配置与下列配置进行了比较：

• 默认：DBMS提供的配置
• 调优脚本：开源调优顾问工具生成的配置
• DBA：数据库管理员生成的配置
• RDS：为DBMS定制的配置，由Amazon RD管理，部署在同样类型的EC2实例上。

我们在Amazon EC2 Spot Instances（现货实例）上进行了所有的试验。我们在两个实例上进行了每次试验：一个实例用于OtterTune的控制器，另一个用于部署的目标DBMS系统。我们分别使用了m4.large和m3.xlarge实例类型。我们将OtterTune的调优管理器和数据资料库部署在了搭载20个核心、128GB内存的本地服务器上。

我们使用了TPC-C工作负载，这是评估联机事务处理（OLTP）系统性能的行业标准。

评估

针对我们在试验中使用的每个数据库：MySQL和Postgres，我们测量了延迟和吞吐量。下面几张图显示了结果。第一张图显示了第99个百分位延迟的数量，这表示“在最糟糕情况下”事务完成所花的时间。第二张图显示了吞吐量的结果，以每秒完成的事务平均数量来测量。

MySQL的结果

将OtterTune生成的最佳配置与调优脚本和RDS生成的配置进行比较，就会发现：如果使用OtterTune配置，MySQL的延迟缩短了约60%，吞吐量提升了35%。OtterTune还生成了结果与数据库管理员选择的配置一样好的配置。

少数几个MySQL的按钮对TPC-C工作负载的性能有重大影响。OtterTune和数据库管理员生成的配置为这每一个按钮提供了很好的设置。由于为一个按钮提供了未达最佳标准的设置，RDS的表现要逊色一点。由于只修改了一个按钮，调优脚本的配置表现最差。

Postgres的结果

就延迟而言，OtterTune、调优工具、数据库管理和RDS生成的配置都比Postgres的默认设置有了相似的改进。我们也许可以将这归因于网络上OLTP-Bench的客户机和DBMS之间的往返所需要的开销。至于吞吐量，如果使用OtterTune建议的配置，Postgres的性能比数据库管理员和调优脚本选择的配置高出了约12%，比RDS更是高出了约32%。

类似MySQL，只有少数几个按钮对Postgres的性能有重大影响。OtterTune、数据库管理员、调优脚本和RDS生成的配置都修改了这些按钮，大多数提供了相当好的设置。

结束语

OtterTune使得为DBMS的配置按钮找到合适的设置这个过程实现了自动化。为了调优新部署的DBMS，它重复使用从之前的调优会话收集而来的训练数据。由于OtterTune不需要生成用于训练机器学习模型的初始数据集，因而显著缩短了调优时间。

接下来是什么？为了适应部署的DBaaS越来越流行这个形势（无法远程访问DBMS的主机系统），OtterTune很快就能够自动检测目标DMBS的硬件功能，而不需要远程访问。

想了解OtterTune方面的更多细节，请参阅我们的论文或放在GitHub上的代码。敬请关注这个网站（http://ottertune.cs.cmu.edu/），我们很快就会推出OtterTune这项在线调优服务。