上一篇文章中，我們從技術和商業角度分析了 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查詢引擎原始碼技術探析》，

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

標籤：其他

上一篇：手把手教你分析MySQL查詢性能瓶頸，包教包會

下一篇：開源公開課丨ChunJun資料傳輸模塊介紹