OtterTune来了，DBA怎么办

https://blog.csdn.net/xiangzhihong8/article/details/72887476

最近AI的新闻特别多，席卷了围棋圈之后，成为了技术圈和媒体热捧的话题。

今天又一个产品借AI上头条了 - OtterTune ，一个数据库参数调优的产品，借助机器学习的技术，生成最优的数据库参数。

虽然OtterTune只是一个结合了机器学习(建模、调参数、获取系统反应、学习、产生最优参数；典型的临床学)，可用于参数优化的小软件(实际上DBA的工作远不止这些)，但是已经代表了一个方向，未来越来越多的活（枯燥的活）可能会被AI取代。

那么如何看待OtterTune呢？DBA真的要失业了吗？

混沌初开（因果学） VS 临床（经验学）

凡事都是有因果，从因可以推理出果。《易经》：“易有太极，是生两仪，两仪生四象，四象生八卦。”

临床医学（Clinical medicine）根据病人的临床表现，从整体出发结合研究疾病的病因、发病机理和病理过程，进而确定诊断，通过预防和治疗以最大程度上减弱疾病、减轻病人痛苦、恢复病人健康、保护劳动力。

临床学是经验的积累，需要总结非常多的案例，观察人体对药物反应，总结经验，提炼成学术。是一种反复试错总结的过程。

OtterTune目前更像是临床学，因为一开始它也不知道哪个参数这样设置会怎么样，那样设置又会怎么样？是在无法知道因果的情况下的一种经验科学。只有在积累了足够多的经验时，才能发挥更好的效果。

所以人类在经验科学方面的发展是比较缓慢的，因为人类大脑对数据的处理能力远不能和计算机相比。计算机推动了经验科学的发展。

一些靠经验吃饭的工作，往往是越老越吃香，不过将来也是最容易被AI替代的。个人认为DBA可以考虑转行，把经验转化为产品。

人类DBA vs 机器DBA vs 云数据库

首先，我们看看DBA的工作有哪些？DBA的工作实际上都是围绕数据库展开，包含但不限于这些工作：

1. 数据库、主机、操作系统、交换机、存储选型，预算，架构设计，部署，参数优化；

2. 数据库备份、恢复、容灾、HA、新老硬件更替；

3. 数据库SQL审计、SQL优化、异常问题诊断、性能优化、巡检、健康诊断；

4. 数据库扩容、缩容、迁移；

5. 数据库版本升级、补丁修复；

6. 数据库开发规范、管理规范的指定和执行；

7. 数据库监控、专家、审核系统的开发与建立；

8. 数据库代码覆盖率测试、功能测试、建模、压测、profiling；

9. 数据库读写分离、sharding、MPP系统的构建；

10. 数据库开发、管理、设计、规范培训；

11. 数据库在垂直行业应用的架构设计（例如OLAP、GIS、时序、流计算、图式搜索、文本搜索、图搜索、化学、基因、等）；

12. 异构数据、同构数据源的数据同步、ETL；

13. 数据库与其他系统的联动；

14. 数据库云产品化、DOCKER化、虚拟化等相关的工作；

15. 数据库内核的研究、BUG上报、结合业务提出对内核的功能、性能提升等需求；

16. 关注不同数据库产品的roadmap、优缺点、适应场景、不适应场景；

17. 关注数据库行业的发展，进行预研性研究，储备技术；

18. 与技术社区保持紧密联系，从参与、了解同行、到分享，从商业产品到开源社区；

19. 技术为业务服务，从本质触发，深入行业，了解业务、行业的发展，抓住核心点，更好的服务于业务。

可以看到DBA的工作还是有蛮多的，一个好的人类DBA从理论基础（因果学）到实际工作经验（临床学），都有非常多的积累。绝对不是一个OtterTune工具可以取代的。OtterTune也只是针对TPC-C，tpc-h场景进行了大量的模拟测试，针对性的输出最优参数而已。

AI要完全取代这些工作，还有非常漫长的过程。就好像现在很多汽车支持的辅助驾驶，也算是AI应用的一种初级阶段，目前辅助驾驶还有很多限制条件，比如必须要有车道线，可能到乡道就不支持了，需要人工介入。目前OtterTune是一个辅助DBA的工具，还没有达到取代DBA的程度。

未来很长一段时间，AI和人类应该是相辅相成的灰色地带。

相比而言，云产品（例如RDS）才真正在逐渐替代大部分DBA的工作。

云厂商不仅提供数据库产品，用户不需要关心架构、部署、备份、容灾、HA、版本升级、读写分离、sharding、内核BUG等问题。同时还提供了增值的服务，比如专家诊断系统（实际上就包含了OtterTune的功能）。更重要的是云厂商提供的数据库还可以和云上的其他产品紧密结合，例如阿里云PostgreSQL，HybridDB for PostgreSQL，可以与阿里云的OSS结合，进行数据的共享，备份，冷热分离。还可以与云BI系统进行联动，用户省去了部署这么多系统的麻烦。

机器学习在数据库中的一些应用

PostgreSQL有多重接口可以与机器学习结合。

PL接口

PostgreSQL支持plpython存储过程语言，用户可以直接在PostgreSQL中编写python代码，让数据和代码紧密的结合，提升计算效率。

同时支持plcuda, plR等接口。

下面这篇文章详细描述了PostgreSQL在计算与数据存储方面的多重融合方法。计算与数据融合，减少了数据传输的部分，提升了运行效率。大家想一想未来数据爆炸，如果计算还是和存储分离，会是一个什么景象？不具备计算能力的存储不是好存储。

《数据库任督二脉 - 数据与计算的生态融合》

madlib库与pivotalR

Madlib库是一个SQL接口的开源的机器学习库，将机器学习的通用算法转换成了SQL UDF，通过调用函数可以支持通用的学习算法，将数据库和机器学习很好的融合在一起，支持PostgreSQL, Greenplum。架构如下：

pivotalR则是R的一个机器学习包，通过这个包可以在R的代码中连接PostgreSQL、Greenplum数据库，调用pivotalR的R function，会自动连接数据库，并转成调用madlib的SQL，在数据库中执行SQL，返回结果给R端。这样的话数据不需要加载到R端，而是在数据库层面完成计算。如果数据库是Greenplum，则是并行的计算。

在这篇文章中有详细的描述，如何在PostgreSQL中玩AI。

《想挑战AlphaGO吗？先和PostgreSQL玩一玩?? PostgreSQL与人工智能(AI)》

rdkit

Rdkit是一个化学垂直行业的数据处理函数库、以及化学行业的机器学习库的包。

rdkit的数据存储选用的就是PostgreSQL，因为PG支持类型、索引、函数、OP的扩展，化学行业选择它就像GIS行业选择它一样，看中它的扩展性，在PostgreSQL实现了一套化学行业的数据类型、索引类型、操作符、函数、聚合函数、机器学习函数等。

rdkit还能与scikit-learn库结合使用，例如下面是一个随机森林的例子

from rdkit.Chem.Draw import SimilarityMaps    

# helper function

def getProba(fp, predictionFunction):

  return predictionFunction((fp,))[0][1]    

m5 = Chem.MolFromSmiles('c1ccccc1O')

fig, maxweight = SimilarityMaps.GetSimilarityMapForModel(m5, SimilarityMaps.GetMorganFingerprint, lambda x: getProba(x, rf.predict_proba))

机器学习在PostgreSQL里的其他应用

在PostgreSQL社区，也不乏看到机器学习的例子，例如

1. zson数据类型，是一个兼容jsonb的数据类型，zson通过对jsonb的数据进行训练，得到字典，将JSONB中的内容翻译成字典存储，优化数据存储的压缩比，提高存储效率，同时降低buffer的使用。

《JSONB 压缩版本 ZSON》

2. aqo，通过机器学习，动态调整SQL语句的执行计划。

《数据库优化器原理 - 如何治疗选择综合症》

人类 vs 机器

当AI真的发展到可以取代大多数人类的工作的时候，人们干什么去呢？比如多陪陪家人，感受大自然，从事一些自己感兴趣的事情，修生养息，天人合一。

但是在此前，我们还是来谈一下转行搞AI，把经验转化为产品的事情，个人认为这是一种情结，一种把种子散播出去的情结，就像各行各业的宗师，比如太极宗师。

转行搞AI，个人认为：

至少要懂得一门相关的编程语言，例如R,PYTHON；至少需要有一定的数学、统计学背景；至少需要对垂直行业有深刻的认识；最后就是选择一个合适的平台；

看完这篇文档，你肯定知道该如何选择。

《数据库任督二脉 - 数据与计算的生态融合》

版权声明：本文为博主原创文章，未经博主允许不得转载。https://blog.csdn.net/xiangzhihong8/article/details/72887476概述最近几年，特别是随着云计算的发展，出现了行业向后重叠和推动的情况。数据库龙头企业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 并不需要在每次生成操作当中再次利用初始数据集进行机器学习模型训练，因此整个调节时间周期得到大幅缩减。--------------------- 作者：code_xzh 来源：CSDN 原文：https://blog.csdn.net/xiangzhihong8/article/details/72887476 版权声明：本文为博主原创文章，转载请附上博文链接！

经历了NoSQL，NewSQL时代正在到来，融合OLTP和OLAP的HTAP发展迅速。

过去几年，起源于Google三大基础设施论文（GFS，Mapreduce和Bigtable），诞生了开源的Hadoop系统，通常用作公司对于海量非结构化数据和结构化数据的存储及分析，得益于开源社区的贡献和各大互联网公司的应用，Hadoop生态系统迅速发展，已经成为了OLAP方面对海量数据处理的事实标准，尽管Hadoop生态系统已经日趋成熟并被业界广泛认可，然而作为一个离线数据分析系统，Hadoop无法实时对数据的分析提供结果，因此通常用作业务数据库之外构建一个新的数据仓库，并且通常仅提供OLAP也就是数据分析方面的支撑，这就要求在传统的数据库和Hadoop之间构建一套ETL系统，用作两者之间数据的导入导出，这就使得数据库和数据仓库的管理更加的复杂。

Hadoop系统作为一个庞大的开源系统，往往需要很多组件才能满足业务的需求，所以我通常认为基于Hadoop构建数据仓库满足OLAP的需求目前仍存很多不足，而NoSQL数据库的不断发展，也为很多大数据量业务的发展带来了福音。

例如可以通过Hbase来管理近千亿的url数据，并且NoSQL数据库通常是可以动态扩容并且支持容错，但是NoSQL系统的缺点也非常的明显，例如应用场景相对简单，通常无法兼容传统的sql语句，多表关联以及事物等需求也通常无法满足。对于开发人员还需要重新学习NoSQL的API和使用方式，带来了额外的代价。

基于上述原因，出现了融合OLTP和OLAP的一种提法HTAP，意味着可以通过一个数据库系统同时满足事务性需求和分析型需求，而最具代表性的就是Google的Spanner+F1的论文，产生了一批NewSQL系统。

例如CockroachDB和国内PingCAP团队开发的TiDB，以TiDB为例，TiDB采用Raft实现分布式协议，并且完全兼容MySQL的客户端，这对笔者本人也非常有吸引力，即可以用熟悉的MySQL的接口，又不需要对数据库进行分库分表，既实现了分布式，又减轻了用户的学习成本，对于企业来讲，可以通过构建一套分布式数据库系统，同时满足事务性和分析型需求，减轻系统复杂性的同时也提高了效率。

在这里向TiDB团队致敬，在数据库领域作出了世界级的开源项目，可以说是具备里程碑的意义。HTAP将成为未来的数据库的主流发展趋势。

三、时序数据库正在崛起

物联网发展势头迅猛，互联网和传统公司也争相布局，随着物联网的发展，传感器等产生了大量的数据，而这些数据往往都是时间顺序，在其他一些应用场景，例如金融领域的，股票交易，汇率等以及Devops的监控数据，都是属于时序数据。

基于这些场景产生了时序数据库的概念，时序数据库可以对时间属性进行特殊的索引，实现数据的快速查询以及更高的压缩，例如InfluxDB项目，InfluxDB是一个使用Go语言开发的分布式时序、时间和指标数据库，无需外部依赖。特别适合处理和分析资源监控数据。

笔者在物联网项目已经尝试使用了InfluxDB，用于存储大型中央空调设备产生的数据，目前项目已经稳定运行半年，与传统DBMS相比，InflluxDB的存储空间减少了近70%，存储和查询效率也有大幅度提升，并且通过InfluxDB集成的聚合函数和连续查询功能，可以自动生成数据的日报表、月报表、年报表，极大减轻了开发成本和系统复杂度。

同样，国内由陶建辉领衔的涛思数据(TAOS Data)团队也正在做时序数据库产品TDengine，目前已经开放测试，希望更多的国内团队做出属于我们自己的优秀数据库产品。

四、结语

数据库作为IT技术架构的核心，新技术层出不穷，随着物联网及人工智能时代的到来，数据库技术迎来高速发展期，DBMS与AI的结合，HTAP以及时序数据库将解决企业海量数据增长带来的各种需求及问题。