关于作者：
杨传辉，OceanBaseCTO。年作为创始成员之一加入OceanBase团队，主导了OceanBase历次架构设计和技术研发，从无到有实现OceanBase在蚂蚁集团全面落地。同时，他也主导了两次OceanBaseTPC-C测试并打破世界纪录，著有《大规模分布式存储系统：原理与实践》。目前，杨传辉带领OceanBase技术团队致力于打造更加开放、灵活、高效、易用的下一代企业级分布式数据库。
Gartner年首次提出HTAP（HybridTransaction/AnalyticalProcessing，混合事务分析处理）并给出明确的定义：即同时支持OLTP和OLAP场景，需要创新的计算存储框架，在一份数据上保证事务的同时支持实时分析，省去费时的ETL过程。在我看来，HTAP代表了一种技术理想，但是落地的时候难免会遇到各种问题，包括：
1.HTAP对用户意味着什么？一个OLTP和OLAP“无所不能”的系统真的是用户想要的吗？
2.基于一份数据的假设，HTAP到底牺牲OLTP，还是牺牲OLAP，或者是二者可以兼得？
3.HTAP系统需要用到什么技术？到底是更加适合OLTP的行存，还是更加适合OLAP的列存？如何避免OLTP和OLAP两类业务互相干扰？
从用户角度谈HTAP
数据库的全称是DBMS（DatabaseManagementSystem），早期是不区分OLTP与OLAP的，E.F.Codd在年就提出了关系模型，JimGray在年提出了事务模型。随着数据库的应用场景越来越丰富，单一数据库的处理能力瓶颈越来越明显，于是有人把复杂分析从数据库中单独拆分出来，BerryDevlin和PaulMurphy在年提出了数据仓库，年E.F.Codd提出OLAP，明确把OLAP与OLTP区分开来，并附带OLAP的12条准则。OLAP发展到今天有各种做法，包括我们常常听到的ROLAP（基于MPP架构的关系数据库之上的OLAP）、MOLAP（基于DataCube的方案）、大数据（基于Hadoop/Spark的大规模分析方案）等等。
经典数据库把业务分成OLTP和OLAP，并通过ETL定期将数据从OLTP数据库抽取到OLAP数据库，这也是数据仓库T+1，T+n的由来。这种方式带来了两个问题：一个是延迟、一个是复杂度，在实际生产系统中经常出现数据同步延迟或者同步出错导致的线上故障。那么，一种很自然的想法就是基于同一份数据同时做好事务处理和实时分析，从而让应用变得简单。
一种方式是在OLTP数据库的基础上扩展OLAP的能力，典型的代表是Oracle和SQLServer。相比MySQL这种纯粹用于KV类简单查询的OLTP系统，Oracle和SQLServer一方面能够处理复杂查询，另外，通过OracleIMC（In-memorycolumnstore）和SQLServer列存/列索引等技术能够很好地处理OLAP。这种类型的混合负载叫做"real-timeoperationalanalytics"，先有OLTP，再有OLAP，且OLTP性能做到极致，这也是我认为的真正的HTAP。OceanBase采用的也是这种做法，不同点在于OceanBase的底层是原生分布式架构，相比Oracle/SQLServer，能够处理更大的数据量。
另外一种方式是在OLAP数据库的基础上引入实时写入能力，典型的代表是一些专门用于实时OLAP的MPP数据库。国内很多创业公司走的是这条路，这种类型的混合负载本质上是"real-timeanalytics"，往往是在数据仓库的基础上引入实时写入，成为一个实时数据仓库，但由于OLTP涉及核心业务门槛太高，不支持完整的事务处理能力，例如不支持跨服务器强一致性，不支持大事务/长事务，不支持触发器/外键/约束，等等。
真正的HTAP（real-timeoperationalanalytics）要求先有高性能的OLTP，且能够很好地支持实时分析。这种类型的HTAP系统天然具备实时数仓（real-timeanalytics）的能力，这也是为什么OracleExadata、SQLServerMPP架构被广泛用于实时数仓场景的原因。需要注意的是，虽然真正的HTAP系统能够同时做OLTP和OLAP，但由于工程复杂度和产品成熟度的原因，真正的HTAP系统也不可能在所有场景都具备优势。例如，纯粹的离线数据仓库，专门的OLAP系统会比HTAP系统做得更好。
HTAP的典型优势场景包括：
1)企业级混合负载。MySQL这样的开源数据库只能处理简单查询，如果涉及到复杂查询，往往是通过用户修改业务的方式来绕过。经典的企业级工作负载一般都是混合负载，既有简单的Key-Value查询，也有更加复杂的跑批作业，甚至是实时分析出报表，需要用到大事务/长事务，以及触发器、外键、约束等严格数据校验功能，例如企业ERP系统。
2)实时数据中台。很多场景会使用MySQL分库分表，并将所有MySQL分库的数据同步到一个专门的汇聚库做实时分析。具备分布式能力的HTAP系统能够同时接管MySQL交易库和汇聚库的工作负载。
3)在线历史数据统一处理。DBA做数据库规划的时候往往会区分在线库和历史库，通过在线库做交易，定期将在线库的冷数据迁移到历史库。HTAP系统能够将在线数据和历史数据统一成一份数据，支持更加灵活的查询方式，降低业务复杂度。
4)面向用户的实时分析。传统的数据仓库往往是面向企业内部人员的，实时性不强，随着数据变得越来越重要，很多数仓场景需要直接面对最终用户，需要提升系统的实时性和并发处理能力，例如淘宝实时分析每个广告主/代理商的广告推广计划/关键词，支付宝对每一笔交易做实时风控，支付宝双十一当天实时分析每个商家的销售情况并根据分析结果快速调整营销策略，等等。
HTAP背后的权衡
如何理解“一份数据”？“一份数据”能否做到资源隔离？
真正的HTAP系统有一个要求是基于”一份数据”同时做好交易和分析。那么，什么叫做“一份数据”？想要回答这个问题，核心是要回答哪一种做法是对用户最友好且性价比更高。我认为，数据的多个副本或者多种形态（列索引/BTree索引/Bitmap索引等）都可以被认为是”一份数据”，前提是能够在满足HTAP处理需求的前提下最大程度降低数据冗余。例如，OceanBase往往存储多个副本（3个副本/5个副本），可以选择让其中一个备副本专门做OLAP查询；OracleIMC支持对表格在内存中建立列索引，SQLServer支持对表格在磁盘/内存中建立列索引，从用户的角度仍然是“一个系统，一份数据”。
很多用户都问我：OceanBase”一份数据”能否支持资源隔离？理解了”一份数据“这个概念之后，这个问题就很容易回答。对于HTAP混合负载，如果是OLTP负载为主，OLAP负载占比很少，那么，可以在主副本同时支持OLTP和OLAP混合负载并在数据库内部实现资源逻辑隔离；如果OLAP负载占比很高，那么，可以在主副本上做OLTP，在专门的备副本或者只读副本上做OLAP查询，实现资源物理隔离。
业界还有一些两套系统的方案，例如OLTP系统采用RocksDB/MySQL，OLAP系统采用Spark或者ClickHouse，并在系统内部实现不同类型SQL的路由分发。这种方案并不符合“一份数据“的要求，不是真正的HTAP。为什么？因为采用两个系统之后必然导致成本大幅上升，为了系统的高可用，OLTP系统和OLAP系统需要有各自独立的多副本容灾架构，且两个系统在理论上无法保证数据的一致性。
HTAP是否意味着全公司一套系统？
HTAP确实能够很好地兼顾OLTP和OLAP，但这并不代表HTAP是万能的，也不代表全公司只有一套HTAP数据库。这里面既有技术因素，也有非技术因素。一个公司往往会有多个业务部门，应用也会做拆分，这就导致OLTP数据库和OLAP数据库的决策部门不同，即使是OLTP数据库也会按照业务做拆分。全公司一套系统在大多数公司基本是不现实的，比较现实的做法是每个业务一套HTAP数据库。例如交易业务一套HTAP数据库，同时支持在线交易实时处理和历史订单的实时分析。
相比基于MySQL/ClickHouse/ElasticSearch/Presto/Kylin等多个系统搭积木的做法，HTAP确实能够大大简化应用。另外，即使HTAP系统足够强大，数据仓库往往也会单独部署。一方面，实时业务和数据仓库的决策部门不同，另一方面，实时业务往往是单一数据源，而数据仓库处理多个业务的多种数据源。
HTAP系统也不等于原生分布式架构。前面提到，Oracle/SQLServer虽然采用集中式架构，但是具备HTAP能力，能够同时处理OLTP和OLAP混合负载，OracleExadata一体机也是经典的HTAP方案之一。当然，通过原生分布式架构，以OceanBase为代表的分布式HTAP数据库具备处理大数据量的能力，大大拓宽了HTAP数据库的应用场景。
HTAP技术上牺牲事务还是分析？
真正的HTAP要求先有高性能的OLTP，然后在OLTP的基础上支持实时分析。无论是Oracle/SQLServer这样的集中式HTAP数据库，还是OceanBase这样的分布式HTAP数据库，都有非常好的事务处理性能。业界有一些“HTAP产品”的事务处理性能比较差，这并不是HTAP的问题，而是这类产品的设计实现问题。
HTAP的“一份数据”可以是数据的多个副本或者多种形态，例如主副本采用行存，备副本采用列存，因此，理论上也能做到不牺牲分析能力。然而，真正的HTAP数据库都是在OLTP的基础上发展起来的，由于工程复杂度的问题，OLAP的能力一般会弱于专门的OLAP系统。HTAP适合OLTP或者OLTP与实时OLAP混合负载处理这两类场景，不适合离线数仓或者大数据无结构化数据处理场景。
HTAP的核心技术
真正的HTAP是在OLTP数据库的基础上扩展OLAP的能力。经典的OLTP数据库，无论是开源的MySQL，还是商业数据库Oracle/SQLServer，都采用集中式架构，底层存储引擎是面向磁盘设计的B+树。这种方案是为小数据量的实时事务处理量身定制的，读写性能很好但相比LSMTree等新型数据结构存储成本更高。以OceanBase为例，底层采用优化过的LSMTree存储引擎，在支付宝所有业务完全替换Oracle/MySQL，存储成本只有原来B+树方案的1/3左右。
为了让OLTP数据库具备OLAP的能力，尤其是大数据量OLAP的能力，思考如下：
首先，需要引入原生分布式架构和低成本存储引擎，提升系统的大数据处理能力，从而使得系统不仅能够处理最新数据的实时交易，也能处理更大规模历史数据的全量分析。OceanBase的底层采用了一个基于LSM-Tree的行列混合式存储方案，大幅降低存储成本，并在OLTP和OLAP二者性能取得很好的平衡。
其次，需要支持OLTP与OLAP之间的资源隔离。这里面既有多个副本之间的物理隔离，也有一个副本内部的CPU/网络/磁盘/内存的逻辑隔离，将cgroup集成到数据库引擎内部做逻辑资源隔离是一个不错的方案。
再次，需要很好地支持复杂查询和大数据量查询，涉及到优化器、并行执行、向量执行等核心技术。对于分布式数据库，优化器不仅仅要考虑单机上的代价，还需要考虑多机上的代价，优化器的搜索空间大幅增加；另外，如何处理并行执行和服务器故障容错的问题，如何实现高效的向量引擎，如何设计内存中的数据格式，等等。
最后，需要更好地支持OLAP的数据开发和建模能力。数据仓库往往会将数据分成多个层次，包括：数据明细层，数据服务层，应用数据层。为了支持实时分析能力，HTAP需要支持高效易用的物化视图，外部表，快速数据导入，并与各种数据开发工具和BI工具完成适配对接。
本人从事数据库内核研发十几年，最大的感受是经典数据库博大精深浩如烟海，虽然我们今天探索的HTAP方案是一种创新，但是，其中大部分优秀的设计都可以从Oracle/SQLServer这样的经典数据库中借鉴，它们代表的是集中式架构的HTAP，我们要做的是分布式架构的HTAP，从而进一步拓展HTAP的应用场景。
HTAP不是万能的，比较适合单个业务部门的OLTP和实时OLAP的混合负载处理。我认为终态HTAP方案一定是基于“一个系统，一份数据”同时处理交易和实时分析的高性价比方案，“一份数据”的多个副本可以存储成多种形态（行存/列存），用于不同的工作负载。
OceanBase从年开始一直坚持做分布式HTAP，虽然已经做了12年，但离产品完全成熟还需要很多年，接下来我们会有HTAP技术系列文章，把我们目前已经实现的HTAP技术方案和场景价值分享出来。虽然这些方案不一定很完善，但是可以作为和我们的开发者进一步探讨的基础。