在上一篇文章《HTAP 的下一步？SoTP 初探（上）：資料分析正在從“大”資料趨向“小”而“寬”資料》中，我們從 HTAP 的發展曆史脈絡出發，結合國際知名咨詢機構Gartner 的調研報告，點出了 SoTP（Serving over TP）誕生的背景。今天這篇文章，我們着重來講一講，SoTP 的定義、解決的問題和典型應用場景。本文是在第七屆中國開源年會上的演講實錄+編輯補充版，權當抛磚引玉，歡迎廣大同行批評指正。
SoTP 的重要支撐
“小”資料和“寬”資料的崛起
開篇還是回顧一下，我們提出 SoTP 的重要背景：從“大”資料轉向“小”資料和“寬”資料。
根據 Gartner 技術成熟度曲線的判斷，小資料正處于“創新出發點”的階段，可能還需要一段時間才可以進入成熟，不過，随着小資料市場滲透率不斷提高，它對 AI 以及更廣義的資料分析的影響是顯而易見且非常深遠的。小資料的優勢在于，抛開了對大型單體資料的依賴，實作了對于大型、小型、結構化、非結構化資料源的分析與協同。
這個趨勢不僅僅是被 Gartner 一家認可的， 國際權威學者吳恩達教授也在今年 2 月初提出了：AI 的下一個發展方向，是從大資料轉向小資料。當然，我們提的 AI 也隻是實時事務處理與資料分析的一個重要應用領域而已，并不是全部。不過，未來資料庫、資料分析處理與 AI、ML 的結合卻是必然的，就比如我們後續将在 StoneDB 架構中加入的 StoneDB Autopilot 功能。作為在人工智能和機器學習領域上有着全球級影響力的領軍人物，吳恩達最近幾年一直在倡導以資料為中心的人工智能。什麼叫以資料為中心？那就是對資料的質要有更高的要求而不是一昧的追求量（優質的小資料集經過訓練也能有很好的泛化能力，如果讀者感興趣，可以閱讀吳恩達接受 IEEE Spectrum 的采訪新聞），而“小”資料和“寬”資料恰恰就是高品質資料集的最佳載體，可以了解為，這是衆多資料分析場景逐漸從依托“量”轉向提升“質”的重大發展趨勢。
大勢所趨之下，作為實時資料分析場景的基礎底座之一，HTAP 資料庫扮演着的角色也越來越重要。如果說通過“小”資料和“寬”資料獲得了更高質的資料，那麼熱資料則是對這個質的再一次提升。
熱資料一般是指頻繁被通路查詢的線上資料，而在一個實時智能決策系統中，近期産生的熱資料往往才會發揮最大的價值，但是，并非所有 HTAP 資料庫都是專注于熱資料場景下的“小”而“寬”資料的，對此，StoneDB 作為國内首個對标 Oracle MySQL HeatWave 的開源實時一體化 HTAP 資料庫，率先提出了面向熱資料、小資料和寬資料場景的 SoTP 型資料庫理念。
SoTP 資料庫的定義
2.1 Serving 的定義和分類
先說這個 Serving 場景，一些同學可能有些不熟悉，因為好像之前聽到的都是 OLTP 場景（指線上事務處理，比如業務處理，交易系統等） 和 OLAP 場景（指線上分析處理，比如BI、Adhoc等），但其實還有一種場景，是指線上實時服務的，介于 OLTP 和 OLAP 之間，可能還偏向 OLTP 一些，那麼這種場景我們就稱之為 Serving（英語時态學得好的人，應該可以 Get 到，就是進行時的意思，也即可了解為“進行中的服務”）
Serving 可以和 OLTP 組合，也可以和 BigData 或者 Stream 組合，我們把 Serving 分成了三類：
Type1. Serving over TP（StoneDB）
- 特點：處理事務型熱資料，提供實時分析、事務和分析處理一體化
- 典型代表：Oracle MySQL Heatwave，StoneDB
Type2. Serving for BigData
- 特點：處理非事務型冷、溫資料；适用讀多寫少BI分析類
- 典型代表：ClickHouse
Type3. Serving for Stream
- 特點：處理非結構化資料，作業狀态狀态等資料管理
- 典型代表：RocksDB
為了友善大家了解，我們做了一張圖，三種類型的 Serving 資料庫如圖所示：
2.2 SoTP 的定義和解決的問題
那麼，SoTP （Serving over TP）的定義也就很清晰了，簡單來說，我們把這種有能力對在 OLTP 資料庫上的熱資料、小資料、寬資料進行 Serving（線上實時服務） 操作的資料庫，稱之為 SoTP 資料庫。具體來講，比如以 SoTP 資料庫 StoneDB 為例，一個 SoTP 産品至少要滿足以下幾點要求：
- 資料量：一個系統，資料量不超過 100 TB，通常介于 100GB~100TB 之間
- 資料類型：主要處理結構化資料，可處理 Text、JSON 等半結構化資料，不處理非結構化資料
- NoETL：TP 到 Serving 的流轉過程中，NOETL，直接基于 TP 資料完成實時分析
- 查詢類型：複雜即時的查詢，将事務型熱資料，從行存變成可被快速讀取的列存資料
- 高并發的混合負載：比 AP 查詢的并發高 3 個數量級
- 成本控制：TCO 總成本下降 80%
簡單舉個例子。如下圖，右邊就 SoTP 據庫 StoneDB，對外主要接受兩個業務請求，分别是左邊的 OLTP 和 Serving，其中，進行 Serving 請求的主要是是 OLTP 産生的熱資料。那麼這個 SoTP 處理資料的過程就是先把 OLTP 請求交給主引擎——TP 引擎承載（如 InnoDB），然後再把 Serving 請求交給次引擎——Serving 引擎承載（如 Tianmu）。
2.3 SoTP 的典型場景案例
2.3.1 場景一：Native Analytics Query
注意，我們這裡重點提出了一個 Native，什麼叫 Native，就是指資料源上的原生，我們如果對 OLTP 系統産生的資料進行查詢分析，這裡的資料應該是同源的熱資料，而不是另外一份資料。
客戶需要一個資料庫，既能執行 OLTP，還能高效、實時地運作Analytics；否則還得需要另外一個資料庫運作 Analytics，這引入了額外的複雜性和代價。
傳統的 ETL 方案架構就是比較複雜的，比如 MySQL + ETL + Elastic：
這種方案就不能稱為是 Native，展現在資料源的不一緻、查詢語句文法變更等等。但是，使用 SoTP 資料庫 StoneDB，就有所不同了，我們是完全一體化架構，如下：
StoneDB 一體化架構
采用 StoneDB 這種一體化架構就可以達成降本增效的效果，下圖就是我們在華東地區的一個 CRM 客戶使用 StoneDB 的案例：
總結來說，這個廠商獲得了以下成果：
高相容：平行替代MySQL業務，零改動
低成本：節省了成本 52%
強性能：DTU 提升了 68%
易維護：技術難度降低 50%
2.3.2 場景二：Native Autopilot
Autopilot 自動化了實作大規模高查詢性能的許多最重要和最具挑戰性的方面，包括provisioning、資料加載、查詢執行和故障處理。
如圖，StoneDB 未來的 Autopilot 将有以下特性：
自動系統配置
- 自動資源占用監測，叢集節點按需自動動态伸縮。
- 自動性能監控，對需要分析的表資料進行自适應采樣來預測運作工作負載所需的節點數量。
資料加載
- 自動并行加載：自動調整資料表最佳并行度來優化加載時間和記憶體使用
- 自動資料放置：存儲資料自動分區以實作最佳查詢
- 自動編碼：采用可變長度的字元串編碼確定最佳查詢性能
查詢執行
- 根據曆史查詢計劃執行情況和統計資訊優化查詢性能，提升查詢效率。
故障處理
- 自動錯誤恢複：當資料庫節點通路異常時，StoneDB将自動配置新的資料庫節點并完成資料遷移，確定資料快速恢複。
這裡也可以舉個例子，比如現在我們的需求是減少使用者使用成本：要提供自動化的叢集配置、加載資料、查詢處理和故障處理服務，使得使用者可以更多關注業務開發，減少其繁重且易出錯的運維操作。
在使用 Autopilot 之前：
1. 依據資料量和資料變化率，估算節點數量；
2. 與業務開發人員确定資料分布方案；
3. 業務運作中，不斷優化SQL語句；調整資料分布政策；
4. 叢集節點變化導緻資料遷移，業務架構，中間件等相關政策需調整；
在使用 Autopilot 之後：
1. 搭建好StoneDB服務；
2. 系統依據運作情況，自動調整相關參數，使得StoneDB處于最佳運作狀态；
3. 業務人員和DBA等得到解放，更加關注業務。
SoTP 與 OLTP、OLAP 的差異
我們總結了 SoTP 與 OLTP、OLAP 的差異，具體如下表：
SoTP 資料庫——StoneDB
當然，可能有部分同學看到我們上述的定位，會想着說 SoTP 和 HTAP 有一些相同之處，這是當然，畢竟我們的說法是 HTAP 的下一步，SoTP 初探。實際上，SoTP 針對的是更加細分的 HTAP 賽道，我們的核心目标就是對最近産生的熱資料、小資料和寬資料進行實時分析，更進一步的是，把資料分析能力與機器學習相結合，而且因為我們是基于 MySQL 生态做的一體化架構，也可以把我們稱作是 MySQL 熱資料分析加速器。總之，StoneDB 作為 SoTP 資料庫的核心特性就是：能夠将 Serving 需要的熱資料實時分析做到極緻。
我們努力的現在，就是為了讓下一代熱資料分析盡早走上國産資料庫的曆史舞台，讓更多的使用者體驗到真正的商業智能，進而更好地利用資料協作共享、驅動營運和做出決策。以下便是我們的 StoneDB 2.0 架構圖：
StoneDB 的 2.0 架構完全對标 Oracle MySQL MDS（HeatWave），HeatWave 有多強大？我們後面也會出一篇文章給大家分享一下。目前，我們的架構設計方案的RFC文檔也完全公布在了 Github 上。（Github搜StoneDB）