深度干货！一篇 Paper 带您读懂 HTAP | StoneDB 学术分享会第①期

在最新一届国际数据库顶级会议 ACM SIGMOD 2022 上，来自清华大学的李国良和张超两位老师发表了一篇论文：《HTAP Database: What is New and What is Next》,并做了 《HTAP Database：A Tutorial》 的专项报告。 本篇文章，我们将系统地梳理一下两位老师的报告，带读者了解 HTAP 的发展现状和未来趋势。

这个报告主体上分为 5 个章节，分别是：

1. 背景介绍 。
2. HTAP Databases ：分享最新的 HTAP 数据库技术，总结它们主要的应用场景与优缺点，并根据存储架构对它们进行分类。
3. HTAP Tecniques ：介绍主流的 HTAP 数据库关键技术，包括事务处理技术、查询分析技术、数据组织技术、数据同步技术、查询优化技术以及资源调度技术等。
4. HTAP Benchmarks ：介绍目前现有的主流 HTAP 基准测试。
5. Challenges and Open Problems ：讨论 HTAP 技术未来的研究方向与挑战。

本文仅作精选分享，会省略一些非必要内容，如想了解更多，请阅读原报告。

Part1 背景介绍

1. Motivation

开头还是一个老生常谈的 HTAP 起源动机问题，这个其实大家看过我们之前的文章

也就很清楚了：HTAP（Hybrid Transactional/Analytical Processing）的概念和定义是 Gartner 在 2014 年第一次给出的，注意，这里特别提到了 in-memory 技术，在其定义中，HTAP 是通过 内存计算 技术在 同一份内存数据 上同时支持事务和分析的处理。

如上图所示，左边是传统架构，要做 OLAP 必须先得把 OLTP 的数据通过 ETL 导过去，很麻烦，复杂度高、延迟高、运维难度大，总之一系列水深问题，一般人把握不住。

但是右边的 HTAP 架构就很酷了，我一个数据库采用行列共存的方式，同时进行事务和分析的处理，So easy，老板再也不用担心我做个 BI 报表需要 “ T+1 ” 甚至 “ T+N ” 了，数据一进来就能做到实时地分析，没错，这就是我们常说的 Real-Time 。

Gartner envisioned that, HTAP techniques will<br>be widely adopted in the business applications<br>with real-time data analytics by 2024.

Gartner 预计 HTAP 这个技术将会在 2024 年被需要实时分析的商业应用广泛采用，因为它在很多行业都有应用场景，包括电商、财务、银行和风控等等。这里举两个栗子：

• 在购物节这种高并发的情形下，如果电商卖家能够实时地分析用户行为数据，并根据分析结果针对性地投放品类广告，这无疑会给卖家带来更多的收益。
• 银行在线上处理用户事务时还能实时地分析数据，从而检测判断该用户及其行为是否异常或者存在风险，这会让风控系统更加智能化。

实现上述的应用，HTAP 技术就是不可或缺的基础设施底座。

可以看到，过去 10 年里，HTAP 数据库不断涌现，本篇报告作者这里根据 HTAP 数据库发展时间线梳理成三个阶段：

• 第一阶段（2010-2014） ：HTAP 数据库主要是采用主列存（primary column store）的方式。如 SAP HANA、HyPer、DB2 和 BLU 等。
• 第二阶段（2014-2020） ：HTAP 数据库主要是扩展了以前主行存的技术，在行存上加上了列存。如 SQL Server，Oracle 和 L-store 等。
• 第三阶段（2020-present） ：HTAP 数据库主要是开启了分布式的架构实现，满足高并发的请求。如 SingleStore、MySQL Heatwave 和 Greenplum 等。

PS：StoneDB 属于第三阶段，是具有分布式架构、内存计算和行列混存的 HTAP 数据库。

在数据库领域，有两个公认的经验法则：

1. 行存（Row Store） ：比较适合 OLTP。

• Row-wise，update-heavy（重更新），short-lived transactions（短时延事务）

2. 列存（Column Store） ：比较适合 OLAP。

• column-wise，read-heavy，bandwidth-intensive queries（带宽敏感查询）

在本篇报告主要研究采用行列共存的 HTAP 数据库。

2. A trade-off for HTAP databases

HTAP 数据库也有需要解决的问题，正所谓鱼和熊掌不可兼得，很多时候我们需要找到一个权衡点，既然是权衡，就有天平的两端，在 HTAP 数据库领域里，主要讨论的是 工作负载隔离（Workload isolation） 和 数据新鲜度（Data freshness） 这两个重要特性的权衡。

工作负载隔离，就是指 OLTP 和 OLAP 之间的负载隔离程度；数据新鲜度，就是指 OLAP 到底能读到多新的事务性数据。

从现有的观测数据来看：

• 高的工作负载隔离会导致较低的数据新鲜度
• 低的工作负载隔离会获得较高的数据新鲜度

Trade-off for workload isolation and data freshness

这里关于 Trade-off 的相关思考我们之前在对外的分享会上也屡次提及，感兴趣的同学可以前往 B 站观看我们最近一期的线上 Meetup 视频：

3. Challenges for HTAP databases

作者这里提出了 HTAP 数据库面临的四大挑战，这里也和我们的第二篇文章里的观点不谋而合，

可以说完全在我们提出的 8 点挑战范围之内：

• 挑战一： 数据组织 （Data Organization）
• 挑战二： 数据同步 （Data Synchronization）
• 挑战三： 查询优化 （Query Optimization）
• 挑战四： 资源调度 （Resource Scheduling）

Challenges for HTAP databases

Part2 HTAP 数据库

这一章节主要调研现有 HTAP 数据库的主要架构，作者这里分成了四大架构：

• 主行存储 + 内存中列存储 （Primary Row Store + InMemory Column Store）
• 分布式行存储 + 列存储副本 （Distributed Row Store + Column Store Replica）
• 磁盘行存储 + 分布式列存储 （Disk Row Store + Distributed Column Store）
• 主列存储 + 增量行存储 （Primary Column Store + Delta Row Store）

a. 主行存储 + 内存中列存储

主行存储 + 内存中列存储

这类 HTAP 数据库利用主行存储作为 OLTP 工作负载的基础，并使用内存列存储处理 OLAP 工作负载。所有数据都保存在主行存储中。行存储也是内存优化的，因此可以有效地处理数据更新。更新也会附加到增量存储中，增量存储将合并到列存储中。例如，Oracle 内存双格式数据库结合了基于行的缓冲区和基于列的内存压缩单元 (IMCU) 来一起处理 OLTP 和 OLAP 工作负载。文件和更改缓存在快照元数据单元 (SMU) 中。另一个例子是 SQL Server，它在 Hekaton 行引擎中的内存表上开发了列存储索引 (CSI)，以实现实时分析处理。这种类型的 HTAP 数据库具有高吞吐量，因为所有工作负载都在内存中处理。

优势：

• TP 吞吐量高
• AP 吞吐量高
• 数据新鲜度高

劣势：

• AP 扩展能力低
• 负载隔离性低

应用：

高吞吐、低扩展（比如需要实时分析的银行系统）

案例研究 1：Oracle Dual-Format

Lahiri, Tirthankar, et al. "Oracle database in-memory: A dual format in-memory<br>database." In ICDE, 2015.

• SIMD：单指令多数据
• Max-Min Zone Map
• Vector Group By：向量化

案例研究 2：SQL Server

Larson, Per-Åke, et al. "Real-time analytical processing with<br>SQL server.” PVLDB 8(12), 2015: 1740-1751.

• Persistent Column Store：持久化列存
• Updatable：可更新

总结

架构 (a) 的两个 HTAP 数据库对比

b. 分布式行存储 + 列存储副本

分布式行存储 + 列存储副本

此类别依赖于分布式架构来支持 HTAP。主节点在处理事务请求时将日志异步复制到从节点。主存储为行存储，选择一些从节点作为列存储服务器进行查询加速。事务以分布式方式处理以实现高可扩展性；复杂查询在具有列存储的服务器节点中执行。

优势：

• 负载隔离性高
• 扩展性高

劣势：

• 数据新鲜度低

应用：

对 TP 和 AP 扩展性要求比较高，同时能够容忍相对较低的数据新鲜度（比如需要实时分析的大规模电商系统）

案例研究：F1 Lightning

Yang, Jiacheng, et al. "F1 Lightning: HTAP as a Service." PVLDB 13(12), 2020: 3313-3325.

总结

架构 (b) 的两个 HTAP 数据库对比

c. 磁盘行存储 + 分布式列存储

磁盘行存储 + 分布式列存储

这种数据库利用基于磁盘的 RDBMS 和分布式内存列存储 (IMCS) 来支持 HTAP。 RDBMS 保留了 OLTP 工作负载的全部容量，并且深度集成了 IMCS 集群以加速查询处理。列数据从行存储中提取，热数据驻留在 IMCS 中，冷数据将被驱逐到磁盘。例如，MySQL Heatwave 将 MySQL 数据库与称为 Heatwave 的分布式 IMCS 集群相结合，以实现实时分析。事务在 MySQL 数据库中完全执行。经常访问的列将被加载到 Heatwave。当复杂查询进来时，可以下推到 IMCS 引擎进行查询加速。

优势：

• 负载隔离性高
• AP 吞吐量和扩展性高

劣势：

• 数据新鲜度不高
• Medium（On-premise）：部署在本地，在不同机器上会有数据新鲜度的牺牲
• Low（Cloud-based）：部署在云端，网络延迟会影响数据新鲜度

应用：

对 AP 扩展性要求比较高，同时能够容忍相对较低的数据新鲜度（比如需要实时分析的 IoT 应用）

案例研究 1：MySQL Heatwave

MySQL Heatwave. Real-time Analytics for MySQL Database Service, August 2021, Version 3.0

• Auto-pilot service：自动调优（一些云服务，可以在系统中自动帮客户实现数据分区、查询优化和资源调度等等）
• Auto-Sunc：自动同步（可实现定时定量同步数据）

案例研究 2：Oracle RAC

Lahiri, Tirthankar, et al. "Oracle database in-memory: A dual format in-memory<br>database." In ICDE, 2015.

• Auto-Sunc：自动同步（基于阈值的方式）

总结

架构 (c) 的两个 HTAP 数据库对比

d. 主列存储 + 增量行存储

主列存储 + 增量行存储

此类数据库利用主列存储作为 OLAP 的基础，并使用增量行存储处理 OLTP。内存中的 delta-main HTAP 数据库将整个数据存储在主列存储中。数据更新附加到基于行的增量存储。OLAP 性能很高，因为列存储是高度读取优化的。但是，由于 OLTP 工作负载只有一个增量行存储，因此 OLTP 的可伸缩性很低。一个代表是 SAPHANA 。它将内存中的数据存储分为三层：L1-delta、L2-delta 和 Main。 L1-delta 以逐行格式保持数据更新。当达到阈值时，将 L1-delta 中的数据附加到 L2-delta。 L2-delta 将数据转换为列数据，然后将数据合并到主列存储中。最后，将列数据持久化到磁盘存储。

优势：

• 数据新鲜度高
• AP 吞吐量高

劣势：

• TP 可扩展性不高
• 负载隔离性不高

应用：

高 AP 吞吐量、高数据新鲜度（比如需要实时分析的风控系统）

案例 1：SAP HANA

Sikka, Vishal, et al. "Efficient transaction processing in SAP HANA database: the end of a column store myth.” In SIGMOD. 2012.

案例 2：Hyper（Column）

Neumann, Thomas, Tobias Mühlbauer, and Alfons Kemper. "Fast serializable multi-version concurrency<br>control for main-memory database systems." In SIGMOD ,2015.

总结

架构 (d) 的两个 HTAP 数据库对比

四种架构 HTAP 数据库的对比

Part3 HTAP 技术

HTAP 的相关技术包括（1）事务处理； (2) 分析处理； (3) 数据同步；(4) 查询优化； (5) 资源调度。这些关键技术被最先进的 HTAP 数据库采用。然而，它们在各种指标上各有利弊，例如效率、可扩展性和新鲜度等等。

这个部分我们留到下一篇文章再做讨论。

StoneDB 已经正式开源，欢迎关注我们

官网：https://stonedb.io/

Github: https://github.com/stoneatom/stonedb

Slack: https://stonedb.slack.com/ssb/redirect#/shared-invite/email