12月2日，Oracle在其官网正式推出“MySQL Database Service with Analytics Engine”。作为MySQL产品的一个重大增强，这一特性颇引人注目。抽空做了个简单了解，各位从中可窥其一二。（本文部分资料、插图来自Oracle官方网站）

MySQL，作为最为流行的一款开源数据库，已经得到非常广泛地使用。从最新的db-engines指数可以看出，其在数据库领域中占据了重要的位置。

但作为一款如此流行的数据库产品，其存在一个明显的短板就是数据分析。相信MySQL使用者都有这种感觉，在大规模数据情况下MySQL有些力不从心。尽管其内核也在不断加强这方面的能力（如最新8.0支持hash join、直方图等），但相较于其他数据库仍然存在一定劣势。其核心在于MySQL原生是为OLTP场景设计的，并没有考虑OLAP场景。

虽然也有一些厂商通过扩展其存储引擎，增强其数据分析能力，但总体来讲还是不尽如人意。于是，通常的一种选择就是在数据分析时，不得不将数据迁移到另一种数据库/大数据架构中。通过后者，去完成数据分析工作。在这一过程中，需要开发者自己定义ETL逻辑（可能基于日志解析或逻辑数据抽取），完成数据迁移。同时，在运行中需时刻关注数据同步，保证数据有效性。在使用上，还需编写单独的语句（异构数据源的语句），来完成数据分析动作。

整个这一过程，无疑对用户来说具有一定的使用门槛，且需要花费额外的精力去解决这一问题。相信Oracle原厂也是看到这一问题，因而推出了MySQL Analytics Engine。

MySQL Analytics Engine（简称MAE），笼统来说是一款内置的分析引擎。通过它与MySQL Database的组合，可以使得数据库管理员和应用程序开发人员能够直接将MySQL数据库作为OLTP和OLAP工作负载的统一服务。其提供的“MySQL Database Service with Analytics Engine”，是由一个MySQL DB实例和多个分析节点组成。当分析功能被启用时，分析服务将被安装在DB实例上，其负责集群管理、数据加载、查询执行等。从用户角度来看，可以通过标准的MySQL JDBC/ODBC Connector来连接使用。下面我们详细展开看看。

首先从整体使用来看，对外提供统一的MySQL Database Service。用户仍然是通过传统的方式去使用它，无论是OLTP还是OLAP场景。在这个服务的内部，是包括了传统的OLTP引擎和新的Analytics引擎。在数据上，也是存在两份。前者仍然保存在例如InnoDB这样的存储引擎之中，后者则保存在一组节点构成集群的内存之中。正常事务操作带来的数据变化，会透明地传播到后面的分析集群中，以加速分析处理。这样就使得客户可以在单个数据库平台上同时运行OLTP和OLAP工作负载。简言之，就是两个计算引擎、两份数据存储。

MAE的核心工作思想就是“化大为小”，通过分区机制，将数据打散后利用独立的CPU资源进行处理。处理后的结果统一返回。

在MAE内部，由多个分析节点组成。其具体节点数量，可由MySQL分析引擎提供的自动配置顾问自动获得。在节点中，数据以一种混合列压缩的格式存储。这有助于向量化处理，从而获得非常好的查询性能。数据在内存中运行之前被编码和压缩。这种压缩和优化的内存使用，对于数值和字符串数据尤为显著，可提高性能并减少内存占用，从而为客户降低成本。同时在每个节点中使用并行操作技术，这为分析提供了高缓存命中率，并提供良好的节点间可伸缩性。集群内的每个分析节点和节点内的每个核心都可以并行处理分区数据，包括并行扫描、连接、分组、聚合和top-k处理。

MySQL分析引擎为分布式内存分析处理实现了最新的算法。通过使用向量化的构建和探测连接内核，可以快速处理分区内的连接。通过使用异步批处理I/O，优化了分析节点之间的网络通信。算法的设计是为了使计算时间与跨节点的数据通信重叠，这有助于实现良好的可伸缩性。

MySQL分析引擎与MySQL数据库服务的集成为企业的所有OLTP和分析需求提供了一个单一的数据管理平台。MySQL分析引擎被设计成一个MySQL可插拔存储引擎，它完全屏蔽了存储层的所有底层实现细节，不让最终用户看到。用户和应用程序通过集群中的MySQL数据库节点与MySQL分析交互。用户通过标准工具和基于标准的ODBC/JDBC连接器连接到MySQL分析引擎。

MySQL分析引擎支持与MySQL相同的ANSI SQL标准和ACID属性，并支持不同的数据类型。这使得现有的应用程序无需对其应用程序进行任何更改就可以利用MySQL分析引擎，从而实现简单快速的集成。一旦用户向MySQL数据库提交查询，MySQL查询优化器就会透明地决定是否将查询卸载到分析集群以加速执行。这是基于MySQL分析引擎是否支持查询中引用的所有操作符和函数并且使用分析引擎处理查询的估计时间比在MySQL中更少时，查询将被下推到分析节点进行处理。处理之后，结果被发送回MySQL数据库节点并返回给用户。

由于MySQL分析引擎是一个内存处理引擎，数据被持久化到MySQL InnoDB存储引擎中。对表的任何更新都会自动实时地传播到分析节点的内存中。这使得后续查询始终能够访问最新的数据。这是通过一个轻量级的更改传播算法在后台完成的，该算法可以跟上MySQL的数据更新率。同步原理未说明？

从产品角度来看，MySQL Analytics Engine是一种云原生服务，专门在Oracle云基础设施中提供，为分析工作负载提供了令人信服的性能和成本。使用MySQL数据库管理企业数据的组织现在可以使用MySQL分析引擎运行分析查询，性能显著提高，成本更低，不需要ETL，并且支持实时分析。该服务可以只部署在云中，也可以部署在混合环境中，它简化了事务和分析应用程序的管理。从其推出产品上，可归纳为以下几个理念：

这一产品最核心价值点就是统一处理场景。之前MySQL的在处理混合业务场景是不得不使用下面方式（如下图）：

通过引入MAE，增强MySQL能力，达到统一效果。

第二个价值点在于，不仅仅是统一平台，而且使用同样的交互方式。原有的逻辑，不需要做任何的改变。无论是前端的事务交易场景，还是后端的数据可视化分析，均不需要做改变。这无疑对用户的吸引力很大，可以有效保护用户的已有软件资产。

对用户来说，不在需要关心数据同步的细节，不需要编写额外的ETL作业。这将大大减少用户的负担。

在MAE之前，用户如果想解决数据分析问题，无外乎两种。要么在库内解决，要么在库外解决。在库内解决的话，需要对MySQL做大量的优化工作或者采取针对分析场景的存储引擎，这些都带来了优化的工作量。对于库外方案同样如此，用户需要自己完成优化工作。

而使用MAE则不需要顾虑这点。其利用了Oracle实验室开发的自动机器学习(AutoML)功能来自动化服务的各个方面。由于这种自动化是基于机器学习的，系统可以智能地预测各种场景并采取行动，包括自动估算工作负载所需的分析节点数量。

当服务启动时，需要将运行分析查询的数据库表加载到MySQL分析集群内存中。所需集群的大小取决于加载所需的表和列，以及此数据在内存中实现的压缩。在传统的配置中，用户需要猜测集群的大小。由于空间限制，低估会导致数据加载或查询执行失败。高估会导致不必要资源的额外成本。因此，用户会不断迭代，直到确定正确的集群大小，当更新表时，这种大小估计就会变得不准确。而MAE则可自动完成上述过程。

MAE作为一种分布式、可伸缩、内存型、混合列式查询引擎，其通过内存中的矢量化处理及大规模节点间和节点内并行处理来极速性能。同时查询处理已针对Oracle云基础设施做了优化，包括节点间网络带宽优化等。通过上述能力，MAE提供了强大的分析能力。下面是针对其主要竞品的性能对比。

使用带有分析引擎的MySQL数据库服务的成本取决于配置的分析节点的数量。分析集群的大小取决于数据集的大小和工作负载的特性。一个分析节点可以容纳大约400GB的数据。当客户使用Analytics Engine迁移到MySQL数据库服务时，他们的成本有望大幅降低。与Amazon Aurora和Redshift相比，MySQL分析引擎的成本是其成本的1/3。

MAE目前在一个集群中支持最多24个分析节点（上千个Core），处理能力约为10 TB的分析数据。10TB是在给定时刻可以填充到分析节点内存中的大约数据量。MySQL数据库中存储的数据量没有限制，客户可以选择从MySQL数据库模式中加载哪些表或列到分析节点的内存中。如果查询不再需要这些表，用户可以从内存中删除这些表，为其他数据腾出空间。

MAE将大量细节隐藏在后面，对于前端客户来讲使用非常简单。只需要根据推荐大小配置分析集群、配置预加速查询的对象、手工完成第一次加载。后面即可享受到分析集群带来的加速能力。

通过查看执行计划，可以直观看出是否使用了分析集群（下图中的Using secondary engine RAPID）

此外，针对混合云场景（即无法将数据部署到云端的客户），可以利用MySQL复制将本地MySQL数据复制到MySQL分析引擎，同样不需要ETL。目前MAE仅在Oracle Cloud Infrastructure (OCI) Gen 2 hardware 平台提供。

MAE的出现，很好地弥补了MySQL原生在数据分析场景的短板。相信，这一特性将更加扩大MySQL的使用范围，为其在更大规模、更为重要的企业化应用铺平道路。比较遗憾的是，MAE目前仅能在OCI中使用，目前国内的广大线下用户还无法使用。