做者：馬靜偉git
編輯：大東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 數據庫可以成爲受市場和用戶追捧的產品趨勢。
關於 ZNBase 的更多詳情能夠查看：
官方代碼倉庫：https://gitee.com/ZNBase/zn-kvs
ZNBase 官網：http://www.znbase.com/
對相關技術或產品有任何問題歡迎提 issue 或在社區中留言討論。同時歡迎廣大對分佈式數據庫感興趣的開發者共同參與 ZNBase 項目的建設。