在上一篇文章《HTAP 的下一步？SoTP 初探（上）：數(shù)據(jù)分析正在從“大”數(shù)據(jù)趨向“小”而“寬”數(shù)據(jù)》中，我們從 HTAP 的發(fā)展歷史脈絡(luò)出發(fā)，結(jié)合國際知名咨詢機(jī)構(gòu)Gartner 的調(diào)研報告，點出了 SoTP（Serving over TP）誕生的背景。今天這篇文章，我們著重來講一講，SoTP 的定義、解決的問題和典型應(yīng)用場景。本文是在第七屆中國開源年會上的演講實錄+編輯補充版，權(quán)當(dāng)拋磚引玉，歡迎廣大同行批評指正。

SoTP 的重要支撐

“小”數(shù)據(jù)和“寬”數(shù)據(jù)的崛起

開篇還是回顧一下，我們提出 SoTP 的重要背景：從“大”數(shù)據(jù)轉(zhuǎn)向“小”數(shù)據(jù)和“寬”數(shù)據(jù)。

根據(jù) Gartner 技術(shù)成熟度曲線的判斷，小數(shù)據(jù)正處于“創(chuàng)新出發(fā)點”的階段，可能還需要一段時間才可以進(jìn)入成熟，不過，隨著小數(shù)據(jù)市場滲透率不斷提高，它對 AI 以及更廣義的數(shù)據(jù)分析的影響是顯而易見且非常深遠(yuǎn)的。小數(shù)據(jù)的優(yōu)勢在于，拋開了對大型單體數(shù)據(jù)的依賴，實現(xiàn)了對于大型、小型、結(jié)構(gòu)化、非結(jié)構(gòu)化數(shù)據(jù)源的分析與協(xié)同。

這個趨勢不僅僅是被 Gartner 一家認(rèn)可的， 國際權(quán)威學(xué)者吳恩達(dá)教授也在今年 2 月初提出了：AI 的下一個發(fā)展方向，是從大數(shù)據(jù)轉(zhuǎn)向小數(shù)據(jù)。當(dāng)然，我們提的 AI 也只是實時事務(wù)處理與數(shù)據(jù)分析的一個重要應(yīng)用領(lǐng)域而已，并不是全部。不過，未來數(shù)據(jù)庫、數(shù)據(jù)分析處理與 AI、ML 的結(jié)合卻是必然的，就比如我們后續(xù)將在 StoneDB 架構(gòu)中加入的?StoneDB?Autopilot?功能。作為在人工智能和機(jī)器學(xué)習(xí)領(lǐng)域上有著全球級影響力的領(lǐng)軍人物，吳恩達(dá)最近幾年一直在倡導(dǎo)以數(shù)據(jù)為中心的人工智能。什么叫以數(shù)據(jù)為中心？那就是對數(shù)據(jù)的質(zhì)要有更高的要求而不是一昧的追求量（優(yōu)質(zhì)的小數(shù)據(jù)集經(jīng)過訓(xùn)練也能有很好的泛化能力，如果讀者感興趣，可以閱讀吳恩達(dá)接受 IEEE Spectrum 的采訪新聞），而“小”數(shù)據(jù)和“寬”數(shù)據(jù)恰恰就是高質(zhì)量數(shù)據(jù)集的最佳載體，可以理解為，這是眾多數(shù)據(jù)分析場景逐漸從依托“量”轉(zhuǎn)向提升“質(zhì)”的重大發(fā)展趨勢。

大勢所趨之下，作為實時數(shù)據(jù)分析場景的基礎(chǔ)底座之一，HTAP 數(shù)據(jù)庫扮演著的角色也越來越重要。如果說通過“小”數(shù)據(jù)和“寬”數(shù)據(jù)獲得了更高質(zhì)的數(shù)據(jù)，那么熱數(shù)據(jù)則是對這個質(zhì)的再一次提升。

熱數(shù)據(jù)一般是指頻繁被訪問查詢的在線數(shù)據(jù)，而在一個實時智能決策系統(tǒng)中，近期產(chǎn)生的熱數(shù)據(jù)往往才會發(fā)揮最大的價值，但是，并非所有 HTAP 數(shù)據(jù)庫都是專注于熱數(shù)據(jù)場景下的“小”而“寬”數(shù)據(jù)的，對此，StoneDB 作為國內(nèi)首個對標(biāo) Oracle MySQL HeatWave 的開源實時一體化 HTAP 數(shù)據(jù)庫，率先提出了面向熱數(shù)據(jù)、小數(shù)據(jù)和寬數(shù)據(jù)場景的 SoTP 型數(shù)據(jù)庫理念。

SoTP 數(shù)據(jù)庫的定義

2.1 Serving 的定義和分類

先說這個?Serving 場景，一些同學(xué)可能有些不熟悉，因為好像之前聽到的都是 OLTP 場景（指在線事務(wù)處理，比如業(yè)務(wù)處理，交易系統(tǒng)等） 和 OLAP 場景（指在線分析處理，比如BI、Adhoc等），但其實還有一種場景，是指在線實時服務(wù)的，介于 OLTP 和 OLAP 之間，可能還偏向 OLTP 一些，那么這種場景我們就稱之為 Serving（英語時態(tài)學(xué)得好的人，應(yīng)該可以 Get 到，就是進(jìn)行時的意思，也即可理解為“進(jìn)行中的服務(wù)”）

Serving 可以和 OLTP 組合，也可以和 BigData 或者 Stream 組合，我們把 Serving 分成了三類：

Type1.?Serving?over TP（StoneDB）

• 特點：處理事務(wù)型熱數(shù)據(jù)，提供實時分析、事務(wù)和分析處理一體化

• 典型代表：Oracle MySQL?Heatwave，StoneDB
  

Type2. Serving?for?BigData

• 特點：處理非事務(wù)型冷、溫數(shù)據(jù)；適用讀多寫少BI分析類

• 典型代表：ClickHouse

Type3.?Serving?for?Stream

• 特點：處理非結(jié)構(gòu)化數(shù)據(jù)，作業(yè)狀態(tài)狀態(tài)等數(shù)據(jù)管理

• 典型代表：RocksDB

為了方便大家理解，我們做了一張圖，三種類型的 Serving 數(shù)據(jù)庫如圖所示：

2.2 SoTP 的定義和解決的問題

那么，SoTP （Serving over?TP）的定義也就很清晰了，簡單來說，我們把這種有能力對在 OLTP 數(shù)據(jù)庫上的熱數(shù)據(jù)、小數(shù)據(jù)、寬數(shù)據(jù)進(jìn)行 Serving（在線實時服務(wù)） 操作的數(shù)據(jù)庫，稱之為 SoTP 數(shù)據(jù)庫。具體來講，比如以 SoTP 數(shù)據(jù)庫 StoneDB 為例，一個 SoTP 產(chǎn)品至少要滿足以下幾點要求：

• 數(shù)據(jù)量：一個系統(tǒng)，數(shù)據(jù)量不超過 100 TB，通常介于 100GB~100TB 之間

• 數(shù)據(jù)類型：主要處理結(jié)構(gòu)化數(shù)據(jù)，可處理 Text、JSON 等半結(jié)構(gòu)化數(shù)據(jù)，不處理非結(jié)構(gòu)化數(shù)據(jù)

• NoETL：TP 到 Serving 的流轉(zhuǎn)過程中，NOETL，直接基于 TP 數(shù)據(jù)完成實時分析

• 查詢類型：復(fù)雜即時的查詢，將事務(wù)型熱數(shù)據(jù)，從行存變成可被快速讀取的列存數(shù)據(jù)

• 高并發(fā)的混合負(fù)載：比 AP 查詢的并發(fā)高 3 個數(shù)量級

• 成本控制：TCO 總成本下降 80%

簡單舉個例子。如下圖，右邊就 SoTP 據(jù)庫 StoneDB，對外主要接受兩個業(yè)務(wù)請求，分別是左邊的 OLTP 和 Serving，其中，進(jìn)行 Serving 請求的主要是是 OLTP 產(chǎn)生的熱數(shù)據(jù)。那么這個 SoTP 處理數(shù)據(jù)的過程就是先把 OLTP 請求交給主引擎——TP 引擎承載（如 InnoDB），然后再把 Serving 請求交給次引擎——Serving 引擎承載（如 Tianmu）。

2.3 SoTP?的典型場景案例

2.3.1 場景一：Native Analytics Query

注意，我們這里重點提出了一個 Native，什么叫 Native，就是指數(shù)據(jù)源上的原生，我們?nèi)绻麑?OLTP 系統(tǒng)產(chǎn)生的數(shù)據(jù)進(jìn)行查詢分析，這里的數(shù)據(jù)應(yīng)該是同源的熱數(shù)據(jù)，而不是另外一份數(shù)據(jù)。

客戶需要一個數(shù)據(jù)庫，既能執(zhí)行 OLTP，還能高效、實時地運行Analytics；否則還得需要另外一個數(shù)據(jù)庫運行 Analytics，這引入了額外的復(fù)雜性和代價。

傳統(tǒng)的 ETL 方案架構(gòu)就是比較復(fù)雜的，比如 MySQL + ETL + Elastic：

這種方案就不能稱為是 Native，體現(xiàn)在數(shù)據(jù)源的不一致、查詢語句語法變更等等。但是，使用 SoTP 數(shù)據(jù)庫 StoneDB，就有所不同了，我們是完全一體化架構(gòu)，如下：

StoneDB?一體化架構(gòu)

采用 StoneDB 這種一體化架構(gòu)就可以達(dá)成降本增效的效果，下圖就是我們在華東地區(qū)的一個 CRM 客戶使用 StoneDB 的案例：

總結(jié)來說，這個廠商獲得了以下成果：

高兼容：平行替代MySQL業(yè)務(wù)，零改動

低成本：節(jié)省了成本 52%

強(qiáng)性能：DTU 提升了 68%

易維護(hù)：技術(shù)難度降低 50%

2.3.2 場景二：Native Autopilot

Autopilot 自動化了實現(xiàn)大規(guī)模高查詢性能的許多最重要和最具挑戰(zhàn)性的方面，包括provisioning、數(shù)據(jù)加載、查詢執(zhí)行和故障處理。

如圖，StoneDB 未來的 Autopilot 將有以下特性：

自動系統(tǒng)配置

• 自動資源占用監(jiān)測，集群節(jié)點按需自動動態(tài)伸縮。

• 自動性能監(jiān)控，對需要分析的表數(shù)據(jù)進(jìn)行自適應(yīng)采樣來預(yù)測運行工作負(fù)載所需的節(jié)點數(shù)量。

數(shù)據(jù)加載

• 自動并行加載：自動調(diào)整數(shù)據(jù)表最佳并行度來優(yōu)化加載時間和內(nèi)存使用

• 自動數(shù)據(jù)放置：存儲數(shù)據(jù)自動分區(qū)以實現(xiàn)最佳查詢

• 自動編碼：采用可變長度的字符串編碼確保最佳查詢性能

查詢執(zhí)行

• 根據(jù)歷史查詢計劃執(zhí)行情況和統(tǒng)計信息優(yōu)化查詢性能，提升查詢效率。

故障處理

• 自動錯誤恢復(fù)：當(dāng)數(shù)據(jù)庫節(jié)點訪問異常時，StoneDB將自動配置新的數(shù)據(jù)庫節(jié)點并完成數(shù)據(jù)遷移，確保數(shù)據(jù)快速恢復(fù)。

這里也可以舉個例子，比如現(xiàn)在我們的需求是減少用戶使用成本：要提供自動化的集群配置、加載數(shù)據(jù)、查詢處理和故障處理服務(wù)，使得用戶可以更多關(guān)注業(yè)務(wù)開發(fā)，減少其繁重且易出錯的運維操作。

在使用?Autopilot 之前：

1. 依據(jù)數(shù)據(jù)量和數(shù)據(jù)變化率，估算節(jié)點數(shù)量；

2. 與業(yè)務(wù)開發(fā)人員確定數(shù)據(jù)分布方案；

3. 業(yè)務(wù)運行中，不斷優(yōu)化SQL語句；調(diào)整數(shù)據(jù)分布策略；

4. 集群節(jié)點變化導(dǎo)致數(shù)據(jù)遷移，業(yè)務(wù)架構(gòu)，中間件等相關(guān)策略需調(diào)整；

在使用?Autopilot 之后：

1. 搭建好StoneDB服務(wù)；

2. 系統(tǒng)依據(jù)運行情況，自動調(diào)整相關(guān)參數(shù)，使得StoneDB處于最佳運行狀態(tài)；

3. 業(yè)務(wù)人員和DBA等得到解放，更加關(guān)注業(yè)務(wù)。

SoTP?與 OLTP、OLAP 的差異

我們總結(jié)了 SoTP 與 OLTP、OLAP 的差異，具體如下表：

SoTP 數(shù)據(jù)庫——StoneDB

當(dāng)然，可能有部分同學(xué)看到我們上述的定位，會想著說 SoTP 和?HTAP 有一些相同之處，這是當(dāng)然，畢竟我們的說法是?HTAP 的下一步，SoTP 初探。實際上，SoTP 針對的是更加細(xì)分的 HTAP 賽道，我們的核心目標(biāo)就是對最近產(chǎn)生的熱數(shù)據(jù)、小數(shù)據(jù)和寬數(shù)據(jù)進(jìn)行實時分析，更進(jìn)一步的是，把數(shù)據(jù)分析能力與機(jī)器學(xué)習(xí)相結(jié)合，而且因為我們是基于 MySQL 生態(tài)做的一體化架構(gòu)，也可以把我們稱作是?MySQL 熱數(shù)據(jù)分析加速器。總之，StoneDB 作為 SoTP 數(shù)據(jù)庫的核心特性就是：能夠將 Serving 需要的熱數(shù)據(jù)實時分析做到極致。

我們努力的現(xiàn)在，就是為了讓下一代熱數(shù)據(jù)分析盡早走上國產(chǎn)數(shù)據(jù)庫的歷史舞臺，讓更多的用戶體驗到真正的商業(yè)智能，從而更好地利用數(shù)據(jù)協(xié)作共享、驅(qū)動運營和做出決策。以下便是我們的 StoneDB 2.0 架構(gòu)圖：

StoneDB 的 2.0 架構(gòu)完全對標(biāo) Oracle MySQL MDS（HeatWave），HeatWave 有多強(qiáng)大？我們后面也會出一篇文章給大家分享一下。目前，我們的架構(gòu)設(shè)計方案的RFC文檔也完全公布在了 Github 上。