上一篇文章中，我們從技術(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ù)廠商宣傳 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）

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ì)的解釋）。相比之下，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ù)載的處理。

當(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)的處理引擎。

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

添加小助手vx：StoneDB_2022，

加入StoneDB開(kāi)源社區(qū)用戶(hù)討論群

作者：李浩

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é)姣、高日耀、

總結(jié)

以上是生活随笔為你收集整理的什么是真正的 HTAP ？（二）挑战篇的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。