HTAP 資料庫如何實現？淺析 ZNBase 中的列存引擎

作者：馬靜偉

編輯：大東BE

導讀

TP 與 AP 融合的 HTAP 資料庫正成為業內的發展趨勢。但由於大規模資料場景下 TP 與 AP 系統本身的複雜性，要在一套資料庫系統中融合兩種使用場景的功能並不容易。浪潮推出的 HTAP 資料庫 ZNBase 採用多模儲存引擎的方案實現 HTAP 特性，在 OLTP 的基礎上引入列存引擎支撐 OLAP 場景。本文將著重介紹列存引擎技術在 HTAP 資料庫 ZNBase 中扮演的重要角色。

OLTP 與 OLAP

名詞釋義OLTP，全稱 On-Line Transaction Processing，翻譯為聯機事務處理OLAP，全稱 On-Line Analytical Processing，翻譯為聯機分析處理

從上個世紀 60 年代開始，計算機系統就被人們用於執行薪資結算、會計和計費等領域的任務。那時，使用者輸入資料，計算機系統再對資料進行處理，從而完成一系列的增刪改查操作，這就是早期的 OLTP 。隨著計算機技術與資料庫技術的進一步發展，OLTP 在政府、銀行和企業資訊系統中被廣泛應用至今。如今，OLTP 被認為是一種低延遲、高容量、高併發工作負載，通常用於開展業務，例如接訂單和履行訂單，進行裝運，為客戶開賬單，收款等事務處理。

而 OLAP 被認為是分析工作負載。OLAP 面對的場景是相對較高的延遲，較低的數量和較低的併發工作負載，這些負載通常用於通過分析運營，歷史和大資料，制定戰略決策或採取措施來提高公司績效，提升產品質量，改善客戶體驗，進行市場預測等。隨著近年來大資料技術的興起，企業對資料分析的場景在時效性方面有了更高的要求，大規模資料下的 OLAP 也開始成為眾多企業的剛需。

在網際網路流量爆發之後，在面對海量資料時，OLTP 和 OLAP 系統的資訊體系結構和基礎結構各不相同，同時又具備各自的複雜性，因此這兩種應用場景分別有不同的產品來滿足使用者需求。這一時期，企業通常採取「事務型資料庫系統+分析型資料庫系統+ETL 工具」的組合方案來實現大規模資料儲存事務+分析的業務需求。

HTAP 的出現

這種採用不同系統來針對不同場景進行資料處理的方案也帶來了相應的難題。因為 TP 和 AP 是跨平臺的，所以在搭配使用時就會有資料傳輸的過程，這就帶來了兩個挑戰：資料同步、資料冗餘。

資料同步的核心是資料時效性問題，過期的資料往往會喪失價值。以往的做法是，OLTP 系統中的資料變化，通過日誌的形式暴露出來；通過訊息佇列解耦傳輸；後端的 ETL 消費拉取，將資料同步到 OLAP 中，形成一套 TP 到 AP 的資料傳輸鏈條。由於整個鏈條較長，這就對時效性要求較高的場景提出了考驗。

另一方面，資料在鏈條中流動，存在多份的資料冗餘儲存。在常規的高可用環境下，資料會進一步儲存多份。因此帶來了更大的技術、人力成本以及資料同步成本。同時橫跨如此多的技術棧、資料庫產品，每個技術棧背後又需要單獨的團隊支援和維護，如 DBA、大資料、基礎架構等，這些都帶來了巨大的人力、技術、時間、運維成本。

2014 年，Gartner 提出了一種混合事務/分析處理的新型資料庫模型 HTAP，旨在打破 OLTP 與 OLAP 系統間的隔閡，將二者融合到一個數據庫系統中，避免 ETL 跨平臺資料傳輸帶來的高昂成本。

隨著軟硬體基礎設施和資料庫技術不斷髮展，兼顧 OLTP 和 OLAP 負載的 HTAP 資料庫系統逐步替代傳統「事務型資料庫系統+分析型資料庫系統+ETL 工具」方案的趨勢已經形成。

ZNBase 和列存引擎

ZNBase 是由浪潮於近期開源的一款 HTAP 分散式資料庫，也是首個即將被開放原子開源基金會接納的國產資料庫項目。該資料庫系統為應對日益劇增的混合負載場景研發，能夠混合事務和分析場景，適用更多資料應用需求。為實現 HTAP 的特性，該資料庫系統中的列存引擎子系統在整個系統架構中扮演了重要的角色。

支撐 ZNBase 的 HTAP 功能的是多模儲存引擎，在其中結構化資料的處理上，儲存可以分成行存和列存，是分別針對 OLTP 和 OLAP 場景的優化，而支撐 OLAP 場景的就是的列存引擎。

列存引擎是 ZNBase 資料庫系統 HTAP 形態的核心元件，用於儲存和管理資料的列存副本，是行存引擎的擴展，列存引擎在提供良好隔離性的同時，也兼顧了讀時強一致性。列存副本通過 Raft Learner 協議非同步複製，但是在讀取的時候通過 Raft 校對索引方式達到 Learner 和 Leader 的同步。這個架構很好地解決了 HTAP 場景的隔離性以及列存同步的問題。

列存引擎架構介紹

列存引擎邏輯架構

列存引擎邏輯架構包含四個部分：

1） DDL 模組；

2） SQL 層向量計算模組；

3） 副本層 Raft 協議模組；

4） 儲存層的透明訪問模組和列存資料庫模組。

DDL 模組負責對錶的列存副本進行管理，它驅動元資料模組、Raft 協議模組和列存資料庫模型協同工作。向量計算模組負責從列存副本中讀取資料並進行向量計算，它讀取元資料模組，從合適的列存副本中讀取資料，完成計算並返回結果。Raft 協議模組負責處理行列副本一致性問題。透明訪問模組負責對上層提供統一儲存訪問介面，並遮蔽下層異構儲存引擎的差異，實現上層與儲存引擎的解耦；列存資料庫是列存引擎最底層儲存元件，負責以列存格式實際儲存列存副本資料。

列存引擎物理架構

列存引擎的物理架構分為三層：

1） 應用層：包括所有呼叫資料庫服務的客戶端應用程式；

2） 閘道器層：資料庫閘道器負責通過優化 SQL 路由，提升叢集整體執行效能。資料庫叢集採用全對等網路拓撲，叢集中的任何一個節點例項都可以處理 SQL，資料庫閘道器根據節點例項負載和資料分佈情況對 SQL 路由進行優化，將 SQL 傳送給較為合適的節點例項，例如將純 OLAP 負載傳送到某一組列存節點上。

3） 叢集層：叢集由角色和作用相同的多個節點例項組成，接收 SQL 的例項節點臨時充當 Master 的角色，負責驅動 SQL 的執行流程，與其他節點例項互動，並返回計算結果。每個節點例項可擁有多個 Store，每個 Store 可以被標記為不同的類型，目前可標記行存 Store 或列存 Store。列存 Store 底層採用列存資料庫，只能儲存列存副本。如果節點例項擁有的 Store 均為列存，則成為列存節點例項。從資源隔離的角度出發，可以將所有列存節點例項組成一個虛擬 OLAP 資料庫叢集，專門負責處理 OLAP 負載，且不對其他行存節點例項造成過大影響。

列存引擎的功能特性

列存引擎有幾大功能特性，向量計算、計算下推、列式儲存和非同步複製。

在具體實現上，列存引擎採用了 Clickhouse 並在其基礎上進行吸收優化。ClickHouse 本身是一套高效的列式儲存引擎，並且實現了資料有序儲存、主鍵索引、稀疏索引、資料 Sharding、資料 Partitioning、TTL 等豐富功能。

總結

作為一款新型的 HTAP 分散式資料庫系統，ZNBase 可以同時滿足事務、分析場景，避免繁瑣且昂貴的 ETL 操作。而列存引擎技術在這其中發揮了重要的作用。

列存引擎作為實現 HTAP 的關鍵技術，其非同步複製功能可以在保證事務處理效能的基礎上，達到分析場景準實時的效果，滿足使用者需求，優化使用者體驗。列存引擎植根於 ZNBase 資料庫中，繼承其強大的產品特性，使得其在原有高效能的 OLTP 能力基礎上，增強了對 OLAP 場景的處理能力，豐富了產品功能。

對於大部分資料庫使用者來說，最好的產品體驗就是開箱即用，無論是 TP 還是 AP 場景，如果能夠在同一個黑盒系統中完成所有操作，就能降低使用者心智負擔和運維成本。所以不難理解為何統一 TP 和 AP 處理的 HTAP 資料庫能夠成為受市場和使用者追捧的產品趨勢。