深度乾貨!一篇 Paper 帶您讀懂 HTAP | StoneDB 學術分享會第①期

語言: CN / TW / HK
在最新一屆國際資料庫頂級會議 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 技術未來的研究方向與挑戰。
本文僅作精選分享,會省略一些非必要內容,如想了解更多,請閱讀原報告。
 

Part1 背景介紹

1. Motivation

開頭還是一個老生常談的 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<br>be widely adopted in the business applications<br>with real-time data analytics by 2024.

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(短時延事務)
  1. 列存(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 for workload isolation and data freshness
 
這裡關於Trade-off的相關思考我們之前在對外的分享會上也屢次提及,感興趣的同學可以前往B站觀看我們最近一期的線上Meetup視訊:

3. Challenges for HTAP databases

作者這裡提出了HTAP資料庫面臨的四大挑戰,這裡也和我們的第二篇文章裡的觀點不謀而合,
 
可以說完全在我們提出的8點挑戰範圍之內:
  • 挑戰一: 資料組織 (Data Organization)
  • 挑戰二: 資料同步 (Data Synchronization)
  • 挑戰三: 查詢優化 (Query Optimization)
  • 挑戰四: 資源排程 (Resource Scheduling)
Challenges for HTAP databases

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

Lahiri, Tirthankar, et al. "Oracle database in-memory: A dual format in-memory<br>database." In ICDE, 2015.
 
  • SIMD:單指令多資料
  • Max-Min Zone Map
  • Vector Group By:向量化

 

案例研究2:SQL Server

Larson, Per-Åke, et al. "Real-time analytical processing with<br>SQL server.” PVLDB 8(12), 2015: 1740-1751.
 
  • 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<br>control for main-memory database systems." In SIGMOD ,2015.

總結

架構(d)的兩個HTAP資料庫對比

四種架構HTAP資料庫的對比

Part3 HTAP 技術

HTAP的相關技術包括(1)事務處理; (2)分析處理; (3) 資料同步;(4) 查詢優化; (5)資源排程。這些關鍵技術被最先進的 HTAP 資料庫採用。然而,它們在各種指標上各有利弊,例如效率、可擴充套件性和新鮮度等等。
 
這個部分我們留到下一篇文章再做討論。
 
StoneDB 已經正式開源,歡迎關注我們
官網:https://stonedb.io/
Github: https://github.com/stoneatom/stonedb
Slack: https://stonedb.slack.com/ssb/redirect#/shared-invite/email