关于数据库:深度干货一篇-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 技术将来的钻研方向与挑战。

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

背景介绍

Motivation

结尾还是一个陈词滥调的 HTAP 起源动机问题，这个其实大家看过咱们之前的文章《什么是真正的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
be widely adopted in the business applications
with real-time data analytics by 2024.](https://files.mdnice.com/user…)

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数据库。

A trade-off for HTAP databases

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

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

从现有的观测数据来看：

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

这里对于Trade-off的相干思考咱们之前在对外的分享会上也多次提及，感兴趣的同学能够返回B站观看咱们最近一期的线上Meetup视频：

Challenges for HTAP databases

作者这里提出了HTAP数据库面临的四大挑战，这里也和咱们的第二篇文章《什么是真正的HTAP？挑战篇》里的观点不约而同，能够说齐全在咱们提出的8点挑战范畴之内：

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

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

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

案例钻研2：SQL Server

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

总结

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

此类别依赖于分布式架构来反对 HTAP。主节点在处理事务申请时将日志异步复制到从节点。主存储为行存储，抉择一些从节点作为列存储服务器进行查问减速。事务以分布式形式解决以实现高可扩展性；简单查问在具备列存储的服务器节点中执行。

劣势：

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

劣势：

• 数据新鲜度低

利用：

对TP和AP扩展性要求比拟高，同时可能容忍绝对较低的数据新鲜度（比方须要实时剖析的大规模电商零碎）

案例钻研：F1 Lightning

总结

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

• Auto-pilot service：主动调优（一些云服务，能够在零碎中主动帮客户实现数据分区、查问优化和资源调度等等）
• Auto-Sunc：主动同步（可实现定时定量同步数据）

案例钻研2：Oracle RAC

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

总结

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

案例2：Hyper（Column）

总结

四种架构HTAP数据库的比照

HTAP 技术

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

这个局部咱们留到下一篇文章再做探讨，欢送大家关注StoneDB。

StoneDB 曾经正式开源，欢送关注咱们

官网：https://stonedb.io/

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

Slack: https://stonedb.slack.com/ssb…