【机器学习化DBMS】——ottertune系统原理

 一、前言

       数据库管理系统（DBMS）是任何数据密集应用的关键部分。它们可以处理大量数据和复杂的工作负载，但同时也难以管理，因为有成百上千个“旋钮”（即配置变量）控制着各种要素，比如要使用多少内存做缓存和写入磁盘的频率。组织机构经常要雇佣专家来做调优，而专家对很多组织来说太过昂贵了。

     卡耐基梅隆大学数据库研究组的学生和研究人员在开发一个新的工具，名为 OtterTune，可以自动为 DBMS 的“旋钮”找到合适的设置。工具的目的是让任何人都可以部署 DBMS，即使没有任何数据库管理专长。OtterTune 跟其他 DBMS 设置工具不同，因为它是利用对以前的 DBMS 调优知识来调优新的 DBMS，这显著降低了所耗时间和资源。OtterTune 通过维护一个之前调优积累的知识库来实现这一点，这些积累的数据用来构建机器学习（ML）模型，去捕获 DBMS 对不同的设置的反应。OtterTune 利用这些模型指导新的应用程序实验，对提升最终目标（比如降低延迟和增加吞吐量）给出建议的配置。

       本文中，我们将讨论 OtterTune 的每一个机器学习流水线组件，以及它们是如何互动以便调优 DBMS 的设置。然后，我们评估 OtterTune 在 MySQL 和 Postgres 上的调优表现，将它的最优配置与 DBA 和其他自动调优工具进行对比。OtterTune 是卡耐基梅隆大学数据库研究组的学生和研究人员开发的开源工具，所有的代码都托管在 Github 上，以 Apache License 2.0 许可证发布。

二、OtterTune整体架构

      OtterTune分为客户端和服务端。目标数据库是用户需要调优参数的数据库：

      1）OtterTune的客户端安装在目标数据库所在机器上，收集目标数据库的统计信息，并上传到服务端。

       2）服务端一般配置在云上，它收到客户端的数据，训练机器学习模型并推荐参数文件。

      客户端接到推荐的参数文件后，配置到目标数据库上，测量其性能。以上步骤可以重复进行直到用户对OtterTune推荐的参数文件满意。当用户配置好OtterTune时，它能自动的持续推荐参数文件并把所得结果上传到服务端可视化出来，而不需要DBA的干预。这样能很大简化DBA的工作，比如DBA可以配置好OtterTune后回家睡觉，第二天早上OtterTune可能就在一晚上的尝试中找到了好的参数文件。而OtterTune尝试的所有参数文件及对应的数据库性能和统计信息都能在服务端的可视化界面上轻易找到。

           

      上图是OtterTune的整体架构：

      1）客户端中controller由Java实现，用JDBC访问目标数据库来收集其统计信息；driver则用了Python的fabric，主要与服务端交互。

     2）服务端用了Django来构建网站，并用Celery来调度机器学习任务；机器学习则调了tensorflow和sklearn。 

    关于OtterTune架构更详细的内容可以参考2018 VLDB的demo paper[4].

三、OtterTune客户端

        下图是 OtterTune 客户端的组件和工作流程

      1、调优过程开始，用户告知 OtterTune 要调优的最终目标（比如，延迟或吞吐量），客户端控制器程序连接目标 DBMS，收集 Amazon EC2 实例类型和当前配置。

      2、然后，控制器启动首次观察期，来观察并记录最终目标。观察结束后，控制器收集 DBMS 的内部指标，比如 MySQL 磁盘页读取和写入的计数。控制器将这些数据返回给调优管理器程序。

      3、OtterTune 的调优管理器将接收到的指标数据保存到知识库。OtterTune 用这些结果计算出目标 DBMS 的下一个配置，连同预估的性能提升，返回给控制器。用户可以决定是否继续或终止调优过程。

注：OtterTune 对每个支持的 DBMS 版本维护了一份“旋钮”黑名单，包括了对调优无关紧要的部分（比如保存数据文件的路径），或者那些会产生严重或隐性后果（比如丢数据）的部分。调优过程开始时，OtterTune 会向用户提供这份黑名单，用户可以添加他们希望 OtterTune 避开的其它“旋钮”。OtterTune 有一些预定假设，对某些用户可能会造成一定的限制。比如，它假设用户拥有管理员权限，以便控制器来修改 DBMS 配置。否则，用户必须在其他硬件上部署一份数据库拷贝给 OtterTune 做调优实验。这要求用户或者重现工作负载，或者转发生产 DBMS 的查询。完整的预设和限制请看我们的论文 。

四、 OtterTune服务端原理

     1、机器学习流水线

        下图是 OtterTune ML流水线处理数据的过程，所有的观察结果都保存在知识库中。OtterTune 先将观察数据输送到“工作流特征化组件”（Workload Characterization component），这个组件可以识别一小部分 DBMS 指标，这些指标能最有效地捕捉到性能变化和不同工作负载的显著特征。下一步，“旋钮识别组件”（Knob Identification component）生成一个旋钮排序表，包含哪些对 DBMS 性能影响最大的旋钮。OtterTune 接着把所有这些信息“喂”给自动调优器（Automatic Tuner），后者将目标 DBMS 的工作负载与知识库里最接近的负载进行映射，重新使用这份负载数据来生成更佳的配置。

         我们来深入挖掘以下机器学习流水线的每个组件。

   2、 工作负载识别
       调优系统的第一步是发现最佳模型代表目标工作量的显著方面，以便它可以识别存储库中之前看到的工作负载与它相似。这使OtterTune能够利用它从以前调整会话收集的信息，以帮助指导为新应用程序寻找一个好的参数配置。我们可能会考虑两种方法来做到这一点。首先是分析逻辑级别的目标工作负载。这意味着检查查询和数据库模式来计算指标，例如每个查询访问的表/列的数目和每个交易的读/写比率。可以使用以下方式进一步细化这些指标通过DBMS的“假设”优化器API(用于估计额外的运行时间信息)，比如最常访问哪些索引。然而，这种方法的问题在于它是不可能确定改变某个特定参数的影响，因为所有这些估计是基于逻辑数据库而不是查询的实际运行时的行为。此外，DBMS如何执行查询以及这个查询与内部组件(受调优参数影响)的关系是取决于数据库的许多因素（例如，大小，基数，工作集大小）。因此，这个信息不可以仅仅通过检查工作量来捕获。

         更好的方法是使用DBMS的内部运行时指标表征工作负载的行为方式。 所有现代DBMS都公开有关系统的大量信息。 例如，MySQL的InnoDB引擎提供了有关数字的统计信息页面读/写数，查询缓存利用率和锁开销。OtterTune使用运行时统计信息来表征工作负载执行时记录。 这些指标提供了更多准确表示工作负载，因为它们捕获更多其运行时行为的各个方面。 它们的另一个优点是它们直接受到参数设置的影响。 例如，如果控制DBMS分配的内存量的参数到它的缓冲池太低，那么这些指标就表明了增加缓冲池缓存未命中数。所有DBMS
提供类似的信息，只是具有不同的名称和不同的粒度。 但正如我们将展示的那样，OtterTune的模型构建算法不需要标记指标。

       2.1 统计收集
       OtterTune的控制器支持模块化架构它为不同的DBMS执行适当的操作收集运行时统计信息。在每次观察周期开始时，控制器首先重置目标DBMS的所有统计数据。然后它在这个周期结束时检索新的统计数据。从那时起，OtterTune就不知道哪些指标实际上很有用，它收集DBMS的每个数字指标使其可用并将其作为键/值对存储在其存储库中。这个收集过程的主要挑战是如何表达DBMS和数据库的子元素的度量标准。一些系统，如MySQL，只报告整个统计数据。但是，其他数据库系统提供单独的统计数据针对表或数据库。商业DBMS甚至保持独立各个组件的统计信息（例如，IBM DB2对每个缓冲池实例跟踪统计信息）。这种细粒度数据问题是DBMS提供多个具有相同名称的指标。一种可能的解决方案是在子元素的名称前加上前缀到度量标准的名称。例如，Postgres的数字度量为表“foo”读取的块存储在存储库中如foo.heap_blks_read。但这种方法意味着它无法实现将此度量映射到其他数据库，因为它们的表会有所不同的名字。而 OtterTune存储指标与单个标量值相同的名称。这是有效的，因为Otter-Tune目前只考虑全局旋钮。我们推迟了这个问题调整表格或组件特定的参数作为未来的工作。

       2.2 修剪冗余监控指标
       下一步是自动删除多余的指标。删除这些元素非常重要，因为使用OtterTune必须考虑捕获在性能和识别不同工作负载可变性的最小指标集。 减小此集的大小会减少ML算法的搜索空间，反过来加速整个过程和增加了模型适合OtterTune基于内存来调优的可能性。 我们将在后续章节中展示OtterTune可用的指标足以区分在同一硬件上部署的DBMS的不同工作负载。冗余DBMS指标出于两个原因。 首先是为完全相同的度量标准提供不同粒度的那些系统。 例如，MySQL读取数据量就innodb_data_read和innodb_pages_read而言。这两个指标是相同的度量只是在不同的单位，因此没有必要同时考虑他们。其他类型的冗余指标就是那些指标表示DBMS的独立组件但其值是强相关的。 例如，我们从实验中发现更新了元组数量的Postgres度量标准pg_stat_database.tup_updated与衡量数量的指标pg_statio_user_tables.idx_blks_hit几乎一致。

       我们使用两种经过充分研究的技术进行修剪。 首先是降维技术，称为因子分析，讲高维DBMS指标转换为低维数据。 然后我们使用第二种技术，称为k-means ，用于聚类这种低维数据，成为有意义的群体。 使用降维技术是许多聚类算法的预处理步骤，因为它们减少了数据中“噪音”的数量。 这个提高了聚类分析的稳健性和质量。

       给定一组包含任意相关的实值变量，FA将这些变量减少到一组较小的因子来捕获原始变量的相关模式。 每个因素是原始变量的线性组合; 因子系数类似于并且可以用相同的方式解释线性回归中的系数。 此外，每个因素都有单位方差与所有其他因素无关。 这意味着人们可以通过多少变化来排序因子来解释原始数据。 我们发现只有最初的几个因素对于我们的DBMS指标数据而言意义重大，这意味着大部分数据可变性由前几个因素捕获。

	Config 1	Config 2	….	Config n
Mrtric 1
Mrtric 2
…
Mrtric m

       然后，我们使用每个指标的一行作为坐标，通过k-means聚类。 我们为每个类保留一个指标，即最靠近集群中心的那个。 使用k-means方法的一个缺点是它需要最佳数量的聚类（K）作为其输入。 我们使用简单的启发式来完全自动化这个选择过程和近似K.虽然这种方法不保证找到最佳解决方案，它不需要人类手动解释问题的图形表示确定最佳簇数。 我们比较了这种启发式与其他技术[55,48]选择K和发现他们选择的值相差一到两个最接近我们的近似值。 这种变化几乎没有差别在OtterTune生成的配置质量方面.

       3、旋钮识别：

       DBMS 可以有几百个旋钮，但只有一部分影响性能。OtterTune 使用一种流行的“特性-选择”技术，叫做 Lasso，来判断哪些旋钮对系统的整体性能影响最大。用这个技术处理知识库中的数据，OtterTune 得以确定 DBMS 旋钮的重要性顺序。接着，OtterTune 必须决定在做出配置建议时使用多少个旋钮，旋钮用的太多会明显增加 OtterTune 的调优时间，而旋钮用的太少则难以找到最好的配置。OtterTune 用了一个增量方法来自动化这个过程，在一次调优过程中，逐步增加使用的旋钮。这个方法让 OtterTune 可以先用少量最重要的旋钮来探索并调优配置，然后再扩大范围考虑其他旋钮。

注：lasso回归的特色就是在建立广义线型模型的时候，这里广义线型模型包含一维连续因变量、多维连续因变量、非负次数因变量、二元离散因变量、多元离散因变，除此之外，无论因变量是连续的还是离散的，lasso都能处理，总的来说，lasso对于数据的要求是极其低的，所以应用程度较广；除此之外，lasso还能够对变量进行筛选和对模型的复杂程度进行降低。这里的变量筛选是指不把所有的变量都放入模型中进行拟合，而是有选择的把变量放入模型从而得到更好的性能参数。 复杂度调整是指通过一系列参数控制模型的复杂度，从而避免过度拟合(Overfitting)。 对于线性模型来说，复杂度与模型的变量数有直接关系，变量数越多，模型复杂度就越高。 更多的变量在拟合时往往可以给出一个看似更好的模型，但是同时也面临过度拟合的危险  。

     视频讲解lasso：https://www.bilibili.com/video/av36942687/?p=4

     推导公式：Lasso回归公式推导

       4、自动调优器：

         现在，在这一点上，OtterTune有（1）非冗余的集合指标，（2）最有影响力的配置参数，以及（3）来自先前调整会话的数据存储在其存储库中。OtterTune重复分析了迄今为止收集的数据会话然后给出下一个配置。 它在调优过程中的每次观察期完成后执行两步分析。 在第一步，系统识别来自先前调整会话的哪个工作负载与目标工作量的最相似。 它通过比较这个会话的指标与之前看到的工作负载的指标，来看看与之前哪个配置最相似。 曾经OtterTune已将目标工作负载与其存储库中最相似的工作负载相匹配，然后启动第二步的分析，选择一个参数配置以最大化目标。 我们现在更详细地描述这些步骤。
        自动调优器组件在每次观察阶段后，通过两步分析法来决定推荐哪个配置。首先，系统使用工作负载特征化组件找到的性能数据来确认与当前的目标 DBMS 工作负载最接近的历史调优过程，比较两者的度量值以确认哪些值对不同的旋钮设置有相似的反应。然后，OtterTune 尝试另一个旋钮配置，将一个统计模型应用到收集的数据，以及知识库中最贴近的工作负载数据。这个模型让 OtterTune 预测 DBMS 在每个可能的配置下的表现。OtterTune 调优下一个配置，在探索（收集用来改进模型的信息）和利用（贪婪地接近目标度量值）之间交替进行。 

         4.1 工作负载映射
        第一步的目标是匹配目标DBMS的工作负载基于所选指标组的值从在数据库中找到最相似的工作负载。OtterTune所做的匹配质量随着数目标工作负载收集的数据而增加，，这就是我们想要的期望。 因此，使用动态映射方案优于静态映射（即在第一个观察期结束后的一次映射）因为它使OtterTune能够做得更多随着调整会话的进展。矩阵集合()有相同的行和列。n是指标的个数(前面通过因子分析降维和k-means聚类进一步修剪后的指标)。每个指标对应一个矩阵，每个元素含义：某个工作负载在某个参数配置下的该指标的值。如果有多个观测值，就取中位数。某个指标在不同工作负载和不同配置下的值.

	Config1	Config2	….	Confign
工作负载1
工作负载2
…
工作负载m

      工作负载映射算法：

     1）目标工作负载表征向量。计算到上面指标对应矩阵的距离，即对应指标到每个工作负载的距离

     2）将第一步计算出的每个指标到每个工作负载的距离取平均值，得到目标工作负载到历史工作负载的距离。

     3） 取距离最小的那个的工作负载就是与目标工作负载最相似的

        在计算得分之前，所有指标具有相同的数量级至关重要。 否则，得到的分数将是不公平的，因为任何规模大得多的指标将主导平均距离计算。 OtterTune通过计算每个指标的十分位数，然后根据它们所属的十进制值对值进行分箱，确保所有度量标准具有相同的数量级。 然后，我们用相应的bin编号替换矩阵中的每个条目。 通过这一额外步骤，我们可以为Otter-Tune存储库中的每个工作负载计算准确且一致的分数。比如某指标值的范围是1到1000，那么分成10等份就是1-100,2-200，...,10-1000等。如果某指标值是160，那取值为2.

       5、 配置推荐

         OtterTune使用高斯过程（GP）回归来推荐它认为可以改进目标度量的配置。 GP回归是一种最先进的技术，其威力大约等于深度网络的威力。 GP有许多吸引人的功能，使其成为建模配置空间和提出建议的合适选择。最重要的是，GP提供了一种理论上合理的方式来权衡探索（即获取新知识）和利用（即制作） 基于现有知识做出的决定。另一个原因是GP默认情况下会提供置信区间。尽管可以使用自举等方法来获取深度网络和其他不具有范围的模型的置信区间。 虽然像bootstrapping（自助抽样）这样的方法可以用来获得深度网络和其他没有给出它们的模型的置信区间，但它们的计算成本很高，因此对于在线调优服务来说是不可行的

         OtterTune通过重用先前选择的工作负载中的数据来训练GP模型，从而开始推荐步骤。 它通过添加目前已观察到的目标工作负载的指标来更新模型。 但由于映射的工作负载与未知工作负载不完全相同，因此系统不完全信任模型的预测。 我们通过增加OtterTune尚未尝试进行此调整会话的GP模型中所有点的噪声参数的方差来处理此问题。 也就是说，我们在协方差中添加一个脊项(ridge )。 我们还为OtterTune选择的每个配置添加了一个较小的脊线项(ridge )。 这对于“噪声”虚拟化环境是有帮助的，其中外部DBMS度量（即，吞吐量和时延）从一个观察周期到下一个观察周期发生变化。

         现在，对于此步骤中的每个观察期，OtterTune尝试找到比此会话中迄今为止所见的最佳配置更好的配置。 它通过（1）搜索GP中的未知区域（即，其几乎没有数据的工作负载）或（2）选择其GP中接近最佳配置的配置来完成此操作。 前一种策略被称为探索。 这有助于OtterTune查找配置，其中旋钮设置为超出其过去尝试过的最小值或最大值的值。 这对于尝试某些参数是有用的，其中上限可能取决于底层硬件（例如，可用的存储量）。 第二种策略称为利用。 这是OtterTune找到了一个很好的配置，它尝试对参数进行微调，以确定它是否可以进一步提高性能。

         在选择下一个配置时，OtterTune选择的这两种策略中的哪一个取决于其GP模型中数据点的方差。 它始终选择具有最大预期改进的配置。 这种方法背后的直觉是，每次OtterTune尝试配置时，它“更信任”来自该配置和类似配置的结果，并且其GP中这些数据点的方差减小。 预期的改进在采样点处接近于零，并且在它们之间增加（尽管可能少量）。 因此，它总是会尝试一种它认为最佳的配置或者它的配置

知之甚少。 随着时间的推移，随着未知区域数量的减少，GP模型预测的预期改善会下降。 这意味着它将探索其解决方案空间中良好配置周围的区域，以进一步优化它们。

       初始值的选择：

       OtterTune使用梯度下降来找到GP模型预测的表面上的局部最优值，使用一组称为初始化集的配置作为起始点。初始化集中有两种类型的配置：第一种是在当前调整会话中已完成的最佳性能配置，第二种是在每个参数的有效值范围内随机选择每个参数值的配置。具体地，最佳配置与随机配置的比率是1比10。在梯度下降的每次迭代期间，优化器在局部最优方向上一步一步走直到它收敛或已经达到其可以采取的最大步数的极限。 OtterTune从优化配置集中选择最大化潜在改进的配置，以便下次运行。这个搜索过程很快;在我们的实验中，OtterTune的调优管理器需要10-20秒才能完成每个观察期的梯度下降搜索。较长时间的搜索没有产生更好的结果。

        与我们在Otter-Tune中使用的其他基于回归的模型类似（参见Sects.5.1和6.1），我们采用预处理来确保特征是连续的并且具有大致相同的比例和范围。 我们使用虚拟变量对分类特征进行编码，并在将其作为输入传递给GP模型之前标准化所有数据。

       一旦OtterTune选择下一个配置，它就会返回此配置以及从运行此配置到客户端的预期改进。 DBA可以使用预期的改进计算来确定他们是否满足OtterTune迄今为止生成的最佳配置。

    6、随机采样

      为了叙述方便，我们不妨假设参数文件中有10个重要参数需要调优。我们将参数文件表示为：X=(x1,x2,…x10)。对应的数据库性能为Y。Y可以是吞吐量，延迟时间，也可以是用户自己定义的测量量。我们假设目标测量量是延迟时间。则我们需要做的是调整这10个数据库参数的值，使得数据库的延迟尽可能少。即找到合适的X，使Y尽可能小。一个好的参数文件会降低数据库的延迟，即X对应的Y越小，我们说X越好。最简单和直观的方法便是随机的进行尝试，即给这10个要调的参数最大和最小值，在这范围内随机地选择值进行尝试。显然这样随机的方法并不高效，可能需要试很多次才能得到好的参数文件。OtterTune也支持这种随机方法以在没有训练数据时收集数据。

     相比随机采样，还有一种更有效率的采样方法叫做拉丁超立方采样。比如在0到3之间随机找3个数，简单随机抽样可能找的三个数都在0到1之间。而拉丁超立方采样则在0到1间找一个数，1到2间找一个数，2到3间找一个数，更加分散。

     推到高维也是类似的情况。如下图是二维的情形，x1和x2取值都在0到1之间，用拉丁超立方采样来取5个样本点，先将x1和x2分成不同的范围，再取样本点使得每一行中只有一个样本点，每一列中也只有一个样本点。这样能避免多个样本点出现在相近的范围内，使其更加分散。

                                        

      对于OtterTune来说，简单随机采样尝试的参数文件可能更集中和相似，而拉丁超立方采样尝试的参数文件更分散和不同。显然后者能给我们更多的信息，因为尝试相似的参数文件很可能得到的数据库性能也相似，信息量少，而尝试很不同的参数文件能更快的找到效果好的一个。

     7、高斯过程回归 

      上述的采样方法并没有利用机器学习模型对参数文件的效果进行预测。

     1）当OtterTune没有数据来训练模型时，可以利用上述方法收集初始数据。

     2）当我们有足够的数据（X,Y）时，OtterTune训练机器学习模型进行回归，即估计出函数f：X→Y，使得对于参数文件X，用f（X）来估计数据库延迟Y的值。则问题变为寻找合适的X，使f（X）的值尽量小。这样我们在f上面做梯度下降即可找出合适的X。

     如下图所示，横坐标是两个参数——缓存大小和日志文件大小，纵坐标是数据库延迟（越低越好）：

                           

        OtterTune用回归模型估计出了f，即给定这两个参数值，估计出其对应的数据库延迟。接着用梯度下降找到合适的参数值使延迟尽可能低。 OtterTune用高斯过程回归来估计上述的函数f。用高斯回归的好处之一是它不仅能在给定X时估计对应的Y值，还能估计它的置信区间。这能恰当的刻画调参的情况：对于同样的参数文件X, 在数据库上多次跑相同的查询时，由于误差缘故，每次得到的数据库性能也可能不一样。比如同样的参数文件和查询语句，这次执行的数据库延迟是1.8秒，下次执行的延迟可能是2秒，但每次得到的延迟很大概率是相近的。高斯过程回归能估计出均值m（X）和标准差s（X），进而能求出置信区间。比如上述例子中，通过回归我们估计其延迟的均值是1.9秒，标准差是0.1秒，则其95%的概率在1.7秒和2.1秒之间。

     再来说说探索（exploration）和利用（exploitation）：

    1）探索即在数据点不多的未知区域探索新的点；

    2）利用即在数据点足够多的已知区域利用这些数据训练机器学习模型进行估计，再找出好的点。

     比如说我们已知10个数据点（X，Y），有9个点的X在0到1之间，有1个点的X在1到2之间。X在0到1之间的数据点较多，可以利用这些数据点进行回归来估计f：X->Y，再利用f来找到合适的X使估计的Y值尽量好，这个过程即为利用。而探索则是尝试未知区域新的点，如X在1到2间的点只有一个已知点，信息很少，很难估计f。我们在1到2间选一个X点进行尝试，虽然可能得到的效果不好，但能增加该区域内的信息量。当该区域内已知点足够多时便能利用回归找到好的点了。OtterTune推荐的过程中，既要探索新的区域，也要利用已知区域的数据进行推荐。即需要平衡探索和利用，否则可能会陷入局部最优而无法找到全局最优的点。比如一直利用已知区域的数据来推荐，虽然能找到这个区域最好的点，但未知区域可能有效果更好的点未被发现。如何很好的平衡探索和利用一直是个复杂的问题，既要求能尽量找到好的点，又要求用尽量少的次数找到这个点。而OtterTune采用的高斯过程回归能很好的解决这个问题。核心思想是当数据足够多时，我们利用这些数据推荐；而当缺少数据时，我们在点最少的区域进行探索，探索最未知的区域能给我们最大的信息量。

      以上利用了高斯过程回归的特性：它会估计出均值m（X）和标准差s（X），若X周围的数据不多，则它估计的标准差s（X）会偏大，直观的理解是若数据不多，则不确定性会大，体现在标准差偏大。反之，数据足够时，标准差会偏小，因为不确定性减少。而OtterTune用置信区间上界Upper Confidence Bound来平衡探索和利用。不妨假设我们需要找X使Y值尽可能大。则U（X） = m（X） + k*s（X）, 其中k > 0是可调的系数。我们只要找X使U（X）尽可能大即可。

      1）若U（X）大，则可能m（X）大，也可能s（X）大。

      2）若s（X）大，则说明X周围数据不多，OtterTune在探索未知区域新的点。

     3）若m（X）大，即估计的Y值均值大， 则OtterTune在利用已知数据找到效果好的点。公式中系数k影响着探索和利用的比例，k越大，越鼓励探索新的区域。

     8、有数据和没数据

      OtterTune用来训练模型的数据好坏很大程度上影响了其最终效果。只要有合适的训练数据，一般OtterTune前几次推荐的参数文件就能得到理想的效果。而当缺少训练数据（或数据集中），甚至没有任何之前的数据时，OtterTune又该如何处理?当OtterTune没有任何数据时，高斯过程回归也能有效的在尽量少的次数内找到好的参数文件。当数据少时，OtterTune倾向探索而非利用，而每次探索新的参数文件时都能尽量的增加信息量，从而减少探索的次数。这种方法比随机采样和拉丁超立方采样都要高效。同时OtterTune也可先用拉丁超立方采样选取少量的一些参数文件进行尝试作为初始数据，之后再用高斯过程回归进行推荐。其实在OtterTune之前，有系统iTuned[5]就用高斯过程回归在没有数据时推荐参数文件。而OtterTune的最大的改进是利用之前收集的数据进行推荐以大幅度减少尝试的次数和等待时间，提高推荐效果。想想看当OtterTune的一个服务端配置到云上，而多个客户端进行访问时，OtterTune会将所有用户尝试的参数文件和对应的性能数据存下来进行利用。这意味着用OtterTune的人越多，用的时间越长，它收集的训练数据越多，推荐效果越好。

     除此之外，OtterTune还利用Lasso回归来自动的选取需要调整的重要参数。数据库有成百上千的参数，而我们只要调其中重要的几个，需要调整哪些参数可以根据DBA的经验，同时OtterTune也利用机器学习将参数的重要性排序，从而选出最重要的几个参数。另外对于不同的工作负载，对应的最优参数文件也不同。如OLTP工作负载通常是很多个简单的查询（如insert，delete），而OLAP工作负载通常是几个复杂查询（通常有多个表的join）。对于OLAP和OLTP，他们需要调整的参数和最优的值都不相同。OtterTune现在的做法是用一些系统的统计量（如读/写的字节数）来刻画工作负载，在已有数据中找到和用户工作负载最相似的一个，然后用最相似的工作负载对应的数据进行推荐。

     9、深度强化学习

      在OtterTune最新的进展中，我们尝试了深度强化学习的方法来进行数据库调参，因为我们发现数据库调参的过程能很好的刻画成强化学习的问题。强化学习问题中有状态、动作，以及环境所给予的反馈。如下图所示，整个过程是在当前状态(st)和环境的反馈(rt)下做动作(at)，然后环境会产生下一状态(st+1)和反馈(rt+1)，再进行下一个动作(at+1)。

                                      

      数据库调参过程中，状态即是参数文件，动作即是调整某个参数的值，而反馈即是参数文件下数据库的性能。所以我们对于当前的参数文件，调整某个参数的值，而得到新的参数文件，对这个新的参数文件做测试得到对应的数据库性能，再根据性能的好坏继续调整参数的值。这样数据库调参的过程就被很好的刻画成强化学习的问题，而深度强化学习即是其中的状态或动作由神经网络来表示。我们用了Deep Deterministic Policy Gradient （DDPG）算法，主要是因为DDPG能允许动作可以在连续的区间上取值。对于调参来说，动作即是调整某个参数的值，比如调整内存容量，DDPG允许我们尝试128MB到16GB的任意值，这个区间是连续的。而很多别的算法只允许动作在离散区间上，比如只允许取几个值中的一个值。通过实现和优化DDPG，最终深度强化学习推荐出的参数文件与高斯过程回归推荐出的效果相似。但我们发现之前的高斯过程回归（GPR）更有优势，能用更少的时间和次数找到满意的参数文件。如下图中所示，我们跑了TPC-H基准中的一条查询（Query 13），OtterTune一次次的推荐参数文件直到其达到好的效果（即对应的数据库延迟变低）。 

              

      该图横坐标是推荐的次数，纵坐标是数据库的延迟，延迟越低越好。蓝线是深度强化学习，而黄线代表高斯过程回归模型。可见两个模型最终推荐出的文件效果相似，但高斯过程回归用了更少的次数便收敛，推荐出了好的参数文件。而深度强化学习需要尝试更多的次数才能达到类似效果。

    我们发现：

     1）DDPG算法模型有一些参数也需要调整，而这些参数对效果的影响很大。调整算法模型的参数也是个费时费力的过程。这样就陷入尴尬的局面，OtterTune是用来自动调整数据库参数的工具，而OtterTune自己算法模型的参数也需要调整。相比而言，GPR的模型参数可以自动的进行调整，从而实现OtterTune真正的自动化。 

     2）GPR能用Upper Confidence Bound更好的平衡探索（exploration）和利用（exploitation），相比DDPG更加高效。 这在没有或缺少数据的情况下，GPR能用更少的次数找到好的参数文件。

     3）DDPG是更加复杂的模型，其中还有神经网络，可解释性差。需要更多的数据和更长的时间来训练和收敛。虽然最后能达到和GPR一样的推荐效果，但往往需要更多的次数和更长的时间，意味着用户需要等更久才能得到满意的参数文件。

五、代码实现

         OtterTune 用 Python 编写。对于工作负载特征化和旋钮识别组件，运行时性能不是着重考虑的，所以我们用 scikit-learn实现对应的机器学习算法。这些算法运行在后台进程中，把新生成的数据吸收到知识库里。对于自动调优组件，机器学习算法就非常关键了。每次观察阶段完成后就需要运行，吸收新数据以便 OtterTune 挑选下一个旋钮来进行测试。由于需要考虑性能，我们用 TensorFlow来实现。为了收集 DBMS 的硬件、旋钮配置和运行时性能指标，我们把 OLTP-Bench 基准测试框架集成到 OtterTune 的控制器内。代码结构参见文章：https://blog.csdn.net/weixin_40449300/article/details/87881045

                                  

 

六、实验设计

         我们比较了 OtterTune 对 MySQL 和 Postgres 做出的最佳配置与如下配置方案进行了比较，以便评估：

• 默认： DBMS 初始配置
• 调优脚本： 一个开源调优建议工具做出的配置
• DBA： 人类 DBA 选择的配置
• RDS： 将亚马逊开发人员管理的 DBMS 的定制配置应用到相同的 EC2 实例类型。

        我们在亚马逊 EC2 竞价实例上执行了所有的实验。每个实验运行在两个实例上，分别是m4.large 和 m3.xlarge 类型：一个用于 OtterTune 控制器，一个用于目标 DBMS 部署。OtterTune 调优管理器和知识库部署在本地一台 20 核 128G 内存的服务器上。工作负载用的是 TPC-C，这是评估联机交易系统性能的工业标准。

     实验环境搭建参见文章：https://blog.csdn.net/weixin_40449300/article/details/87904128

七、评估

        我们给每个实验中的数据库 —— MySQL 和 Postgres —— 测量了延迟和吞吐量，下面的图表显示了结果。第一个图表显示了“第99百分位延迟”的数量，代表“最差情况下”完成一个事务的时长。第二个图表显示了吞吐量结果，以平均每秒执行的事务数来衡量。

       1、mysql实验结果

       

        OtterTune 生成的最佳配置与调优脚本和 RDS 的配置相比，OtterTune 让 MySQL 的延迟下降了大约 60%，吞吐量提升了 22% 到 35%。OtterTune 还生成了一份几乎跟 DBA 一样好的配置。在 TPC-C 负载下，只有几个 MySQL 的旋钮显著影响性能。OtterTune 和 DBA 的配置给这几个旋钮设置了很好的值。RDS 表现略逊一筹，因为给一个旋钮配置了欠佳的值。调优脚本表现最差，因为只修改一个旋钮。

        2、Postgres 实验结果

         

         在延迟方面，相比 Postgres 默认配置，OtterTune、调优工具、DBA 和 RDS 的配置获得了近似的提升。我们大概可以把这归于 OLTP-Bench 客户端和 DBMS 之间的网络开销。吞吐量方面，Postgres 在 OtterTune 的配置下比 DBA 和调优脚本要高 12%，比 RDS 要高 32%。

八、结束语        

         对于数据库来说，有很多部分都能尝试与机器学习结合。比如预测数据库一段时间的工作负载，如通过挖掘数据库的日志来做自动预警，再到更核心的部分，如学习数据库索引，甚至帮助优化器做查询优化。

       我们发现这个通用模型在业界的很多地方都有真实的应用，不仅能调优数据库的参数，还能够调优操作系统内核的参数，甚至可以尝试调优机器学习模型的参数。比如以下场景：

    1）某欧洲银行需要自动化调优数据库集群的参数以提高性能，减少人工成本。

    2）某大型云厂商需要在不影响性能的前提下尽量调低分配的资源（如内存）, 减少硬件成本。

    3）某纽约高频交易公司需要调优机器的操作系统参数以优化机器性能，减少延迟，从而增加利润。

      OtterTune专注的参数文件调优只是其中的一部分。由于OtterTune和数据库的交互只是一个参数文件，这使得该工具更加通用，理论上能适用于所有的数据库。当要调参一个新的数据库时，我们只需要给OtterTune该数据库的一些参数和统计量信息即可，不需要去改动这个数据库的任何代码。再者，OtterTune的通用框架也可以用于其他系统的调参，如我们尝试用OtterTune来调优操作系统的内核参数也取得了不错的效果。现在的OtterTune仍有要改进的地方：

     1）比如假定了硬件配置需要一样，而我们希望OtterTune能利用在不同的硬件配置上的数据来训练模型进行推荐。

     2）再比如现在OtterTune每次只推荐一个文件，当有多个相同机器时，我们希望一次推荐多个文件并行的去尝试，这样能加快推荐速度。

     另外还可以尝试与其他部分的机器学习方法结合，比如可以先用机器学习方法预测工作负载，再根据预测的工作负载提前调优参数文件。用机器学习来优化系统是最近很火很前沿的一个话题，无论是在工业界还是在学术界。

    全球最大数据库厂商Oracle如今的最大卖点便是autonomous  database[6] ，即自适应性数据库，利用机器学习来自动优化数据库来减少DBA的干预，要知道在美国雇一个资深的DBA是多么困难的一件事。Oracle投入大量的专家和资金来做这件事便证明了它的工业价值。学术上，一些ML和系统的大佬在前两年开了一个新的会议叫SysML[7]，专注于机器学习和系统的交叉领域。更不用说越来越多的相关论文，比如卡内基梅隆大学的OtterTune，再如MIT和谷歌开发的用神经网络学习数据库的索引[8]。

       OtterTune 将寻找 DBMS 配置旋钮的最优值这一过程自动化了。它通过重用之前的调优过程收集的训练数据，来调优新部署的 DBMS。因为 OtterTune 不需要生成初始化数据集来训练它的机器学习模型，调优时间得以大大减少。下一步会怎么样？ 为了顺应的越来越流行的 DBaaS （远程登录 DBMS 主机是不可能的），OtterTune 会很快能够自动探查目标 DBMS 的硬件能力，而不需要远程登录。

 

【参考文章】

       [1]   伯乐在线 - Panblack 翻译。译文：http://blog.jobbole.com/111486/

       [2]  https://github.com/cmu-db/ottertune

       [3]  Automatic Database Management System Tuning Through Large-scale Machine Learning.  Dana Van Aken, Andrew Pavlo, Geoffrey J. Gordon, Bohan Zhang.  SIGMOD 2017

       [4]  A Demonstration of the OtterTune Automatic Database Management System Tuning Service.  Bohan Zhang, Dana Van Aken, Justin Wang, Tao Dai, Shuli Jiang, Jacky Lao, Siyuan Sheng, Andrew Pavlo, Geoffrey J. Gordon. VLDB 2018

       [5]  Tuning Database Configuration Parameters with iTuned. Songyun Duan, Vamsidhar Thummala, Shivnath Babu. VLDB 2009

        [6]  https://www.oracle.com/database/what-is-autonomous-database.html

        [7]  https://www.sysml.cc/

        [8]  The Case for Learned Index Structures. Tim Kraska, Alex Beutel, Ed H. Chi, Jeffrey Dean, Neoklis Polyzotis. SIGMOD 2018

         [9]  http://learningsys.org/nips17/assets/slides/dean-nips17.pdf

        [11]  https://mp.weixin.qq.com/s/y8VIieK0LO37SjRRyPhtrw

        [12] https://blog.csdn.net/u013385018/article/details/84028360