对话 ｜ PolarDB-MySQL 云原生HTAP解读
姜帅（云壤）
阿里云数据库高级产品专家，具备多年云计算数据库相关产品经验，负责PolarDB-MySQL的产品管理、方案设计和特性规划工作。
王剑英（北楼）
阿里云数据库高级技术专家，PolarDB HTAP以及PolarDB X-Engine存储引擎的研发负责人。
刘宗喜（道奇）
阿里云数据库解决方案架构师，具备多年的数仓、数据中台实践经验，主要负责泛互联网行业的客户数据库上云，架构优化，诊断调优等方面的工作。
云壤：PolarDB—MySQL是OLTP 原生的 MySQL 数据库，而 IMCI 的上线使其具备了 in memory列存加持的HTAP 的能力。IMCI 全称为 In-Memory Column Index(内存中的列存索引)，它是业内独有的 HTAP 创新技术，也称为原生 HTAP。IMCI 使 PolarDB MySQL 具备了一体化实时事务处理和实时数据分析的能力，使分析业务相比于传统方式有了百倍加速，同时可以百分百兼容 MySQL 生态，实现一体化简单运维。
Q
HTAP 的概念产品形式诞生于十几年以前，有非常多数据库产品都称为 HTAP 数据库。那么，到底什么是真正的HTAP？其特点是什么？
Gartner 对 HTAP 的定义如下：HTAP 通过内存计算来实现，它可以使分析业务与事务业务共享同一份数据，通过消除数据在数据库和数据仓库之间的数据迁移体系架构，可以对实时事务数据进行实时分析和态势感知，而不只是对数据进行事后分析。
首先，是“同一个”数据库系统，不是两个数据系统拼接；其次，它使用了非常关键的技术——内存计算；第三，“同一份”数据，消除了不同数据库之间的数据迁移工作和时延；第四，可以同时支持 OLTP 和 OLAP 业务负载。同时具备以上四个特点的数据库，可以称之为 HTAP 数据库。
Q
那么，客户在使用数据库过程中，存在什么样的痛点？是什么样需求在驱动 HTAP 发展？
道奇：关系型数据库诞生后，在数据库和数据量较小的时候， TP 类请求与 AP 类请求往往是在同一个数据库实例上处理的。随着业务发展，数据量慢慢变大，AP 类的查询性能逐步降低，且愈发消耗资源。
在业务高峰期， AP 类业务可能会影响到 TP 类业务。因此，很多客户会在原有的基础上引入独立 AP 数据库，再通过一些同步工具将 TP 数据同步到 AP 数据库，在 AP 数据库内完成业务数据分析。此方案的优势是， AP数据库性能较好，同时能与 TP 数据库分离，所以业务高峰时 AP 类业务不会影响 TP 类业务。
部分客户为了整体架构更稳定，还会在源和目标之间引入消息队列，做系统解耦，可以起到缓冲的作用。不过此方案也有些问题：首先系统会更复杂，很难保证其稳定性；数据同步链路更长，工具本身的稳定性以及它对源库 DDL 的支持不完善，经常出现数据同步链路中断，影响下游业务，比如下游的财务分析报表等，是比较突出的痛点；由于采用了同步工具将源库数据同步到目标库，如果源库写入并发特别高或存在大事务，消息队列往往会积压很多消息，数据延迟不可控。再者，引入 AP 数据库后开发语言与原业务不一致，会产生额外的学习和运营成本；此方案成本也较高，同步链路与消息队列都需要额外的资源成本。
总而言之，通过同步工具 + 消息队列 + 独立 AP 数据库的方案，在稳定性、实时性以及管理成本上也存在诸多问题。客户更期待一个生态兼容性更好，架构更简单，数据延迟更低，更简单易用的 HTAP 数据库解决方案。
Q
面对客户使用过程中的诸多痛点， HTAP 技术如何解决这些问题？
北楼：最开始的时候 MySQL 是面向 TP 系统的。在MySQL诞生之初，其所运行的服务器规格都比较低，比如服务器 CPU 可能只支持单线程或者两个线程同时运行，运行内存只有几兆到几百兆，而IO因为使用HDD机械磁盘只有几十IOPS，这在数据量很小的时候，运行事务查询和分析查询都能胜任的。
在上世纪 90 年代到 2000 年，互联网开始爆发，数据库需要处理的数据量也急剧增长。数据增多的同时，现有数据库上除运行 TP 业务，也会同时运行分析性查询请求，其特征为单请求需要同时扫描几十万甚上百万行数据。一个大 AP 查询执行时间很长，消耗大量 CPU 时间片和IO资源。同时因为服务器 IO能力较弱，IO 打满也进而影响 TP 负载的处理速度。
而传统 TP系统存储引擎一般是行式存储，对 TP 业务负载较友好。但是在分析型业务场景下，如典型的销售额统计场景，销售订单表可能有上百列，对金额列做SUM实时聚合时需要将每一行的所有列都从磁盘读取上来进行处理，其IO 效率和计算效率都是非常低的。
在同时期，学术界也在研究按列存储的技术，即将关系表中一行数据的每一列单独存储在一起。针对列式存储做数据分析做查询时，比如实时统计销售额，只需读取并处理销售额这一列，执行效率非常高。
此外，CPU 执行效率方面，行存系统查询时，每一次扫描一行需要将所有列都读取出来，但分析查询只会对其中部分列做运算或聚合，其余的列会对 CPU Cache命中率造成干扰。而如果是按列存储，分析时只需读取出需要查询的列，CPU Cache中存储的也全都是需要分析的列，能够大幅提升 Cache 命中率，此时运算性能相较于行式存储能够提升十倍至百倍。
当时业内研究结论是认为 TP 系统和 AP 系统需要向不同方向做优化， TP 系统向高事务并发、低处理延时发展，而 AP 系统向高IO吞吐和大量数据扫描方向优化。两项技术各自发展迭代，最终诞生出不同的产品来解决这两个截然不同的问题。
这样实际使用时，不同业务需求在不同系统上运行，同时需要维护一个同步链路连接TP系统和AP系统。这样的部署架构虽然可以解决业务问题，但也会带来一些麻烦，比如数据同步延迟、数据不一致，以及上下生态不同带来的业务开发困难。
在2014年左右，数个领先的商业数据库系统Oracle/SQL Server/DB2先后在那一年推出HTAP功能支持。当时的硬件发展趋势上看，主流服务器内存容量从之前的几十GB提升到几百GB甚至TB级。另一方面， SSD 固态硬盘开始大规模普及，能够提供非常高的 IOPS 。这一硬件基础能力的提升，为解决 TP 系统和 AP 系统存储结构差异导致的数据同步延迟问题做好了准备。
传统上，在 TP 系统里更新一行数据的事务时延是毫秒级别的，而列式存储因为索引较稀疏，其更新一列数据可能就需要数十毫秒的时间，更新一行的延迟比行存引擎高一个数量级。因此，如果将行存和列存维护在一套引擎内部，会导致 TP 请求的处理延迟非常大。而有了更大内存之后，列存数据（或者索引）可以全部放置于于内存里，而内存更新速度是纳秒级别的。在TP请求行存更新毫秒级的时延基础上，列式存储增加的每一列几微秒级别的时间，对 TP 事务整体延时不会带来显著的增加。即更多内存、更快 SSD 可以在同时维护行列数据一致性的同时保证 TP 系统的低延时。
另一方面，TP请求与 AP 请求的资源使用特征也很不同，AP 类型请求顺序扫描非常多的数据并做运算，会同时在 CPU 和 IO 资源上对 TP类型请求的处理带来干扰。但是有了更快 SSD 以及更多 CPU 核心之后，系统可使用的CPU/IO资源增加，在上述情况下AP请求不会对 TP 请求产生过大的干扰，这意味着硬件能力的准备达到了 HTAP 系统诞生的需求。
在同时期，阿里云的PolarDB刚诞生之际，团队花了很多精力基于云原生技术比如存储计算分离等对数据库进行重构，没有精力对HTAP技术方向做过多投入。且早期PolarDB的客户主要为互联网企业客户，也对HTAP有没有过多诉求，他们天然的适应TP/AP分离的架构。
而在近几年，产业互联网崛起，新上阿里云PolarDB的很大一部分都是传统企业，他们的业务自诞生起，其使用的 SQL Server/Oracle等商业数据库原始就具有特别强的 HTAP 能力。因而他们的数据库业务迁移上云之后，对 HTAP 有着天然要求。同时,因为业务本身比较复杂，改造成本非常高，所以企业期望能够以一体化、透明的方式迁到云数据库。这也意味着云原生 HTAP 技术是阿里云数据库团队必需解决的问题。
云壤：为什么最近互联网数据库都在谈论 HTAP？首先，HTAP 技术趋于成熟；其次，客户逐渐上云，对 HTAP 的需求越来越强烈。PolarDB MySQL 最新发布的特性 IMCI 得到很多人的关注，它是百分百云原生的 HTAP 技术。
IMCI 相比于其他友商的 HTAP 技术有如下三个优点：
可以实现业内独有的无缝兼容 MySQL 生态的一站式应用体验，这也是 IMCI 最大的特点。对于客户而言，无需进行任何业务改造，无需做语法调整，也无需做数据迁移，即可在原先 MySQL 数据库的基础之上，无缝叠加列存加持的分析能力。
IMCI 的性能相比于传统 MySQL 行存，最高可达 400 倍加速，同时可以达到业内主流专业 OLAP 系统的能力。
相比于传统 OLAP 加 OLTP 搭积木的形式，它可以为客户节约更多成本。
一站式应用体验，指可以无缝兼容 MySQL 。开发 IMCI 的所有代码都构建在 PolarDB MySQL 原生代码基础之上，而不是使用第三方 OLAP 系统来包装。其最大价值在于：客户在使用过程中无须做任何业务调整。
如果客户希望开启 IMCI 能力，只需在 create table 语句的 comment 字段里增加一个columnar=1字符串，对应表即能生成一套列存，相当于创建了列存索引，无须更改任何其他语法。此外，字符串也可以加在列维度，对应列会生成列索引，按照列形式来进行存储。同理，还可以通过 DDL 语句对存列索引做删除或修改。其最大好处在于，当某些业务只需针对部分固定目标数据做分析，则可以只将目标列、目标表变为列式存储，最大化节约资源。
与此同时，客户无需指定 SQL 语句的处理方式导流，IMCI 为客户提供了统一入口和统一 endpoints 。系统会自动处理客户所有 SQL 语句，通过解析器优化来判断 SQL 语句的cost是多少，扫描行数是多少，扫描函数是什么，其特点是 OLTP 还是 OLAP 等。完成判断之后，会将相关 SQL 语句引导到对应引擎实现加速。
IMCI 能够支持大部分 MySQL 原生算子或函数，如果是非常生僻或少见的函数、算子，可能存在不支持的情况，但此时也能够将 SQL 回退到行存上，再进行处理。保障了对MySQL的100%兼容。
综上，对于客户而言，只需要使用 DDL 语句加上列存，无须任何其他操作，即可体验 IMCI 的优越性能。
IMCI 第二大特点是性能优化。开发团队针对 tpc-h 场景做了非常丰富的测试。将 IMCI 与原生行存进行对比测试，结果显示 IMCI 处理可以实现 22 条query 语句全部加速，加速程度从 10 倍到数百倍不等，最高可达 400 倍加速。
将 IMCI 与现有专业 OLAP 系统 ClickHouse 进行对比，结果显示在 80% 测试场景下， query 语句相比于 ClickHouse 有性能加速，尤其是关联查询方面的语句，可达数倍加速。
IMCI 第三大特点是可以为客户降低 TCO。传统方式下，解决 OLTP 和 OLAP 需求需要通过两套系统，存在 OLAP 采购成本、计算和存储以及同步链路成本、消息队列成本。
而使用 IMCI 后，客户只需两部分成本：第一部分为新增加只读节点，即 HTAP 里 OLAP 的计算费用；第二部分为生成的列索引需要占用存储空间，但可以实现高倍压缩。相比于两套系统的方式，至少节省了中间链路以及消息队列成本。
除了采购成本，IMCI 最大的优势在于维护成本非常低。它提供了一站式应用体验，原生 MySQL 兼容，原生 HTAP ，通过列索引的方式实现了行存和列存数据同步，客户无需对其进行独立维护。
Q
那么，为什么我们能够做到原生 HTAP ？为什么能够做到成本很低？为什么能够实现相比于传统方式近百倍的加速？
北楼：IMCI 产品主要面向实时事务处理叠加实时数据分析领域，因此在HTAP一体化实时数据分析领域有几个核心问题需要解决：
数据分析引擎执行效率问题：如何在保证OLTP的功能和性能的前提下，让AP分析性能达到与专用OLAP系统相同的速度？
一体化部署架构：如何在客户的业务代码不做任何修改或部署架构的变更的前提下，使用的OLTP数据库同时提供户实时数据分析能力？
访问体验问题：即如何解决 SQL 语法兼容性、业务访问异构系统带来的程序维护复杂性等问题？
第一个执行效率问题，传统TP系统运行AP查询存在两方面的效率问题：分别是 IO 效率和CPU计算效率。
对于IO效率问题，由于使用行存做数据分析时，很多场景会读取很多不需要的列列，造成 IO 浪费，因此我们通过列索引技术提供了一个列存副本供AP分析查询使用。当对一张TP系统的表增加列索引之后，对于该列索引覆盖的所有列，都会单独按列拆分存储。其中每 64k 行列会形成一个 rowgroup，rowgroup 内的将每一列单独抽取出来，编码为 Datapack 。Datapack 默认压缩存储，同时会在上面构建稀疏索引。由于Datapack 里都是相同列的数据，相似性更高，因而一般都能够达到近 10 倍左右的压缩率，对比非压缩数据，可以减少10倍IO量读盘量。
同时因为有稀疏索引的存在，做数据扫描时可以依据查询条件和索引信息，提前按Datapack粒度进行数据过滤。如果查询条件未命中Datapack上的索引，一次可以过滤 64K 行数据，过滤效率非常高。
通过稀疏索引结合数据压缩，IO效率得到了极大提高。
而在CPU执行效率方面，由于MySQL 原始的执行引擎是火山模型按行为单位迭代处理的，其执行引擎对CPU Cache不友好，执行效率差。我们对分析类查询里面频繁被使用的算子比如 join、group by, agg 等进行了重新实现。重新实现的算子主要在两方面进行增强。首先是增强算子的并行执行能力，其次算子的函数之间数据传输单位由按行为单位转为按一个batch为一个单位，这样极大地减少了函数调用开销，同时列格式也提升了CPU Cache效率，计算效率能获得大幅提升。除了使用并行和算子向量化之外，我们还充分发挥了现代CPU里提供的SIMD指令，其可以在单次 CPU指令周期里处理多行数据。
列存数据压缩、粗糙索引过滤结合算子向量化并执行和及SIMD指令，使得IMCI在处理复杂分析SQL时，达到了百倍加速效果，极大的提升了执行效率。
第二个问题，即一体化部署架构方面，传统搭积木方案存在的典型问题是数据同步延迟问题。TP 和 AP 系统之间通过一个消息队列同步，很容易出具数据不一致和数据延迟的可能。而在 IMCI 的架构里，通过列索引方式实现列存副本，原先两套系统的数据同步问题变成数据库内部两个索引之间的数据一致性维护问题。而内部数据的一致性维护由事务系统来保证，事务提交需要行存和列存一起提交才能成功；如果失败，则两边一起回滚，这样能够最大化避免数据不一致。
其次，传统TP系统到 AP 系统数据同步延迟问题的出现，根本原因是一般列存引擎是一般设计为索引稀疏结构，其精准定位到特定行并进行更新的代价很高，一般不能支持比较高的更新吞吐。在IMCI里面，因为行列混合存储，且行存为主表，列存为索引。因此可以借助行存进行辅助定位，同时我们实现了一个专门进行列映射的紧凑索引结构，该索引只需保存行的 PK 信息和列的 RowID信息，可以在使用非常少量内存的情况下，快速对列索引中的数据进行定位并做标记删除或更新，保证列存数据更新速度永远可以跟得上行存系统的更新速度，这样业务永远可以读到实时的最新数据。
第三个问题，即一体化体验问题。在搭积木方案中，TP请求和AP请求往往由不同生态的不同产品来响应，因此一般情况下前端需要一套系统读写 TP 系统，另一套系统读 AP 系统，这尝尝意味着需要不同的访问语言和接口（例如TP系统为MySQL, AP 系统为ClickHouse）。
而我们希望让用户用一套访问接口同时解决TP请求和AP请求的响应问题，在PolarDB MySQL 支持原生 HTAP 能力之后，所有AP请求使用的数据类型操作语法都都与原生 MySQL行存完全一致。像MySQL生态里可以直接的各种内置函数以及更复杂的比如存储过程功能等，都能够支持在列存数据上运行。
同时在PolarDB HTAP一体化架构下，用户的TP/AP SQL分流需求被内置到 PolarDB MySQL内部解决，PolarDB 在接收到用户的SQL请求之后，会对用户 SQL 做优化并进行代价预估。如果判定 SQL可以是精准使用行存索引，查询读取数量较少，可以走原生的行式执行计划；如果 SQL 是大范围数据扫描，同时索引比较模糊，可以走列存，以此实现了一体化的用户体验，用户无需担心自己将一个负载查询发送到了TP系统从而干扰到正常TP系统的请求处理。
云壤：在正式上线 IMCI 之前，我们做了白名单灰度发布，有超过 30 个客户参与测试了 IMCI 的能力，而且有客户已经将实际业务放在 IMCI 上运行。
Q
那么，IMCI 能解决客户什么问题？它适用于什么场景？
道奇：有个专门给跨境卖家提供 SaaS 软件服务的客户，它们的运营系统上线了PolarDB HTAP。运营系统会从亚马逊实时获取订单数据，给跨境卖家提供实时运营管理能力，采用多租户应用架构，按照库来分租户，单表数量可达亿级别。
此前试过 OLTP + OLAP 两套独立系统的方案，OLTP 使用 PolarDB MySQL ，OLAP使用ClickHouse ，通过 ClickHouse 原生物化表的方式，将 PolarDB MySQL 数据同步到 ClickHouse，并在 ClickHouse 里完成分析业务。
此方案背景下，客户在实际使用过程中遇到较多问题：
首先，稳定性方面，客户端基于 ClickHouse 自带物化表的方式同步，对 MySQL DDL 支持不完善，经常会出现数据链路中断，导致数据丢失，对客户影响很大。
其次， ClickHouse 不擅长处理行级更新场景，需要通过冷热表周期性合并做去重来完成更新去重，延时较大，一般会存在15分钟左右延时。
第三，性能瓶颈方面，ClickHouse在大宽表数据场景下比较有优势，但在多表关联场景下的性能不佳。
第四，管理比较复杂。ClickHouse开发语言与 MySQL 不同，客户的学习和运维成本较大。
而运营系统上线 PolarDB HTAP方案后，基本解决了客户痛点：
第一，简单易用，可以无缝兼容。100%兼容MySQL语法，同时满足TP和AP需求，架构简单，支持统一地址接入，对应用无侵入。
第二，实时性更好。基于产品内部redolog复制同步数据，数据同步延迟毫秒级；利用MySQL自身强数据一致性，不存在数据同步遗漏，同步链路更稳定。
第三，相比Innodb行存，复杂的查询性能有百倍以上性能提升；对比ClickHouse，性能至少为同量级或略优。
最后，成本较低。首先，节省了同步链路方面的投入；其次，相较于 ClickHouse ECS自建成本大约可降低15%。
PolarDB HTAP目前已经在客户运营系统上线，性能提升非常明显。另外，PolarDB HTAP也非常适合零售电商行业实时库存，金融行业的欺诈监测、风险分析等业务场景。
云壤：IMCI 很大的优势在于实时性非常好，非常适用于业务高实时性以及强一致场景。同时，它可以很好地兼容客户现有 PolarDB MySQL 业务以及系统。
Q
那么，未来 IMCI 会有哪些能力规划？在性能提升或者成本降低方面会有哪些措施？
北楼：IMCI未来的演进主要有以下三个方向：
第一，多机执行能力的扩展。目前 PolarDB集群能够支持多 个RO节点 ，最多支持单个 RW 挂15个 RO 。而目前 IMCI 为单机执行，即每个 query 只能使用一个 RO 的计算能力。未来希望通过实现多机计算引擎，让单个 query 同时使用PolarDB集群中的多RO节点的算力。
支持多机执行之后，结合分布式共享内存，IMCI 能够分析的数据量可达到 10 TB 甚至百 TB 级别。而在小数据量的情况下，用户单个 SQL 也能拥有更快的处理速度，最大化利用用户的自有资源能力。
第二，冷热数据分离能力。在PolarDB支持 HTAP 后，更多用户会将分析性需求放到 PolarDB上，分析性需求往往需要处理比纯TP系统更大的数据量。PolarDB 原始的存储系统设计是面向高性能的TP业务，成本相对较高。但是分析性需求所使用的数据中有大量历史数据，这些数据很少被更新，读取的频率也较低。
因此我们希望实现自动化冷热分离能力，用户可以将无须频繁读写的数据转储至对象存储，如此用户存储成本有 10 倍下降空间。同时 PolarDB 内置一体化冷热分离能力后，用户可以实现对在线业务和历史归档数据的关联分析，极大简化用户管理数据的复杂度。
第三，提供Serverless售卖模式。云上数据库大量客户日常CPU资源使用率不到10%，意味着存在 90% 的成本浪费。而运行分析性负载的系统其负载随业务动性明显，出现有复杂运算需求的SQL时可能会导致 CPU 打满，而其他时间经常处于完全空闲状态。
通过在系统负载高峰时弹出数倍的 CPU/内存资源，快速消纳请求；而在系统空闲时候，将资源留给其他客户使用。从而可以以相同成本的情况获得数倍的执行性能的加速，或在相同的处理性能下，实现数倍的费用压缩。
云壤：IMCI 产品功能已经全面上线。8.0.13及以上集群版本可以实时开启列存索引的能力，只需在已有集群中新增 RO 节点，在增加过程中点击开启 IMCI 列存即可。更多使用说明、购买方法请参见官网。
推荐阅读