說到 Why TiDB Matters，其實包含兩部分，一部分是說爲什麼我們叫 HTAP，另外一部分是說 TiDB 怎樣在 HTAP 架構下發揮它的優勢。

什麼是 HTAP？

HTAP，首先 HTAP 是 Gartner 提出的一個名詞，它其實描述的概念很簡單，就是一個數據庫同時能具備 TP 和 AP 兩種能力。TP 就是 Transactional Processing，也就是交易處理，這樣的數據庫是使用行存，支持實時更新，也可以有高併發，一般來說提供強一致的需求，每次 workload 基本上只觸及比較少的數據。通常在數據庫裏面存的是當前數據。AP 則相反，全稱爲 Analytical Processing，即分析處理，大多數分析處理的場景是列存，它支持的只是批量更新支持的也是中低併發的 workload，基本上每個查詢都會處理大量的數據。一般存放的是歷史數據。

所以大家可以看到 TP 和 AP 對於需求和技術側其實是非常不一樣的。因爲這些不同，所以傳統的數據架構其實是下圖這樣子的。

我的在線數據其實是在 online database 上，這部分是處理 TP 的數據，然後 TP 的數據需要通過一個 T+1 導到 AP 數據庫，一般來說有很多種選擇，比如說你是 Relational 的 Data Warehouse 或者也可以是 Hadoop 的 Data Lake，數據處理完之後有兩種選項。一種選項是，數據處理完之後直接出報表或者導到一個 Data Serving 的 database 裏面去，或者回饋到在線庫。不管是其中哪一個環節都會增加數據的延遲，整個數據架構會比較複雜，其實如果你有一臺 HTAP 數據庫，它其實是可以給用戶降低架構的複雜度，也降低運維成本的，順便會提升業務的實時性，以及提升業務的敏捷性。敏捷性就是說你要開啓一個業務或者要新建一個業務所需要的開發週期和架構週期。爲什麼呢？大家之前不是都是用這種老的架構，也跑的也好好的。現在其實 TP 和 AP 的邊界會變得更加模糊化，AP 業務會變得 TP 化。比如說提供報表的同時也提供高併發的短查詢，然後可能會對歷史明細提供一些小範圍的查詢。或者 TP 也會變得更 AP 化，比如在交易的同時需要大規模的分析，或者回饋在線庫，優化在線行爲，或者要對實時的數據業務進行實時分析，或者要對跨業務線提供一個綜合查詢能力。

舉個具體的例子，比如說有一個很簡單的業務叫銷售業務平臺（見上圖），靠左邊是偏 TP 的，最 TP 的是在線訂單管理，要求的就是純粹的 TP 能力，大家可以看右下角的註釋：綠色的是使用行存索引做細粒度的查詢，黑色是高併發，藍色是實時更新。

最左側是最典型的 TP 業務，TP 業務來說需求的就是很明顯的 TP 業務所有的一些技術特徵。再往最右側來看，最典型的 AP 業務是銷售的歷史報表，因爲是歷史報表，所以需要存大量的數據，要求的是可擴展性，一般來說使用列存，列存是用黃色的點。

中間的一些其實是有點像 TP 也有點像 AP 的東西：歷史明細查詢，雖然數據量也很多，但是可能需要點查某一些數據，比如點查某一個人的明細訂單或者點查某一批獲批的明細訂單；熱銷推薦，可能需要的是在交易發生的同時迅速的計算出現在賣的最好的是什麼東西，它可能是對在線業務的一個多維聚合查詢；訂單聯合倉儲的明細查詢或者說實時查詢，它要求的不只是查詢訂單庫的內容，還可能要求同時查詢倉儲庫的內容；實時大屏就更好理解了，我一邊賣的時候一邊看哪些東西賣的比較好或者在什麼城市賣了哪些東西；實時促銷調價會稍微複雜一點，比如根據現在促銷的情況，通過程序的方式實時進行調價。

除了一左一右兩邊分別是 TP 和 AP，中間其實都是 TP 和 AP 混合的場景，因爲它對整個技術側來說需求是非常不一樣的，大家可以看到下方標的那些能力的點都是有不同的需求的。

同時滿足這些需求其實不是很容易，爲什麼？比如說擴展性，TP 的擴展性其實是很難做的，雖然 AP 的擴展性，比如說像 AP 數據庫或者 Hadoop 那些其實都已經很早就有了，但能做 TP 的數據庫還能夠擴展的，其實是近幾年纔有的，就是所謂的 NewSQL。TP 同時要兼具 AP 能力，就要求它同時能有行存和列存兩種存儲格式，光是這兩者還不夠，它還要能有機的把這兩者統和起來，統和起來就會帶來很多問題，比如說在互通數據的時候怎樣保持高實時性，同時兼顧一致性。

TiDB 4.0 HTAP 體系

現在講一下 TiDB。在 TiDB 4.0 之前，已經具備了一些能力。比如首先它立項的時候是爲了一個交易型數據庫來設計的，所以最早的時候就已經是一個比較完善的交易型數據庫，同時兼容 MySQL 的特性，現在線上已經有萬億級的單庫規模，能承載千萬級的 QPS 業務，銀行核心業務上已經穩定上線。但立項一開始並沒有預計到的是，我們其實推出去之後它其實也是一個良好的數據中樞或者叫 data hub 或者是實時數倉的載體。這是以前 TiDB 已經有的兩個大類的使用，就是 TP 和 AP。

從 4.0 來說，TiDB 把 HTAP 體系更加完善了，主要是加入了實時更新的列存，就是 TiFlash。 這套引擎整合在一起其實就是一個可擴展的行存和列存整合的架構，這套整合的架構在存儲上是可以使用分離的不同的節點，可以確保兩邊互相之間沒有干擾，它的實時性、一致性、可延展性都能得到很好的保證。複製本身這套體系是沒有中間層的，所以複製是非常簡便而且非常快的。 就整個體系來說，它不光有列存，有全面支持行存的所有的索引的特性。另外添加了向量化引擎，列存本身和行存之間能通過智能的引擎選擇。

TiDB 本身其實沒有辦法做很詳細的闡述，因爲這是一個短 talk。我們在 VLDB 發了一個 paper，之後等這個 paper 可以公開的時候基本上我們會出一些更詳細的說明，具體說整個 HTAP 這套體系在 TiDB 裏面是怎麼設計的。之所以提一下 paper，是想說這個東西並不是我們自嗨說它是 HTAP 或者說是一個很先進的架構，至少這個東西能通過一個頂刊的學術審覈，能讓研究者也覺得它是一個很有意思的東西。

上圖是現在 TiDB 4.0 的 HTAP 架構，左側是新增的 TiFlash 的節點，右側是 TiKV，上面的計算層還是一樣的，上面的計算層還是以 TiDB 或者說以 TiSpark 爲主。

可擴展的實時更新體系

首先說可擴展的實時更新體系，這裏包括幾點：

第一個是 TiDB 的 TiFlash 架構下還是使用 Mutli-Raft 的 ，也就是說 TiFlash 複製數據和存儲數據的單元，比如說是以 region 爲單元存儲，這些和 TiKV 還是保持一致的，但是它是從一個行存到列存的複製。

第二，這個複製的特點是無需中間介質的 ，也就是說所有的複製並不像普通的複製體系可能要通過一些分佈式的管道，比如像 Kafka 或者其它的 MQ 系統，這樣的話，複製其實會有比較大的延遲。在 TiDB 體系底下的行存和列存之間複製是以 region 點到點之間複製的，所以說你可以認爲當中沒有任何的中間介質，保證複製的實時性。

第三，它兼顧複製和存儲的伸縮性 ，也就是說整個體系來說，剛剛說過還是以 Multi-Raft 來做的，所以 Sharding 的單位也是以 region 爲單位 Sharding，整個調度的模式還是符合原先的調度模式，所以他還是一樣可以自然擴展。有意思的是行存和列存可以分別擴展，也就是說你有可能有一些用戶行存可能需要用更多的機器，有一些用戶可能列存需要用更多的機器，這相對於那些行存和列存放在同機的系統設計來說，要有很大的優勢。

第四也是最方便的是，以上這些，只需要一道命令來開啓。

上圖中，左邊是我們複製體系，大家可以看到是以 region 爲單位，region 到 region 直接複製，相對來說傳統的如果是 T+1 的 ETL 的話要經過一個 Staging Area 或者哪怕實時複製，可能也需要經過 Kafka 那樣的系統，複雜度和延時性都會上升。開啓 TiFlash 同步其實只要一條命令：

mysql> ALTER TABLE orders SET TIFLASH REPLICA 2;

就是爲 orders 表創建 2 個列存副本。

異步卻實時 + 一致的讀取

這 其實是一個異步複製體系，並不是一個同步強制說兩邊都要寫平才能提供服務的一套體系。 所以說交易事務不會被列存 block，也就是說列存不管你是寫的快還是寫的慢，交易都不會被列存 block。哪怕說列存這邊即使 down 了，行存這裏還是可以繼續工作。同時雖然是一個異步複製不等待的體系，Raft 整個共識協議會保證我讀取的數據是最新的。

爲什麼在異步複製底下讀取還是可以最新？說起來其實是一個非常簡單的東西。可以看上圖，我們在讀取的同時會對行存的 leader 節點發起一個讀取校對，這個校對其實就包含我現在複製的進度是多少，你只要告訴我一個進度號就行了，如果進度號不滿足最新的數據要求，其實列存這邊會等待。實際上測下來等待如果不是在  90% 到 100% 的滿載系統裏面，等待的時間其實是非常短的，是以毫秒來計算的。

優化器智能選擇

比較有意思的一點是，這套系統並不是一個和行存之間割裂的系統。 行列之間是一個有機整合，怎麼整合？就是通過 TiDB 優化器，優化器會把列存當做一個特殊的索引，然後通過統計信息的方式，在不同的行存索引之間選擇是一樣的方式，就是基於統計信息和代價優化器去選擇出現在最快的路徑應該是選擇行存還是列存或者說選擇哪一條索引，所以說這套系統在同一個 TiDB 的入口就可以體現行存和列存兩種不同的優勢，用戶也不需要在一個複雜的查詢當中去考慮說我到底是使用行存還是列存，當然用戶如果要保證完美的隔離，也可以手工開啓只讀行存或者只讀列存，這樣就會對應出 TP 和 AP 之間非常隔離的一種方式。

其實之前我們的 blog  上都寫過，由上面兩個圖可見，這套系統的性能是非常不錯的。當時是用 TiDB 加上 TiFlash，對比 Mariadb，對比 Spark 以及對比 Greenplum，當然也對比了 Oracle，但是 Oracle 沒有開始它的列存。

配合 TiSpark

整套 HTAP 體系還有一個特色，就是配合 TiSpark 可以無縫銜接 Spark 上的生態， 比如提供 AI 計算、Data Science 的 toolbox、BI 的對接，或者複雜的場景分析，這些都是可以由 Spark 體系加 TiSpark 來提供。它同時也可以 Hadoop Data Lake 當做同一套系統來查詢。對於 TiDB 體系來說，則是提供一個重型複雜查詢良好的分佈式計算的性能。

上圖是 TiSpark 加 TiFlash 對比 Greenplum 的性能，大家可以看到基本上是處於同一個量級，就是有一些 Greenplum 會更快一些，有一些 TiSpark 加 TiFlash 更快一些。

TiDB HTAP 應用實踐

回到前面已經闡述過的觀點， 在 HTAP 場景底下 TiDB 能爲用戶提供一個簡化架構，降低運維複雜度，更重要的是我們提升業務的實時性，提升業務的敏捷性。

上圖是 TiDB 其中 AP 場景當中一個比較主流的用法，就是做一個實時集成，也可以叫實時數倉，也就是說我用同一套 TiDB 可以做一個多源匯聚，不同的數據業務庫從不同條線實時匯聚到 TiDB，因爲 TiDB 是一個可持續更新的系統，所以它可以很方便的兼容從其它的 OLTP 庫同步數據。同時在這套 TiDB 上也可以提供實時的查詢，比如說可以提供報表，或者做一個客服系統，把各種不同庫匯聚過來的信息給客戶提供服務，或者做實時大屏，還可以做 AI。

另外一種是更具體一點的用法（見上圖），比如原本有很多用戶是拿 MySQL 當在線庫，然後他需要做 T+1 的同步到一個分析型數據庫或者到 Hadoop，MySQL 提供的是在線的業務，BI 工具是連接到分析型數據庫或者是連接到 Hadoop 上。對於這樣的場景只需要一套 TiDB，原來 APP Server 對接的在線業務庫就可以對接 TiDB 的行存，原來 BI 工具對接的報表類分析可以對接 TiDB 的列存。這樣的話，對比先前，不光是架構簡化還可以大大增加你的實時性能。

有很多人可能會說你說的這麼好，其實我不可能把所有業務都遷到 TiDB 上去，我現在也有我很成熟的 Data Warehouse 架構，我也在數倉做了很多建模，有很多方法論，對於這樣的場景來說，是不是 TiDB 就沒用了呢？

很多現在其實已經有 Hadoop 或者有數據倉庫的用戶其實是這樣使用 TiDB 的 HTAP 體系的（見上圖）。對於實施層來說，它會把數據匯聚到 TiDB 當中，TiDB 會提供一個 Real Time Layer，這個 Layer 會直接提供一些實時的查詢，甚至直接提供對外的數據業務服務。同時也可以通過 Spark 把數據遷移到 Offline 的 Hadoop Layer，Hadoop Layer 同時可以把數據建完模或者清洗完，或者做一些聚合之後再回饋到 TiDB 層，這樣 TiDB 會提供一個更方便的數據服務。因爲一般來說不太可能把 Hadoop 直接當做 API 暴露到對外的層面，因爲 Hadoop 承載不了這樣比較高速實時的查詢。所以這樣的一套體系就會比較方便的爲你整個現有的這套機構賦予一個 real time 的能力。

目前這套系統已經被很多用戶應用了，大家可以查看《 TiDB HTAP 助力小紅書業務升級 》、《 TiDB 4.0 在 VIPKID 的應用實踐 》、《 海外直播軟件 Bigo 的 TiDB 4.0 線上實踐 》、《 從 Exadata 到 TiDB，中通快遞 HTAP 實踐 》，看看我們的用戶現在怎麼用以及現在這套他們用的好不好。