上一篇文章中，我們從技術和商業角度分析了 HTAP 系統緣起的背景，本篇文章中，我們將從 HTAP 定義及其相關核心技術等方面來討論：構建一個 HTAP 所面臨的核心問題和挑戰有哪些？

HTAP 涉及技術和對產品的影響

HTAP 是將 TP 和 AP 進行高度融合的產物， 而非簡單的 TP 和 AP 相加：TP+AP ≠ HTAP。有的資料庫讓 TP 系統通過簡單的數據同步方式（比如 Binlog等），將數據同步到 AP 系統，然後再由 AP 系統進行處理數據，雖然該種方式從用戶的角度來看似乎是獲得了同時處理 TP 和 AP 的能力，但是從本質上來看，這並不能稱為真正的 HTAP 產品，國內有一些資料庫廠商宣傳 HTAP 概念很起勁，但是自身可能還真不滿足 HTAP 的定義。下麵我們就 HTAP 所涉及到的幾個核心問題來探討一下，一個真正的 HTAP 產品需要具備哪些能力。
我們將從以下維度進行探討：

1. 架構選擇（Architecture choice）
2. 數據導入及查詢處理引擎 （Ingestion and query processing egnines）
3. 存儲方案 （Storage options）
4. 數據組織方案 （Data organization）
5. 事務語義（Transaction semantics）
6. 數據的時效性（Recency of data being read by OLAP)
7. 索引支持（Indexing supports）
8. AP 負載和 TP 負載的相互干擾（Workload interference）

當系統接收到一個查詢負載的時候，查詢處理模塊需要識別出該查詢負載中的 TP 負載和 AP 負載。並能夠依據相應的策略（這裡可以是基於規則或者是基於查詢代價），將相應的負載轉發至相應的處理引擎。

1. 架構的選擇
Single system（即 One system） 還是 Seperate system 的選擇當前更多是基於工程上的難度。目前不少產品均是在原有的 TP 系統之上，疊加了一個 AP 系統並使用某種數據同步工具將TP系統中的數據同步至AP系統中。Seperate system 雖然有其優點，但這種方案存在著許多不容忽視的問題，比如無法保證對事務的支持能力、數據的時效性，以及複雜的系統架構等（下文會有詳細的解釋）。相比之下，One system 不僅架構簡潔，對於事務的支持能力和數據的時效性等方面都能提供更好的保證。但是，One system 架構的技術難度相對較大，工程上也具有一定的難度，同時還需要考慮 TP 和 AP 負載間的相互干擾等問題。StoneDB 目前就是採用 One System 的架構設計，我們深知此架構的優勢和難度。

2. 查詢處理及數據導入引擎

該維度對產品有兩個方面的描述。由於 HTAP 所面臨的業務場景通常存著需要對海量數據進行分析處理需求，而在分析場景下，為了加速分析，通常的做法是將需要進行分析的數據，以列存的方式進行組織，這樣可以利用列存的優勢加速分析。因此，需要將適用於 TP 場景的行存類型數據轉為適用於 AP 場景的列存數據。對於一個 HTAP 資料庫首先需要解決的問題是高速的數據載入。這裡又包括兩個方面：

- 全量數據的載入方案，保證海量數據快速準確導入。

- 增量數據的更新方案，保證數據的時效性。

在數據載入完成後，另外一個維度是查詢處理。查詢處理部分屬於整個 HTAP 資料庫的核心模塊，其最重要的能力是能夠同時完成 TP 負載和 AP 負載的處理。
索引已成為 TP 系統的標配，通過設置索引可以大大提高資料庫的檢索速度，改善資料庫性能。而 AP 系統中的更新操作通常為批量更新，在更新時首先需要定位到待更新的數據，考慮到 AP 系統的數據組織和存儲模型，如何能夠通過設置索引快速定位到需要更新的數據（尤其是在以列存且數據多為壓縮形式的情況下）也是需要解決的一個難題。

3. 存儲方案

隨著存儲技術的進步，存儲介質和方式以及單位價格都發生了翻天覆地的變化，一個清晰的事實是：高速存儲介質正在廣泛地應用到資料庫領域。對於 HTAP 資料庫來說，TP 部分和 AP 部分的存儲方案選擇涉及到架構、性能、成本和業務場景等多方因素的影響。

4. 數據組織方案

選擇列存儲加行存儲（DSM + NSM），還是 PAX （Partition Attributes Across）方案或者是其它方案。數據組織方案的選擇不僅會極大的影響系統性能，還會影響數據的存儲成本。而系統的整體性價比也是我們挑選產品的重要指標之一。

5. 事務語義

需要具有支持完整的事務語義的能力，即無論是 TP 部分還是 AP 部分都需要對事務進行完整的支持。現有的很多 HTAP 解決方案，AP 系統中所處理的數據均是同步自 TP 系統中已提交的數據。這類解決方案存在以下幾個問題：首先，對應長事務場景下，如何保證 AP 系統可以獲得最新版本的數據值得我們仔細考慮。再者，通過以同步日誌的方式，數據的時效性和一致性需要認真考慮。最後，為瞭解決上述問題，會影響到事務的執行效率，導致系統吞吐量的下降。

6. 數據的時效性

需要保證 AP 系統所處理的數據均為當前最新版本的數據。當前的很多系統是在 TP 數據提交完成後，通過同步日誌的方式將 TP 部分的變更同步到 AP 部分，這種方式無法保證數據的時效性，因而不能稱之為真正的 HTAP 系統。

7.索引的支持

索引已成為 TP 系統的標配，通過設置索引可以大大提高資料庫的檢索速度，改善資料庫性能。而 AP 系統中的更新操作通常為批量更新，在更新時首先需要定位到待更新的數據，考慮到 AP 系統的數據組織和存儲模型，如何能夠通過設置索引快速定位到需要更新的數據（尤其是在以列存且數據多為壓縮形式的情況下）也是需要解決的一個難題。

8. 不同類型負載間的相互干擾

系統需要能夠保證 AP 負載對 TP 負載無影響或者使得兩種類型負載間的影響最小化。
上述討論了一個真正的 HTAP 系統應該具備的幾點核心能力，當然這些只是我們認為的核心能力，其它的相關問題這裡就不在展開，後續我們會陸續給出上述 HTAP 核心能力的詳細解讀。

從不同維度對現有 HTAP 產品/解決方案進行分類

現有的 HTAP 產品圖譜分類的主要方法：

1. 架構方式；
2. 存儲範式（Cloud/Shared Disk）；
3. 擴展方式（Scale out/Scale up）；
4. 查詢語句標準；
5. 併發策略（MVCC）；
6. 數據/表的組織方式；
7. 索引（LSM, ART, B-tree, lock-free Bw-Tree）。

下表從功能/許可證/是否開源等各個維度，對當前 HTAP 市場中的標桿產品進行了綜合分析。如需獲取更多信息，請訪問我們的官網：https://stonedb.io/

其它方面：多模能力等屬於非必要，這裡暫不考慮。



這裡我們將 ClickHouse 放進來，主要是考慮其在 AP 處理方面的優異能力，可以作為我們 HTAP 產品在 AP 方面的一個標桿。

HTAP所面臨的核心挑戰

綜上，我們可以總結出 HTAP 面臨的挑戰有：

1. 真正的 HTAP，而非 TP 與 AP 的疊加
2. 架構的選擇
3. 數據組織方案選擇，存儲方案選擇
4. 查詢優化：如何依據負載類型和查詢代價選擇合適的執行引擎
5. 數據的時效性：如何能夠減少 TP 和 AP 之間的數據移動，高效實時地將 TP 數據更新同步到 AP 數據中
6. 負載隔離：如何有效地消除或者最小化 TP 和 AP 負載之間的相互干擾
7. 資源管理：如何能夠高效的管理 TP 和 AP 負載之間的資源使用
8. 實時分析的能力
9. 事務語義支持

以上是對HTAP資料庫的部分挑戰梳理，在下一篇文章中，我們將對這些核心問題和挑戰展開更加深度的討論並給出選擇一款 HTAP 產品的建議。
StoneDB 是國內首款基於 MySQL 的一體化實時 HTAP 開源資料庫，內核引擎完全自研。我們將在開源資料庫領域持續耕耘，不斷與各個開源資料庫社區、企業合作共建，共創國產開源資料庫良好生態。

StoneDB 在6月29日已宣佈正式開源。如果您感興趣，可以通過下方鏈接查看 StoneDB 源碼、閱讀文檔，期待您的貢獻！

StoneDB 開源倉庫

https://github.com/stoneatom/stonedb

作者李浩

StoneDB 首席架構師、StoneDB PMC

曾在華為、愛奇藝、北大方正從事資料庫內核核心架構設計。超過10年資料庫內核開發經驗，擅長查詢引擎，執行引擎，大規模並行處理等技術。擁有數十項資料庫發明專利，著有《PostgreSQL查詢引擎源碼技術探析》。

編輯 &校對：李明康、王學姣、高日耀、