在今年的第七屆中國開源年會上，StoneDB 團隊在大數(shù)據(jù)分論壇發(fā)表了《HTAP 的下一步？SoTP 初探》主題演講，在本次演講中，我們首次正式對外闡釋了“SoTP 數(shù)據(jù)庫”的技術(shù)理念，本系列是演講實錄+小編補充版，權(quán)當拋磚引玉，供大家批評指正。由于內(nèi)容比較多，本文為第一章節(jié)，主要講講我們提 SoTP 的背景：From Big to Small and Wide Data。

HTAP 的起源、流派和迷思

HTAP 起源

我們首先從起源講起，不過由于是公開演講，考慮到一些聽眾是小白，所以這里主要是從一個比較宏觀的關(guān)系型數(shù)據(jù)庫行業(yè)發(fā)展歷史視角來看的，關(guān)于 HTAP 更具體的技術(shù)和商業(yè)的起源背景，可以看看 StoneDB 首席架構(gòu)師李浩老師寫的這篇文章：HTAP 的背景。

眾所周知，圖靈獎（Turing Award）算是計算機領(lǐng)域里最高的一個獎項，截至今日，因為在數(shù)據(jù)庫領(lǐng)域有杰出貢獻而獲得圖靈獎的只有四位，分別是：

1. 查爾斯·巴赫曼（CharlesW. Bachman），1973 年獲獎，設(shè)計并開發(fā)了網(wǎng)狀數(shù)據(jù)庫管理系統(tǒng) IDS，推動了數(shù)據(jù)庫標準的制定，包括網(wǎng)狀數(shù)據(jù)庫模型、數(shù)據(jù)定義和數(shù)據(jù)操縱語言的規(guī)范說明（通俗來講，是他第一次提出了數(shù)據(jù)庫這么個東西，可以說是咱們的祖師爺）；

2. 埃德加·弗蘭克·科德（Edgar Frank Codd），1981 年獲獎，提出了關(guān)系數(shù)據(jù)庫模型（關(guān)系型數(shù)據(jù)庫經(jīng)久不衰，目前依然占據(jù)市場最多的份額）；

3. 詹姆斯·古瑞（James Gray），1998 年獲獎，主要是在大型數(shù)據(jù)庫和事務(wù)處理技術(shù)上的突破（重點研究如何保障數(shù)據(jù)的完整性、安全性、并行性，以及故障恢復，曾擔任 VLDB 期刊的主編）；

4. 邁克爾·斯通布雷克（Michael Stonebraker），2014 年獲獎，現(xiàn)代數(shù)據(jù)庫系統(tǒng)的概念和實踐方面的基礎(chǔ)性貢獻（領(lǐng)導了影響力巨大的奠基性數(shù)據(jù)庫 Ingres 的開發(fā)，也是最早提倡發(fā)展列存數(shù)據(jù)庫的大佬之一）。

除了這四位數(shù)據(jù)庫界公認的大佬外，也有其他大牛，比如：

• 1988 年，為解決數(shù)據(jù)集成問題，IBM 的 2 位研究員 Barry Devlin 和 Paul Murphy，創(chuàng)造性地提出了數(shù)據(jù)倉庫（Data Warehouse）的概念；

• 1992 年，比爾·恩門（Bill Inmon）給出了數(shù)據(jù)倉庫的定義。數(shù)據(jù)倉庫是一個面向主題的、集成的、相對穩(wěn)定的、反映歷史變化的數(shù)據(jù)集合，用于支持管理中的決策制定；

• 1993 年，E.F.Codd 提出 OLAP，以及 OLAP 12 條準則。

• ......

能看到，早些年的數(shù)據(jù)庫界名人們，并沒有太多中國人士，和操作系統(tǒng)一樣，中國在這類基礎(chǔ)軟件上的起步和投入都不算太早，這也是數(shù)據(jù)庫領(lǐng)域目前成為我國 35 個“卡脖子”技術(shù)之一的原因吧。

我這里要指出的是——相信那些在數(shù)據(jù)庫界深耕數(shù)十年的朋友們應該早就感受到了——仿佛，自從上述這些大佬奠定了關(guān)系型數(shù)據(jù)庫發(fā)展的總基調(diào)后，后續(xù)的幾十年里，就再沒看到什么轟動一時的創(chuàng)新了，或者說，影響力能達到以上這些人士的數(shù)據(jù)庫專家學者也沒那么多了。那段時間，關(guān)系型數(shù)據(jù)庫的熱點話題好像從百家爭鳴陷入了一個相對沉寂的時期，當然，后面也斷斷續(xù)續(xù)有一些新的技術(shù)熱點，不過，能像上面這些大佬一樣直接奠定一個學科或者理論的，就比較少了。

萬籟“俱寂”時，一家知名 IT 研究與顧問咨詢機構(gòu)的發(fā)聲，給關(guān)系型數(shù)據(jù)庫這個平靜的池塘丟了顆巨石：2014 年，Gartner 正式提出了 HTAP 這個概念。

Gartner’s definition in 2014: utilizes?in-memory?computing technologies to enable concurrent analytical and transaction processing on the same?in-memory?data store.

Gartner’s new definition in 2018: supports weaving analytical and transaction processing techniques together as needed to accomplish the business task.

可以看到，Gartner 重點強調(diào)了使用內(nèi)存技術(shù)實現(xiàn) HTAP 的可行性，并表示?HTAP 將為巨大的業(yè)務(wù)創(chuàng)新創(chuàng)造機會，增量市場空間巨大。

一石卷起千層浪，陷入半沉寂的關(guān)系型數(shù)據(jù)庫技術(shù)，好像迎來了春天。那個時候，商業(yè)智能（BI）已經(jīng)開始廣泛滲入到眾多企業(yè)的營銷業(yè)務(wù)體系里了，處理數(shù)據(jù)的業(yè)務(wù)分析部門對實時處理和運維最簡化的需求越來越重要，HTAP 方案的提出自然迅速地引起了行業(yè)的強勢關(guān)注，因為這玩意兒光是聽起來就省心省力，誘惑很大。

我們正在做的 StoneDB，就是對標 Oracle MySQL HeatWave 的一款開源版實時一體化 HTAP 數(shù)據(jù)庫。

HTAP 流派

上圖是 HTAP 數(shù)據(jù)庫的發(fā)展時間線，我們這里再舉幾個大家耳熟能詳?shù)钠髽I(yè)：像數(shù)據(jù)庫巨頭 Oracle 去年就推出了 MySQL HeatWave，沒錯，Oracle 官方已經(jīng)明確表示了，做 HeatWave 的目的就是為了支持 HTAP，在最近的 Oracle CloudWorld 大會上還官宣了 MySQL HeatWave Lakehouse；Google 在 HTAP 上也動作頻頻，除了搞 F1 Lightning 以外，在今年 5 月 12 日的 Google I/O 2022 開發(fā)者大會還宣布了云原生 HTAP 數(shù)據(jù)庫 AlloyDB for PostgreSQL；緊接著，所有云數(shù)倉都想打的知名廠商 SnowFlake 也在 6 月 14 日的用戶大會 Snowflake Summit 2022 上官宣正式推出 HTAP 存儲引擎 Unistore；數(shù)據(jù)庫獨角獸SingleStore（前身為 MemSQL）?也早就在 HTAP 領(lǐng)域上頻頻發(fā)聲，頂會論文都發(fā)了。國際上的這些大廠和獨角獸都在搞 HTAP，國內(nèi)的更不用說了，阿里、百度、騰訊、華為、字節(jié)和眾多新興創(chuàng)業(yè)公司（包括咱們 StoneDB），以及老牌數(shù)據(jù)庫廠商都開始宣傳自己的一些產(chǎn)品可以實現(xiàn)或者主攻 HTAP。Gartner 之前在報告里預測說，到 2024 年，HTAP 數(shù)據(jù)庫會被廣泛用到各行各業(yè)中，現(xiàn)在看來，真的是有這種勢頭了。

顯而易見，HTAP 這倆馬車的車輪已經(jīng)壓在了數(shù)據(jù)庫行業(yè)的歷史軌跡上，正在滾滾向前，勢不可擋。但是，隨著越來越多的廠商正式加入賽道，對于 HTAP 架構(gòu)的技術(shù)實現(xiàn)，自然產(chǎn)生了一些分化。

我們之前在文章《深度干貨！一篇 Paper 帶您讀懂 HTAP》中有做介紹，這篇報告里提到，至少有四種不同的架構(gòu)方式可以實現(xiàn) HTAP。

目前 HTAP 大致有四種實現(xiàn)方式：

• 方案 1（一套系統(tǒng)一套存儲）：在一個系統(tǒng)里用一種數(shù)據(jù)格式滿足兩種業(yè)務(wù)需求；

• 方案 2（一套系統(tǒng)兩套存儲）：一個系統(tǒng)里同時存在行存儲和列存儲，行存儲上的更新會定期導入到列存儲里轉(zhuǎn)換成列存儲格式；

• 方案 3（兩套系統(tǒng)兩套存儲）：系統(tǒng)里同時存在 OLTP 與 OLAP 兩套引擎，分別寫入和讀取行存儲和列存儲；

• 方案 4（多套系統(tǒng)松耦合）：不同的異構(gòu)系統(tǒng)之間，通過獨立的插件服務(wù)對數(shù)據(jù)進行準實時同步，對外呈現(xiàn) HTAP 能力。

下面這張表圖是我們對這四種架構(gòu)方案的一個簡單的綜合盤點??

HTAP 迷思

隨著一些 HTAP 產(chǎn)品功能能夠?qū)崿F(xiàn)落地了，在 HTAP 架構(gòu)的選擇上引起了不少爭議（我們講叫技術(shù)口水戰(zhàn)），這很正常，大家都想說 HTAP 是自己做得比較好嘛。比如 StoneDB 這邊就比較支持完全一體化的混合負載架構(gòu)（我們稱之為真正的 HTAP 面臨的挑戰(zhàn)）；也有的團隊比較想搞那種兩套系統(tǒng)疊加的架構(gòu)；還有更猛的，直接說要基于 GPU/CPU 搞 HTAP，就是 RateupDB，據(jù)說是全球唯一一個基于 GPU/CPU 和并行的 HTAP 數(shù)據(jù)庫，還發(fā)了一篇 VLDB，不過好像現(xiàn)在銷聲匿跡了，創(chuàng)始人目前應該是投身一家勢頭較猛的云數(shù)倉創(chuàng)業(yè)公司去了。

由此可見，HTAP 雖然引起了一陣狂歡，但是，對 HTAP 數(shù)據(jù)庫架構(gòu)選擇目前業(yè)界還是沒有一套特別稱得上成熟的方案，大家也都是在打磨產(chǎn)品中。有的走得稍微早了一些；有的還在孵化打磨；有的已經(jīng)倒在半路上了，但是一個不可否認的事實是，大家都開始說自己能或者即將能支持 HTAP 了，就和數(shù)據(jù)庫領(lǐng)域另外一個爆火的“云原生”關(guān)鍵字一樣，這真可謂是“二四八月亂穿衣”了，這也算是現(xiàn)在 HTAP 領(lǐng)域上存在的迷思吧。

新的趨勢：From Big to Small and Wide data

所以，在這個時候，作為率先提出要做 MySQL 開源 HTAP 數(shù)據(jù)庫的 StoneDB，想要稍微冷靜一下。

不是說我們不做 HTAP 了，而是有了一個新的思路。這個思路，也同樣來自咱們的老朋友、好伙伴，大家都巴不得上他們報告的權(quán)威機構(gòu)——Gartner。

Gartner 在去年發(fā)布的《Gartner 2021 十大數(shù)據(jù)和分析趨勢》[1]報告里，特別提到了一個重要的趨勢：。From Big to Small and Wide data[2]

據(jù) Gartner 預測，到 2025 年 70% 的組織會把重點從“大”數(shù)據(jù)轉(zhuǎn)向“小”數(shù)據(jù)和“寬”數(shù)據(jù)[3]，為分析提供更多的場景，使人工智能（AI）減少對數(shù)據(jù)量的需求（原文是 making artificial intelligence (AI) less data hungry）。

當然，這個趨勢的調(diào)研結(jié)論是有背景的，那就是突如其來的新冠疫情。面對新冠，很多數(shù)據(jù)幾乎是一夜式爆發(fā)式變化增長，導致了基于大量歷史數(shù)據(jù)的機器學習和人工智能模型變得不那么可靠，隨著智能決策變得更加復雜和嚴格，數(shù)據(jù)和分析領(lǐng)導者應選擇能夠更加有效利用現(xiàn)有數(shù)據(jù)的分析技術(shù)。

如何更加有效利用數(shù)據(jù)分析？那就是我們講的用“小”而“寬”的數(shù)據(jù)取代“大”數(shù)據(jù)來解決問題。小數(shù)據(jù)——顧名思義，指的是能夠使用所需數(shù)據(jù)量較少，但仍能提供實用洞見的數(shù)據(jù)模型。寬數(shù)據(jù)——可以理解為多模數(shù)據(jù)，即使用寬數(shù)據(jù)分析各種小而多樣化的非結(jié)構(gòu)化和結(jié)構(gòu)化數(shù)據(jù)源并發(fā)揮它們的協(xié)同效果，從而增強情景態(tài)勢感知（contextual awareness，情境感知）和決策。

下面就來詳細講解一下 Small Data 和 Wide Data 的定義。

Small data 概念

小數(shù)據(jù)的方法是指使用相對較少的數(shù)據(jù)，但仍能提供有見解的分析技術(shù)。其中包括了有針對性地使用數(shù)據(jù)要求比較低的模型，比如一些時間序列分析的技術(shù)，而不是用一刀切的方式去使用數(shù)據(jù)量要求較高的深度學習技術(shù)。

通俗地來講，使用 AI 或者 ML 技術(shù)，往往需要大量的數(shù)據(jù)源作為分析的訓練模型，但并不是數(shù)據(jù)量越多越好，特別是那些過時的歷史數(shù)據(jù)，對分析毫無意義，如果可以及時地找到一些比較精準的小數(shù)據(jù)進行分析，往往能獲得更有價值的效果。總之，小數(shù)據(jù)側(cè)重于應用分析技術(shù)，在小量的、單獨的數(shù)據(jù)集中尋找有用的信息。

Wide data 概念

寬數(shù)據(jù)允許分析師檢查和組合各種大小、非結(jié)構(gòu)化和結(jié)構(gòu)化數(shù)據(jù)。具體來說，寬而廣泛的數(shù)據(jù)就是將各種來源的不同數(shù)據(jù)源捆綁在一起，以進行有意義的分析。

基于寬數(shù)據(jù)的數(shù)據(jù)分析技術(shù)圍繞著結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)的分析和協(xié)同，而不管數(shù)據(jù)集是否直接相關(guān)。寬數(shù)據(jù)最大的特征是可以提取或識別異構(gòu)數(shù)據(jù)集之間的聯(lián)系。

Small and Wide data 結(jié)合的作用

Gartner 知名研究副總裁 Rita Sallam 表示：“使用‘小’而‘寬’的數(shù)據(jù)能夠提供強大的分析和 AI，同時降低企業(yè)機構(gòu)對大型數(shù)據(jù)集的依賴性。企業(yè)機構(gòu)可以使用‘寬’數(shù)據(jù)獲得更豐富、更完整的態(tài)勢感知或 360 度視圖，這將使企業(yè)機構(gòu)能夠使用分析技術(shù)做出更好的決策。”

Gartner 高級研究總監(jiān)孫鑫表示：“隨著企業(yè)逐漸認識到大數(shù)據(jù)作為分析和人工智能關(guān)鍵推動者的局限性，被稱為小數(shù)據(jù)和寬數(shù)據(jù)的方法正在慢慢涌現(xiàn)，小數(shù)據(jù)的方法拋開了對于大型單體數(shù)據(jù)的依賴，實現(xiàn)了對于小型、大型、結(jié)構(gòu)化、非結(jié)構(gòu)化的數(shù)據(jù)源的分析和協(xié)同。”

同時，據(jù) Gartner 預測，到 2025 年，超過 85% 的技術(shù)供應商，將在人工智能解決方案當中加入讓數(shù)據(jù)變得更豐富的方法和模型訓練技術(shù)，以提高模型的彈性和敏捷性，而在 2020 年，這樣做的供應商只有不到 5%。?由此可見，小數(shù)據(jù)和寬數(shù)據(jù)的市場增量巨大。

Small and Wide data 核心場景

說了這么多“小”數(shù)據(jù)和“寬”數(shù)據(jù)，這兩個到一塊兒究竟能落地到什么應用場景上？

從一個具體的場景為例，現(xiàn)在電商以及社交媒體都在做一個實時推薦的業(yè)務(wù)場景，而實時推薦的標準流程是首先通過大數(shù)據(jù)系統(tǒng)對客戶的購買歷史進行分析，要關(guān)注客戶購買產(chǎn)品的生命周期，客戶與企業(yè)之間的交互歷史；同時要去通過各種渠道去了解，目前客戶正在什么環(huán)境，聽到了什么？正在瀏覽什么信息？結(jié)合各種數(shù)據(jù)進行分析，最后產(chǎn)生 Top10 的產(chǎn)品推薦，然后通過 APP 或者其他手段推送給客戶。

在這個過程中，需要收集的數(shù)據(jù)非常龐大，包括各種結(jié)構(gòu)化數(shù)據(jù)，例如歷史訂單，客戶個人信息等，另外客戶的上網(wǎng)日志，網(wǎng)頁瀏覽歷史，客戶的位置信息， 行動軌跡，這些數(shù)據(jù)的體量都非常大，而一旦涉及到千萬乃至上億的用戶，同時上萬種產(chǎn)品的場景下，這個數(shù)據(jù)量就是天文數(shù)字，而等待所有這些數(shù)據(jù)都收集完整并進行 AI 建模預測，則很可能是 1-2 天之后的事情了。

所以，為了盡可能快地對客戶當前狀況進行反饋，并推出相應的推薦方案，必須把數(shù)據(jù)鏈條縮短：首先通過在生產(chǎn)系統(tǒng)端，貼合用戶的購買歷史和行為，對整個場景進行約束，從海量數(shù)據(jù)分析，變成小數(shù)據(jù)量的分析，把推薦產(chǎn)品從幾萬，縮小到幾十的范圍，這個時候，就是從大數(shù)據(jù)到“小”數(shù)據(jù)的過程。然后在此基礎(chǔ)之上，通過補足其他渠道的信息，包括圖像、聲音、瀏覽日志等等，對幾十的范圍進行進一步的精準化定位。這個時候，則體現(xiàn)了“寬”數(shù)據(jù)的價值。

預計小數(shù)據(jù)和寬數(shù)據(jù)技術(shù)將產(chǎn)生積極的結(jié)果，即：

• 零售需求預測（Retail demand forecasting）

• 實時行為智能（ Real time behavioral intelligence）

• 超個性化和整體客戶體驗的改善（ Hyper personalization and improvement of the overall customer experience）

• 人生安全

• 欺詐檢測

• 自適應自動系統(tǒng)（比如自適應 AI，這個很有前景）等等

雖然“小”數(shù)據(jù)和“寬”數(shù)據(jù)技術(shù)的確切結(jié)果還沒有出現(xiàn)，但這個概念肯定是未來可期的，因為這兩個技術(shù)的結(jié)合能夠在繁多雜亂的當前和歷史數(shù)據(jù)集中分析提取出卓有成效的洞察結(jié)果。

對于從“大”數(shù)據(jù)到“小”數(shù)據(jù)的過程，一個趨勢就是：數(shù)據(jù)分析不必一定從數(shù)倉開始， 而是從前端業(yè)務(wù)系統(tǒng)，結(jié)合一定的場景，首先發(fā)起快捷的數(shù)據(jù)分析， 解決場景定位，方案范圍初篩等數(shù)據(jù)的初步處理，讓后繼的分析盡可能地聚焦在指定的領(lǐng)域，一方面減少計算量，同時加速后繼決策的速度。

所以業(yè)務(wù)系統(tǒng)在承擔業(yè)務(wù)交易的時候，必須增加一定的數(shù)據(jù)分析和篩選的能力， 這個和傳統(tǒng)的業(yè)務(wù)系統(tǒng)是純粹 OLTP 系統(tǒng)的定義不一樣， 將來業(yè)務(wù)系統(tǒng)的能力將會從 OLTP 向 HTAP 逐步變遷。

這一塊還有很多東西可以講，后續(xù)我們繼續(xù)探討，今天就先點一下。作為在數(shù)據(jù)分析領(lǐng)域耕耘多年的數(shù)據(jù)庫團隊，StoneDB 對這個觀點是非常認可的。因為，經(jīng)常做數(shù)據(jù)分析的人都知道，隨著使用數(shù)據(jù)的場景越來越多，數(shù)據(jù)支撐運營的場景也越來越多，很多情況下，數(shù)據(jù)驅(qū)動運營需要的是近期的熱數(shù)據(jù)，而不是長時間的歷史數(shù)據(jù)。而這個“熱數(shù)據(jù)”，再更精確一些講，就應該是“熱”的“小”而“寬”數(shù)據(jù)。

這恰恰和 StoneDB 提倡的基于 MySQL 的 HTAP 數(shù)據(jù)庫要能夠支持實時與中小數(shù)據(jù)量場景不謀而合（正常 10T 左右，最高不超過 100T，當然了，要是擴展成 LakeHouse，支持的數(shù)據(jù)量會更多）。也和 SingleStore 講的觀點很類似：沒有 HTAP，機器學習和人工智能都是不切實際的。

基于此，我們提出一個 idea，即?StoneDB 這種強調(diào)對熱數(shù)據(jù)實時分析的 HTAP 數(shù)據(jù)庫，也可以叫做 SoTP 數(shù)據(jù)庫。

SoTP 初探

SoTP，即 Serving over TP。

Serving 是什么？SoTP 的定義和驅(qū)動又是什么？SoTP 的案例場景又是什么？這個留給我們下一篇文章繼續(xù)解讀，歡迎關(guān)注 StoneDB 公眾號。

StoneDB?2.0?云原生分布式實時 HTAP 架構(gòu)詳細設(shè)計以?RFC?形式持續(xù)進行，歡迎大家關(guān)注我們最新進展，更歡迎給我們開源協(xié)作的模式和方法提出改進意見，一起通過開源的方式共建 StoneDB ~