在最新一屆國(guó)際數(shù)據(jù)庫(kù)頂級(jí)會(huì)議 ACM SIGMOD 2022 上，來(lái)自清華大學(xué)的李國(guó)良和張超兩位老師發(fā)表了一篇論文：《HTAP Database: What is New and What is Next》,并做了 《HTAP Database：A Tutorial》 的專(zhuān)項(xiàng)報(bào)告。<br />
本篇文章，我們將系統(tǒng)地梳理一下兩位老師的報(bào)告，帶讀者了解 HTAP 的發(fā)展現(xiàn)狀和未來(lái)趨勢(shì)。
這個(gè)報(bào)告主體上分為5個(gè)章節(jié)，分別是：
- 背景介紹。
- HTAP Databases：分享最新的 HTAP 數(shù)據(jù)庫(kù)技術(shù)，總結(jié)它們主要的應(yīng)用場(chǎng)景與優(yōu)缺點(diǎn)，并根據(jù)存儲(chǔ)架構(gòu)對(duì)它們進(jìn)行分類(lèi)。
- HTAP Tecniques：介紹主流的 HTAP 數(shù)據(jù)庫(kù)關(guān)鍵技術(shù)，包括事務(wù)處理技術(shù)、查詢(xún)分析技術(shù)、數(shù)據(jù)組織技術(shù)、數(shù)據(jù)同步技術(shù)、查詢(xún)優(yōu)化技術(shù)以及資源調(diào)度技術(shù)等。
- HTAP Benchmarks：介紹目前現(xiàn)有的主流 HTAP 基準(zhǔn)測(cè)試。
- Challenges and Open Problems：討論 HTAP 技術(shù)未來(lái)的研究方向與挑戰(zhàn)。
本文僅作精選分享，會(huì)省略一些非必要內(nèi)容，如想了解更多，請(qǐng)閱讀原報(bào)告。
背景介紹
Motivation
開(kāi)頭還是一個(gè)老生常談的 HTAP 起源動(dòng)機(jī)問(wèn)題，這個(gè)其實(shí)大家看過(guò)我們之前的文章《什么是真正的HTAP？背景篇》，也就很清楚了：HTAP（Hybrid Transactional/Analytical Processing）的概念和定義是 Gartner 在 2014 年第一次給出的，注意，這里特別提到了in-memory技術(shù)，在其定義中，HTAP 是通過(guò)內(nèi)存計(jì)算技術(shù)在同一份內(nèi)存數(shù)據(jù)上同時(shí)支持事務(wù)和分析的處理。
如上圖所示，左邊是傳統(tǒng)架構(gòu)，要做OLAP必須先得把OLTP的數(shù)據(jù)通過(guò)ETL導(dǎo)過(guò)去，很麻煩，復(fù)雜度高、延遲高、運(yùn)維難度大，總之一系列水深問(wèn)題，一般人把握不住。
但是右邊的HTAP架構(gòu)就很酷了，我一個(gè)數(shù)據(jù)庫(kù)采用行列共存的方式，同時(shí)進(jìn)行事務(wù)和分析的處理，So easy，老板再也不用擔(dān)心我做個(gè)BI報(bào)表需要“T+1”甚至“T+N”了，數(shù)據(jù)一進(jìn)來(lái)就能做到實(shí)時(shí)地分析，沒(méi)錯(cuò)，這就是我們常說(shuō)的 Real-Time。
Gartner 預(yù)計(jì) HTAP 這個(gè)技術(shù)將會(huì)在 2024 年被需要實(shí)時(shí)分析的商業(yè)應(yīng)用廣泛采用，因?yàn)樗诤芏嘈袠I(yè)都有應(yīng)用場(chǎng)景，包括電商、財(cái)務(wù)、銀行和風(fēng)控等等。這里舉兩個(gè)栗子：
- 在購(gòu)物節(jié)這種高并發(fā)的情形下，如果電商賣(mài)家能夠?qū)崟r(shí)地分析用戶(hù)行為數(shù)據(jù)，并根據(jù)分析結(jié)果針對(duì)性地投放品類(lèi)廣告，這無(wú)疑會(huì)給賣(mài)家?guī)?lái)更多的收益。
- 銀行在線(xiàn)上處理用戶(hù)事務(wù)時(shí)還能實(shí)時(shí)地分析數(shù)據(jù)，從而檢測(cè)判斷該用戶(hù)及其行為是否異?；蛘叽嬖陲L(fēng)險(xiǎn)，這會(huì)讓風(fēng)控系統(tǒng)更加智能化。
實(shí)現(xiàn)上述的應(yīng)用，HTAP 技術(shù)就是不可或缺的基礎(chǔ)設(shè)施底座。
可以看到，過(guò)去10年里，HTAP數(shù)據(jù)庫(kù)不斷涌現(xiàn)，本篇報(bào)告作者這里根據(jù) HTAP 數(shù)據(jù)庫(kù)發(fā)展時(shí)間線(xiàn)梳理成三個(gè)階段：
- 第一階段（2010-2014）：HTAP 數(shù)據(jù)庫(kù)主要是采用主列存（primary column store）的方式。如SAP HANA、HyPer、DB2和BLU等。
- 第二階段（2014-2020）：HTAP 數(shù)據(jù)庫(kù)主要是擴(kuò)展了以前主行存的技術(shù)，在行存上加上了列存。如SQL Server，Oracle和L-store等。
- 第三階段（2020-present）：HTAP 數(shù)據(jù)庫(kù)主要是開(kāi)啟了分布式的架構(gòu)實(shí)現(xiàn)，滿(mǎn)足高并發(fā)的請(qǐng)求。如SingleStore、MySQL Heatwave和Greenplum等。
PS：StoneDB 屬于第三階段，是具有分布式架構(gòu)、內(nèi)存計(jì)算和行列混存的HTAP數(shù)據(jù)庫(kù)。
在數(shù)據(jù)庫(kù)領(lǐng)域，有兩個(gè)公認(rèn)的經(jīng)驗(yàn)法則：
- 行存（Row Store）：比較適合OLTP。
- Row-wise，update-heavy（重更新），short-lived transactions（短時(shí)延事務(wù)）
- 列存（Column Store）：比較適合OLAP。
- column-wise，read-heavy，bandwidth-intensive queries（帶寬敏感查詢(xún)）
在本篇報(bào)告主要研究采用行列共存的HTAP數(shù)據(jù)庫(kù)。
A trade-off for HTAP databases
HTAP 數(shù)據(jù)庫(kù)也有需要解決的問(wèn)題，正所謂魚(yú)和熊掌不可兼得，很多時(shí)候我們需要找到一個(gè)權(quán)衡點(diǎn)，既然是權(quán)衡，就有天平的兩端，在HTAP數(shù)據(jù)庫(kù)領(lǐng)域里，主要討論的是工作負(fù)載隔離（Workload isolation） 和 數(shù)據(jù)新鮮度（Data freshness） 這兩個(gè)重要特性的權(quán)衡。
工作負(fù)載隔離，就是指OLTP和OLAP之間的負(fù)載隔離程度；數(shù)據(jù)新鮮度，就是指OLAP到底能讀到多新的事務(wù)性數(shù)據(jù)。
從現(xiàn)有的觀測(cè)數(shù)據(jù)來(lái)看：
- 高的工作負(fù)載隔離會(huì)導(dǎo)致較低的數(shù)據(jù)新鮮度
- 低的工作負(fù)載隔離會(huì)獲得較高的數(shù)據(jù)新鮮度
[圖片上傳失敗...(image-e0725b-1661936843130)]
這里關(guān)于Trade-off的相關(guān)思考我們之前在對(duì)外的分享會(huì)上也屢次提及，感興趣的同學(xué)可以前往B站觀看我們最近一期的線(xiàn)上Meetup視頻：
Challenges for HTAP databases
作者這里提出了HTAP數(shù)據(jù)庫(kù)面臨的四大挑戰(zhàn)，這里也和我們的第二篇文章《什么是真正的HTAP？挑戰(zhàn)篇》里的觀點(diǎn)不謀而合，可以說(shuō)完全在我們提出的8點(diǎn)挑戰(zhàn)范圍之內(nèi)：
- 挑戰(zhàn)一：數(shù)據(jù)組織（Data Organization）
- 挑戰(zhàn)二：數(shù)據(jù)同步（Data Synchronization）
- 挑戰(zhàn)三：查詢(xún)優(yōu)化（Query Optimization）
- 挑戰(zhàn)四：資源調(diào)度（Resource Scheduling）
HTAP 數(shù)據(jù)庫(kù)
這一章節(jié)主要調(diào)研現(xiàn)有 HTAP 數(shù)據(jù)庫(kù)的主要架構(gòu)，作者這里分成了四大架構(gòu)：
- 主行存儲(chǔ)+內(nèi)存中列存儲(chǔ)（Primary Row Store + InMemory Column Store）
- 分布式行存儲(chǔ)+列存儲(chǔ)副本（Distributed Row Store + Column Store Replica）
- 磁盤(pán)行存儲(chǔ)+分布式列存儲(chǔ)（Disk Row Store + Distributed Column Store）
- 主列存儲(chǔ)+增量行存儲(chǔ)（Primary Column Store + Delta Row Store）
a.主行存儲(chǔ)+內(nèi)存中列存儲(chǔ)
這類(lèi) HTAP 數(shù)據(jù)庫(kù)利用主行存儲(chǔ)作為 OLTP 工作負(fù)載的基礎(chǔ)，并使用內(nèi)存列存儲(chǔ)處理 OLAP 工作負(fù)載。所有數(shù)據(jù)都保存在主行存儲(chǔ)中。行存儲(chǔ)也是內(nèi)存優(yōu)化的，因此可以有效地處理數(shù)據(jù)更新。更新也會(huì)附加到增量存儲(chǔ)中，增量存儲(chǔ)將合并到列存儲(chǔ)中。例如，Oracle 內(nèi)存雙格式數(shù)據(jù)庫(kù)結(jié)合了基于行的緩沖區(qū)和基于列的內(nèi)存壓縮單元 (IMCU) 來(lái)一起處理 OLTP 和 OLAP 工作負(fù)載。文件和更改緩存在快照元數(shù)據(jù)單元 (SMU) 中。另一個(gè)例子是 SQL Server，它在 Hekaton 行引擎中的內(nèi)存表上開(kāi)發(fā)了列存儲(chǔ)索引 (CSI)，以實(shí)現(xiàn)實(shí)時(shí)分析處理。這種類(lèi)型的 HTAP 數(shù)據(jù)庫(kù)具有高吞吐量，因?yàn)樗泄ぷ髫?fù)載都在內(nèi)存中處理。
優(yōu)勢(shì)：
- TP 吞吐量高
- AP 吞吐量高
- 數(shù)據(jù)新鮮度高
劣勢(shì)：
- AP 擴(kuò)展能力低
- 負(fù)載隔離性低
應(yīng)用：
高吞吐、低擴(kuò)展（比如需要實(shí)時(shí)分析的銀行系統(tǒng)）
案例研究1：Oracle Dual-Format
- SIMD：?jiǎn)沃噶疃鄶?shù)據(jù)
- Max-Min Zone Map
- Vector Group By：向量化
案例研究2：SQL Server
- Persistent Column Store：持久化列存
- Updatable：可更新
總結(jié)
b.分布式行存儲(chǔ)+列存儲(chǔ)副本
此類(lèi)別依賴(lài)于分布式架構(gòu)來(lái)支持 HTAP。主節(jié)點(diǎn)在處理事務(wù)請(qǐng)求時(shí)將日志異步復(fù)制到從節(jié)點(diǎn)。主存儲(chǔ)為行存儲(chǔ)，選擇一些從節(jié)點(diǎn)作為列存儲(chǔ)服務(wù)器進(jìn)行查詢(xún)加速。事務(wù)以分布式方式處理以實(shí)現(xiàn)高可擴(kuò)展性；復(fù)雜查詢(xún)?cè)诰哂辛写鎯?chǔ)的服務(wù)器節(jié)點(diǎn)中執(zhí)行。
優(yōu)勢(shì)：
- 負(fù)載隔離性高
- 擴(kuò)展性高
劣勢(shì)：
- 數(shù)據(jù)新鮮度低
應(yīng)用：
對(duì)TP和AP擴(kuò)展性要求比較高，同時(shí)能夠容忍相對(duì)較低的數(shù)據(jù)新鮮度（比如需要實(shí)時(shí)分析的大規(guī)模電商系統(tǒng)）
案例研究：F1 Lightning
總結(jié)
c.磁盤(pán)行存儲(chǔ)+分布式列存儲(chǔ)
這種數(shù)據(jù)庫(kù)利用基于磁盤(pán)的 RDBMS 和分布式內(nèi)存列存儲(chǔ) (IMCS) 來(lái)支持 HTAP。 RDBMS 保留了 OLTP 工作負(fù)載的全部容量，并且深度集成了 IMCS 集群以加速查詢(xún)處理。列數(shù)據(jù)從行存儲(chǔ)中提取，熱數(shù)據(jù)駐留在 IMCS 中，冷數(shù)據(jù)將被驅(qū)逐到磁盤(pán)。例如，MySQL Heatwave將 MySQL 數(shù)據(jù)庫(kù)與稱(chēng)為 Heatwave 的分布式 IMCS 集群相結(jié)合，以實(shí)現(xiàn)實(shí)時(shí)分析。事務(wù)在 MySQL 數(shù)據(jù)庫(kù)中完全執(zhí)行。經(jīng)常訪問(wèn)的列將被加載到 Heatwave。當(dāng)復(fù)雜查詢(xún)進(jìn)來(lái)時(shí)，可以下推到IMCS引擎進(jìn)行查詢(xún)加速。
優(yōu)勢(shì)：
- 負(fù)載隔離性高
- AP吞吐量和擴(kuò)展性高
劣勢(shì)：
- 數(shù)據(jù)新鮮度不高
- Medium（On-premise）：部署在本地，在不同機(jī)器上會(huì)有數(shù)據(jù)新鮮度的犧牲
- Low（Cloud-based）：部署在云端，網(wǎng)絡(luò)延遲會(huì)影響數(shù)據(jù)新鮮度
應(yīng)用：
對(duì)AP擴(kuò)展性要求比較高，同時(shí)能夠容忍相對(duì)較低的數(shù)據(jù)新鮮度（比如需要實(shí)時(shí)分析的IoT應(yīng)用）
案例研究1：MySQL Heatwave
- Auto-pilot service：自動(dòng)調(diào)優(yōu)（一些云服務(wù)，可以在系統(tǒng)中自動(dòng)幫客戶(hù)實(shí)現(xiàn)數(shù)據(jù)分區(qū)、查詢(xún)優(yōu)化和資源調(diào)度等等）
- Auto-Sunc：自動(dòng)同步（可實(shí)現(xiàn)定時(shí)定量同步數(shù)據(jù)）
案例研究2：Oracle RAC
- Auto-Sunc：自動(dòng)同步（基于閾值的方式）
總結(jié)
d.主列存儲(chǔ)+增量行存儲(chǔ)
此類(lèi)數(shù)據(jù)庫(kù)利用主列存儲(chǔ)作為 OLAP 的基礎(chǔ)，并使用增量行存儲(chǔ)處理 OLTP。內(nèi)存中的 delta-main HTAP 數(shù)據(jù)庫(kù)將整個(gè)數(shù)據(jù)存儲(chǔ)在主列存儲(chǔ)中。數(shù)據(jù)更新附加到基于行的增量存儲(chǔ)。OLAP 性能很高，因?yàn)榱写鎯?chǔ)是高度讀取優(yōu)化的。但是，由于 OLTP 工作負(fù)載只有一個(gè)增量行存儲(chǔ)，因此 OLTP 的可伸縮性很低。一個(gè)代表是 SAPHANA 。它將內(nèi)存中的數(shù)據(jù)存儲(chǔ)分為三層：L1-delta、L2-delta 和 Main。 L1-delta以逐行格式保持?jǐn)?shù)據(jù)更新。當(dāng)達(dá)到閾值時(shí)，將 L1-delta 中的數(shù)據(jù)附加到 L2-delta。 L2-delta 將數(shù)據(jù)轉(zhuǎn)換為列數(shù)據(jù)，然后將數(shù)據(jù)合并到主列存儲(chǔ)中。最后，將列數(shù)據(jù)持久化到磁盤(pán)存儲(chǔ)。
優(yōu)勢(shì)：
- 數(shù)據(jù)新鮮度高
- AP吞吐量高
劣勢(shì)：
- TP可擴(kuò)展性不高
- 負(fù)載隔離性不高
應(yīng)用：
高AP吞吐量、高數(shù)據(jù)新鮮度（比如需要實(shí)時(shí)分析的風(fēng)控系統(tǒng)）
案例1：SAP HANA
案例2：Hyper（Column）
總結(jié)
四種架構(gòu)HTAP數(shù)據(jù)庫(kù)的對(duì)比
HTAP 技術(shù)
HTAP的相關(guān)技術(shù)包括（1）事務(wù)處理； (2)分析處理； (3) 數(shù)據(jù)同步；(4) 查詢(xún)優(yōu)化； (5)資源調(diào)度。這些關(guān)鍵技術(shù)被最先進(jìn)的 HTAP 數(shù)據(jù)庫(kù)采用。然而，它們?cè)诟鞣N指標(biāo)上各有利弊，例如效率、可擴(kuò)展性和新鮮度等等。
這個(gè)部分我們留到下一篇文章再做討論
StoneDB 已經(jīng)正式開(kāi)源，歡迎關(guān)注我們
