TDSQL | 深度解讀HTAP系統的問題與主義之爭

近日，第12屆中國資料庫技術大會（DTCC 2021）在北京國際會議中心召開。作為全球領先的雲端計算、資料庫產品服務商，騰訊雲資料庫集結多位頂級技術大咖亮相本次大會，圍繞當前比較熱門的資料庫技術主題，共同探討最前沿的技術趨勢與實踐。

本期為大家帶來騰訊專家工程師朱閱岸老師在本次大會上的分享，主題為**“HTAP系統的問題與主義之爭”**。以下是分享實錄：

問題與主義之爭其實是上世紀初胡適與李大釗之間的一場論戰。胡適主張改良，提倡解決一個個問題，也就是少談些主義，多研究些問題；而李大釗則主張改革，認為只有解決了這個根本問題，其他的問題才能解決，二人代表著兩個截然不同的路線。其實圍繞著HTAP系統的演進也存在類似兩條路線，一條路線是改良，一個路線是通過改革的方式打造全新的系統。今天我就為大家分享HTAP系統的技術實現相關路線。

# 1. HTAP的定義與挑戰

我們先來解釋HTAP的定義與挑戰是什麼。下圖是經典的資料處理框架，我們在裡面劃分出兩種資料庫系統：一種是事務型的系統，這是資料來源頭產生的地方；另一種是分析型的系統，是我們的數倉。資料會定期從交易型資料庫中藉助ETL的方式流入到數倉. 然後在資料倉儲做分析處理，產生相應的報表和報告。企業的經營決策者能夠通過分析報告和決策報表去觀察企業的經營行為，從而觀察到未來的發展趨勢。這是資料寶貴之處的體現之一。不少公司都在資料基礎設施上投入人力物力，期待在資料變現上獲得更好的回報。

研究表明，這些樣本公司在每13美金的投入中就有1美金投入到資料分析裡，有74%的公司想成為一個資料驅動型的公司，如果一個公司採用更為先進的資料分析手段，那它超越競爭對手的可能性將達到兩倍。

**資料分析具備巨大的商業價值。但在目前的資料處理框架中，OLTP和OLAP兩類系統是割裂開的**，主要是通過ETL把資料從交易型資料庫匯入到分析型資料庫，而ETL的時延比較大，可以達到數十分鐘到幾小時，甚至是幾天。上圖右下角的圖片顯示，資料的商業價值會隨著時間的流逝而下降。資料產生再經過ETL匯入到數倉，在數倉裡進行分析，然後做決策，執行相應的動作。在這時，資料的商業價值就會大打折扣。

因此最理想的情況是在資料產生後就能迅速對其進行分析。為了解決這個問題， HTAP系統應運而生，它的初衷就是要打破事務處理和分析處理的界限，使企業能夠通過HTAP系統更好地發現市場反饋，獲得更好的創新。這麼先進的資料處理技術，為什麼近年來才引起人們的關注呢？我個人認為，這主要得益於現代列儲存技術的發展，HTAP系統的出現才成為了可能。

以前客戶用SQL Server做查詢分析處理，需要十多個小時以上。在這種技術能力下是無法達到實現HTAP系統要求的。後來SQL Server採用列儲存技術，耗時十幾個小時的分析可以降到幾分鐘，甚至可以在秒級時間內把結果執行出來。列儲存技術及背後的向量查詢引擎的發展，使得HTAP登上了歷史舞臺。

**HTAP能讓資料產生後馬上就可以進入分析場景**。但它面臨最大的問題是如何把OLTP和OLAP兩類工作負載更好放在一個系統上執行，畢竟這兩類工作負載本質上是互斥的。交易型的事務是短事務，以寫為主；分析型的事務是長事務，以讀為主，經常需要做全表掃描，在掃描的基礎上做統計、聚合等操作。這種情況下，OLAP的事務經常需要獨佔系統資源，使交易型的事務吞吐量下降。有研究表明，把OLTP和OLAP放在一個系統裡排程，OLTP的吞吐量可能會下降到原本的1/3到1/5。所以如何讓OLTP和OLAP在系統執行的過程中相互干擾最小，就成為HTAP系統設計的難題。

從過去十多年的發展來看，主要有兩種實現HTAP的方案：第一種是改良的方式，在現有業務系統上延伸擴充套件，打造一個HTAP的系統來滿足業務的需要，；第二種是從頭開始設計一個具有顛覆性的系統. 當然第二種方式會產生更多有價值的技術，也會涉及到比較多技術難題，包含技術突破、業務適配等。

從現在來看很難說哪種更好，今天的分享我們也不回答哪一條路線更好，我們會在這兩條路線上挑選典型的具有鮮明技術特色的系統，來和大家分享，同時會在最後給出最近十年來HTAP系統技術的演變過程和發展趨勢。

# 2. HTAP系統的架構實踐

**2.1 HTAP系統的類別**

總體來看，HTAP系統架構的實踐可以分成兩類：一類是改革，另一類是改良。前者採用One size fits all的策略，用一個大而全的系統同時滿足OLTP和OLAP的需求，後者採用One size doesn’t fit all模型，將OLTP和OLAP兩種系統組合起來，通過CDC的方式把OLTP上產生的資料以增量的方式匯入到數倉進行分析。

第一類下又分為兩個子類。第一個子類是單拷貝系統，在一個系統裡用一種資料格式滿足兩種業務需求，通常是採用PAX儲存。系統整體來看是採用行儲存，但是當它把資料打包儲存到某個頁面時轉換成列儲存的形式。另一種是雙拷貝系統，一個系統裡同時存在行儲存和列儲存，行儲存上的更新會定期匯入到列儲存裡轉換成列儲存格式。在列儲存上進行分析，行儲存上執行更新。這在某種程度上降低了它們的競爭。第二類可以分為共享儲存和獨立儲存兩個子類。

下圖右上角就是這四種型別的系統實現HTAP特徵時的比較，可以從兩個維度來刻畫，**一是資料新鮮度，二是工作負載干擾程度。**

One size fits all策略把OLTP和OLAP兩種工作負載放在一個系統上，如圖1左上角，就干擾程度而言，OLTP和OLAP相互干擾最強，而單系統單拷貝方式尤為明顯，其次就是單系統雙拷貝的方式。這兩種實現方式的缺點是OLTP/OLAP的干擾比較大會導致事務工作負載的吞吐嚴重下降，但優點是資料可見度高，因為不需要做資料的同步匯入匯出或資料轉換。

One size doesn’t fit all 即鬆耦合模型也有兩種類別，橙色橢圓代表共享儲存下的鬆耦合系統，好像目前還沒有有商業化的產品，只有IBM出了一個DEMO；另一種是採用類似proxy方式把TP與AP兩種獨立系統組合起來的鬆耦合系統。這兩類系統中，OLTP和OLAP分別在兩個獨立的系統上進行，可以把干擾降到最小，但資料需要同步，交易型資料庫更新的資料要通過CDC的方式同步到分析型系統上，資料的延遲會比較大。

列出了幾個典型的HTAP工作負載對時延的需求。系統監控的延遲在20毫秒，線上遊戲、個性化廣告推薦、商品價格監控，則是在100-200之間。

**2.2 單系統單拷貝之Hyper**

接下來我們從四類系統實踐中挑選部分代表性的系統來看HTAP技術如何具體實現。首先是Hyper。Hyper是很典型的系統，它原本是德國慕尼黑工業大學的 Thomas Neumann教授團隊開發的原型產品，但是效能與創新性實在太好，後來被美國tableau公司收購，從學術型的產品變成了商業化的產品，不論從技術與經歷都具有較高的代表性。

Hyper的查詢執行模式很有考究。OLTP是序列執行，不需要加鎖。這是因典型OLTP資料庫把大部分時間都消耗在加鎖、緩衝區管理、日誌管理上，這些操作消耗了系統80%左右的資源。在Hyper中沒有這些開銷，事務序列執行，去除維護事務隔離性等開銷。一個事務序列執行的耗時只有微秒級別，這個是可以接受的。VoltDB是類似的一個系統，事務執行同樣不需要加鎖，序列地執行（通過分片達到並行執行的效果）。OLAP則通過fork產生子程式在事務一致性的拷貝上執行查詢。更新時再把相關的資料頁拷貝出來，讓交易型事務在不同的資料頁上進行更新（Copy-on-Write）。

此外通過區分冷熱資料的方式，把資料分成熱資料、冷資料和溫資料。上圖右下角就是通過硬體的方式即MMU的記憶體管理單元去區分資料的訪問熱度。熱資料放在正常頁面即小頁面上，冷資料是壓縮儲存，放在4M的大頁面上。這種做法的好處是更新代價比較小，同時在做OLAP查詢的時候，在大頁面上會有比較好的效能。

Hyper的查詢引擎也是相當優秀的，它利用向量化的查詢引擎，用LLVM生成可執行的機器碼。這個技術非常具有代表性，連著名的Spark也參考了它的程式碼生成技術。

**2.3 單系統單拷貝之SAP HANA**

HANA也是採用單系統單拷貝實現HTAP。它不太像一個資料庫系統，反而像是一個支援多引擎多工作負載型別的統一資料管理平臺。HANA系統的分層結構做得很好，總體來看可以分為編譯層和執行層，上層又可以分為查詢的解析，生成抽象語法樹AST，再對映到計算圖模型，接著對計算圖模型進行物理優化。此後由分散式執行框架去構建實際的資料流，將具體的物理執行運算元分發到特定的引擎執行。因為HANA支援多個工作引擎，比如資料倉的查詢引擎、文字、圖等，它向上提供了針對這些特定引擎的物理運算元，比如關係操作運算元、圖計算的運算元等。

執行引擎下又有統一的表模型。它向上提供一個統一的介面，類似於MySQL下的handler介面，下面的儲存引擎負責實現具體的儲存，上面的查詢執行器只要實現handler介面就可以對接到系統裡去。裡面的儲存分成三級：首先是L1-delta，對應的是熱資料和無壓縮的行儲存；其次是L2-delta，對應的是輕量級壓縮的列儲存，比如字典壓縮；最後是L3-main store，對應的是重度壓縮列儲存。更新發生在L1-delta，資料會定量地匯入到Main store裡。Main store是讀友好的實現方式，滿足AP型別的查詢，而L1-delta是寫優化的實現。通過這種方式來滿足HTAP的需求。

它會定期地執行合併操作，把資料定期地合併到Main store裡。在合併操作的過程中會生成Main2和Delta2，這時讀操作就在Main1、Delta1和Delta2進行。拷貝完成以後Main1和Delta1最終會合併到Main2，最後切換過來，在Main2上進行讀操作，寫操作發生在Delta2。資料加鎖的行為只是發生在緩衝區切換階段。L1-delta採用redo日誌保持永續性，Main store採用影子頁技術減少日誌的寫入，保持一致性與永續性。

**2.4 單系統雙拷貝之SQL Server**

SQL Server是一個雙拷貝系統，把資料按行切分成group，定期轉變成列儲存。具體來說是，每一百萬條資料做一個Group，進行切分，然後針對每列轉換成列儲存，叫做segment。每個列採用單獨的壓縮演算法，比如有些適合用字典壓縮，有些適合用數值壓縮，因此不同的列採用不同的壓縮演算法。轉換後的列儲存附加額外字典表（如有），儲存到Blob型別中。外面的directory追蹤這些segment的存放位置。SQL Server也針對列儲存提供了批量執行的演算法，加速分析操作。

**2.5 單系統雙拷貝之Oracle**

Oracle是另外一個採用雙拷貝方式實現HTAP的系統，每個系統裡針對有需要的表，會同時存在一份行儲存和列儲存，在列儲存上做分析操作；在行儲存上進行更新，定期同步到列儲存裡。系統可以靈活指定需要採用行存與列存的表，也可以系統執行時更改表特性。Oracle利用RAC叢集進行橫向擴充。

這裡舉兩個例子，來介紹Oracle是如何利用列儲存加速分期操作的。假如我們查詢Outlet這個商店型別所有的銷售額，首先掃描維表，根據“type把Outlet型別的商店ID拿到，生成一個map”，接著在事實表的對於外來鍵列裡把商品ID拿出來在這個map查詢，如果找到就可以把Amount累加起來。它通過只掃描某些特定的列，生成相關的map，就可以把要訪問的資料找出來，即把關聯操作簡化成表掃描操作，提升效能。

另外一個比較複雜的是要掃描兩個維表，生成兩個vectors，在裡面再去事實表找相關的外來鍵列，就可以直接定位到相關的vector，如果符合條件，就分類寫到相應的臨時表裡。優點在於可以把表關聯操作轉換成表掃描操作，只需要訪問查詢中涉及到的列。

**2.6 鬆耦合共享儲存之Wildfire**

目前還沒有商業化的HTAP產品採用鬆耦合共享儲存架構，但是IBM開發了一個原型，叫Wildfire。從技術細節來看，它的系統分成兩類節點：一類是有狀態的節點，一類是無狀態的節點。有狀態的節點處理事務型的請求，無狀態的節點處理OLAP型的請求。OLAP型的請求可以容忍一定的延遲。

OLTP型的資料不會直接寫入到共享檔案系統裡，會寫入私有組成的一個叢集，按照表分片的模式在這裡進行資料的快速寫入，再定期匯入到共享檔案系統裡，然後供分析型查詢去執行。分析型查詢會自己去定製一個引擎，去對接spark executor。這個引擎是無狀態的，可以去定製修改，在資料分析領域也是比較強悍的引擎，叫BLU，是IBM自家的分析執行引擎。總體上看，這個系統分成兩個叢集：一個是OLTP，一個是OLAP。

國內有部分產品的技術和該架構比較類似，利用spark的能力和生態去做分析型查詢，比如利用spark的查詢優化器和機器學習能力去構建OLAP能力，OLTP能力則自己構建，這樣就把資料和這兩套系統在某種程度上做了一定的融合，變成HTAP。

**2.7 鬆耦合獨立儲存之F1 Lightning**

鬆耦合獨立系統近幾年比較流行，有兩個典型代表，一個是谷歌的F1 Lightning，另外一個是IBM的IDAA。我們先來介紹F1 Lightning。

F1 Lightning把系統分成三個模組：OLTP資料庫、Lightning、查詢執行引擎。Lightning通過Changepump捕獲OLTP資料庫的更新，以訂閱的方式把資料分發到訂閱者。Lightning內部還開發了一個介面卡，將CDC的模式轉換成內部統一的格式。內部有兩級儲存：記憶體儲存和磁碟儲存。記憶體儲存是以行儲存的模式存在，採用B-tree索引，在這裡沒有轉換成列儲存，只有在資料寫入磁碟時才把行儲存轉換成列儲存。上層查詢通過快照的機制讀取可見範圍的相關資料。F1 Lightning將捕獲的日誌分成兩層儲存,為日誌維護系統範圍的檢查點時間戳以及為適配不同資料庫而設計的客戶端介面很大程度上借鑑了Databus。這種實現方式帶來的問題是查詢延遲。從谷歌的測試來看，查詢延遲在8-10分鐘之間。因為採用CDC方式，要把OLTP資料轉換成CDC內部統一的格式，再批量提交，因此延遲會比較大。

**2.8 鬆耦合獨立儲存之IDAA**

接下來介紹IBM的IDAA。最初IBM也開發了類似鬆耦合的HTAP架構。下圖中左邊是Db2，右邊是他們的Warehouse，掛載到事務型引擎，事務型引擎將更新定期同步。但IBM系統設計者認為，CDC方案需要花費大量的時間和背景知識來維護額外的程式，且延遲比較大。基於這個原因，他們對此進行了改進，通過輕量級的整合同步方案規避上述問題，將延遲減少180倍。

CDC的方案需要在源端經歷6個步驟：讀取資料，解密；過濾無關的日誌，按照LSN排序；之後還要對資料進行行列轉換；把資料暫存起來，把資料轉換成CDC統一內部的格式；再批量等待commit或Rollback，傳送之前還要把Rollback資料去除。這種情況對源端的壓力是比較大的，延遲也會比較大。

IDAA則建議把這幾個步驟都挪到目的端執行。目的端能夠原生地識別從Db2裡傳輸過來的資料，當然這個是比較定製化的方案，通用性沒那麼好，但延遲可大幅降低，只有原來的1/180。現在延遲只有1-2秒左右就能讀到最新的資料。

**2.9 HTAP技術發展一覽**

這部分我們來對HTAP近10年來的發展脈絡做梳理。圖中的直線方向表示後者的技術借鑑前驅或者是從該產品演變過來的。

從圖上可以看到，HTAP技術在2015、2016年之前主要是以One size fits all 策略為主，2015、2016年以後則以鬆偶合架構為主。這幾年如F1 Lightning、IDAA等都是採用鬆偶合方式來實現HTAP，甚至SAP也是有采用鬆偶合的技術方案實現HTAP。從One size fits all 的演變趨勢來看，大多是從雙拷貝轉換成單拷貝，從行儲存轉換成單一的列儲存來應對OLTP/OLAP的請求。從原先在磁碟上用列儲存，到記憶體裡用行儲存，再到現在統一改成列儲存。這就是最近10年來HTAP技術的演變趨勢。

# 3. 雲原生對於HTAP系統的啟示

這一部分我們來看看雲原生架構對HTAP系統實現是否能帶來幫助。

下面是三個值得思考的問題：首先是雲原生架構即存算分離架構能否為HTAP的設計帶來便利？其次是存算分離架構和彈性算力能否緩解資源競爭？因為這兩條技術下的系統，在資源競爭和資料可見度上的表現各有優缺點，並不能說哪種產品的表現最優，都是在資料延遲和資源爭用上做取捨。此外，雲環境下豐富的計算資源池和儲存資源池能否針對不同的計算、不同的業務特徵進行劃分從而降低使用者的成本，這也是值得大家去思考的問題。

下圖是我構想中的願景圖。總體來看，理想的情況是，在一個雲原生架構裡，Share storage和Query processing 分層，在查詢入口處採用多租戶設計，這裡執行查詢解析和查詢的優化，然後把查詢的執行推到查詢執行層。

查詢執行層分為有狀態和無狀態兩種，分別處理與OLTP和OLAP相關的請求。共享儲存層Share storage針對工作模式和工作負載採取不同的儲存設計策略。在OLAP方面可以主打價效比，用物件儲存和糾錯編碼模式降低成本。AWS Redshift團隊的調研也表明，OLAP型的使用者會更加關注成本，所以在Share storage裡OLAP方面可以偏向價效比的權衡。而OLTP資料儲存則採用高效能的儲存，優化事務提交的關鍵路徑，達到使用者最優體驗，比如說高效能Nvme，加速事務的提交速度，然後定期把資料從OLTP型儲存匯入到OLAP型的儲存。

希望在不久的未來，可以看到相關廠商或資料庫開發者實現這樣的方案或技術特徵。

# 4.總結

總體來看，**HTAP已有的問題是OLTP和OLAP這兩種互斥的屬性，如何在一個系統裡共存而干擾儘可能小，資料可見度延遲儘可能短。**

目前存在兩種架構實踐：一種是One size fits all，用一個資料庫系統來滿足OLTP和OLAP多樣化工作負載的需求；對系統相關的架構革新，針對兩種工作負載的特性做更好的適配優化。另外一種是採用鬆偶合的方式，通過CDC把兩類系統黏合起來，在上面架構一個類似於proxy的東西，為使用者呈現出一個系統的表象，使用者感知不到OLAP型系統的存在。這種方案能更好地降低兩類工作負載對資源的競爭，但是由於需要跨系統進行資料同步因此延遲較大。而前一種方案雖然資源競爭比較大，但不需要對資料進行跨系統同步，因此延遲比較小，資料能見度、新鮮度高，可以滿足緊急型任務的需求。

展望未來，我們認為雲原生的彈性算力可能更適合HTAP系統，在雲原生上會誕生更優秀的HTAP系統。