一、HTAP 的起源、流派和迷思
HTAP 起源
我們首先從起源講起，不過由于是公開演講，考慮到一些聽衆是小白，是以這裡主要是從一個比較宏觀的關系型資料庫行業發展曆史視角來看的，關于 HTAP 更具體的技術和商業的起源背景，可以看看 StoneDB 首席架構師李浩老師寫的這篇文章：HTAP 的背景。
衆所周知，圖靈獎（Turing Award）算是計算機領域裡最高的一個獎項，截至今日，因為在資料庫領域有傑出貢獻而獲得圖靈獎的隻有四位，分别是：
- 查爾斯・巴赫曼（CharlesW. Bachman），1973 年獲獎，設計并開發了網狀資料庫管理系統 IDS，推動了資料庫标準的制定，包括網狀資料庫模型、資料定義和資料操縱語言的規範說明（通俗來講，是他第一次提出了資料庫這麼個東西，可以說是咱們的祖師爺）；
- 埃德加・弗蘭克・科德（Edgar Frank Codd），1981 年獲獎，提出了關系資料庫模型（關系型資料庫經久不衰，目前依然占據市場最多的份額）；
- 詹姆斯・古瑞（James Gray），1998 年獲獎，主要是在大型資料庫和事務處理技術上的突破（重點研究如何保障資料的完整性、安全性、并行性，以及故障恢複，曾擔任 VLDB 期刊的主編）；
- 邁克爾・斯通布雷克（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.<br /><br /> 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 資料庫。