简介： Gartner 2016 年首次提出 HTAP(Hybrid Transaction / Analytical Processing，混合事务分析处理)并给出明确的定义：即同时支持 OLTP 和 OLAP 场景，需要创新的计算存储框架，在一份数据上保证事务的同时支持实时分析，省去费时的 ETL 过程。在我看来，HTAP 代表了一种技术理想，但是落地的时候难免会遇到各种问题，包括：
从用户角度谈 HTAP
数据库的全称是 DBMS(Database Management System)，早期是不区分 OLTP 与 OLAP 的，E.F.Codd 在 1970 年就提出了关系模型，Jim Gray 在 1976 年提出了事务模型。随着数据库的应用场景越来越丰富，单一数据库的处理能力瓶颈越来越明显，于是有人把复杂分析从数据库中单独拆分出来，Berry Devlin 和 Paul Murphy 在 1988 年提出了数据仓库，1993 年 E.F.Codd 提出 OLAP，明确把 OLAP 与 OLTP 区分开来，并附带 OLAP 的 12 条准则。OLAP 发展到今天有各种做法，包括我们常常听到的 ROLAP(基于 MPP 架构的关系数据库之上的 OLAP)、MOLAP(基于 Data Cube 的方案)、大数据(基于 Hadoop/Spark 的大规模分析方案)等等。
经典数据库把业务分成 OLTP 和 OLAP，并通过 ETL 定期将数据从 OLTP 数据库抽取到 OLAP 数据库，这也是数据仓库 T+1，T+n 的由来。这种方式带来了两个问题：一个是延迟、一个是复杂度，在实际生产系统中经常出现数据同步延迟或者同步出错导致的线上故障。那么，一种很自然的想法就是基于同一份数据同时做好事务处理和实时分析，从而让应用变得简单。
一种方式是在 OLTP 数据库的基础上扩展 OLAP 的能力，典型的代表是 Oracle 和 SQL Server。相比 MySQL 这种纯粹用于 KV 类简单查询的 OLTP 系统，Oracle 和 SQL Server 一方面能够处理复杂查询，另外，通过 Oracle IMC(In-memory column store)和 SQL Server 列存/列索引等技术能够很好地处理 OLAP。这种类型的混合负载叫做"real-time operational analytics"，先有 OLTP，再有 OLAP，且 OLTP 性能做到极致，这也是我认为的真正的 HTAP。OceanBase 采用的也是这种做法，不同点在于 OceanBase 的底层是原生分布式架构，相比 Oracle/SQL Server，能够处理更大的数据量。
另外一种方式是在 OLAP 数据库的基础上引入实时写入能力，典型的代表是一些专门用于实时 OLAP 的 MPP 数据库。国内很多创业公司走的是这条路，这种类型的混合负载本质上是"real-time analytics"，往往是在数据仓库的基础上引入实时写入，成为一个实时数据仓库，但由于 OLTP 涉及核心业务门槛太高，不支持完整的事务处理能力，例如不支持跨服务器强一致性，不支持大事务/长事务，不支持触发器/外键/约束，等等。
真正的 HTAP(real-time operational analytics)要求先有高性能的 OLTP，且能够很好地支持实时分析。这种类型的 HTAP 系统天然具备实时数仓(real-time analytics)的能力，这也是为什么 Oracle Exadata、SQL Server MPP 架构被广泛用于实时数仓场景的原因。需要注意的是，虽然真正的 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 查询;Oracle IMC 支持对表格在内存中建立列索引，SQL Server 支持对表格在磁盘/内存中建立列索引，从用户的角度仍然是“一个系统，一份数据”。
很多用户都问我：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/Elastic Search/Presto/Kylin 等多个系统搭积木的做法，HTAP 确实能够大大简化应用。另外，即使 HTAP 系统足够强大，数据仓库往往也会单独部署。一方面，实时业务和数据仓库的决策部门不同，另一方面，实时业务往往是单一数据源，而数据仓库处理多个业务的多种数据源。
HTAP 系统也不等于原生分布式架构。前面提到，Oracle / SQL Server 虽然采用集中式架构，但是具备 HTAP 能力，能够同时处理 OLTP 和 OLAP 混合负载，Oracle Exadata 一体机也是经典的 HTAP 方案之一。当然，通过原生分布式架构，以 OceanBase 为代表的分布式 HTAP 数据库具备处理大数据量的能力，大大拓宽了 HTAP 数据库的应用场景。
HTAP 技术上牺牲事务还是分析?
真正的 HTAP 要求先有高性能的 OLTP，然后在 OLTP 的基础上支持实时分析。无论是 Oracle/SQL Server 这样的集中式 HTAP 数据库，还是 OceanBase 这样的分布式 HTAP 数据库，都有非常好的事务处理性能。业界有一些“HTAP 产品”的事务处理性能比较差，这并不是 HTAP 的问题，而是这类产品的设计实现问题。
HTAP 的“一份数据”可以是数据的多个副本或者多种形态，例如主副本采用行存，备副本采用列存，因此，理论上也能做到不牺牲分析能力。然而，真正的 HTAP 数据库都是在 OLTP 的基础上发展起来的，由于工程复杂度的问题，OLAP 的能力一般会弱于专门的 OLAP 系统。HTAP 适合 OLTP 或者 OLTP 与实时 OLAP 混合负载处理这两类场景，不适合离线数仓或者大数据无结构化数据处理场景。
HTAP的核心技术
真正的 HTAP 是在 OLTP 数据库的基础上扩展 OLAP 的能力。经典的 OLTP 数据库，无论是开源的 MySQL，还是商业数据库 Oracle/SQL Server，都采用集中式架构，底层存储引擎是面向磁盘设计的 B+ 树。这种方案是为小数据量的实时事务处理量身定制的，读写性能很好但相比 LSM Tree 等新型数据结构存储成本更高。以 OceanBase 为例，底层采用优化过的 LSM Tree 存储引擎，在支付宝所有业务完全替换 Oracle/MySQL，存储成本只有原来 B+ 树方案的 1/3 左右。
为了让 OLTP 数据库具备 OLAP 的能力，尤其是大数据量 OLAP 的能力，思考如下：
首先，需要引入原生分布式架构和低成本存储引擎，提升系统的大数据处理能力，从而使得系统不仅能够处理最新数据的实时交易，也能处理更大规模历史数据的全量分析。OceanBase 的底层采用了一个基于 LSM-Tree 的行列混合式存储方案，大幅降低存储成本，并在 OLTP 和 OLAP 二者性能取得很好的平衡。
其次，需要支持 OLTP 与 OLAP 之间的资源隔离。这里面既有多个副本之间的物理隔离，也有一个副本内部的 CPU/网络/磁盘/内存的逻辑隔离，将 cgroup 集成到数据库引擎内部做逻辑资源隔离是一个不错的方案。
再次，需要很好地支持复杂查询和大数据量查询，涉及到优化器、并行执行、向量执行等核心技术。对于分布式数据库，优化器不仅仅要考虑单机上的代价，还需要考虑多机上的代价，优化器的搜索空间大幅增加;另外，如何处理并行执行和服务器故障容错的问题，如何实现高效的向量引擎，如何设计内存中的数据格式，等等。
最后，需要更好地支持 OLAP 的数据开发和建模能力。数据仓库往往会将数据分成多个层次，包括：数据明细层，数据服务层，应用数据层。为了支持实时分析能力，HTAP 需要支持高效易用的物化视图，外部表，快速数据导入，并与各种数据开发工具和 BI 工具完成适配对接。
本人从事数据库内核研发十几年，最大的感受是经典数据库博大精深浩如烟海，虽然我们今天探索的 HTAP 方案是一种创新，但是，其中大部分优秀的设计都可以从 Oracle/SQL Server 这样的经典数据库中借鉴，它们代表的是集中式架构的HTAP，我们要做的是分布式架构的 HTAP，从而进一步拓展 HTAP 的应用场景。
结语：
HTAP 不是万能的，比较适合单个业务部门的 OLTP 和实时 OLAP 的混合负载处理。我认为终态 HTAP 方案一定是基于“一个系统，一份数据”同时处理交易和实时分析的高性价比方案，“一份数据”的多个副本可以存储成多种形态(行存/列存)，用于不同的工作负载。
OceanBase 从 2010 年开始一直坚持做分布式 HTAP，虽然已经做了 12 年，但离产品完全成熟还需要很多年，接下来我们会有 HTAP 技术系列文章，把我们目前已经实现的 HTAP 技术方案和场景价值分享出来。虽然这些方案不一定很完善，但是可以作为和我们的开发者进一步探讨的基础。