鑽石舞台

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

我們首先從起源講起，不過由於是公開演講，考慮到一些聽眾是小白，所以這裡主要是從一個比較宏觀的關係型數據庫行業發展歷史視角來看的，關於 HTAP 更具體的技術和商業的起源背景，可以看看 StoneDB 首席架構師李浩老師寫的這篇文章：HTAP 的背景。

眾所周知，圖靈獎（Turing Award）算是計算機領域裡最高的一個獎項，截至今日，因為在數據庫領域有傑出貢獻而獲得圖靈獎的只有四位，分別是：

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

能看到，早些年的數據庫界名人們，並沒有太多中國人士，和操作系統一樣，中國在這類基礎軟件上的起步和投入都不算太早，這也是數據庫領域目前成為我國 35 個「卡脖子」技術之一的原因吧。

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

萬籟「俱寂」時，一家知名 IT 研究與顧問諮詢機構的發聲，給關係型數據庫這個平靜的池塘丟了顆巨石：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 重點強調了使用內存技術實現 HTAP 的可行性，並表示 HTAP 將為巨大的業務創新創造機會，增量市場空間巨大。

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

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

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

顯而易見，HTAP 這倆馬車的車輪已經壓在了數據庫行業的歷史軌跡上，正在滾滾向前，勢不可擋。但是，隨着越來越多的廠商正式加入賽道，對於 HTAP 架構的技術實現，自然產生了一些分化。

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

目前 HTAP 大致有四種實現方式：

下面這張表圖是我們對這四種架構方案的一個簡單的綜合盤點👇

隨着一些 HTAP 產品功能能夠實現落地了，在 HTAP 架構的選擇上引起了不少爭議（我們講叫技術口水戰），這很正常，大家都想說 HTAP 是自己做得比較好嘛。比如 StoneDB 這邊就比較支持完全一體化的混合負載架構（我們稱之為真正的 HTAP 面臨的挑戰）；也有的團隊比較想搞那種兩套系統疊加的架構；還有更猛的，直接說要基於 GPU/CPU 搞 HTAP，就是 RateupDB，據說是全球唯一一個基於 GPU/CPU 和並行的 HTAP 數據庫，還發了一篇 VLDB，不過好像現在銷聲匿跡了，創始人目前應該是投身一家勢頭較猛的雲數倉創業公司去了。

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

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

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

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

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

當然，這個趨勢的調研結論是有背景的，那就是突如其來的新冠疫情。面對新冠，很多數據幾乎是一夜式爆發式變化增長，導致了基於大量歷史數據的機器學習和人工智能模型變得不那麼可靠，隨着智能決策變得更加複雜和嚴格，數據和分析領導者應選擇能夠更加有效利用現有數據的分析技術。

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

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

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

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

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

基於寬數據的數據分析技術圍繞着結構化和非結構化數據的分析和協同，而不管數據集是否直接相關。寬數據最大的特徵是可以提取或識別異構數據集之間的聯繫。

Gartner 知名研究副總裁 Rita Sallam 表示：「使用『小』而『寬』的數據能夠提供強大的分析和 AI，同時降低企業機構對大型數據集的依賴性。企業機構可以使用『寬』數據獲得更豐富、更完整的態勢感知或 360 度視圖，這將使企業機構能夠使用分析技術做出更好的決策。」

Gartner 高級研究總監孫鑫表示：「隨着企業逐漸認識到大數據作為分析和人工智能關鍵推動者的局限性，被稱為小數據和寬數據的方法正在慢慢湧現，小數據的方法拋開了對於大型單體數據的依賴，實現了對於小型、大型、結構化、非結構化的數據源的分析和協同。」

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

說了這麼多「小」數據和「寬」數據，這兩個到一塊兒究竟能落地到什麼應用場景上？

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

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

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

預計小數據和寬數據技術將產生積極的結果，即：

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

對於從「大」數據到「小」數據的過程，一個趨勢就是：數據分析不必一定從數倉開始， 而是從前端業務系統，結合一定的場景，首先發起快捷的數據分析， 解決場景定位，方案範圍初篩等數據的初步處理，讓後繼的分析儘可能地聚焦在指定的領域，一方面減少計算量，同時加速後繼決策的速度。

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

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

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

基於此，我們提出一個 idea，即 StoneDB 這種強調對熱數據實時分析的 HTAP 數據庫，也可以叫做 SoTP 數據庫。

SoTP，即 Serving over TP。

Serving 是什麼？SoTP 的定義和驅動又是什麼？SoTP 的案例場景又是什麼？這個留給我們下一篇文章繼續解讀，歡迎關注 StoneDB 公眾號。