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

一、HTAP 的起源、流派和迷思

HTAP 起源

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

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

1. 查爾斯·巴赫曼（CharlesW. Bachman），1973 年獲獎，設計并開發了網狀資料庫管理系統 IDS，推動了資料庫標準的制定，包括網狀資料庫模型、資料定義和資料操縱語言的規范說明（通俗來講，是他第一次提出了資料庫這么個東西，可以說是咱們的祖師爺）；
2. 埃德加·弗蘭克·科德（Edgar Frank Codd），1981 年獲獎，提出了關系資料庫模型（關系型資料庫經久不衰，目前依然占據市場最多的份額）；
3. 詹姆斯·古瑞（James Gray），1998 年獲獎，主要是在大型資料庫和事務處理技術上的突破（重點研究如何保障資料的完整性、安全性、并行性，以及故障恢復，曾擔任 VLDB 期刊的主編）；
4. 邁克爾·斯通布雷克（Michael Stonebraker），2014 年獲獎，現代資料庫系統的概念和實踐方面的基礎性貢獻（領導了影響力巨大的奠基性資料庫 Ingres 的開發，也是最早提倡發展列存資料庫的大佬之一），

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

• 1988 年，為解決資料集成問題，IBM 的 2 位研究員 Barry Devlin 和 Paul Murphy，創造性地提出了資料倉庫（Data Warehouse）的概念；
• 1992 年，比爾·恩門（Bill Inmon）給出了資料倉庫的定義，資料倉庫是一個面向主題的、集成的、相對穩定的、反映歷史變化的資料集合，用于支持管理中的決策制定；
• 1993 年，E.F.Codd 提出 OLAP，以及 OLAP 12 條準則，
• ......

能看到，早些年的資料庫界名人們，并沒有太多中國人士，和作業系統一樣，中國在這類基礎軟體上的起步和投入都不算太早，這也是資料庫領域目前成為我國 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 流派

上圖是清華大學李國良教授團隊梳理的 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 大致有四種實作方式：

• 方案 1（一套系統一套存盤）：在一個系統里用一種資料格式滿足兩種業務需求；

• 方案 2（一套系統兩套存盤）：一個系統里同時存在行存盤和列存盤，行存盤上的更新會定期匯入到列存盤里轉換成列存盤格式；

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

• 方案 4（多套系統松耦合）：不同的異構系統之間，通過獨立的插件服務對資料進行準實時同步，對外呈現 HTAP 能力，

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

HTAP 迷思

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

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

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

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

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

Gartner 在去年發布的《Gartner 2021 十大資料和分析趨勢》報告里，特別提到了一個重要的趨勢：，From Big to Small and Wide data

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

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

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

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

Small data 概念

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

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

Wide data 概念

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

基于寬資料的資料分析技術圍繞著結構化和非結構化資料的分析和協同，而不管資料集是否直接相關，寬資料最大的特征是可以提取或識別異構資料集之間的聯系，

Small and Wide data 結合的作用

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

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

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

Small and Wide data 核心場景

說了這么多“小”資料和“寬”資料，這兩個到一塊兒究竟能落地到什么應用場景上？

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

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

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

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

• 零售需求預測（Retail demand forecasting）
• 實時行為智能（ Real time behavioral intelligence）
• 超個性化和整體客戶體驗的改善（ Hyper personalization and improvement of the overall customer experience）
• 人生安全
• 欺詐檢測
• 自適應自動系統（比如自適應 AI）等等

雖然“小”資料和“寬”資料技術的確切結果還沒有出現，但這個概念肯定是未來可期的，因為這些技術能夠在過去或歷史趨勢不再相關的領域提供卓有成效的洞察分析能力，

對于從“大”資料到“小”資料的程序，一個趨勢就是，資料分析不必一定從數倉開始， 而是從前端業務系統，結合一定的場景，首先發起快捷的資料分析， 解決場景定位，方案范圍初篩等資料的初步處理，讓后繼的分析盡可能地聚焦在指定的領域，一方面減少計算量，同時加速后繼決策的速度，

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

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

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

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

SoTP 初探

SoTP，即 Serving over TP，

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

StoneDB 2.0 云原生分布式實時 HTAP 架構詳細設計以 RFC 形式持續進行，歡迎大家關注我們最新進展，更歡迎給我們開源協作的模式和方法提出改進意見，一起通過開源的方式共建 StoneDB ~

https://github.com/stoneatom/stonedb/issues/436

• StoneDB 代碼已完全在 Github 開源：

https://github.com/stoneatom/stonedb

• StoneDB 官網：

https://stonedb.io/

標籤：MySQL

上一篇：封裝適用于CentOS7的MySQL離線包

下一篇：Python基礎之資料庫：2、MySQL的下載與安裝、基本使用、系統服務制作