架構選型之痛，如何構造 HTAP 資料庫來收斂技術棧？

HTAP，是目前資料庫領域比較流行的一個新理念。

近日，國際頂級專業分析機構 451 Research 發表了一篇關於 TiDB 的報告《PingCAP eyes US market with database targeting operational and analytical workloads》，其中就提到 TiDB 是一款同時面對在線處理業務和數據分析業務的混合資料庫，也就是現在流行的新理念 HTAP。

此外，報告還很清晰地向資料庫大鱷集中的美國市場宣布，中國狼來了。那什麼是 HTAP？如何進行構造？本文我們就以 TiDB 為例一起詳細解讀下。

我們到底需要多少數據副本？

首先從業務數據副本數量開始。先問大家一個問題，在你們公司（假設在一個信息化比較完整公司），核心業務數據在整個公司數據生命周期里有多少份數據副本？這其實是個很大的問題。

按照主流概念，系統架構分為在線處理系統（OLTP）和在線數據分析系統（OLAP）。從數據流的角度，往往 OLTP 在上游、OLAP 在下游，中間還有一層數據通道，包括 WAl 等日誌及相關解析工具，比如 MySQL 的 Syncer、Databus，以及數據隊列（MQ）、數據清洗（ETL） 等。

在常規的高可用環境下，這三層數據都需要進行冗餘，那麼副本數量到底有多少？我們按照這幾個階段簡單進行下統計。

OLAP 產品百花齊放

關注大數據的同學會發現，現在的大資料庫產品在最近十年可以說百花齊放，湧現出了很多優秀技術棧以及對應的產品，比如 Hadoop 系的 HBase & Hive，搜索引擎 ES、Sorl，數倉組合 Kudu & Impala ，文檔資料庫 Mongodb 等等......這些產品都有表現很優秀的場景和特長。

但另一個現狀是，每個產品適用場景都有相對清晰的邊界（當然每個產品都在通過自身的迭代來擴展空間）。而業務需求是無邊界的，所以很多大一點的公司在大數據層面都存在若干個 OLAP 產品。因此這裡面隱藏了比較大的技術、人力成本，以及數據同步的成本，這造成的最直接結果就是在泛 OLAP 需求上存在很多數據副本。

大數據發展路線圖：

業務系統（OLTP）為何也存在多副本？

相對 OLAP，OLTP 的技術創新相對會平淡很多。

從 DB engine 排名來看，近幾十年，前幾名一如既往的是那幾個耳熟能詳的關係型資料庫。當然每個資料庫產品都在按照自己的方向進行迭代、升級，Oracle 在技術層面持續領先和極致優化，MySQL 5.6 / 5.7 / 8.0 迭代越來越快，也有很多關鍵特性如 MGR、Innodb cluster、並行複製等、PostgreSQL 被評為2017年度資料庫、SQL Server 得意於中型用戶，近兩年資料庫市場份額在穩步提升。

但是這些傳統的單機資料庫，在存儲容量、吞吐容量（讀寫 QPS）、單錶行數方面都有一定的上限。以 MySQL 為例，為了滿足業務更大的吞吐量需求，普遍採取分庫分表的妥協方案（Sharding + Proxy），這套方案對應用侵入很大，而且還需要業務進行一定的妥協。比如，拆表會帶來業務多維度查詢的問題。以電商業務為例，分庫分表往往是按照用戶的維度進行拆分，但從業務角度，一定有商家維度查詢或者其他某業務屬性維度的查詢，比如 deal、地域、門店、類型等等。那普遍作法是按照商家（或者某業務屬性）再做一份數據，然後用雙寫或者非同步隊列的方式進行非同步同步，中間還會根據需要維護一份多維度對應關係（Mapping）。這樣業務多一個維度需求，就會多一份數據冗餘，而在一些細分行業，業務維度是很難控制的，比如餐飲行業的報表 SaaS 服務，業務維度往往有十個之多。

我們真的需要這麼多副本嗎？

從高可用角度都需要進行數據副本冗餘，如果有跨 IDC 高可用需求副本冗餘再進行相應增加。在 master - slave，slave 普遍用於進行承擔讀流量，而在實際情況下，由於讀容量及不同讀流量的隔離考慮，往往是一主 N 從庫。再加上分表後多維度的問題，假設需要 M 個維度，那麼在 OLTP 場景下，副本數據量就變成了 (1+N)*M。

數據通道會有份 WAL 日誌，以及日誌解析後的隊列，算上高可用的至少一份冗餘，那麼數據通道至少會存在 2-3 X 副本（X 是技術棧數量），最後數據流入中台系統，以及大數據分析用的後台系統（OLAP）。

假如 OLAP 場景有 Y 個技術產品，同樣以三份冗餘進行高可用，那麼整個副本數量變成了 (1+N)*M + 2X + 3Y。

這裡的數據量都是預估，不用糾結具體多少，只是想表達副本的數據是比我們感覺得要多很多。那麼這 20+ 個數據副本背後是很多技術棧、資料庫產品，每個技術棧背後又需要單獨的人力、團隊進行支持和維護，如 DBA、大數據組、基礎架構等。所以這些傳統方案背後存在巨大的人力、技術、時間、運維成本。

如何在滿足各種業務需求的同時，盡量減少副本數量、收斂技術棧就變的很重要，所以構造一款能同時支持在線處理業務和在線分析業務的混合資料庫（HTAP），就是一個非常理想的解決方案。

如何構造 HTAP？

既然如此，那麼如何構造 HTAP？

其實最早的混合資料庫還要從 Oracle 說起。在最早期，Oracle 就通過針對性的技術點，比如分區、並行計算、點陣圖索引、Hash Join、物化視圖、單次 IO 吞吐量等技術點來支持 OLAP 場景。

正如前文所說，單機資料庫的容量限制制約了其在海量數據場景下的使用，而與此同時 OLTP 業務更關注的是並發能力、事務、實時更新、響應時間，而 OLAP 業務更關注的是容量、計算能力、吐吞量等。所以 OLTP、OLAP 為了面對各種的需求，一個再分、一個再合，從技術實現上開始分道揚鑣。

因此，在海量數據下如果要實現 HTAP 需要滿足至少以下幾點：

底層數據要麼是一份，要麼可以快速複製，並且要同時滿足高並發的實時更新；

要滿足海量數據的容量問題，在存儲、計算、吞吐量都具有很好的線性擴展能力；

表最好不要進行分片，至少在邏輯層需要是一張表，盡量避免去處理跨分片 Join 的問題；

要充分利用分散式多節點優勢，要有很好的並行計算、並行 IO 掃描能力，不管是表掃描還是索引掃描；

有很好的優化器，支持多種關聯演算法，如 Hash Join、Sort Merge 等；

既要支持 OLTP 必須的事務、標準 SQL，高並發讀寫、二級索引，還要支持諸如分區表、並行下推計算、bitmap（或者列引擎）、並行數據定址、向量化等 OLAP 常用技術。

新一代資料庫 TiDB 在 HTAP 的嘗試

首先要解決資料庫容量和吞吐量的問題，而且是在不進行分表前提下。

熟悉 TiDB 的同學應該知道，TiDB 在存儲層通過自動分片分裂技術（auto region split）實現了邏輯表與底層分片一對多的關係（可以理解就是一張表），避免了分表 Join 問題，並且通過在不同欄位支持二級索引的方式，規避里分庫分表業務多維度查詢的問題。具體這塊不展開，大家可以關注官網進行架構解讀（https://pingcap.com/docs-cn/）。

儘可能地利用本地（存儲）計算能力。

TiDB 底層是個分散式存儲系統，每個存儲節點都有自己獨立的計算層（Coprocessor）和緩存層，我們可以採取最大程度的下推策略（謂詞、計算、小表廣播等）來儘可能地利用本地（存儲）計算能力。

這樣實現了一個類似 MPP 的並行計算模型。不但大規模地減少網路交互，還極大提升了整個集群的並行計算能力，如下圖：

具有多種表關聯演算法。

大家都知道，MySQL 里所有表的關聯只有嵌套循環一種演算法（Nest Loop）。嵌套循環其實就是兩層循環，數據量較少外層（驅動表）數據集（表）取一條數據，然後和數據量較大的內層（被驅動表）數據集（表）進行逐條匹配。這種演算法是響應時間優先，只適合於小表做驅動表的情況，對最後匹配數據（吐吞量）並不友好。

這個有點類似當下流行的相親會節目《非誠勿擾》，每次就四五個男生（小表）作為驅動表逐個亮相，然後被一群女嘉賓（大表）進行選擇。假如男生數量也很多，顯然這種演算法就會很低效，尤其是當你更關注最終結果時候（吐吞量優先業務，比如想知道最終相親成功多少對），所以這種演算法遠遠不夠，尤其是我們要面向更大量的數據時候。

所以 TiDB 表關聯的時候不但支持 Nest Loop，還支持 Hash Join 、Sort Merge 、Index Join 對吐吞量更友好的演算法。同時在進行 Hash Join 的過程與驅動表還支持並行匹配，而數據定址過程不管是表還是索引都支持並行掃描，這些都變得很重要。具體見下圖：

計算與存儲分離。

我們可以在存儲系統部署不同的計算層。除了默認的 TiDB Sever，我們還可以藉助 Spark 平台本身的優勢，同時融合 TiKV 分散式集群的優勢，讓 Spark 識別存儲層數據格式、索引結構、統計信息等，進而實現計算下推、CBO、二級索引等功能。最終我們可以提供 TiSpark 的解決方案，面向索引篩選粒度很低，甚至沒有很好索引的大表複雜查詢場景。

除了默認的行存資料庫，拼圖上還需要一款列存儲引擎。

在列式資料庫里，數據是按照列進行存儲，每一列單獨存放，數據即是索引。由於數據類型一致，會有非常高的壓縮比，應用只需查詢對應的列，所以整個掃描的 I / O會很低。同時列存也非常適合批量數據處理、即時查詢，尤其是聚合、分析查詢。

所以在 TiDB 架構上，我們選擇一個非同步的同步副本存儲在列存儲引擎上，面對更重、更複雜的聚會等查詢。進而實現了底層兩款不同的存儲引擎、上層兩款不同的計算引擎組合架構。具體見下圖：

SQL ON TiDB

如果我們把 SQL 按照複雜程度做個幾層分類，TiDB 至少以下四個級別的場景都有對應的解決方案和思路，包括：

高並發的實時寫入更新、隨機點查、範圍查（典型 OTLP）；

多表及大表關聯等一般複雜查詢（數據中台）；

索引過濾低的高吞吐計算查詢（OLAP）；

複雜聚合、分析等重查詢（OLAP)。

具體見下圖：

當然我們並不是想表達 TiDB 就是 HTAP 的銀彈。就像前面所說的，在資料庫產品體系中，尤其是 OLAP 技術棧百花齊放，每個產品都有表現非常好的場景，TiDB 並不是要替換誰，設計思路是從最上游業務系統就接入數據，用底層複製技術來替換傳統的數據通道，進而實現數據的實效性。然後再通過不同的計算層、不同的存儲層來面對不同的業務需求，同時依賴自身的架構優勢，可以實現通過增加計算節點、存儲節點來實現讀、寫、存儲容量的線性擴展，通過設置、分配後台不同等級隊列、副本讀、Slave cluster 等思路來實現 OLTP 查詢和 OLAP 查詢底層的資源隔離。

這樣就給大家提供一個新的選擇，尤其對不想花很大精力去維持多個技術產品、平台，或者對數據分析有一定實效性的需求的公司。

最後

TiDB 是先致力解決 OLTP 單機容量的問題，在這個場景相對於傳統的 Proxy + Sharding 優勢很大。但與此同時，我們也發現在很多業務中台、OLAP 也有很好的場景，尤其是在一些垂直行業。

比如餐飲行業的 SaaS 服務，他們會為商家提供各種業務維度的統計報表，這些業務維度高達十個之多。最早商家總是質疑：既然我們的訂單、外賣、排隊、營銷等等都是實時產生數據，為何相關維度報表要 T+1 之久？最早服務商會通過加機器、預處理、Mapping 等手段去優先少部分業務維度需求，顯然這種處理方式性價比很低，而且商家也不太理解（有的時候，使用者不懂技術會成為一種生產力）。

而在 TiDB 里，不需要分表，這些維度都可以簡單抽象成某欄位列二級索引的形式進行滿足，進而實現真正意義的任意業務維度實時報表。目前這個垂直行業大部分提供商都已經上線或者 POC TiDB 中。

在《汽車總動員三》中，大家發現除了我們喜愛的閃電麥昆外，這條賽道里湧現了很多新的面孔。而在資料庫的漫長賽道里，從 EF.Codd 提出關係型資料庫模型到現在，關係型資料庫已經在主導這個賽場近半個世紀，而本世紀初大數據滋生了十年之久 NoSQL 的思潮，產品可以說百花齊放。

在此基礎之上，近幾年各種 NewSQL 產品也逐步嶄露頭角。正如前文所述，喜聞樂見的是在這場新的角逐了也湧現了很多中國力量。正如那個有趣的《嚇尿指數理論》，資料庫變革也在加速。在新的賽場上，下一個明星可能是新一代的黑風暴傑克遜，或者是那個一直不被看好的小妞酷姐拉姆雷斯。

作者：房曉樂（dbaoutdo），PingCAP 架構師，前美團點評資料庫專家，前搜狗、百度資深 DBA。

聲明：本文為作者投稿，版權歸作者個人所有。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！