時代在召喚： HTAP Is On The Way 近些年，HTAP 正在受到人們越來越多的關註，Gartner 在 2014 年提出了 HTAP 這個術語和它的定義： Hybrid transaction/analytical processing (HTAP) is an emerging ap ...
時代在召喚： HTAP Is On The Way
近些年，HTAP 正在受到人們越來越多的關註，Gartner 在 2014 年提出了 HTAP 這個術語和它的定義：
Hybrid transaction/analytical processing (HTAP) is an emerging application architecture that ”breaks the wall“ between transaction processing and analytics. It enables more informed and ”in business real time“ decision making.
在此之前，市面上基本是 OLTP 和 OLAP 資料庫的天下。
OLTP
第一個有效的面向事務的資料庫在 1970 / 1980 年代開始廣泛使用，它們後來被稱為線上事務處理 (OLTP：Online Transaction Processing) 系統， 事務處理對單記錄操作可靠性、準確性和速度要求非常高。
OLAP
隨著數據量的增大，特別是互聯網的發展，OLTP 資料庫的工作負載越來越大，同時分析能力嚴重受限，我們需要一個能非常快速地在一個或多個資料庫表中查找單個記錄、多條記錄或一種記錄總數的資料庫。OLAP 資料庫同 OLTP 資料庫在技術上也分道揚鑣。
然而，針對不同數據場景選擇對應的 TP / AP 系統也帶來了相應的難題，因為 TP 和 AP 不是一套系統，在搭配使用時就會有數據傳輸的過程。在 一體化實時 HTAP 資料庫 StoneDB，如何替換 MySQL 並實現近百倍性能提升的文章中，我們總結了業界通過 TP / ETL或數據遷移 / AP 結構來構建 HTAP 系統存在的一些問題：
- 實時性低（TP + AP 系統導致了數據孤島，意味著 OLAP 資料庫中的數據總是過時的，根據數據量的不同，數據延遲通常從幾小時到一周）。
- 企業維護兩套資料庫系統，管理和維護成本很高。
Gartner 的最新報告表明，傳統的 TP + AP 架構將事務和分析系統分開，業務實時響應的高需求意味著使用“過時”的數據已經不合時宜，商業時刻轉瞬即逝。我們需要創建一套更簡單的體繫結構，讓 TP + AP 及 ETL 過程被單個資料庫所取代，消除數據副本，將數據存儲在 OLTP 引擎中進行事務處理，然後將數據複製到 OLAP 引擎（可能多次）以進行分析。隨著軟硬體基礎設施和資料庫技術的不斷進步，屬於 HTAP 資料庫系統的時代已經到來。
HTAP 資料庫 StoneDB 為什麼選擇擁抱 MySQL 生態?
StoneDB 並不希望打造一個新的 StoneDB HTAP 生態。對於大部分資料庫用戶來說，最好的產品體驗就是開箱即用，在一個黑盒系統中完成業務的平滑遷移，最大程度的降低用戶學習成本和運維成本。而 MySQL 是世界上最流行的資料庫，擁有龐大和成熟的生態。
從 DB-Engines 排名上看到，MySQL 穩居第二，僅次於 Oracle。（下圖來自 DB-Engines）
Shadowserver Foundation 在 5 月 31 日發佈了一份全網的 MySQL掃描報告，超過 360 萬個 MySQL 實例暴露在公網。這隻是暴露出來的，我們可以推斷，實際的裝機量要遠遠大於這個數字。
IPv4 掃描
IPv6 掃描
業界唯一開源的 HTAP
我們以存儲架構為特征對業界最新的 HTAP 資料庫做一個概覽：
- 基於磁碟的行存儲 + 分散式列存儲：MySQL HeatWave
- 以行存儲為主 + IMCS （記憶體列）：Oracle Database In-Memory（A dual format in-memory database）、 SQL Server、DB2 BLU
- 分散式行存儲 + 列存副本：SingleStore
- 以列存為主 + Delta Row Store：SAP HANA
從上述中可以看到，哪怕是最流行的開源資料庫 MySQL，它的 HeatWave 也不開源。
StoneDB 就是希望打破這種局面，在開源這條道路上做一個探索，做一款由我們中國人主導的開源 HTAP 資料庫。
MySQL 原生
StoneDB 沿用並適配 MySQL sql 層，原生 100% 相容 MySQL 協議和語法，我們先看下 StoneDB 官網提供的 2.0 架構圖：
架構圖中相關術語介紹：
IMCDP：In Memory Column Data Pack 的縮寫，存儲在記憶體中的列數據包。
IMCDPI：In Memory Column Data Pack Index 的縮寫，用於保存 IMCDP 的元數據，包括：
- 對象數量
- 列數量
- 映射行的信息
- 事務相關的數據
SMU：snapshot meta unit 的縮寫。
在 StoneDB 2.0 的設計中，會推出類似 MySQL HeatWave 的 In-Memory Column Store 引擎：基於磁碟的 RDBMS （MySQL 8.0）和分散式記憶體列存儲（IMCS）來實現 HTAP。
StoneDB 在不改變 MySQL 原生的 OLTP 工作負載的前提下，深度集成 IMCS 集群以加速查詢處理，事務在原生 MySQL 工作負載中執行。另外 StoneDB 會自行判斷複雜查詢並將其下推到 IMCS 引擎進行加速處理，經常訪問的列將被載入到 IMCS 中，列數據從行存儲中提取（由 InnoDB 並行載入到 IMCS），熱數據駐留在 IMCS，冷數據落盤。
基於 IMCS 引擎我們將實現 AP 負載的全記憶體計算：
- 記憶體中數據組織方式：IMCDP + IMCDPI 。
- 數據載入方式：由 InnoDB 並行載入至 IMCS 中。
- 數據的更新：當 TP 中的數據發生變化的時候，實時更新到 AP 引擎中。
- 記憶體中數據持久化及系統恢復：為了加速恢復的速度，我們將記憶體中的數據持久化到我們的 on-disk column store 中。
高效載入 TP 數據（From InnoDB）
上圖是剛剛介紹了 StoneDB 2.0 架構中提到的從 InnoDB 並行載入數據的示意圖。
與 HeatWave 採用的方案類似，通過並行掃描 TP 中的數據（主要是 InnoDB 表），將需要載入的數據按 partition ,chunk, vector, tile 的數據組織方式並行的載入至 IMCS 中，每個partion 中包括若幹個 chunk，每個 chunk 中又包含若幹個 vector，每個 vector 中包括了某列中的部分數據。同時，提供導入行為的監控能力，實時感知載入進度。在載入過程中通過非阻塞，無鎖機制來實現高性能數據載入能力。
數據的更新
當 TP 中的數據發生變化後，將該項數據插入到 Population Buffer 中，並維護該數據的版本信息。當滿足如下任一條件的時候，會將 Population Buffer 中的數據，依據版本信息依次與記憶體中的數據合併為最新的版本數據：
- 當我們的 Population Buffer 已經寫滿後，會執行一次 flush 動作，將 Population Buffer 中的數據更新到其對應的數據中。
- 指定 merge 的時間，例如：200ms。
- 當 AP 中的負載發現其引用到了 TP 中的數據，其會主動的檢查 Population Buffer 是否有最新的版本。如果有則合併形成最新數據。
未來 2.0 其它的重點工作：
- 基於代價的新查詢引擎：一個負載透明，具有更加高效，準確的代價模型將是我們系統性能的保證；並行查詢和向量化等技術也將會得到持續的迭代。
- 分散式 Column Store AP 集群將在單機能力構建後，重點演進。
最後
除了 Gartner 的原始定義，我們對 HTAP 更多視為一個集硬體、TP、AP、記憶體、雲原生資料庫技術、可擴展事務管理等多種功能的新興架構，使事務處理和分析（HTAP）能夠在同一套資料庫上運行。
一個現代的 HTAP 資料庫應該具備以下特性：
一致性：包含全面的 ACID 事務支持。數據密集型應用程式可以依靠它來保證數據一致性，從而提高開發人員的速度和用戶體驗。
高可用性：無論後端發生什麼，用戶都能進行 7x24 小時的訪問。有一套內部機制來處理機器故障和網路問題等瞬時和永久性故障（比如宕機/腦裂），並且提供數據複製和細粒度數據放置功能，以確保數據高可用。並且提供滾動升級機制，避免集群擴展和架構升級等引發的停機對業務造成影響。
可擴展性：應用雲原生技術，其計算和存儲資源可以輕鬆擴展以應對業務的增長。按需且實時地添加新節點，以存儲更多數據、處理更多讀取和寫入以及處理更複雜的查詢。
實時性：資料庫應支持任何實時更新，從而實現細粒度索引和並行查詢執行。為了確保及時性，資料庫架構必須同時利用行存儲和列存儲，並基於查詢優化器選擇最佳的數據訪問路徑。
