在最新一屆國際數(shù)據(jù)庫頂級會議 ACM SIGMOD 2022 上，來自清華大學(xué)的李國良和張超兩位老師發(fā)表了一篇論文：《HTAP Database: What is New and What is Next》,并做了 《HTAP Database：A Tutorial》 的專項報告。 本篇文章曼氛，我們將系統(tǒng)地梳理一下兩位老師的報告，帶讀者了解 HTAP 的發(fā)展現(xiàn)狀和未來趨勢。
這個報告主體上分為5個章節(jié)，分別是：
- 背景介紹。
- HTAP Databases：分享最新的 HTAP 數(shù)據(jù)庫技術(shù)强重，總結(jié)它們主要的應(yīng)用場景與優(yōu)缺點拱燃，并根據(jù)存儲架構(gòu)對它們進行分類父晶。
- HTAP Tecniques：介紹主流的 HTAP 數(shù)據(jù)庫關(guān)鍵技術(shù)，包括事務(wù)處理技術(shù)、查詢分析技術(shù)、數(shù)據(jù)組織技術(shù)、數(shù)據(jù)同步技術(shù)韧骗、查詢優(yōu)化技術(shù)以及資源調(diào)度技術(shù)等。
- HTAP Benchmarks：介紹目前現(xiàn)有的主流 HTAP 基準(zhǔn)測試狈定。
- Challenges and Open Problems：討論 HTAP 技術(shù)未來的研究方向與挑戰(zhàn)。
本文僅作精選分享让蕾，會省略一些非必要內(nèi)容缸濒，如想了解更多，請閱讀原報告粱腻。
Part1 背景介紹
1. Motivation
開頭還是一個老生常談的 HTAP 起源動機問題庇配，這個其實大家看過我們之前的文章《StoneDB：什么是真正的HTAP？（一）背景篇》栖疑，也就很清楚了：HTAP（Hybrid Transactional/Analytical Processing）的概念和定義是 Gartner 在 2014 年第一次給出的讨永，注意，這里特別提到了in-memory技術(shù)遇革，在其定義中卿闹，HTAP 是通過內(nèi)存計算技術(shù)在同一份內(nèi)存數(shù)據(jù)上同時支持事務(wù)和分析的處理揭糕。
如上圖所示，左邊是傳統(tǒng)架構(gòu)锻霎，要做OLAP必須先得把OLTP的數(shù)據(jù)通過ETL導(dǎo)過去著角，很麻煩，復(fù)雜度高旋恼、延遲高吏口、運維難度大，總之一系列水深問題冰更，一般人把握不住产徊。
但是右邊的HTAP架構(gòu)就很酷了，我一個數(shù)據(jù)庫采用行列共存的方式蜀细，同時進行事務(wù)和分析的處理舟铜，So easy，老板再也不用擔(dān)心我做個BI報表需要“T+1”甚至“T+N”了奠衔，數(shù)據(jù)一進來就能做到實時地分析谆刨，沒錯，這就是我們常說的 Real-Time归斤。
Gartner 預(yù)計 HTAP 這個技術(shù)將會在 2024 年被需要實時分析的商業(yè)應(yīng)用廣泛采用痊夭，因為它在很多行業(yè)都有應(yīng)用場景，包括電商脏里、財務(wù)她我、銀行和風(fēng)控等等。這里舉兩個栗子：
- 在購物節(jié)這種高并發(fā)的情形下膝宁，如果電商賣家能夠?qū)崟r地分析用戶行為數(shù)據(jù)鸦难，并根據(jù)分析結(jié)果針對性地投放品類廣告，這無疑會給賣家?guī)砀嗟氖找妗?/li>
- 銀行在線上處理用戶事務(wù)時還能實時地分析數(shù)據(jù)员淫，從而檢測判斷該用戶及其行為是否異澈媳危或者存在風(fēng)險，這會讓風(fēng)控系統(tǒng)更加智能化介返。
實現(xiàn)上述的應(yīng)用拴事，HTAP 技術(shù)就是不可或缺的基礎(chǔ)設(shè)施底座。
可以看到圣蝎，過去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ù)庫主要是擴展了以前主行存的技術(shù)大诸，在行存上加上了列存渊啰。如SQL Server，Oracle和L-store等捂齐。
- 第三階段（2020-present）：HTAP 數(shù)據(jù)庫主要是開啟了分布式的架構(gòu)實現(xiàn)蛮放，滿足高并發(fā)的請求。如SingleStore奠宜、MySQL Heatwave和Greenplum等包颁。
PS：StoneDB 屬于第三階段，是具有分布式架構(gòu)压真、內(nèi)存計算和行列混存的HTAP數(shù)據(jù)庫娩嚼。
在數(shù)據(jù)庫領(lǐng)域，有兩個公認(rèn)的經(jīng)驗法則：
- 行存（Row Store）：比較適合OLTP榴都。
- Row-wise待锈，update-heavy（重更新），short-lived transactions（短時延事務(wù)）
- 列存（Column Store）：比較適合OLAP嘴高。
- column-wise，read-heavy和屎，bandwidth-intensive queries（帶寬敏感查詢）
在本篇報告主要研究采用行列共存的HTAP數(shù)據(jù)庫拴驮。
2. A trade-off for HTAP databases
HTAP 數(shù)據(jù)庫也有需要解決的問題，正所謂魚和熊掌不可兼得柴信，很多時候我們需要找到一個權(quán)衡點套啤，既然是權(quán)衡，就有天平的兩端随常，在HTAP數(shù)據(jù)庫領(lǐng)域里潜沦，主要討論的是工作負(fù)載隔離（Workload isolation） 和 數(shù)據(jù)新鮮度（Data freshness） 這兩個重要特性的權(quán)衡。
工作負(fù)載隔離绪氛，就是指OLTP和OLAP之間的負(fù)載隔離程度唆鸡；數(shù)據(jù)新鮮度，就是指OLAP到底能讀到多新的事務(wù)性數(shù)據(jù)枣察。
從現(xiàn)有的觀測數(shù)據(jù)來看：
- 高的工作負(fù)載隔離會導(dǎo)致較低的數(shù)據(jù)新鮮度
- 低的工作負(fù)載隔離會獲得較高的數(shù)據(jù)新鮮度
這里關(guān)于Trade-off的相關(guān)思考我們之前在對外的分享會上也屢次提及争占，感興趣的同學(xué)可以前往B站觀看我們最近一期的線上Meetup視頻：
3. Challenges for HTAP databases
作者這里提出了HTAP數(shù)據(jù)庫面臨的四大挑戰(zhàn)，這里也和我們的第二篇文章里的觀點不謀而合序目，可以說完全在我們提出的8點挑戰(zhàn)范圍之內(nèi)：
- 挑戰(zhàn)一：數(shù)據(jù)組織（Data Organization）
- 挑戰(zhàn)二：數(shù)據(jù)同步（Data Synchronization）
- 挑戰(zhàn)三：查詢優(yōu)化（Query Optimization）
- 挑戰(zhàn)四：資源調(diào)度（Resource Scheduling）
Part2 HTAP 數(shù)據(jù)庫
這一章節(jié)主要調(diào)研現(xiàn)有 HTAP 數(shù)據(jù)庫的主要架構(gòu)臂痕，作者這里分成了四大架構(gòu)：
- 主行存儲+內(nèi)存中列存儲（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. 主行存儲+內(nèi)存中列存儲
這類 HTAP 數(shù)據(jù)庫利用主行存儲作為 OLTP 工作負(fù)載的基礎(chǔ)，并使用內(nèi)存列存儲處理 OLAP 工作負(fù)載猿涨。所有數(shù)據(jù)都保存在主行存儲中握童。行存儲也是內(nèi)存優(yōu)化的，因此可以有效地處理數(shù)據(jù)更新叛赚。更新也會附加到增量存儲中澡绩，增量存儲將合并到列存儲中稽揭。例如，Oracle 內(nèi)存雙格式數(shù)據(jù)庫結(jié)合了基于行的緩沖區(qū)和基于列的內(nèi)存壓縮單元 (IMCU) 來一起處理 OLTP 和 OLAP 工作負(fù)載英古。文件和更改緩存在快照元數(shù)據(jù)單元 (SMU) 中淀衣。另一個例子是 SQL Server，它在 Hekaton 行引擎中的內(nèi)存表上開發(fā)了列存儲索引 (CSI)召调，以實現(xiàn)實時分析處理膨桥。這種類型的 HTAP 數(shù)據(jù)庫具有高吞吐量，因為所有工作負(fù)載都在內(nèi)存中處理唠叛。
優(yōu)勢：
- TP 吞吐量高
- AP 吞吐量高
- 數(shù)據(jù)新鮮度高
劣勢：
- AP 擴展能力低
- 負(fù)載隔離性低
應(yīng)用：
高吞吐只嚣、低擴展（比如需要實時分析的銀行系統(tǒng)）
案例研究1：Oracle Dual-Format
- SIMD：單指令多數(shù)據(jù)
- Max-Min Zone Map
- Vector Group By：向量化
案例研究2：SQL Server
- Persistent Column Store：持久化列存
- Updatable：可更新
總結(jié)
架構(gòu)(a)的兩個HTAP數(shù)據(jù)庫對比
b. 分布式行存儲+列存儲副本
此類別依賴于分布式架構(gòu)來支持 HTAP。主節(jié)點在處理事務(wù)請求時將日志異步復(fù)制到從節(jié)點艺沼。主存儲為行存儲册舞，選擇一些從節(jié)點作為列存儲服務(wù)器進行查詢加速。事務(wù)以分布式方式處理以實現(xiàn)高可擴展性障般；復(fù)雜查詢在具有列存儲的服務(wù)器節(jié)點中執(zhí)行调鲸。
優(yōu)勢：
- 負(fù)載隔離性高
- 擴展性高
劣勢：
- 數(shù)據(jù)新鮮度低
應(yīng)用：
對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.
總結(jié)
架構(gòu)(b)的兩個HTAP數(shù)據(jù)庫對比
c. 磁盤行存儲+分布式列存儲
磁盤行存儲 + 分布式列存儲
這種數(shù)據(jù)庫利用基于磁盤的 RDBMS 和分布式內(nèi)存列存儲 (IMCS) 來支持 HTAP挽荡。 RDBMS 保留了 OLTP 工作負(fù)載的全部容量藐石，并且深度集成了 IMCS 集群以加速查詢處理。列數(shù)據(jù)從行存儲中提取定拟，熱數(shù)據(jù)駐留在 IMCS 中于微，冷數(shù)據(jù)將被驅(qū)逐到磁盤。例如青自，MySQL Heatwave將 MySQL 數(shù)據(jù)庫與稱為 Heatwave 的分布式 IMCS 集群相結(jié)合株依，以實現(xiàn)實時分析。事務(wù)在 MySQL 數(shù)據(jù)庫中完全執(zhí)行延窜。經(jīng)常訪問的列將被加載到 Heatwave恋腕。當(dāng)復(fù)雜查詢進來時，可以下推到IMCS引擎進行查詢加速需曾。
優(yōu)勢：
- 負(fù)載隔離性高
- AP吞吐量和擴展性高
劣勢：
- 數(shù)據(jù)新鮮度不高
- Medium（On-premise）：部署在本地吗坚，在不同機器上會有數(shù)據(jù)新鮮度的犧牲
- Low（Cloud-based）：部署在云端，網(wǎng)絡(luò)延遲會影響數(shù)據(jù)新鮮度
應(yīng)用：
對AP擴展性要求比較高呆万，同時能夠容忍相對較低的數(shù)據(jù)新鮮度（比如需要實時分析的IoT應(yīng)用）
案例研究1：MySQL Heatwave
MySQL Heatwave. Real-time Analytics for MySQL Database Service, August 2021, Version 3.0
- Auto-pilot service：自動調(diào)優(yōu)（一些云服務(wù)商源，可以在系統(tǒng)中自動幫客戶實現(xiàn)數(shù)據(jù)分區(qū)、查詢優(yōu)化和資源調(diào)度等等）
- Auto-Sunc：自動同步（可實現(xiàn)定時定量同步數(shù)據(jù)）
案例研究2：Oracle RAC
Lahiri, Tirthankar, et al. Oracle database in-memory: A dual format in-memory<br>database. In ICDE, 2015.
- Auto-Sunc：自動同步（基于閾值的方式）
總結(jié)
架構(gòu)(c)的兩個HTAP數(shù)據(jù)庫對比
d. 主列存儲+增量行存儲
主列存儲+增量行存儲
此類數(shù)據(jù)庫利用主列存儲作為 OLAP 的基礎(chǔ)谋减，并使用增量行存儲處理 OLTP牡彻。內(nèi)存中的 delta-main HTAP 數(shù)據(jù)庫將整個數(shù)據(jù)存儲在主列存儲中。數(shù)據(jù)更新附加到基于行的增量存儲。OLAP 性能很高庄吼，因為列存儲是高度讀取優(yōu)化的缎除。但是，由于 OLTP 工作負(fù)載只有一個增量行存儲总寻，因此 OLTP 的可伸縮性很低器罐。一個代表是 SAPHANA 。它將內(nèi)存中的數(shù)據(jù)存儲分為三層：L1-delta渐行、L2-delta 和 Main轰坊。 L1-delta以逐行格式保持?jǐn)?shù)據(jù)更新。當(dāng)達到閾值時祟印，將 L1-delta 中的數(shù)據(jù)附加到 L2-delta肴沫。 L2-delta 將數(shù)據(jù)轉(zhuǎn)換為列數(shù)據(jù)，然后將數(shù)據(jù)合并到主列存儲中蕴忆。最后颤芬，將列數(shù)據(jù)持久化到磁盤存儲。
優(yōu)勢：
- 數(shù)據(jù)新鮮度高
- AP吞吐量高
劣勢：
- TP可擴展性不高
- 負(fù)載隔離性不高
應(yīng)用：
高AP吞吐量套鹅、高數(shù)據(jù)新鮮度（比如需要實時分析的風(fēng)控系統(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 concurrency control for main-memory database systems. In SIGMOD ,2015.
總結(jié)
架構(gòu)(d)的兩個HTAP數(shù)據(jù)庫對比
四種架構(gòu)HTAP數(shù)據(jù)庫的對比
Part3 HTAP 技術(shù)
HTAP的相關(guān)技術(shù)包括（1）事務(wù)處理站蝠； (2)分析處理； (3) 數(shù)據(jù)同步卓鹿；(4) 查詢優(yōu)化沉衣； (5)資源調(diào)度。這些關(guān)鍵技術(shù)被最先進的 HTAP 數(shù)據(jù)庫采用减牺。然而，它們在各種指標(biāo)上各有利弊存谎，例如效率拔疚、可擴展性和新鮮度等等。
這個部分我們留到下一篇文章再做討論既荚。
本文作者：李明康
