深度干货！一篇 Paper 带您读懂 HTAP | StoneDB 学术分享会第①期
在最新一届国际数据库顶级会议 ACM SIGMOD 2022 上，来自清华大学的李国良和张超两位老师发表了一篇论文：《HTAP Database: What is New and What is Next》,并做了 《HTAP Database：A Tutorial》 的专项报告。 本篇文章，我们将系统地梳理一下两位老师的报告，带读者了解 HTAP 的发展现状和未来趋势。
这个报告主体上分为5个章节，分别是：
-
背景介绍 。
-
HTAP Databases ：分享最新的 HTAP 数据库技术，总结它们主要的应用场景与优缺点，并根据存储架构对它们进行分类。
-
HTAP Tecniques ：介绍主流的 HTAP 数据库关键技术，包括事务处理技术、查询分析技术、数据组织技术、数据同步技术、查询优化技术以及资源调度技术等。
-
HTAP Benchmarks ：介绍目前现有的主流 HTAP 基准测试。
-
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数据库。
在数据库领域，有两个公认的经验法则：
-
行存（Row Store） ：比较适合OLTP。
-
Row-wise，update-heavy（重更新），short-lived transactions（短时延事务）
-
列存（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
