上一篇文章中，我們從技術(shù)和商業(yè)角度分析了 HTAP 系統(tǒng)緣起的背景，本篇文章中，我們將從 HTAP 定義及其相關(guān)核心技術(shù)等方面來(lái)討論：構(gòu)建一個(gè) HTAP 所面臨的核心問(wèn)題和挑戰(zhàn)有哪些？
HTAP 涉及技術(shù)和對(duì)產(chǎn)品的影響
HTAP 是將 TP 和 AP 進(jìn)行高度融合的產(chǎn)物， 而非簡(jiǎn)單的 TP 和 AP 相加：TP+AP ≠ HTAP。有的數(shù)據(jù)庫(kù)讓 TP 系統(tǒng)通過(guò)簡(jiǎn)單的數(shù)據(jù)同步方式（比如 Binlog等），將數(shù)據(jù)同步到 AP 系統(tǒng)，然后再由 AP 系統(tǒng)進(jìn)行處理數(shù)據(jù)，雖然該種方式從用戶(hù)的角度來(lái)看似乎是獲得了同時(shí)處理 TP 和 AP 的能力，但是從本質(zhì)上來(lái)看，這并不能稱(chēng)為真正的 HTAP 產(chǎn)品，國(guó)內(nèi)有一些數(shù)據(jù)庫(kù)廠(chǎng)商宣傳 HTAP 概念很起勁，但是自身可能還真不滿(mǎn)足 HTAP 的定義。下面我們就 HTAP 所涉及到的幾個(gè)核心問(wèn)題來(lái)探討一下，一個(gè)真正的 HTAP 產(chǎn)品需要具備哪些能力。
我們將從以下維度進(jìn)行探討：
- 架構(gòu)選擇（Architecture choice）
- 數(shù)據(jù)導(dǎo)入及查詢(xún)處理引擎 （Ingestion and query processing egnines）
- 存儲(chǔ)方案 （Storage options）
- 數(shù)據(jù)組織方案 （Data organization）
- 事務(wù)語(yǔ)義（Transaction semantics）
- 數(shù)據(jù)的時(shí)效性（Recency of data being read by OLAP)
- 索引支持（Indexing supports）
- AP 負(fù)載和 TP 負(fù)載的相互干擾（Workload interference）
當(dāng)系統(tǒng)接收到一個(gè)查詢(xún)負(fù)載的時(shí)候，查詢(xún)處理模塊需要識(shí)別出該查詢(xún)負(fù)載中的 TP 負(fù)載和 AP 負(fù)載。并能夠依據(jù)相應(yīng)的策略（這里可以是基于規(guī)則或者是基于查詢(xún)代價(jià)），將相應(yīng)的負(fù)載轉(zhuǎn)發(fā)至相應(yīng)的處理引擎。
1. 架構(gòu)的選擇
Single system（即 One system） 還是 Seperate system 的選擇當(dāng)前更多是基于工程上的難度。目前不少產(chǎn)品均是在原有的 TP 系統(tǒng)之上，疊加了一個(gè) AP 系統(tǒng)并使用某種數(shù)據(jù)同步工具將TP系統(tǒng)中的數(shù)據(jù)同步至AP系統(tǒng)中。Seperate system 雖然有其優(yōu)點(diǎn)，但這種方案存在著許多不容忽視的問(wèn)題，比如無(wú)法保證對(duì)事務(wù)的支持能力、數(shù)據(jù)的時(shí)效性，以及復(fù)雜的系統(tǒng)架構(gòu)等（下文會(huì)有詳細(xì)的解釋?zhuān)?。相比之下?strong>One system 不僅架構(gòu)簡(jiǎn)潔，對(duì)于事務(wù)的支持能力和數(shù)據(jù)的時(shí)效性等方面都能提供更好的保證。但是，One system 架構(gòu)的技術(shù)難度相對(duì)較大，工程上也具有一定的難度，同時(shí)還需要考慮 TP 和 AP 負(fù)載間的相互干擾等問(wèn)題。StoneDB 目前就是采用 One System 的架構(gòu)設(shè)計(jì)，我們深知此架構(gòu)的優(yōu)勢(shì)和難度。
2. 查詢(xún)處理及數(shù)據(jù)導(dǎo)入引擎
該維度對(duì)產(chǎn)品有兩個(gè)方面的描述。由于 HTAP 所面臨的業(yè)務(wù)場(chǎng)景通常存著需要對(duì)海量數(shù)據(jù)進(jìn)行分析處理需求，而在分析場(chǎng)景下，為了加速分析，通常的做法是將需要進(jìn)行分析的數(shù)據(jù)，以列存的方式進(jìn)行組織，這樣可以利用列存的優(yōu)勢(shì)加速分析。因此，需要將適用于 TP 場(chǎng)景的行存類(lèi)型數(shù)據(jù)轉(zhuǎn)為適用于 AP 場(chǎng)景的列存數(shù)據(jù)。對(duì)于一個(gè) HTAP 數(shù)據(jù)庫(kù)首先需要解決的問(wèn)題是高速的數(shù)據(jù)載入。這里又包括兩個(gè)方面：
- 全量數(shù)據(jù)的載入方案，保證海量數(shù)據(jù)快速準(zhǔn)確導(dǎo)入。
- 增量數(shù)據(jù)的更新方案，保證數(shù)據(jù)的時(shí)效性。
在數(shù)據(jù)加載完成后，另外一個(gè)維度是查詢(xún)處理。查詢(xún)處理部分屬于整個(gè) HTAP 數(shù)據(jù)庫(kù)的核心模塊，其最重要的能力是能夠同時(shí)完成 TP 負(fù)載和 AP 負(fù)載的處理。
索引已成為 TP 系統(tǒng)的標(biāo)配，通過(guò)設(shè)置索引可以大大提高數(shù)據(jù)庫(kù)的檢索速度，改善數(shù)據(jù)庫(kù)性能。而 AP 系統(tǒng)中的更新操作通常為批量更新，在更新時(shí)首先需要定位到待更新的數(shù)據(jù)，考慮到 AP 系統(tǒng)的數(shù)據(jù)組織和存儲(chǔ)模型，如何能夠通過(guò)設(shè)置索引快速定位到需要更新的數(shù)據(jù)（尤其是在以列存且數(shù)據(jù)多為壓縮形式的情況下）也是需要解決的一個(gè)難題。
3. 存儲(chǔ)方案
隨著存儲(chǔ)技術(shù)的進(jìn)步，存儲(chǔ)介質(zhì)和方式以及單位價(jià)格都發(fā)生了翻天覆地的變化，一個(gè)清晰的事實(shí)是：高速存儲(chǔ)介質(zhì)正在廣泛地應(yīng)用到數(shù)據(jù)庫(kù)領(lǐng)域。對(duì)于 HTAP 數(shù)據(jù)庫(kù)來(lái)說(shuō)，TP 部分和 AP 部分的存儲(chǔ)方案選擇涉及到架構(gòu)、性能、成本和業(yè)務(wù)場(chǎng)景等多方因素的影響。
4. 數(shù)據(jù)組織方案
選擇列存儲(chǔ)加行存儲(chǔ)（DSM + NSM），還是 PAX （Partition Attributes Across）方案或者是其它方案。數(shù)據(jù)組織方案的選擇不僅會(huì)極大的影響系統(tǒng)性能，還會(huì)影響數(shù)據(jù)的存儲(chǔ)成本。而系統(tǒng)的整體性?xún)r(jià)比也是我們挑選產(chǎn)品的重要指標(biāo)之一。
5. 事務(wù)語(yǔ)義
需要具有支持完整的事務(wù)語(yǔ)義的能力，即無(wú)論是 TP 部分還是 AP 部分都需要對(duì)事務(wù)進(jìn)行完整的支持。現(xiàn)有的很多 HTAP 解決方案，AP 系統(tǒng)中所處理的數(shù)據(jù)均是同步自 TP 系統(tǒng)中已提交的數(shù)據(jù)。這類(lèi)解決方案存在以下幾個(gè)問(wèn)題：首先，對(duì)應(yīng)長(zhǎng)事務(wù)場(chǎng)景下，如何保證 AP 系統(tǒng)可以獲得最新版本的數(shù)據(jù)值得我們仔細(xì)考慮。再者，通過(guò)以同步日志的方式，數(shù)據(jù)的時(shí)效性和一致性需要認(rèn)真考慮。最后，為了解決上述問(wèn)題，會(huì)影響到事務(wù)的執(zhí)行效率，導(dǎo)致系統(tǒng)吞吐量的下降。
6. 數(shù)據(jù)的時(shí)效性
需要保證 AP 系統(tǒng)所處理的數(shù)據(jù)均為當(dāng)前最新版本的數(shù)據(jù)。當(dāng)前的很多系統(tǒng)是在 TP 數(shù)據(jù)提交完成后，通過(guò)同步日志的方式將 TP 部分的變更同步到 AP 部分，這種方式無(wú)法保證數(shù)據(jù)的時(shí)效性，因而不能稱(chēng)之為真正的 HTAP 系統(tǒng)。
7.索引的支持
索引已成為 TP 系統(tǒng)的標(biāo)配，通過(guò)設(shè)置索引可以大大提高數(shù)據(jù)庫(kù)的檢索速度，改善數(shù)據(jù)庫(kù)性能。而 AP 系統(tǒng)中的更新操作通常為批量更新，在更新時(shí)首先需要定位到待更新的數(shù)據(jù)，考慮到 AP 系統(tǒng)的數(shù)據(jù)組織和存儲(chǔ)模型，如何能夠通過(guò)設(shè)置索引快速定位到需要更新的數(shù)據(jù)（尤其是在以列存且數(shù)據(jù)多為壓縮形式的情況下）也是需要解決的一個(gè)難題。
8. 不同類(lèi)型負(fù)載間的相互干擾
系統(tǒng)需要能夠保證 AP 負(fù)載對(duì) TP 負(fù)載無(wú)影響或者使得兩種類(lèi)型負(fù)載間的影響最小化。
上述討論了一個(gè)真正的 HTAP 系統(tǒng)應(yīng)該具備的幾點(diǎn)核心能力，當(dāng)然這些只是我們認(rèn)為的核心能力，其它的相關(guān)問(wèn)題這里就不在展開(kāi)，后續(xù)我們會(huì)陸續(xù)給出上述 HTAP 核心能力的詳細(xì)解讀。
從不同維度對(duì)現(xiàn)有 HTAP 產(chǎn)品/解決方案進(jìn)行分類(lèi)
現(xiàn)有的 HTAP 產(chǎn)品圖譜分類(lèi)的主要方法：
- 架構(gòu)方式；
- 存儲(chǔ)范式（Cloud/Shared Disk）；
- 擴(kuò)展方式（Scale out/Scale up）；
- 查詢(xún)語(yǔ)句標(biāo)準(zhǔn)；
- 并發(fā)策略（MVCC）；
- 數(shù)據(jù)/表的組織方式；
- 索引（LSM, ART, B-tree, lock-free Bw-Tree）。
下表從功能/許可證/是否開(kāi)源等各個(gè)維度，對(duì)當(dāng)前 HTAP 市場(chǎng)中的標(biāo)桿產(chǎn)品進(jìn)行了綜合分析。如需獲取更多信息，請(qǐng)?jiān)L問(wèn)我們的官網(wǎng)：https://stonedb.io/
其它方面：多模能力等屬于非必要，這里暫不考慮。
這里我們將 ClickHouse 放進(jìn)來(lái)，主要是考慮其在 AP 處理方面的優(yōu)異能力，可以作為我們 HTAP 產(chǎn)品在 AP 方面的一個(gè)標(biāo)桿。
HTAP所面臨的核心挑戰(zhàn)
綜上，我們可以總結(jié)出 HTAP 面臨的挑戰(zhàn)有：
- 真正的 HTAP，而非 TP 與 AP 的疊加
- 架構(gòu)的選擇
- 數(shù)據(jù)組織方案選擇，存儲(chǔ)方案選擇
- 查詢(xún)優(yōu)化：如何依據(jù)負(fù)載類(lèi)型和查詢(xún)代價(jià)選擇合適的執(zhí)行引擎
- 數(shù)據(jù)的時(shí)效性：如何能夠減少 TP 和 AP 之間的數(shù)據(jù)移動(dòng)，高效實(shí)時(shí)地將 TP 數(shù)據(jù)更新同步到 AP 數(shù)據(jù)中
- 負(fù)載隔離：如何有效地消除或者最小化 TP 和 AP 負(fù)載之間的相互干擾
- 資源管理：如何能夠高效的管理 TP 和 AP 負(fù)載之間的資源使用
- 實(shí)時(shí)分析的能力
- 事務(wù)語(yǔ)義支持
以上是對(duì)HTAP數(shù)據(jù)庫(kù)的部分挑戰(zhàn)梳理，在下一篇文章中，我們將對(duì)這些核心問(wèn)題和挑戰(zhàn)展開(kāi)更加深度的討論并給出選擇一款 HTAP 產(chǎn)品的建議。
StoneDB 是國(guó)內(nèi)首款基于 MySQL 的一體化實(shí)時(shí) HTAP 開(kāi)源數(shù)據(jù)庫(kù)，內(nèi)核引擎完全自研。我們將在開(kāi)源數(shù)據(jù)庫(kù)領(lǐng)域持續(xù)耕耘，不斷與各個(gè)開(kāi)源數(shù)據(jù)庫(kù)社區(qū)、企業(yè)合作共建，共創(chuàng)國(guó)產(chǎn)開(kāi)源數(shù)據(jù)庫(kù)良好生態(tài)。
StoneDB 在6月29日已宣布正式開(kāi)源。如果您感興趣，可以通過(guò)下方鏈接查看 StoneDB 源碼、閱讀文檔，期待您的貢獻(xiàn)！
StoneDB 開(kāi)源倉(cāng)庫(kù)
https://github.com/stoneatom/stonedb
作者李浩
StoneDB 首席架構(gòu)師、StoneDB PMC
曾在華為、愛(ài)奇藝、北大方正從事數(shù)據(jù)庫(kù)內(nèi)核核心架構(gòu)設(shè)計(jì)。超過(guò)10年數(shù)據(jù)庫(kù)內(nèi)核開(kāi)發(fā)經(jīng)驗(yàn)，擅長(zhǎng)查詢(xún)引擎，執(zhí)行引擎，大規(guī)模并行處理等技術(shù)。擁有數(shù)十項(xiàng)數(shù)據(jù)庫(kù)發(fā)明專(zhuān)利，著有《PostgreSQL查詢(xún)引擎源碼技術(shù)探析》。
編輯 &校對(duì)：李明康、王學(xué)姣、高日耀、
