OceanBase的HTAP的实现

Gartner 2014 年首次提出 HTAP（Hybrid Transaction / Analytical Processing，混合事务分析处理）并给出明确的定义：即同时支持 OLTP 和 OLAP 场景，需要创新的计算存储框架，在一份数据上保证事务的同时支持实时分析，省去费时的 ETL 过程

HTAP 的典型优势场景包括：

1. 企业级混合负载。MySQL这样的开源数据库只能处理简单查询，如果涉及到复杂查询，往往是通过用户修改业务的方式来绕过。经典的企业级工作负载一般都是混合负载，既有简单的Key-Value查询，也有更加复杂的跑批作业，甚至是实时分析出报表，需要用到大事务/长事务，以及触发器、外键、约束等严格数据校验功能，例如企业 ERP系统。
2. 实时数据中台。很多场景会使用 MySQL 分库分表，并将所有 MySQL分库的数据同步到一个专门的汇聚库做实时分析。具备分布式能力的 HTAP 系统能够同时接管 MySQL 交易库和汇聚库的工作负载。
3. 在线历史数据统一处理。DBA做数据库规划的时候往往会区分在线库和历史库，通过在线库做交易，定期将在线库的冷数据迁移到历史库。HTAP系统能够将在线数据和历史数据统一成一份数据，支持更加灵活的查询方式，降低业务复杂度。
4. 面向用户的实时分析。传统的数据仓库往往是面向企业内部人员的，实时性不强，随着数据变得越来越重要，很多数仓场景需要直接面对最终用户，需要提升系统的实时性和并发处理能力，例如淘宝实时分析每个广告主/代理商的广告推广计划/关键词，支付宝对每一笔交易做实时风控，支付宝双十一当天实时分析每个商家的销售情况并根据分析结果快速调整营销策略，等等

HTAP 代表了一种技术理想，但是落地的时候难免会遇到各种问题，包括：

1. HTAP 对用户意味着什么？一个 OLTP 和 OLAP “无所不能”的系统真的是用户想要的吗？
2. 基于一份数据的假设，HTAP 到底牺牲 OLTP，还是牺牲 OLAP，或者是二者可以兼得？
3. HTAP 系统需要用到什么技术？到底是更加适合 OLTP 的行存，还是更加适合 OLAP 的列存？如何避免 OLTP 和 OLAP 两类业务互相干扰？

实现方式

数据库的全称是 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 的能力，典型的代表是 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 性能做到极致。

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

真正的 HTAP要求先有高性能的 OLTP，且能够很好地支持实时分析。这种类型的 HTAP 系统天然具备实时数仓（real-time analytics）的能力，这也是为什么 Oracle Exadata、SQL Server MPP 架构被广泛用于实时数仓场景的原因。需要注意的是，虽然真正的 HTAP 系统能够同时做 OLTP 和 OLAP，但由于工程复杂度和产品成熟度的原因，真正的 HTAP 系统也不可能在所有场景都具备优势。例如，纯粹的离线数据仓库，专门的 OLAP 系统会比 HTAP 系统做得更好。

一份数据

真正的 HTAP 系统有一个要求是基于”一份数据”同时做好交易和分析。那么，什么叫做“一份数据”？想要回答这个问题，核心是要回答哪一种做法是对用户最友好且性价比更高。我认为，数据的多个副本或者多种形态（列索引/ BTree 索引/ Bitmap 索引等）都可以被认为是”一份数据”，前提是能够在满足 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 混合负载处理这两类场景，不适合离线数仓或者大数据无结构化数据处理场景。

OceanBase的实现

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

为了让 OLTP 数据库具备 OLAP 的能力，尤其是大数据量 OLAP 的能力：

• 首先，需要引入原生分布式架构和低成本存储引擎，提升系统的大数据处理能力，从而使得系统不仅能够处理最新数据的实时交易，也能处理更大规模历史数据的全量分析。OceanBase 的底层采用了一个基于 LSM-Tree 的行列混合式存储方案，大幅降低存储成本，并在 OLTP 和 OLAP 二者性能取得很好的平衡。
• 其次，需要支持 OLTP 与 OLAP 之间的资源隔离。这里面既有多个副本之间的物理隔离，也有一个副本内部的 CPU/网络/磁盘/内存的逻辑隔离，将 cgroup 集成到数据库引擎内部做逻辑资源隔离是一个不错的方案。
• 再次，需要很好地支持复杂查询和大数据量查询，涉及到优化器、并行执行、向量执行等核心技术。对于分布式数据库，优化器不仅仅要考虑单机上的代价，还需要考虑多机上的代价，优化器的搜索空间大幅增加；另外，如何处理并行执行和服务器故障容错的问题，如何实现高效的向量引擎，如何设计内存中的数据格式，等等。
• 最后，需要更好地支持 OLAP 的数据开发和建模能力。数据仓库往往会将数据分成多个层次，包括：数据明细层，数据服务层，应用数据层。为了支持实时分析能力，HTAP 需要支持高效易用的物化视图，外部表，快速数据导入，并与各种数据开发工具和 BI 工具完成适配对接。

HTAP 不是万能的，比较适合单个业务部门的 OLTP 和实时 OLAP 的混合负载处理。我认为终态 HTAP 方案一定是基于“一个系统，一份数据”同时处理交易和实时分析的高性价比方案，“一份数据”的多个副本可以存储成多种形态（行存/列存），用于不同的工作负载。