历程剖析：阿里云自研HTAP数据库的技术发展之路

摘要：8月24日，阿里云数据库技术峰会到来，本次技术峰会邀请到了阿里集团和阿里云数据库老司机们，为大家分享了一线数据库实践经验和技术干货。阿里云高级数据库技术专家队皓庭分享了高度兼容MySQL，并且能免去传统数仓ETL过程实现数据分析，同时支持高并发、大吞吐量的在线事务处理的PB级数据存储数据库是如何实现的，帮助大家了解了同时支持海量数据在线事务（OLTP）和在线分析（OLAP）的HTAP关系型数据库是如何打造出来的。

本文将介绍HybridDB for MySQL的定位和现状，以及其技术演进路线和尚待解决的问题。
 
一、产品现状
HybridDB for MySQL在RDS MySQL的基础上做了很多拓展和改进，同时也保留了一些传统关系型数据库的特性。Hybrid是在2005年提出的HTAP数据库的概念，指混合的事务和分析处理。传统的数据库因为各方面的限制，偏向于OLTP或OLAP的场景，两者很难兼得，目前也只有Oracle勉强地解决了这个问题。但是在更大的数据场景下，因为Oracle产品价格高昂，一般用户往往难以承担。而MySQL在国内外拥有很高的知名度和用户量，从这个生态出发可以让阿里云研发团队收获更多的产品改进思路。HybridDB for MySQL从个角度出发，提供一种高性价比、大数据库的产品，在解决OLTP和OLAP业务的同时，维持好MySQL的生态。

HybridDB for MySQL在SQL兼容性方面做了很多的扩展，包括支持了TPC-H和TPC-DS这两个OLAP领域的测试集。由于是阿里云的云数据库服务，HybridDB for MySQL继承了RDS的云服务特征，高可靠、高可用等特性一应俱全并支持在线的扩容。目前HybridDB for MySQL的线上服务规模遍及国内外十多个region，为阿里云及外部的用户提供了可靠服务，总数据量已经达到TB级，日新增数据达百T级。

二、产品定位
HybridDB for MySQL的定位是使用一份数据同时支持OLTP和OLAP。它的创新包括实现了share noting的架构，支持线性的信息扩展，以及使用了更新颖的高压缩比引擎，可以在大数据规模下有很好的表现。从定位上说，HybridDB for MySQL与其他分布式数据库产品各有分工。与其他阿里云数据库产品有所偏向不同，HybridDB for MySQL在OLTP和OLAP方面均有不错的扩展能力。HybridDB for MySQL吸收各家所长，希望提供一个通用的数据库解决方案来帮助用户解决大数据场景下基于SQL的业务问题。

三、技术演进路线
2013年从单机数据库加中间件的思路出发，阿里云利用分库分表中间件形成分库分表数据库。之后，阿里云对存储和计算方面进行了大幅度的优化，支持大数据存储的同时大幅降低成本，改进了SQL兼容性。今年开始做行列混合存储引擎，期望在更高的分析领域场景提供更好的服务。明年期望把RDS的PolarDB当作存储引擎，使整套数据能够运行在共享存储上，解决棘手的运维问题。

1、发展起点
单机数据库在遇到大数据场景下有很多瓶颈，以MySQL为例，它对SQL的执行只有一个Session线程，最多只能利用一个CPU的核。当单表数据量超过千万时，它的检索显得力不从心。这时候主流搜索引擎像innoDB被加数层级会变得比较高，致使单次OLTP的查询或更新的代价更大，相应时间变高。

单机数据库几乎无法解决这种问题，因为它所有的数据（数据结构和磁盘存储）都落在一台机器上，没有办法进行线性扩展。在并发密度高的环境下，不同并发线程间会资源争抢。从硬件的CPU、内存，再到软件的锁、日志和事务，都是线程密集争抢的对象。因此并发越高，数据库的整体存储下降地愈发明显。从这个角度出发，阿里云思考如何将单机数据库的性能扩展起来？

2、合久必分

传统解决方案利用中间件把一个大数据库的数据切成多个分片，集成到用户的业务代码中提高并行能力，中间件把用户的大查询拆成多个小查询，并行的计算并行的合并。这个思路让用户的代码背上了沉重的中间件，不同的用户想使用这套体系的时候还需要重复地编码。

从这个角度出发，阿里云研发团队把中间件抽取出来加入到数据库服务器中，对外呈现同一套的数据库访问协议，让用户使用SQL连接数据库进行查询和更新。在这个过程中，中间件代理用户完成并行计算。

整个设计思路偏向于MPP数据库。MPP数据库将用户的语句通过查询解析器、优化器翻译成一个并行控制的执行计划。这样一个执行计划可以最大程度地利用多级计算资源，将数据分而治之，所有用户都可以使用MySQL的协议去访问HybridDB for MySQL而不再关心额外的业务代码。

在这个设计架构下，阿里云研发团队遇到的问题及解决策略如下：

• 事务状态机。研发团队需要解决的问题是如何维护多级间数据一致性，尤其是要与原先用户的事务特性保证兼容？研发人员引入两阶段提交来解决分布式事务的问题。用户的跨区更新可以通过两阶段提交协议来保证强一致性。
• 流式执行器。数据库服务器的内存和磁盘空间都是有限的，不能解决超大规模的查询。例如一个表做一个全局的join in，需要把数据从各个表取出来做本地join in，如果此时再需要按不同维度排序，很可能产生临时表，而临时表往往扛不住这种压力。所以本阶段只考虑可以流式执行的SQL，包括count、sum等聚合函数以及一个维度的order by。
• 请求级连接池。连接到数据库的用户session很可能超过了单机上限。目前采取的措施是支持一个用户的请求级连接池。数据库从每一个连接请求中提取出执行计划，分析它后端引用的分区，不同的会话可以共享后端的分区连接。这样某些业务的前端并发连接高达数十万，而后端仅需要几千个连接。

最终，研发团队完成了一个连接数、QPS/TPS、容量线性提升，支持动态扩容的一个通用的数据库服务器。用户可以使用MySQL协议顺利接入而不需要繁琐的代码改造。目前线上服务的典型用户包括RDS的新闻数据，日均TPS达到20000多，前端并发连接日常达到8000多，每秒入库量在50000行的级别。

3、存储优化
当用户数据量不断扩大时，数据库将面临巨大的成本问题和运维问题。一个数据分区的存储容量高达一个多TB时，一个副本损坏后的重建需要花费数天的周期。从这个角度出发，阿里云团队做了如下改进：

• 性能与成本的平衡。使用SSD盘加SATA盘组成混合存储：SSD盘做第一级的读写CACHE，SATA盘做持久化存储。这个解决方案是阿里团队在FACEBOOK的FLASHCACHE上改造实现的BCACHE，它在不需要上层应用改制的前提下将SSD盘和SATA盘组合成混合存储。在CACHE命中率比较好的前提下，它的读写性能可以媲美FLASH卡，容量可以媲美SATA盘。
• SQL优化器。该产品的存储引擎放弃MySQL主流的innoDB而使用ToKuDB。它对压缩有很好的支持。一些优化的较好的insert语句可以直接写入它的根Buffer，随着时间推移异步向叶节点合并。用户的更新只要写入根Buffer就可以立即返回。这样的设计对成本做了很大优化，使同等资源规格、容量比普通RDS更大的实例的成本变为RDS的1/6。
• 针对运维问题开发了新的迁移方案，即使用流式的方式解决迁移问题。包括使用数据库的全量快照去做多级间的流式对反，不再通过外部存储做中转。同时，Binlog实时地流式传输出去可以避免在全量迁移过程中产生较大的磁盘空间对爆。

最终，研发团队完成了一个PB级容量的HybridDB for MySQL，它的TB级副本可以在数小时内迁移完毕。根据最新数据显示，一个1.3TB的副本可以在四小时内迁移完毕。目前线上几个规模比较大的数据库数据量在200至500TB左右，压缩比在3到5倍。一个典型的业务是RDS业务，240TB数据压缩到40TB，低成本机型下只消耗了不到32台机器，成本较以前降低了1/10左右。

物联网中心数据库和历史数据业务很适合使用这样低成本的存储体系。在物联网业务中，多点传感器直接向中心数据库汇聚数据，其对于并发连接的优化能够扩大传感器规模，再加上低廉的存储成本，使解决物联网场景变得格外有效；在历史数据业务中，用户的日志和历史数据可能非常大并且不会被删除，例如金融、游戏用户等数据汇聚到这种数据库中十分合适。

4、计算优化
随着线上业务的继续扩展，用户也提出了更多需求：数据库是否可以在存储之外附加更多功能让数据更具价值？为了提供复杂查询的能力，阿里云对架构做了进一步改造，即在OLAP领域做了进一步的改进。

阿里云研发团队为该产品引入了一个全功能计算引擎，该引擎基于开源的大数据框架Flink以及阿里云自研的MPP引擎。它将存储分区视作通用存储分区，将数据通过一系列算子计算后由SQL接口展示给用户。在过这个程中研发人员遇到的问题及解决策略如下：

• SQL兼容性，即SQL语句的支持程度。研发团队改造了解析器和优化器，使其能够支持各种SQL语法。团队选择开源优化器生成执行计划，并将所有的执行计划统一在执行算子上面。这样的架构模型类似于SparkSQL，但基于流式的Flink使响应延迟比Spark低更多。这样的计算引擎让复杂查询下的并行计算能力大幅增强并让计算能够贴着存储部署（本地计算可以通过本地引擎过滤）。例如存储引擎可以过滤映射，将全局的group by、join in交给计算引擎，来保证网络间的数据交换尽可能的少。研发团队使用了两层优化器：基于规则的和基于开销的。在优化器框架下，研发人员利用存储分区上的数据规模代价做了很多深度优化。
• 全局数据一致性，即用户通过事务更新数据时，如何保证复杂计算下数据的一致。复杂查询运行在独立的计算引擎上，它无法看到之前的update数据。为此研发人员在MySQL内核打了patch，暴露出数据的读视图，这样就保证了通用的数据一致性。
• 资源隔离，即在线AP类业务与TP类业务的资源争抢问题。数据库对OLTP业务和OLAP业务共享，但区别不出它们的重要性。研发人员在内核中做了patch根据SQL的query级别做IOPS隔离。这样，两类业务可以单独进行资源隔离控制，服务质量得到了单独的保障。

这样，研发团队收获了一个支持TPC-H和TPC-DS测试集的数据库，它的复杂查询的性能得到了大幅度的优化。目前HybridDB for MySQL解决的业务主要是实时写入实时查询实时分析的业务，比如用户在多点汇聚性能数据，数据既要对外部客户做实时展现，还需要多维度聚合保证用户看到期望的视图展现的业务类型。典型的例子是CDN的一个业务场景，它需要将用户各region的流量实时统计上来并对用户做实时报表。数据量每秒入库数万行，查询延迟不能超过毫秒级。

5、细分场景
对于OLAP业务而言，行存并不适合，为此研发团队附加了列存索引。它会把行存数据build成各样格式，比如位图索引等。这样数据库在OLAP场景下的性能有了大幅度提升，也在OLAP领域提供了更多功能。在这个过程中遇到的问题及解决方案如下：

• 行列存引擎。列存索引build会有延时，并且不能保证全局事务的强一致性（数据在行存上更新后不能立即在列存索引上可见）。所幸用户可以接受这种程度的延迟。
• 查询优化器。引入新的开销模型，考虑了存储引擎的存储格式。由于不同索引格式适合于不同计算，数据库在不同索引上有不同的代价模型，融入到之前的优化器框架里面。

最终，研发团队完成了一个在不同业务场景下去做细分的存储结构，而且可以根据业务做自适应的优化。典型业务有在线业务实时报表，例如在电商的交易类业务中订单数据存储后直接做大盘统计和分析。相比于之前的高延迟，数据库实现了实时的报表展示。

6、持续创新
前不久，RDS团队推出了重磅产品PolarDB。PolarDB基于共享存储，它的思路来自于亚马逊的Aurora。

Aurora将存储和计算做了分离。它的server层只负责非持久化的内存数据管理，而将持久化部分交给共享存储。副本间的数据同步抛弃Binlog使用Readlog，使一致性变得更强。数据的data格式直接在共享存储上存放成用户预期的innoDB格式，这样主副本完全负责写和实时的读操作，而备库可以从共享存储上取得数据但不承担写压力。

RDS团队将这样的架构引入云数据库产品中，也就有了PolarDB。PolarDB的引入解决了大副本的数据迁移问题。由于共享存储中的数据已经被独立切片，用户不再需要关心1TB大副本的迁移问题而由共享存储做分片间的数据搬移，这样使效率得到提升并很容易build成多种数据格式。

PolarDB的引入是明年预期的目标。PolarDB引入后，HybridDB for MySQL在OLTP中的并发事务处理能力会得到很大的提升。使用PolarDB后，PetaData可以从PB跨越到10PB的等级，这样就可以称HybridDB for MySQL为实时海量数据库，因为它的存储几乎可以不断扩展下去。

HybridDB for MySQL从一个中间件的种子逐步成长为目前具有混和事务混合处理能力的复杂架构。用户的大数据业务甚至是通用的混合业务都可以在PetaData上尝试，这是因为HybridDB for MySQL支持不断扩容，用户可以从小规模数据不断成长起来。

四、产品限制
HybridDB for MySQL不是万能的。研发团队在进行分布式架构的设计时做了很多折中和牺牲。它暂不适合的业务场景包括业务结构简单且数据量小的业务，例如百万级的表。百万级的表从全局取数据的代价比较高，且存储在单机数据库中就可以收获较高效率。同时HybridDB for MySQL也不支持一些高级特性：触发器、存储过程、游标和外键。另外，HybridDB for MySQL目前只支持有限的分区规则：只支持哈希分区和一个字段作为分区键。所幸这个限制并不太影响用户，因为用户使用最广的分区规则仍然是哈希。

五、产品展望



最后，本文将介绍研发团队对HybridDB for MySQL一至两年内的展望。

• 改进体验。团队希望用户从小规模数据开始使用HybridDB for MySQL，进而逐步成长为大规模数据而不需要经过痛苦的改造，可以像使用MySQL一样使用HybridDB for MySQL。
• 降低成本。
• 增强兼容性和安全性。支持更丰富的UDF和索引格式，为MySQL提供更高的扩展；
• 支持SSL协议；支持多种字符集。
• 改进运维。包括引入共享存储引擎，支持智能调度，数据的动态拆分，合理利用资源将计算和存储贴合在一起。