在最新一屆國際資料庫頂級會議 ACM SIGMOD 2022 上，來自清華大學的李國良和張超兩位老師發表了一篇論文：《HTAP Database: What is New and What is Next》,並做了 《HTAP Database：A Tutorial》 的專項報告。 本篇文章，我們將 ...
在最新一屆國際資料庫頂級會議 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 起源動機問題，這個其實大家看過我們之前的文章StoneDB：什麼是真正的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 預計 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的相關思考我們之前在對外的分享會上也屢次提及，感興趣的同學可以前往B站觀看我們最近一期的線上Meetup視頻：
3. Challenges for HTAP databases
作者這裡提出了HTAP資料庫面臨的四大挑戰，這裡也和我們的第二篇文章里的觀點不謀而合，可以說完全在我們提出的8點挑戰範圍之內：
- 挑戰一：數據組織（Data Organization）
- 挑戰二：數據同步（Data Synchronization）
- 挑戰三：查詢優化（Query Optimization）
- 挑戰四：資源調度（Resource Scheduling）
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
- SIMD：單指令多數據
- Max-Min Zone Map
- Vector Group By：向量化
案例研究2：SQL Server
- 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 control for main-memory database systems. In SIGMOD ,2015.
總結
架構(d)的兩個HTAP資料庫對比
四種架構HTAP資料庫的對比
Part3 HTAP 技術
HTAP的相關技術包括（1）事務處理； (2)分析處理； (3) 數據同步；(4) 查詢優化； (5)資源調度。這些關鍵技術被最先進的 HTAP 資料庫採用。然而，它們在各種指標上各有利弊，例如效率、可擴展性和新鮮度等等。
這個部分我們留到下一篇文章再做討論。
StoneDB 已經正式開源，歡迎關註我們
Github: https://github.com/stoneatom/stonedb
Slack: https://stonedb.slack.com/ssb/redirect#/shared-invite/email
本文作者：李明康
