這個報告主體上分為5個章節(jié)，分別是：

背景介紹。

HTAP Databases：分享最新的 HTAP 數(shù)據(jù)庫技術，總結它們主要的應用場景與優(yōu)缺點，并根據(jù)存儲架構對它們進行分類。

HTAP Tecniques：介紹主流的 HTAP 數(shù)據(jù)庫關鍵技術，包括事務處理技術、查詢分析技術、數(shù)據(jù)組織技術、數(shù)據(jù)同步技術、查詢優(yōu)化技術以及資源調度技術等。

HTAP Benchmarks：介紹目前現(xiàn)有的主流 HTAP 基準測試。

Challenges and Open Problems：討論 HTAP 技術未來的研究方向與挑戰(zhàn)。

本文僅作精選分享，會省略一些非必要內容，如想了解更多，請閱讀原報告。

背景介紹

1Motivation

開頭還是一個老生常談的 HTAP 起源動機問題，這個其實大家看過我們之前的文章《什么是真正的HTAP？背景篇》，也就很清楚了：HTAP（Hybrid Transactional/Analytical Processing）的概念和定義是 Gartner 在 2014 年第一次給出的，注意，這里特別提到了in-memory技術，在其定義中，HTAP 是通過內存計算技術在同一份內存數(shù)據(jù)上同時支持事務和分析的處理。

Motivation

如上圖所示，左邊是傳統(tǒng)架構，要做OLAP必須先得把OLTP的數(shù)據(jù)通過ETL導過去，很麻煩，復雜度高、延遲高、運維難度大，總之一系列水深問題，一般人把握不住。

但是右邊的HTAP架構就很酷了，我一個數(shù)據(jù)庫采用行列共存的方式，同時進行事務和分析的處理，So easy，老板再也不用擔心我做個BI報表需要“T+1”甚至“T+N”了，數(shù)據(jù)一進來就能做到實時地分析，沒錯，這就是我們常說的 Real-Time。

Gartner envisioned that, HTAP techniques willbe widely adopted in the business applicationswith real-time data analytics by 2024.

Gartner 預計 HTAP 這個技術將會在 2024 年被需要實時分析的商業(yè)應用廣泛采用，因為它在很多行業(yè)都有應用場景，包括電商、財務、銀行和風控等等。這里舉兩個栗子：

在購物節(jié)這種高并發(fā)的情形下，如果電商賣家能夠實時地分析用戶行為數(shù)據(jù)，并根據(jù)分析結果針對性地投放品類廣告，這無疑會給賣家?guī)砀嗟氖找妗?/p>

銀行在線上處理用戶事務時還能實時地分析數(shù)據(jù)，從而檢測判斷該用戶及其行為是否異常或者存在風險，這會讓風控系統(tǒng)更加智能化。

實現(xiàn)上述的應用，HTAP 技術就是不可或缺的基礎設施底座。

可以看到，過去10年里，HTAP數(shù)據(jù)庫不斷涌現(xiàn)，本篇報告作者這里根據(jù) HTAP 數(shù)據(jù)庫發(fā)展時間線梳理成三個階段：

第一階段（2010-2014）：HTAP 數(shù)據(jù)庫主要是采用主列存（primary column store）的方式。如SAP HANA、HyPer、DB2和BLU等。

第二階段（2014-2020）：HTAP 數(shù)據(jù)庫主要是擴展了以前主行存的技術，在行存上加上了列存。如SQL Server，Oracle和L-store等。

第三階段（2020-present）：HTAP 數(shù)據(jù)庫主要是開啟了分布式的架構實現(xiàn)，滿足高并發(fā)的請求。如SingleStore、MySQL Heatwave和Greenplum等。

PS：StoneDB 屬于第三階段，是具有分布式架構、內存計算和行列混存的HTAP數(shù)據(jù)庫。

在數(shù)據(jù)庫領域，有兩個公認的經驗法則：

行存（Row Store）：比較適合OLTP。

Row-wise，update-heavy（重更新），short-lived transactions（短時延事務）

列存（Column Store）：比較適合OLAP。

column-wise，read-heavy，bandwidth-intensive queries（帶寬敏感查詢）

在本篇報告主要研究采用行列共存的HTAP數(shù)據(jù)庫。

2A trade-off for HTAP databases

HTAP 數(shù)據(jù)庫也有需要解決的問題，正所謂魚和熊掌不可兼得，很多時候我們需要找到一個權衡點，既然是權衡，就有天平的兩端，在HTAP數(shù)據(jù)庫領域里，主要討論的是工作負載隔離（Workload isolation） 和 數(shù)據(jù)新鮮度（Data freshness） 這兩個重要特性的權衡。

工作負載隔離，就是指OLTP和OLAP之間的負載隔離程度；數(shù)據(jù)新鮮度，就是指OLAP到底能讀到多新的事務性數(shù)據(jù)。

從現(xiàn)有的觀測數(shù)據(jù)來看：

高的工作負載隔離會導致較低的數(shù)據(jù)新鮮度

低的工作負載隔離會獲得較高的數(shù)據(jù)新鮮度

Trade-off for workload isolation and data freshness
這里關于Trade-off的相關思考我們之前在對外的分享會上也屢次提及，感興趣的同學可以前往B站觀看我們最近一期的線上Meetup視頻：

視頻地址：https://m.bilibili.com/video/BV1jB4y1577G

3Challenges for HTAP databases

作者這里提出了HTAP數(shù)據(jù)庫面臨的四大挑戰(zhàn)，這里也和我們的第二篇文章《什么是真正的HTAP？挑戰(zhàn)篇》里的觀點不謀而合，可以說完全在我們提出的8點挑戰(zhàn)范圍之內：

挑戰(zhàn)一：數(shù)據(jù)組織（Data Organization）

挑戰(zhàn)二：數(shù)據(jù)同步（Data Synchronization）

挑戰(zhàn)三：查詢優(yōu)化（Query Optimization）

挑戰(zhàn)四：資源調度（Resource Scheduling）

Challenges for HTAP databases

HTAP 數(shù)據(jù)庫

這一章節(jié)主要調研現(xiàn)有 HTAP 數(shù)據(jù)庫的主要架構，作者這里分成了四大架構：

主行存儲+內存中列存儲（Primary Row Store + InMemory Column Store）

分布式行存儲+列存儲副本（Distributed Row Store + Column Store Replica）

磁盤行存儲+分布式列存儲（Disk Row Store + Distributed Column Store）

主列存儲+增量行存儲（Primary Column Store + Delta Row Store）

1主行存儲+內存中列存儲

主行存儲+內存中列存儲

這類 HTAP 數(shù)據(jù)庫利用主行存儲作為 OLTP 工作負載的基礎，并使用內存列存儲處理 OLAP 工作負載。所有數(shù)據(jù)都保存在主行存儲中。行存儲也是內存優(yōu)化的，因此可以有效地處理數(shù)據(jù)更新。更新也會附加到增量存儲中，增量存儲將合并到列存儲中。例如，Oracle 內存雙格式數(shù)據(jù)庫結合了基于行的緩沖區(qū)和基于列的內存壓縮單元 (IMCU) 來一起處理 OLTP 和 OLAP 工作負載。文件和更改緩存在快照元數(shù)據(jù)單元 (SMU) 中。另一個例子是 SQL Server，它在 Hekaton 行引擎中的內存表上開發(fā)了列存儲索引 (CSI)，以實現(xiàn)實時分析處理。這種類型的 HTAP 數(shù)據(jù)庫具有高吞吐量，因為所有工作負載都在內存中處理。

優(yōu)勢：

TP 吞吐量高

AP 吞吐量高

數(shù)據(jù)新鮮度高

劣勢：

AP 擴展能力低

負載隔離性低

應用：

高吞吐、低擴展（比如需要實時分析的銀行系統(tǒng)）

案例研究1：Oracle Dual-Format

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

SIMD：單指令多數(shù)據(jù)

Max-Min Zone Map

Vector Group By：向量化

案例研究2：SQL Server

Larson, Per-?ke, et al. "Real-time analytical processing withSQL server.” PVLDB 8(12), 2015: 1740-1751.

Persistent Column Store：持久化列存

Updatable：可更新

總結

架構(a)的兩個HTAP數(shù)據(jù)庫對比

2分布式行存儲+列存儲副本

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

此類別依賴于分布式架構來支持 HTAP。主節(jié)點在處理事務請求時將日志異步復制到從節(jié)點。主存儲為行存儲，選擇一些從節(jié)點作為列存儲服務器進行查詢加速。事務以分布式方式處理以實現(xiàn)高可擴展性；復雜查詢在具有列存儲的服務器節(jié)點中執(zhí)行。

優(yōu)勢：

負載隔離性高

擴展性高

劣勢：

數(shù)據(jù)新鮮度低

應用：

對TP和AP擴展性要求比較高，同時能夠容忍相對較低的數(shù)據(jù)新鮮度（比如需要實時分析的大規(guī)模電商系統(tǒng)）

案例研究：F1 Lightning

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

總結

架構(b)的兩個HTAP數(shù)據(jù)庫對比

3磁盤行存儲+分布式列存儲

磁盤行存儲 + 分布式列存儲

這種數(shù)據(jù)庫利用基于磁盤的 RDBMS 和分布式內存列存儲 (IMCS) 來支持 HTAP。RDBMS 保留了 OLTP 工作負載的全部容量，并且深度集成了 IMCS 集群以加速查詢處理。列數(shù)據(jù)從行存儲中提取，熱數(shù)據(jù)駐留在 IMCS 中，冷數(shù)據(jù)將被驅逐到磁盤。例如，MySQL Heatwave將 MySQL 數(shù)據(jù)庫與稱為 Heatwave 的分布式 IMCS 集群相結合，以實現(xiàn)實時分析。事務在 MySQL 數(shù)據(jù)庫中完全執(zhí)行。經常訪問的列將被加載到 Heatwave。當復雜查詢進來時，可以下推到IMCS引擎進行查詢加速。

優(yōu)勢：

負載隔離性高

AP吞吐量和擴展性高

劣勢：

數(shù)據(jù)新鮮度不高

Medium（On-premise）：部署在本地，在不同機器上會有數(shù)據(jù)新鮮度的犧牲

Low（Cloud-based）：部署在云端，網絡延遲會影響數(shù)據(jù)新鮮度

應用：

對AP擴展性要求比較高，同時能夠容忍相對較低的數(shù)據(jù)新鮮度（比如需要實時分析的IoT應用）

案例研究1：MySQL Heatwave

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

Auto-pilot service：自動調優(yōu)（一些云服務，可以在系統(tǒng)中自動幫客戶實現(xiàn)數(shù)據(jù)分區(qū)、查詢優(yōu)化和資源調度等等）

Auto-Sunc：自動同步（可實現(xiàn)定時定量同步數(shù)據(jù)）

案例研究2：Oracle RAC

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

Auto-Sunc：自動同步（基于閾值的方式）

總結

架構(c)的兩個HTAP數(shù)據(jù)庫對比

4主列存儲+增量行存儲

主列存儲+增量行存儲

此類數(shù)據(jù)庫利用主列存儲作為 OLAP 的基礎，并使用增量行存儲處理 OLTP。內存中的 delta-main HTAP 數(shù)據(jù)庫將整個數(shù)據(jù)存儲在主列存儲中。數(shù)據(jù)更新附加到基于行的增量存儲。OLAP 性能很高，因為列存儲是高度讀取優(yōu)化的。但是，由于 OLTP 工作負載只有一個增量行存儲，因此 OLTP 的可伸縮性很低。一個代表是 SAPHANA 。它將內存中的數(shù)據(jù)存儲分為三層：L1-delta、L2-delta 和 Main。L1-delta以逐行格式保持數(shù)據(jù)更新。當達到閾值時，將 L1-delta 中的數(shù)據(jù)附加到 L2-delta。L2-delta 將數(shù)據(jù)轉換為列數(shù)據(jù)，然后將數(shù)據(jù)合并到主列存儲中。最后，將列數(shù)據(jù)持久化到磁盤存儲。

優(yōu)勢：

數(shù)據(jù)新鮮度高

AP吞吐量高

劣勢：

TP可擴展性不高

負載隔離性不高

應用：

高AP吞吐量、高數(shù)據(jù)新鮮度（比如需要實時分析的風控系統(tǒng)）

案例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 concurrencycontrol for main-memory database systems." In SIGMOD ,2015.

總結

架構(d)的兩個HTAP數(shù)據(jù)庫對比

5四種架構HTAP數(shù)據(jù)庫的對比

HTAP 相關技術

HTAP的相關技術包括（1）事務處理；(2)分析處理；(3) 數(shù)據(jù)同步；(4) 查詢優(yōu)化；(5)資源調度。這些關鍵技術被最先進的 HTAP 數(shù)據(jù)庫采用。然而，它們在各種指標上各有利弊，例如效率、可擴展性和新鮮度等等。