Gartner在2014年首次提出了htap(混合事务/分析处理)，并给出了明确的定义:即同时支持OLTP和OLAP场景，需要创新的计算和存储框架，在支持实时分析的同时保证单个数据上的事务，节省耗时的ETL过程。

htap的典型优势场景包括:

企业级混合负载。这样的开源MySQL数据库只能处理简单的查询。如果涉及到复杂的查询，修改业务的用户通常会绕过它们。经典的企业级工作负载一般都是混合工作负载，从简单的键值查询到更复杂的批处理作业，甚至是报表的实时分析，都需要大/长事务和触发器、外键、约束等严格的数据验证功能，比如企业ERP系统。

实时数据中心。很多场景会使用MySQL子数据库和子表，将MySQL子数据库的所有数据同步到一个专门的聚合数据库中进行实时分析。分布式htap系统可以同时接管MySQL交易库和聚合库的工作量。

在线历史数据的统一处理。DBA在做数据库规划时，往往会区分联机数据库和历史数据库，通过联机数据库进行事务处理，定期将联机数据库中的冷数据迁移到历史数据库中。htap系统可以将在线数据和历史数据统一为一个数据，支持更加灵活的查询方式，降低业务复杂度。

面向用户的实时分析。传统的数据仓库往往面向企业内部员工，实时性不强。随着数据变得越来越重要，很多仓库场景需要直接面对最终用户，系统的实时和并发处理能力需要提高。比如淘宝实时分析每个广告主/代理商的广告推广方案/关键词，支付宝对每笔交易进行实时风控，支付宝实时分析每个商家11日的销售情况并根据分析结果快速调整营销策略，等等。

HTAP代表了一种技术理想，但它在着陆时不可避免地会遇到各种问题，包括:

HTAP对用户意味着什么？OLTP和OLAP“万能”系统真的是用户想要的吗？

基于a数据的假设，htap是牺牲OLTP、OLAP还是两者都牺牲？

htap系统需要什么技术？它更适合OLTP行存储还是OLAP列存储？如何避免OLTP和OLAP服务之间的干扰？

实现模式

数据库的全称是DBMS(数据库管理系统)。在早期，OLTP和OLAP是没有区别的。E.F.Codd在1970年提出了关系模型，Jim Gray在1976年提出了事务模型。随着数据库的应用场景越来越丰富，单一数据库的处理能力瓶颈越来越明显，于是有人将复杂的分析从数据库中分离出来。Berry Devlin和Paul Murphy在1988年提出了数据仓库，E.F.Codd在1993年提出了OLAP，明确区分了OLAP和OLTP，并附有12条OLAP准则。现在有OLAP的各种实践，包括ROLAP(基于MPP架构的OLAP)、MOLAP(基于数据立方体的方案)、大数据(基于Hadoop/Spark的大规模分析方案)等等。

一种方法是在OLTP数据库的基础上扩展OLAP的能力，典型代表是Oracle和SQL Server。相对于MySQL这种纯粹用于KV级简单查询的OLTP系统，Oracle和SQL Server一方面可以处理复杂的查询，而Oracle IMC(内存中列存储)和SQL Server列存储/列索引技术可以很好地处理OLAP。这种类型的混合负载称为“实时运营分析”，首先是OLTP，然后是OLAP，OLTP性能最好。

另一种方法是在OLAP数据库的基础上引入实时写能力，典型代表是一些专门用于实时OLAP的MPP数据库。国内很多创业公司都走这条路。这种类型的混合负载本质上是“实时分析”，往往是在数据仓库的基础上引入实时写入，成为实时数据仓库。但由于OLTP涉及核心业务门槛太高，不支持完整的事务处理能力，如跨服务器的强一致性、大/长事务、触发器/外键/约束等。

真正的HTAP首先需要高性能的OLTP，能够很好的支持实时分析。这类htap系统天然具有实时分析的能力，这也是Oracle数据库云服务器和SQL Server MPP架构被广泛应用于实时仓库场景的原因。需要注意的是，虽然真正的HTAP系统可以同时做OLTP和OLAP，但是由于工程的复杂性和产品的成熟度，真正的HTAP系统不可能在所有场景下都有优势。比如纯线下的数据仓库，专业化的OLAP系统会比HTAP系统做得更好。

一条数据

真正的HTAP系统的一个要求是基于“一个数据”做好交易和分析。那么，什么是“一个数据”？回答这个问题，核心是回答哪种方法最人性化，性价比最高。在我看来，多份数据或者多种形式(列索引/BTree索引/位图索引等。)可视为“一片数据”，前提是在满足HTAP处理要求的前提下，尽量减少数据冗余。比如OceanBase经常存储多个副本(3个副本/5个副本)，你可以选择让其中一个备份副本专门做OLAP查询；Oracle IMC支持在内存中为表建立列索引，而SQL Server支持在磁盘/内存中为表建立列索引，从用户的角度来看仍然是“一个系统，一个数据”。

对于HTAP的混合负载，如果OLTP负载是主要负载，OLAP负载占较小比例，那么在主副本上可以支持OLTP和OLAP的混合负载，在数据库内部可以实现资源的逻辑隔离。如果OLAP负载比例高，那么可以在主副本上做OLTP，在专用备份副本或只读副本上做OLAP查询，实现资源的物理隔离。

HTAP确实可以兼顾OLTP和OLAP，但这并不意味着HTAP是万能的，也不意味着全公司只有一个HTAP数据库。既有技术因素，也有非技术因素。一个公司往往有多个业务部门，应用会拆分，导致OLTP数据库和OLAP数据库的决策部门不同，甚至OLTP数据库也会按业务拆分。一个全公司的制度，在大部分公司基本是不现实的。更现实的方法是为每个企业建立一个HTAP数据库。比如一套交易业务的HTAP数据库，支持在线交易的实时处理和历史订单的实时分析。

HTAP的“一份数据”可以是多份数据或以各种形式存在。例如，主副本存储在行中，备份副本存储在列中。所以理论上可以在不牺牲分析能力的情况下实现。然而，真正的HTAP数据库都是基于OLTP开发的。由于项目的复杂性，OLAP的能力普遍弱于专门的OLAP系统。HTAP适用于OLTP或OLTP和实时OLAP的混合负载处理，但不适用于大数据的离线仓库或非结构化数据处理。

海洋基地的实施

真正的HTAP是在OLTP数据库的基础上扩展OLAP的能力。经典的OLTP数据库，无论是开源的MySQL还是商用数据库Oracle/SQL Server，都采用集中式架构，底层存储引擎是为磁盘设计的B+ tree。这种方案是为具有少量数据的实时事务处理量身定制的。它具有良好的读写性能，但比LSM树等新的数据结构具有更高的存储成本。

为了使OLTP数据库具备OLAP的能力，特别是大容量OLAP的能力:

首先，需要引入原生分布式架构和低成本存储引擎，提高系统的大数据处理能力，使系统既能处理最新数据的实时事务，又能处理更大规模历史数据的全尺度分析。OceanBase底层采用基于LSM树的行列混合存储方案，大大降低了存储成本，在OLTP和OLAP之间取得了很好的平衡。

其次，需要支持OLTP和OLAP之间的资源隔离。既有多个副本之间的物理隔离，也有一个副本内CPU/网络/磁盘/内存的逻辑隔离。将cgroup集成到数据库引擎中进行逻辑资源隔离是一个很好的方案。

再次，要很好地支持复杂查询和大规模查询，涉及优化器、并行执行、向量执行等核心技术。对于分布式数据库，优化器不仅要考虑单台机器上的开销，还要考虑多台机器上的开销，这就大大增加了优化器的搜索空间。另外，如何处理并行执行和服务器容错，如何实现高效的矢量引擎，如何设计内存中的数据格式等等。

最后，我们需要更好地支持OLAP的数据开发和建模能力。数据仓库通常将数据分为多个层次，包括:数据细节层、数据服务层和应用数据层。为了支持实时分析能力，HTAP需要支持高效易用的物化视图、外部表、快速数据导入，并配以各种数据开发工具和BI工具。

HTAP并不是万能的，它更适合单个业务单元中OLTP和实时OLAP的混合负载处理。我认为最终的HTAP方案必须是一个基于“一个系统，一个数据”的高性价比方案，同时处理交易和实时分析。“一个数据”的多个副本可以以各种形式(行存储/列存储)存储，用于不同的工作负载。