2022年中国数据库行业年度分析报告：HTAP

一、技术背景

（1）商业层面。"陈旧的报告、缺失的数据、缺乏高级分析以及完全缺乏实时分析对于任何需要新见解以在商业客户时代保持竞争力的企业来说都是一种无法忍受的状态。"- Forrester。

随着业务需要的发展和数据库技术的发展，使得数据库产品需要具有同时处理AP和TP的能力，需满足：（1）负载隔离能力，AP负载不会影响TP负载；（2）数据的新鲜度要高，AP可以访问最新的TP数据。因此，基于HTAP的能力可以简化业务系统的架构。

AP和TP的能力由统一的系统对外提供，由此带来：（1）业务架构简单化；（2）具有一定的扩展能力；（3）系统技术栈简单，运维方便等等优势。

产生 HTAP 用户侧的需求或者诉求如下：（1）事务数据及历史数据的集成；（2）理解用户需求的超维度数据分析的需要；全局视角来看数据，方能看清事物的本质。（例如：从手机的位置信息，用户的填表所获得信息，社交媒体所获得富媒体信息）;（3）企业运行所需的商业分析的实时性需求。

（2）技术层面。以下技术的发展进一步的推动了HTAP技术的快速发展及在业务层面的落地。

• 列存技术：该种数据存储模型下，只需要读取分析计算所需的属性即可，由此可以节约宝贵的IO和memory资源。同时，列存模型也属于CPU Cache友好型。但是，该模型有一个问题：其在将结果返回用户的时候，或者在上层算子进行计算的时候需要重构记录（Tuple）。
• in-memory技术(包括：distributed in-memory)：当执行Analytical Processing（AP）的时候，可以将AP所需数据加载内存中，甚至可以将所需的表的数据全部加载至内存，获得急速的处理速度。最后，为了保证系统crash的时候可以正确且快速的完成 recovery，需要将内存中的数据持久化至磁盘中。
• 可扩展的架构：（scale-out architect）: 水平扩展架构的发展，分布式锁技术的成熟，记录的分布式管理。当然分布式对于 HTAP 来说，只是一个充分条件，而非必要条件。
• 数据压缩（data compression）。
• 分层存储架构（tiered storage）：为能够以最大的性价比对用户提供高性能，分层存储架构应运而生。例如：使用DRAM，NVME，SSD，HDD 来构成分层存储架构。将对于计算实时性有要求的数据加载至 DRAM 中进行计算，以获得实时计算结果。如果计算过程复杂，中间结果集较大，可将中间结果集保存至 NVME 中，这样既可以保证数据的实时性，又可以支持更大的数据量，以获得较高的性价比。同样，SSD 和 HDD 也起着同样的作用。

二、发展历程

HTAP 数据库的兴起和发展是在2010 年代，有三条技术路线，分别是单机数据库，云数据库，NewSQL，SAP HANA 是以内存数据库为主的单机架构，MySQL在2021年发布的Heatwave 虽然在分析能力上是个MPP的架构，但MySQL本身还是单机版的，Google AlloyDB 参考了AWS Aurora 的架构，做到了青出于蓝的效果。NewSQL的分支鼻祖是Google Spanner, 但同为NewSQL架构的 TiDB 持续在 Real Time HTAP 投入巨大，TiDB 早期解决了MySQL分库分表的问题就面临用户的在线分析需求，在2018年TiSpark 的引入，2020 年TiFlash 架构完成了 HTAP架构的闭环，再到2021年 5.0版本MPP能力，这个能力通过TiDB Cloud向所有云上用户输出，在5年时间完成了Real Time HTAP产品能力的四连跳。

图1：主流HTAP数据库大事件

与 2014 年 HTAP 刚刚提出来的内存数据库架构大不相同，当前最有四个代表性的新一代 HTAP 数据库，我们会发现一些共性：首先新一代 HTAP 数据库都应对的是互联网和数字化催生的更大数据量，更低延迟，更低成本的新一代需求，其次，新一代 HTAP 数据库无论路径如何，都采用了分布式架构，行列混存，低延迟的 Log 复制机制，并通过云端的扩展获得了准 PB 级别的扩展性，很多还借助了 ML 的学习能力来提升查询的效率，最终都实现了以全托管的模式给用户提供一个简单而强大数据库的使用体验。合久必分，分久必合，新一代 HTAP 数据库在云端，以一种简化而强大的数据库能力为用户提供秒级的实时交易和查询体验，已经是一种公认的潮流。

三、典型厂商和架构对比

• 国外：SnowFlake（Unistore)、Google（AlloyDB）、Oracle（MySQL HeatWave)、SingleStore、SAP HANA、Microsoft SQL Server、Aurora（Parallel Query）等。
• 国内：OceanBase、TiDB、StoneDB、PolarDB、GaussDB、TDSQL-H等。

（1）Aurora Parallel Query

熟悉 Aurora 架构的读者清楚，Aurora 最早的版本是基于 MySQL 的，Aurora 的理念是 “Log is Database”。Aurora 主要是靠存算分离和共享存储来提升系统的扩展性，在 OLTP 方面，主库和从库采用Log 在共享存储层的同步机制来保证从库的数据及时更新；在 OLAP 方面，Aurora 基于 MySQL 5.6 和 5.7 兼容版本都支持并行查询，2019 年，AWS 基于 Aurora 上推出并行查询（Parallel Query），借助 Aurora 的存算分离架构，Parallel Query 可以把大规模查询的负载下推给 Aurora 存储层，而 Aurora 计算节点可以继续为事务服务，这样就可以在一个 Aurora 数据库中互不干扰地运行事务和分析负载。Aurora 解决混合负载的办法主要是采用存算分离的架构特点，充分借助云存储层的扩展性；但 Aurora 一写多读的架构在写入扩展性方面存在瓶颈，造成在 OLTP 上面的性能很容易达到上限。对于大多数 MySQL 用户来说，迁移到 Aurora 可以体验到云端 OLTP 性能和扩展性得到一个巨大的提升。Aurora Parallel Query 也提供了 MySQL 架构的并行版本，但无论是 OLTP 的写瓶颈，还是缺少列存支持的Parallel Query，都在 OLTP 和 OLAP 方向留下两个不小的遗憾，是带有缺憾的 HTAP 解决方案。

图1：Google Cloud AlloyDB

（2）Google Cloud AlloyDB

Google AlloyDB 是基于 PG 协议的，总体采用类似 AWS Aurora 的共享存储架构，通过存算分离和共享存储来提升系统的整体扩展性。从 AlloyDB 官方的架构演进图可以看到，AlloyDB 的扩展性和HTAP 能力都是靠智能存储引擎“ Intelligent Database Storage Engine ” OffLoad 数据计算节点的 IO 来实现的 ，而这一层“智能存储引擎”是围绕 LPS 通过 Log、Cache 和 Shared Block Storage 来实现的。在 OLTP 的写操作，主库通过 WAL 机制加速，在 OLAP 的读操作，可以应用可以从从库的 Buffer Cache、Ultra-fast Cache、智能存储层依次并行地去读取数据，可以自适应地决定资源的分布，无论读写，都可以解决 IO 瓶颈、热点、Block Write 等瓶颈，并借助 AI 算法可以不断地学习数据放置的方式。AlloyDB 增加了针对 OLAP 的列存引擎，这使得 OLAP 的分析能力大幅增强，不过这个主要是靠内存和缓存来完成的，由于 OLTP 和 OLAP 都采用的是一个跨 Region 的共享存储，所以 OLAP 永远读到的都是最新的数据，这是 HTAP 能力一种非常好的实现方式。

Aurora 的共享存储从根本上是一个服务 OLTP 的引擎，没有提供列存引擎，Aurora Parallel Query 还是要通过下推利用多节点从行存中 Query 数据。而 AlloyDB 是在 Aurora 的架构上为共享存储的 Log 服务机制增加了AI 的能力和列存引擎，在 OLAP 处理方面会带来很大的提升，但是 OLTP 的单写机制是否有足够的扩展性有待真实场景检验。AlloyDB 的出现给 PG 的用户带来一个云上 HTAP 加强版，这对于 PG 用户来说是一个福音。

无论是 Aurora 还是 AlloyDB 都是 AWS 和 GCP 的专有服务，用户只有成为 AWS 和 GCP的用户才有可能使用。此外，AlloyDB 在付费的透明度方面针对 Aurora 做了很大的改进，算是青出于蓝了。

图2：AlloyDB 的改进

（3）MySQL Heatwave，增加列存外挂引擎和 ML 的大号 MySQL

图3：MySQL Heatwave

MySQL 在原有架构上增加了一个列存引擎 Heatwave，成为了一个 MySQL 统一入口的分析引擎外挂，主要解决 MySQL 用户的规模化查询的问题。从系统架构上看，用户的 SQL 请求由系统判断是去 MySQL 自身的 InnoDB 还是 Heatwave，大规模的查询可以下推给 Heatwave 多节点并行计算，再返回结果，可以将查询提升一到两个数量级，处理的同时 Heatwave 和 InnoDB 互不干扰，不影响 InnoDB 侧的事务处理和 OLTP 查询。Heatwave 虽然大大提升了查询能力，但 InnoDB 本身的扩展性依然有瓶颈， OLTP 的吞吐量依然很容易达到上限，造成 OLTP 的扩展性仅限于 MySQL 原有的处理能力，无法满足 MySQL 用户对 OLTP 大规模扩展性的需求。

（4）TiDB HTAP，独立列存引擎设计，基于分布式 NewSQL 的跨云 HTAP

TiDB 是 2015 年在 GitHub 开始发布的 NewSQL数据库，其架构的灵感来源是Google Spanner / F1， 兼容 MySQL 协议，在 GitHub Star 数超过 31000+；在TiDB 2017年的早期版本 就开始尝试支持 HTAP 的能力，并分别在2019年发布了TiSpark, 2020 年发布了列存引擎 Ti Flash，其行列混存的Real Time HTAP架构论文 （此处嵌入论文链接） 是对NewSQL 架构的一次创新，2021年 TiDB 5.0 支持了 TiFlash 的MPP 版本，从而使得TiDB 的Real-Time HTAP 变成了在OLTP, OLAP 双向扩展能力的Real-Time HTAP 数据库；2022年5，经过一年的预览后，基于TiDB HTAP 数据库能力的全托管服务TiDB Cloud 正式全球商用，成为以全托管模式支持Real-Time HTAP 数据库服务。

TiDB HTAP 的架构如下图：TiDB 采用计算存储分离的分布式架构，TiKV 采用行存，TiFlash 采用列存，通过 Raft 协议同步数据，行列存之间保持强一致的数据读取。用户层面使用 TiDB 数据库，一个访问入口，一份数据，只要写 SQL 就行了，不用去考虑业务是 OLTP 还是 OLAP。TiDB HTAP 提供的 OLTP 与 OLAP 能力在架构设计上是完全对等的，各自都可以根据业务的规模实现规模化扩展，在实时性与一致性前提下 OLTP 和 OLAP 是完全隔离的，互不干扰和影响。

图4：TiDB负载分离

TiDB 列存引擎的 MPP 执行器对窗口函数的框架性支持，内存消耗被分布式分担，批处理场景的处理性能较为突出。 TiDB Cloud 已经在 AWS 和 GCP 上面提供服务，用户可以构建跨云构建 HTAP 数据架构，避免了单一云厂商的锁定。

本文初版写完的时候，Data Cloud的领导者Snowflake 也加入了HTAP 的行列，他们发布的Unistore 一看名字都是行列混存的路子，大家都知道 Snowflake 之前的主要领域是把 云上数据库仓库服务，重点在偏向 OLAP的分析领域，用的也是列存引擎，此次 Unistore的发布主要是通过新发布的Hybrid Table 增加了对行存的支持，一方面支持的交易类型的应用，另一方面让实时分析可以在不移动数据的情况下，分析来自交易应用，分析引擎，和原有Snowflake 数据源的数据。Snowflake 在HTAP的用户价值角度也强调了一个数据栈，不移动数据，同时支持在线交易和实时分析。

讲了那么多比较，现在用一张表来看这几个主要HTAP 数据库的特点，此表格对HTAP 数据库的关键能力做了一个粗颗粒的对比。

表 8：HTAP 数据库的关键能力对比

新一代 HTAP 数据库最关键的指标是什么？它和数据仓库，数据湖靠什么来区分？

前面这个分析表从各个不同角度分析了HTAP数据库应该具备的关键能力，从结果上看，HTAP数据库和数据仓库，数据湖最简单的划分是什么？答案只有一个，Latency，下面一张图把 HTAP 能力的Operational databases 和数据仓库，数据湖做了区分，回到本文开头的“秒回”这个词，无论具备HTAP能力的Operational Database 采用了那些技术组合，最终的效果就是要“秒回”，而数据仓库总体来说是秒到分钟级别的，而数据湖的数据访问都要分钟到小时级别了。

图5：HTAP 能力的Operational databases 和数据仓库，数据湖的区分

四、选择HTAP产品的维度

（1）业务场景:

首先，我们从业务场景的角度来讨论如何选择一款HTAP数据库，主要有以下四个维度：

• 业务类型

业务所在的领域决定了产品底层技术栈的选择。这个很好理解，比如电商这个业务场景所需要的技术栈和产品特点与传统制造、CRM 等所关注的侧重点就完全不一样——电商关注高并发、低延时、数据一致性和秒杀场景等等，而传统制造商则对海量多样化数据的处理和如何有效挖掘数据价值这些方面更加关注。

在不同的业务类型下，选择一款 HTAP 产品需要重点考察的是——这个业务类型需要哪一部分能力为主：TP 能力为主亦或是 AP 能力为主。

对于电商系统需要更加注重其在 TP 方面的关键能力，例如：事务、数据一致性等等；而对于CRM系统，经销存等等对TP能力则不会那么严苛，其可能更加看重AP的能力，在 TP 能力满足其基本业务需求的情况下，哪款产品的 AP 能力更强，业务侧可能会更倾向于选择该款产品。

而现有 HTAP 产品从技术实现路线上，基本可以分为这么两类路线，其决定产品的基因：即侧重于 TP 还是 AP？

路线1：以成熟的TP系统为基础，在其上进行AP能力的扩展。现有大部分 HTAP 数据库产品均采用该种策略。为什么采用该种策略？其原因是显而易见的，TP 系统发展到现在其相较于 AP 系统，更加成熟。例如：国内外的 OB，StoneDB，TiDB，Oracle MySQL Heatwave 和 Google AlloyDB 等；

路线2：在 AP 系统的基础上扩展其处理 TP 的能力。例如：Snowflake 等。这种路线，比较困难，但是成熟的科技公司会有更多的资源去做这个事儿，难度大，但是做出来了，也会是一大利器。

• 端到端的解决方案能力：

对于业务开发相关人员，一个新产品或者解决方案的引入，自然希望不会给其带来额外的工作负担，并且最好能够与其原有的技术栈相兼容，这样对于原有业务系统的改动要求最少。但也不完全就是为了让干的活儿更轻松一些，因为，对于一个在线运行的系统，其对于稳定性的要求非常高，而新组件的引入往往会让整个业务的不稳定因素增大。因此，如果不能够保持原有的技术栈，则需要提供端到端的解决方案。例如：原系统采用的 ClickHouse 或者 ElasticSearch，如果需要替换为 OB 或者StoneDB，那么需要考虑原系统 ClickHouse 或者 ElasticSearch 上下游相关模块接口兼容性，数据同步到 CK 或者 ES 的方式等等，这些解决方案都要提供出来。

• 数据实时性要求：

数据实时性的高低同样也会影响到产品的选择。当前现有的 HTAP 数据库在 TP和 AP 之间的数据同步策略实现机制不尽相同。例如：有些云厂商通过 MySQL+Binlog+ClickHouse 的组合方式提供 HTAP 服务，从用户的角度看似乎该服务具备了HTAP的能力，但实际上完全不是那么回事儿——因为通过 Binlog 这种方式会有很多弊端，又如有厂商通过 TP+Redo+Raft+AP 这样的组合构成 HTAP 产品，其相较于前一种在数据的实时性上有了较大的提升，但也只是提供数据的最终一致性，同样数据的实时性还是得不到保证；有的厂商则采用了基于 LSM-tree 实现的行列混存，这种可以基本保证对于数据实时性的要求；而像 MySQL Heatwave 和 StoneDB 则提供了基于内存计算的强实时性的方案。

HTAP 数据库在产品具体实现的时候，其选择的存储方案会直接到影响架构的选择：是一体化的架构？还是 TP 系统叠加 AP 系统的方案？架构的选择则会直接决定数据同步策略和数据实时性的高低。

技术能力：产品背后其公司所代表的技术实力也是业务方选择一款产品的考量因素，例如：我们在下文第六点中给出的观点。  

（2）性能

考量完业务场景相关的因素后，接下来需要考量的一个重要因素就是性能。不同于TP系的 Benchmark TPC-C 或者 AP 系统的 Benchmark TPC-H，对于HTAP 的性能测评一般不再使用这两个传统的方式来进行衡量。

当前大家更多地使用 TPC-H 来对其 AP 的能力进行评估，该种方法可以对其系统有一定的评价作用，但也存在着一定的弊端，那就是 TPC-H 无法全面地衡量一款 HTAP——因为 HTAP 数据库的系统中会同时存在两类负载：TP负载和AP负载。两类负载需要同时使用系统的CPU资源、IO 资源和网络资源等等。对资源的竞争会导致两类负载的相互干扰。因此，为了更好的衡量 HTAP 数据库，无论是学术界还是工业界，都逐渐提出了一些适用于HTAP数据库的 Benchmark 系统。

这里也简单提一下，除了具体的性能指标，例如：TPS、QPS、吞吐量等等，资源隔离性也是我们的重要考量。而资源隔离通常有两种方式：（1）通过系统手段（软件）隔离。例如，通过 Cgroup 的方式进行资源的管理；（2）通过物理手段进行隔离。例如，依据不同的负载类型 Route 到不同引擎上，将 AP 查询路由到列存引擎节点上，这样可将 TP 负载和 AP 负载运行于不同的节点上，从而做到真正的物理隔离。

（3）运维

运维的难度也需要我们认真考量。数据库的运维不同于其它基础系统，其对于 DBA 的综合素质有比较高的要求。在系统长时间运行的过程中会遇到各种数据库的使用、功能、性能等等问题。解决这些问题除了需要数据库、操作系统和业务等多方面的知识，同样也需要相关运维工具的支持。运维手段和运维工具可以高效的支持 DBA 的运维工作。复杂的系统形态，会导致 DBA 的运维工作量增大，最直接的影响就是难以快速定位问题，增加了解决问题的耗时。

（4）生态

生态是选择一款 HTAP 数据库的一个重要因素。当前有两类生态：PostgreSQL 和 MySQL。选择哪一种生态，会直接影响到后续围绕数据库所构成的整个技术栈。同时，业务也会从其自身的特点选择相应的技术路线。例如：如果业务系统是基于 JSON 和 GIS 能力的话，那么多数的业务开发者可能更倾向于选择 PostgreSQL 生态；如果是电商业务则更多的会选择 MySQL 生态。
具体来讲，生态中的周边工具、中间件和解决方案的完整性和丰富性非常重要。除工具、方案外，社区参与的人数（不管是对开源的 HTAP 数据库，还是对于商业或云上的 HTAP 服务，都需要考量该使用该服务的人群数量），更多的社区参与人数往往意味着社区比较活跃，那么，我们使用者遇到的一些问题就可以得到快速的响应。
生态的繁荣也从另外一个侧面反映出该技术路线获得了相当多的上下游厂商的支持。

（5）成本

成本是一个无法绕过的话题，一般企业/组织内的管理者对于成本的关注度往往是多于其他项的。如果想要使用一款 HTAP，需要考量的成本主要包括以下几个方面：硬件成本、替换（迁移）成本、运维成本等：

• 硬件成本：

其中最主要包括：计算成本和存储成本。在 StoneDB 实际的产品 POC 过程中，遇到很多客户实际的业务数据量在 100GB-1TB 内。如果采用一些现有的其他国产 HTAP 产品，由于这些产品对最小集群有要求，从而使得这些小厂商在使用 HTAP 服务时，必须付出比较高的集群硬件成本，这个是他们不愿意接受的。特别地，当需要替换现有MySQL数据库的时候，目前的一些国产 HTAP 数据库，基本都存在 MySQL 语法兼容性的问题，这导致迁移到新的业务系统上需要进行大量的修改，从而造成整体成本的飙升。如果厂商比较在乎这一部分的成本的话，StoneDB 就是很好的选择了。

• 替换成本：

需要能够提供对于原系统的平滑迁移能力。对于业务侵入改动最小，业务无需做修改即可平滑迁移到新的数据库平台。

• 运维成本：

在第三点中我们讨论运维问题，这里就不再详细讨论了。运维成本将会是系统稳定后，最主要的支出成本。

（6）LTS 支持性

对于LTS（Long Term Support，长期支持版）支持性，这里又可以从两个方面来讨论。（1）商业 HTAP 数据库（2）开源 HTAP 数据库。无论对于商业数据库还是开源数据库都面临某个版本的生命周期问题。

商业数据库相对来说，其售后服务有保障，但同时商业数据库又面临闭源和售后服务需要支付昂贵的服务费用等问题。而开源数据库，其 LTS 的支持除了需要社区支持以外，也需要由其背后的公司来进行保证。我们也很容易发现，一个成功的开源数据库项目背后，通常都有一个成功的商业公司支撑。

因此，无论是选择哪类 HTAP 数据库，都需要注意所选择的产品的 LTS 支持性的问题。

好了，以上就是我们总结的选择一款 HTAP 数据库需要考量的六大因素，也即：业务场景、性能、运维、生态、成本和 LTS 支持性，希望对于这六点的分析能给大家在做 HTAP 产品选型时提供帮助。

五、新一代HTAP在云端重构

新一代 HTAP 面对的市场需求和技术环境已经发生巨变，理论上，只要 MySQL 和 PG 的交易类应用有实时分析的需求就会需要HTAP 的能力，随着云基础设施普遍应用，“分布式✖️云原生”正在重构企业数据架构，成为新一代HTAP的技术环境。

HTAP 最早在 2014 年由分析机构 Gartner 提出，当时主要指以 SAP HANA 为代表的内存数据库的混合负载能力，HANA 快是快，但数据量有限，最大的门槛是“贵且专有”，仅在使用SAP的 大企业有少量用户，那一代HTAP并没有真正扩展起来，也并没有流行形成趋势。直到最近几年，互联网“海量、实时、在线” 的需求越来越广泛，大量采用 MySQL 和 PostgreSQL 开源数据库的新一代企业需要提升对于热数据的实时在线分析能力，这类需求遍布几乎所有的互联网企业，从事线上业务的数字化转型企业。电商、游戏、数字媒体、金融科技、网络安全等互联网和数字化业务，对于新鲜数据的实时分析能力直接决定了这些业务的生死存亡，秒甚至毫秒级的低延迟成为他们提升消费者体验的重要手段，实时营销、实时风控等业务诉求变得更加普遍，这种新诉求催生了新一代 HTAP的共同诉求：一个数据库，一套架构，同时满足 OLTP 和 OLAP 的低延迟数据处理且互不干扰，这个架构 Gartner 定义为 Augmented Analytics，IDC 称为ATP（ Analytic Transaction Processing），Forrester 称为 Translytical Data Platform , 可见新一代 HTAP 已经成为三大分析机构关注的焦点趋势。

下面重点拿几个HTAP 代表产品来看新一代 HTAP 技术架构的异同点，他们分别是 GCP AlloyDB, AWS Aurora Parallel Query，Oracle MySQL Heatwave 以及 TiDB 。总体来看，虽然各产品的具体实现虽有不同，但新一代 HTAP 架构有一些明显的共性追求：以开源打底，借助了云端扩展性，追求一个入口，一套数据栈，可以将 OLTP 数据和 OLAP 数据实时同步，部分厂商OLAP 的实现采用了类似 MPP 下推方式，达到 No Application Change、No Schema Change、No ETL，No data move 的四不效果，最大化减少对应用程序的改动。

任何一种数据库潮流都是“需求变化 ✖️技术变革 ✖ 架构创新” 三者融合的产物，HTAP 也不例外。首先，在需求变化侧，推动新一代 HTAP 的数据库厂商在提到 HTAP 的时候都不约而同地用到 Operation 这个词，借助热数据实现运营级别的实时分析，获得实时的洞察以支持运营动作的反馈，这是推动新一代 HTAP 走上舞台中央的最大需求侧变化。其次，在技术变革与架构创新侧，云基础设施的发展带来了存算分离更为彻底的变化，这是技术变革带来的新可能性，分布式理论与云计算、AI 算法的融合带来了新一代的架构创新，这些都使得 HTAP 在云端可以支持不同的云存储，AI 等新技术，打造更有成本竞争力的创新。第三，这一轮 HTAP 的用户群体和上一代内存数据库 HTAP 的小众贵族非常不同，这一代 HTAP 的用户非常大众化，几乎采用 MySQL 和 PG 开源数据库的所有企业都可以借助新一代 HTAP 架构拓展 OLTP 和 OLAP 的能力范围，都能用上一种不用修改应用，不用增加额外数据系统且拥有强大分析能力的数据库。

六、问题和挑战

HTAP是将TP和AP进行高度融合的产物， 而非简单的TP和AP相加：TP+AP ≠ HTAP。真正的HTAP，而非TP与AP的叠加。

（1）架构的选择。Single system（即 One system） 还是Seperate system的选择当前更多是基于工程上的难度。目前不少产品均是在原有的TP系统之上，叠加了一个AP系统并使用某种数据同步工具将TP系统中的数据同步至AP系统中。Seperate system虽然有其优点，但这种方案存在着许多不容忽视的问题，比如无法保证对事务的支持能力、数据的时效性，以及复杂的系统架构等（下文会有详细的解释）。相比之下，One system不仅架构简洁，对于事务的支持能力和数据的时效性等方面都能提供更好的保证。但是，One system架构的技术难度相对较大，工程上也具有一定的难度，同时还需要考虑TP和AP负载间的相互干扰等问题。

（2）查询处理及数据导入引擎。HTAP数据库首先需要解决的问题是高速的数据载入。 全量数据的载入方案，保证海量数据快速准确导入。增量数据的更新方案，保证数据的时效性。

（3）存储方案。高速存储介质正在广泛地应用到数据库领域。

（4）数据组织方案。选择列存储加行存储（DSM + NSM），还是PAX（Partition Attributes Across）方案或者是其它方案。系统的整体性价比也是我们挑选产品的重要指标之一。

（5）事务语义。无论是TP部分还是AP部分都需要对事务进行完整的支持。

（6）数据的时效性。需要保证AP系统所处理的数据均为当前最新版本的数据。

（7）索引的支持。如何能够通过设置索引快速定位到需要更新的数据（尤其是在以列存且数据多为压缩形式的情况下）也是需要解决的一个难题。

（8）不同类型负载间的相互干扰。系统需要能够保证AP负载对TP负载无影响或者使得两种类型负载间的影响最小化。