茴字有四种写法，HTAP呢？

在数据库几十年的发展历程中，有两种最主流的数据处理负载，OLTP（后文简称TP）联机事务处理（On-Line Transaction Processing）和OLAP（后文简称AP）联机实时分析（On-Line Analytical Processing）。前者侧重于交易的处理过程，比如银行的转账，网站订单等，后者侧重于数据分析，比如大量数据统计与展示等。这两类负载在很长的一段时间内都是由不同的数据库产品来满足的。但是在实际的使用场景中，往往两类需求都需要被满足，因此用户希望有一个单一数据库可以既支持事务处理，也支持数据分析。

2014 年， Gartner在《混合事务/分析处理促进重大商业创新》报告中用HTAP（Hybrid Transaction and Analytical Process，混合事务和分析处理）一词描述新型的应用程序框架，以打破TP和AP之间的隔阂，既可以应用于事务型数据库场景，亦可以应用于分析型数据库场景。HTAP一词从此被业界熟知。

图：Gartner对HTAP的描述

(图片来源：Gartner)

HTAP架构看起来对用户使用非常友好，对简化企业的复杂大数据结构将起到非常关键的作用。但是HTAP的实现并不是一件容易的事情，TP与AP在很多方面都存在着巨大的矛盾。如下表所示，比如在数据插入方面，TP数据库一般都是插入即可见，每行数据插入之后马上就可以查询到，但是AP就不一定能做到这点。在数据更新方面，对TP来说是个必备功能，但是让AP支持单行级别的UPDATE是一个非常有挑战的问题。再比如在一些经典关系模型中非常重要的事务、完整性约束、次级索引等特性来说，AP数据库都会支持的相对比较弱。而在AP比较擅长的复杂查询和大量数据查询能力上来说，又是很多TP数据库的弱项。

图：OLTP与OLAP的矛盾

这其中有很大程度上由于系统的应用定位不同，导致了设计上的差异。比如在次级索引上，TP数据库的索引设计非常直接，比如Hash Index, Bitmap Index, B-Tree等，这些次级索引本质上是为了满足某种范围内的少量数据访问的Range Query，去帮助查询加速。

但是对AP来说，我们往往更看重扫描的性能，所以说绝大多数次级索引都会产生随机IO和大的构建开销，因此做多索引的意义有限，一般AP数据库只会采用像Zonemap，Sparse index这样的简单索引。

我们可以看到要把TP与AP融合成一个HTAP系统是有一些本质的矛盾点的。那针对这些矛盾点，学术界已经做过相当深入的研究。比如OSDI 2021会议上的“Retrofitting High Availability Mechanism to Tame Hybrid Transaction/Analytical Processing”这篇文章就针对数据实时性与性能影响程度的矛盾点做了深入研究。

如下图所示，x轴是数据实时性，即一个数据从TP系统写入到AP系统可读到的延时，y轴是TP能力的下降程度，即在TP与AP查询同时进行的时候系统的性能下降程度。

图：数据实时性与性能影响程度的Tradeoff

(图片来源：https://www.usenix.org/system/files/osdi21-shen.pdf)

• 图右下角的第1类系统，这里包含了目前业界比较熟悉的TiDB，Google的F1 Lightning等。这些系统的HTAP其实是TP和AP分离的两套系统，TP的行存存入数据后会做一次ETL导出到AP的列存中，因此这类系统的数据实时性会达到秒级甚至更长时间。但是由于两套系统存储和计算的独立性，因此在性能上几乎没有损失。

• 图左上角的第2类系统，有Hyper和MemSQL(现在改名叫SingleStore)这样的内存数据库产品，它们采用单引擎融合路线，提供插入即可见的高实时性，同时满足事务，但事务的并发能力上会有较大损耗。

• 图中间的第3类系统，这里的产品包含了微软的SQL Server和2017年的一个学术界的数据库BatchDB，采用的另外一种融合型引擎的路线，数据实时性会从数十毫秒到接近秒级，同时性能的损耗可以控制在一定的程度，处在以上两种情况的中间状态。

首先，我们将HTAP的五条技术路线分成两大类：第一大类是将现有的TP与AP做一个包装，通过一些中间件的方式将它们连接起来再做一个封装，本质上仍然是两套系统。第二大类就是融合，抛弃现有的TP与AP独立架构，从底层存储开始就将TP与AP的引擎融合起来，形成一套系统。

图：HTAP的五条技术路线

路线一本质上是一种中台，就是我们把现有的TP和AP通过ETL连接起来。这里普遍的一种做法是通过一个流式join的方式将多张TP表连成一张AP宽表。这个流式join对大数据社区来讲有很多的选型，比如Debezium作为CDC工具，Kafka消息队列以及Flink流式计算引擎等。在这样的系统中往往至少需要这三种东西，才能把数据从TP合并到AP里去。因此这种路线，它本质上是一种中台的构型。它的缺点就是组件太多，成本非常高，优点是在技术实现上非常容易，我们只需要在前端实现一个统一的Proxy，通过它分析我们SQL的请求是TP型的还是AP型的，然后将请求路由到不同的引擎上即可。即使不实现这个SQL Proxy的话，也可以由中台的开发人员从业务逻辑入手来拆解我们的请求应该怎么去处理，其实这也是近些年互联网和传统企业建设大数据平台或者数据中台的一种普遍做法。另外，在使用场景上来说，路线一的应用范围是最广的，因为它能将多个TP的表连接成一张宽表，这种用法是HTAP使用场景中最普遍的一种用法。

路线二我们将之称之为广义MQ模式，事实上它与路线一的模式比较接近。它与路线一的区别就是通过将TP的日志复制到独立的AP引擎来实现两套系统的连接，从存储和计算来讲他们仍然是独立的两套系统。而广义的MQ就是有一定创新性的连接方式，比如业界目前比较熟悉的TiDB中采用的就是这条路线，他们采用Raft Learner，这比路线一在产品的完整性，实时性以及数据的一致性上有了质的提高。但是路线二在使用场景上相比路线一有一个明显的限制，由于该路线的做法是将一个TP数据库的日志通过广义MQ传到AP的存储引擎里做回放，那就只能是一张TP表对应一张AP表，但是我们几乎所有的AP使用场景的时候都是需要几十甚至上百张TP表join成一张很大的宽表，然后再去进行数据探索分析等等。因此这条路线缺了一个很关键组件就是Stream处理。这里所谓的Stream处理是指必须具备完整的Stream SQL能力，特别Stream Join能力，它能把多张TP的表实时增量的连接成一张宽表，缺乏这个能力会导致这条路线的使用场景比较局限。

路线三四五与前面两条路线不同的是，是采用融合的形式来实现HTAP，也就是采用一套存储与计算引擎既做TP也做AP。融合型路线的特点是实时性更加受到重视，也就是希望达到更快的数据插入即可见性，同时也会极大的降低冗余存储和组件运维成本。

路线三我们称之为多副本融合模式，这种模式目前停留在学术界，并没有工程化的产品出现。它的核心思考是利用现在新型数据库系统都是分布式高可用的特点，而分布式的实现机制又绝大部分都是靠复制状态机（RSM），那么复制状态机中所需要的三个数据副本没有必要全部采用一种引擎。我们可以将两个副本用TP的行存存储，一个副本用AP列存存储。三个副本的节点都参与复制状态机的投票。这个方式有个缺点就是，AP的列存本身的实现机制与TP的行存实现机制有较大差别，如果AP的列存更新性能不佳的话(这是列存的主要难点之一)，就会影响分布式共识的性能，因此会拖慢整个系统性能。当然，如果列存解决了更新的挑战，这不失为一个好的方案。

图：路线四产品代表——SQL Server

图：路线四产品代表——Oracle

图：路线五产品代表——SingleStore

SingleStore的做法是将增量数据放在内存里，用行存的格式存储，而列存用于持久化，可以存在本地文件系统里，也可以放到云原生的存储里面去。增量行存数据到列存的转化是自动完成的，整个系统只有一份存储。由于行存对分析来说有一定的性能影响，所以SingleStore就将行存存放在内存里，不至于因为针对这部分数据的查询影响整体的吞吐量。

图：路线五产品代表——HANA

HANA最早是一个内存数据库，但是在后来的发展中也有了自己的持久化引擎。HANA也是一个Delta+Main结构。Delta有两级，L1 Delta采用面向写优化的行存结构，L2 Delta是一个Append Only列存，Main存放读优化的列存结构。当行存从内存中进行落盘时，会触发Compaction行为，通过合并不断去增加写放大，来满足对读的一些优化。HANA整体上看就是用一个存储(主要是列存)去服务TP和AP的系统。

HTAP是一个非常复杂的工程架构，其中对不同的指标看重程度会导致系统的不同Tradeoff。那究竟如何评估和衡量一个HTAP系统的好坏呢？这里我们将上述五种路线做了一个全面的对比，从6个维度来评价和衡量。

MatrixOne的定位是超融合异构云原生数据库， MatrixOne希望通过一套比较简洁one-size-fits-most的架构，能提供一套统一的满足大部分场景数据处理需求的平台，将复杂性包含在系统内部，让用户能够高效快速的处理和应用数据。MatrixOne也将将极简易用作为重要的设计准则，尤其对于IT能力并不太强的传统行业而言，MatrixOne希望将大数据系统设计的与MySQL一样简单。关于MatrixOne的整体产品和技术理念可以参考之前的一系列文章《昂贵、复杂、低效... 中小型企业如何打破大数据技术栈困境》, 《MatrixOne技术架构详解》。

基于这两个设计思想，MatrixOne采用了一种路线一与路线五的结合模式来设计我们的架构，我们称之为HSTAP(Hybrid Streaming/Transaction/Analytical Processing), 除了满足TP与AP融合以外，通过增加流的能力，来同时满足应用场景的丰富度。如下图所示，MatrixOne的架构前端有统一的SQL层，包含了SQL的计算引擎。中间层这块是我们的分布式框架MatrixCube，也是基于复制状态机实现的，它目前基于Raft去管理存储引擎。

图：MatrixOne的HSTAP愿景

存储层正在设计一套TAE（Transactional Analytical Engine）引擎，其核心与上文中路线五一致，都是采用一套存储引擎来同时满足TP与AP。而我们所采用的存储引擎是基于列存所构建，原因是我们对TAE的定位是面向TP优化的AP引擎，或者是带事务一致性的AP引擎，因此基于列存构建可以满足AP的高性能要求。在MatrixOne去年年底release的0.2版本中，我们已经完整的验证了列存与Raft协议的结合的可行性，同时性能与成熟的AP数据库相比不相上下，我们将其称之为AOE引擎（Append Only Engine），而TAE引擎将由AOE进化而来。另外MatrixOne将会设计自己的流引擎（Streaming Engine），这里我们会结合路线一中重要的Stream join能力，以构建系统内部可以将多表快速连接成一张宽表的能力。这个能力是绝大多数AP使用场景中都会用到的能力。

基于这样一套架构，MatrixOne将会以相对统一的构型实现HSTAP，既能满足融合型路线中的高实时性，低存储冗余度，强一致，同时又能兼顾路线一中对应用场景的全面覆盖程度，以及好的负载隔离。目前MatrixOne的TAE引擎与流引擎都在设计中。根据我们的路线图，今年7月份我们将推出一个单机版的TAE引擎，预计到10月份将完成将分布式事务框架与TAE引擎的结合，形成分布式TAE能力，而到年底的时候，预计将有一个初步的流引擎面世，届时将会是一个完整的HSTAP版本。顺便提及一下，基于复制状态机的存储引擎管理架构，也会发生大的变化，以更好应对云原生架构。

MatrixOne也是一个完全开源的社区驱动型的项目，欢迎感兴趣的开发者和数据库用户关注和贡献。