使用 TiDB 構建實時應用

做者介紹：雷宇，TiFlash 研發工程師，畢業於中山大學軟件工程專業。目前主要在 PingCAP 從事 TiDB SQL MPP 的相關研發工做。

本文由 PingCAP 研發工程師雷宇分享，主要從宏觀角度分析 TiDB 究竟能作什麼，創造什麼樣的價值，以及研發過程當中的一些設計立足點。 文章將從四個部分分享：

• 首先，數據管理技術的演進；

• 其次，TiDB 能作什麼？

• 第三，你們是怎麼用 TiDB 的？

• 第四，TiDB HTAP 的將來。

數據管理技術的演進

首先，簡單的回顧一下數據管理技術的演進。

• 上個世紀 70 年代，IBM 研發了世界上第一個關係型數據庫 System R，是第一個使用 SQL 做爲查詢語言的數據庫，也爲後來的關係型數據庫的設計奠基了基礎。

• 到了 80 和 90 年代，關係型數據庫開始野蠻生長，涌現出一大批商業關係型數據庫，好比當前知名的 Oracle、IBM 的 DB二、微軟的 SQL Server，以及如今比較流行的開源關係型數據庫 PostgreSQL、MySQL 等。這個時期，技術上的重點主要是數據庫的功能完善，好比存儲過程、觸發器、各類各樣的索引，以知足不一樣的業務需求。

• 2000 年代初期，全世界都進入了互聯網時代，數據開始呈現指數型增加，傳統的關係型數據庫沒法容納如此龐大的數據。此時，一些互聯網公司開始牽頭，將內部處理海量數據的方案進行開源。2004 年左右，由谷歌牽頭髮表了三篇論文，分別是他們的分佈式文件系統 GFS、分佈式計算系統 MapReduce、分佈式存儲系統 BigTable。在這三篇論文的指導下，Hadoop 生態社區繁榮發展。同時，分佈式 KV 數據庫 Cassandra、MongoDB 等也在這個時期出現；傳統的關係型數據庫也在發展，出現了一些很是關鍵的技術，好比 MySQL 的 InnoDB 引擎、Oracle RAC 分析引擎。單一的數據庫產品已沒法知足用戶的需求，整個數據處理領域的技術方向出現了嚴重的分化。OLTP 領域依然被傳統關係型數據庫佔領，OLAP 領域則成爲了後來的大數據技術主戰場。

• Pre - 2010s，得益於硬件的發展，內存的容量和網絡的帶寬與延遲有了極大提高，數據庫架構迎來變革。內存數據庫和分佈式數據庫大規模投入生產。表明產品：Google Spanner、SAP HANA、SQL Server Hekaton、Amazon Aurora。這個時期 OLTP 的概念和 OLAP 的概念逐漸開始模糊，並有人提出了 HTAP，將 OLTP 和 OLAP 混合在一塊兒，在同一個數據庫上同時處理這兩種負載，回到了數據庫產品的初衷。

• Post - 2010s，延續了 2010 年代初期的輝煌，各類 NewSQL 數據庫出現，能夠承載更加複雜的負載。表明產品：CockroachDB、TiDB、VoltDB、Azure Cosmos DB，各類技術開始走向不一樣的方向。

總體來看，從 2000 年開始，大數據的技術就邁入了互聯網生態，使用大數據技術來創建數據倉庫已較爲廣泛。儘管數據倉庫的理念在 90 年代就已經出現了，但各個數據倉庫的產品都還沒有開源，業界缺少共識。而 Hadoop 開源以後，基於Hadoop 的數倉架構逐漸成爲主流，也即傳統的數倉架構。

傳統數倉架構

如上圖所示，左邊是 OLTP 在線業務所使用的數據庫，由於沒法直接在上面進行分析，因此通常會經過 MySQL 的 Binlog CDC 或直接讀寫數據庫 ETL 的方式，將數據變動或全量的數據導至 Hadoop 平臺，而後在 Hadoop 中使用 Hive 等軟件進行數據分析，而且生成報表，將結果寫入到另外一個 OLTP 的數據庫中，也就是右邊用來作離線分析的結果呈現的 Data Serving 層。最後再由 Data Serving 層將數據展示給應用。

因爲這一整套鏈路很是長，還有 Hadoop 中各類各樣實現的緣由，因此這一架構在最開始只能作到 T+1 的程度，即當天的數據寫入後次日才能計算出來。

雖然解決了海量存儲與計算的問題，可是失去了數據處理的實時性。近年來，隨着實時性的需求愈來愈多，爲了保證數據處理的實時性，出現了一種新的架構：Lambda架構。

Lambda 實時數倉

Lambda 架構的特色在於爲離線的 Hadoop 加了一個實時計算層，通常稱之爲 Speed Layer，早期主要使用 Spark Streaming 或 Storm 流式計算引擎來直接採集 OLTP 的數據，將其計算爲實時的數據，而後和離線的 T+1 的數據混合在一塊兒，提供給應用。如此，應用便可獲得一個相對來講比較實時的數據。

傳統數倉時代只能作到 T+1，有了 Lambda 的架構後，就能夠實現 T 加零點幾，昨天的數據和今天半天的數據合併在一塊兒處理。不過，在此基礎上可否實現更實時的數據分析？

Kappa 實時數倉

Kappa 架構應運而生。以前 Lambda 架構的痛點在於須要作很是複雜的維護，由於同時要把數據寫到 T+0，也要把數據寫到實時的部分，而後再將兩部分的結果整合起來。有了 Kappa 架構以後，只要經過實時的計算層，按需拉取 OLTP 業務的變動，而後將計算結果數據呈現出來便可。可是這一套體系由於性能方面的緣由，暫時尚未獲得特別普遍的應用。

能夠看到，在數倉架構演講的過程當中，數據實時性已經變成了你們廣泛的需求，同時海量的數據處理能力也必不可少。在這種狀況下，咱們來看看 TiDB 能作什麼。

TiDB 能作什麼？

TiDB 4.0 以前

TiDB 1.0 發佈時，架構圖以下，這也是全部不少人對 TiDB 的第一印象。

TiDB 的架構很是簡單，首先是 Load Balancer，能夠將用戶的 SQL 請求打散，發送到 TiDB Server 中。TiDB Server 是一個無狀態的計算層，能夠隨意擴展，實際的數據存儲在分佈式 KV 存儲 TiKV 中。此外，還有一個 PD 組件來對這些數據進行調度以及規整。

這一套架構最突出的部分是擴容，以擴容做爲第一要義。擴容體如今兩個方面，一是存儲擴容，傳統的單機數據庫沒法承載的數據量，TiDB 能夠將其存儲到分佈式存儲中。二是計算上，傳統數據庫單機沒法承受較高的 QPS， 經過這種擴容的方式，QPS 能夠打散到不一樣的計算節點上。

在 TiDB 4.0 以前，咱們一直延續這套架構。如下是 TiDB 4.0 以前咱們能作到什麼的總結：

• 兼容 MySQL 協議及特性的關係型數據庫；

• 存儲天生具有水平擴展能力，無需分庫分表；

• 承載千萬級 QPS 在線業務；

• 計算存儲分離，可進行彈性的資源配置；

• 數倉 Serving 層的優質載體（數據中臺）。

首先，TiDB 的立足點是一個兼容 MySQL 協議以及 MySQL 特性的關係型數據庫，具有水平擴展能力，包括存儲和計算均可以進行水平擴展，而且不須要分庫分表。在此基礎上，由於支持計算的水平擴展，因此能承載高 QPS 的在線業務，而且存儲、計算分離，爲彈性資源配置提供了基礎。

但超乎咱們想象的是，許多開源社區用戶將 TiDB 做爲數倉的優質載體。TiDB 能夠接受海量數據的存儲，同時也能夠提供比較方便的訪問接口，因此不少用戶天然地將其做爲數倉的中間層。

在 TiDB 4.0 以前，設計上徹底沒有考慮到這種用法，因此存在不少問題，好比計算是單節點，沒法進行分佈式擴容，一些比較重的計算任務也不支持。同時，TiDB 的存儲引擎 TiKV 使用的是行存的存儲格式，行存的優點在於 OLTP 場景下能夠較好的處理併發事務，可是在 OLAP 場景下的性能不太理想。

由於收到了各類各樣的用戶需求，因此咱們專門研發了 TiDB 的列存引擎 TiFlash，來承載 TiDB 的 OLAP 負載。在 TiDB 4.0 中，TiFlash 正式成爲了 TiDB 家族的一名成員。

TiDB 4.0 以後

在 4.0 以前，社區已經提供了一套 TiSpark。TiSpark 本質上是一個 Spark 插件，經過 TiSpark，咱們能夠在 Spark 中訪問 TiDB 集羣中的數據，並對其進行讀寫。可是使用 Spark 訪問 TiDB 的數據會存在必定問題，由於它是一個高併發的掃表請求，會致使 TiKV 自己 OLTP 的負載受到影響。

在有了 TiFlash 以後，就能夠徹底隔離到 OLAP 和 OLTP 的負載，也能保證一致性。TiFlash 的一致性是經過 Raft 的同步協議來作的，熟悉 Raft 的同窗應該知道，它是一個同步複製協議，全部的數據都是以 log 的形式來呈現。每一條 log 都有一個全局一致的 ID，也是其位置的 index。假如兩條 log，一個是 4，一個是 5，那麼 Raft 協議能夠保證 5 必定是在 4 以後纔會寫入，當 5 進行寫入時全部的 Client(TiDB) 均能讀到 4，從而知足線性一致性。

通常來講，在 Raft 中只有 leader 能夠進行讀寫操做，但若是對此進行優化，實現一個 learner 或者 follower 的狀態便可知足讀取 leader 上一樣一個 index 的條件，就能夠直接從 learner 上讀取數據。TiFlash 就是利用這樣一種機制從 TiKV 集羣中同步數據，而且達到線性一致性的。這樣作的優勢在於：

首先，假設用 binlog 等方式來將數據同步到列式分析引擎中，中間會有額外的傳輸開銷或者相似於中間件的處理開銷。而直接經過 Raft 協議來進行寫入，在一條數據寫到 leader 時，會走 Raft 的 quorum 確認流程，此時數據已經被髮送到 TiFlash 進行寫入了。另外，雖然 TiFlash 的寫入確認不須要同步，可是它的數據和 TiKV 內部的高可用優先級是同樣的，這是達到一致性的關鍵。

整體而言，在有了 TiDB 4.0以後，分析能力上了一個臺階。此時，咱們能夠自豪說 TiDB 是一個真正意義上的 HTAP 數據庫了。TiDB 的特色以下：

• 真正意義上的 HTAP 數據庫；

• 互相隔離的 OLAP 和 OLTP 負載；

• 分析友好，強實時性、強一致性的列存；

• 一體化部署運維體系，優化器智能選擇存儲引擎；

• ALTER TABLE `db`.`table` SET TIFLASH REPLICA 1，一句簡單的 SQL 便可體驗 TiFlash 帶來的加強。

TiDB 5.0 HTAP

在 5.0 的時候，爲了解決上述痛點，咱們研發了 TiDB 的 MPP。先了解一下 MPP 到底是什麼。

在執行 SQL 時，使用的是一套  Volcano 的模型，其優點在於算子之間是能夠解耦的，缺點在於上下游之間的調用有耦合，即必須是上游找下游要數據，而後下游纔會將數據算出來提供給上游。每個算子之間的消費能力和生產能力很是不匹配。儘管 TiDB 自己也作了很是多的優化，在算子內部經過並行計算來加快其計算速度。但歸根結底它也只是一個單機的計算引擎，上限很是低。爲了解決這個問題，咱們充分利用了 TiFlash 節點。

首先，看看如何實現。

一條 SQL 從 TiDB 進來，通過 Parser 和 Planner 生成一個 TiDB Logical Plan，而後 Logical Plan 通過 TiDB 的優化器以後，會判斷是不是 OLAP 請求。

若是是 OLAP 的請求，須要根據代價估算來選擇從 TiKV 進行讀寫，仍是 TiFlash 進行讀寫。在此過程當中，咱們還會爲這些 join 的算子加上 exchange，也就是  Volcano 論文中提到的並行化的方式，生成一個並行的執行計劃，再將這些執行計劃的片斷給推送到對應的 TiFlash 節點執行。

來看一個實際的例子。

上述是來自於 TPCH 數據集的數據。TPCH 數據集中有一個叫作 lineitem 的表，lineitem 的表中存取的是全部的商品的信息，通常來講是6億行左右。此外，還有 orders 表，orders 表是商品訂單的事實表，咱們在作簡單的 Join 以後，加上一個 Count Star 的聚合。此時的 Plan 在 MPP 架構下則有所不一樣。之前，一般狀況下 Join 下面是兩個 Table Scan，若是是在 TiDB 中進行計算，兩個 Table Scan 以後能夠直接放到 Join 的算子中。但在 MPP 以後，咱們會先對 Scan 出來的 Table 進行一個根據 Join Key 的 Shuffle，而後將數據推送到對應的計算節點，總體計算完成以後，再推到 TiDB 中返回給用戶。

這樣的好處有兩點，一方面若是使用單個 TiDB 節點來進行計算，須要在內存中放大量數據，甚至數據多是 TiDB 容納不下的，此時就必須將其落到磁盤上，計算效率很是低。可是經過 shuffle 分區以後，每一個計算節點上須要計算的數據量變小，能夠所有容納在內存中，能夠實現加速的效果。另外，MPP 能夠同時利用多臺機器的 CP，理論上能夠實現很是強的擴展性。

爲了驗證 TiDB MPP 的性能，咱們對比了其餘產品，集羣是三個節點的集羣，每一個節點上面使用的都是 NVMe 的 SSD，能夠儘量的排除存儲上讀取對於整個計算速度的影響。

如上圖，能夠看到藍色的是 TiFlash MPP 的性能，長短表明它的執行時間，這項指標越短越好。從上圖能夠看出，對比 Greenplum 和 Apache Spark，MPP 在絕大多數的查詢下都處於優點地位。緣由在於：一方面，TiDB 5.0 自己集成了一套列式計算引擎，性能很是強大；另一方面，MPP 架構相對於批處理引擎的優點在於全部的任務是平行的，不會存在互相依賴的狀況，因此它能夠用更好的方式進行併發。但缺點在於，相較於批處理，沒法支持過於龐大的數據量，不過在絕大多數的場景下， MPP 架構已經很是夠用了。

總結一下TiDB 的 MPP。

• 支持多種並行執行算法：

  • Broadcast Join。

  • Repartition(Shuffle) Join；

  • Two Phase Aggregation；

  • One Phase Aggregation；

• 可擴展複雜的查詢處理能力；

• TiDB 高度集成，優化器自動選擇；

• 升級到 TiDB 5.0 後，僅需開啓開關 SET tidb_allow_mpp=ON 便可使用。

有了 MPP 架構以後，TiDB 5.0 新引入的幾個 Feature，使 TiDB 的 HTAP 能力獲得了極大的提高：

• OLTP:

  • Async Commit，1PC 提供更低的事務延遲。

  • Clustered Index 強化特定負載下的延遲和吞吐量。

• OLAP:

  • SQL MPP 大幅提高 TiDB 處理複雜查詢的能力。

以上分享了 TiDB 不一樣階段的功能特性和產品能力，下面將具體說明你們是怎麼用 TiDB 的。

你們是怎麼用 TiDB 的？

根據用戶反饋以及咱們本身的整理，發現了當前 TiDB 最經常使用的幾個場景。

交易/分析一體化

首先，交易分析的一體化，這種場景下數據量級通常處於中等程度，即 TB 級別。

若是單純使用 MySQL，沒法比較好地進行數據計算，因此通常須要將這些數據導入到分析型數據庫中進行計算，好比 ClickHouse、GreenPlum 等，再將計算出來的報表呈現出來。有了 TiDB 以後，能夠將這兩部分相結合，TP 直接寫 TiDB，AP 也直接在 TiDB 上進行計算，而後呈現結果，這樣能夠極大節省了運維成本，而且可能實現性能上的提高。

交易分析一體化的場景比較常見的，如：CRM 系統、ERP 系統等，也是咱們很是推崇的最完整的 HTAP 的場景。可是互聯網公司通常沒法使用，必須也有離線的部分來處理海量的數據。

所以，在這套體系中，TiDB 主要被用於實時分析。

實時分析

業務數據經過 Kafka + Flink 的方式，在 Flink 中作預聚合或拼寬表，而後再將這個結果寫入到 TiDB 中，供應用查詢。這是常見的實時分析架構。而若是應用的線上業務已經用了 TiDB，整套架構就更天然了，能夠直接使用 TiDB 的 CDC 功能，將數據導入到 Flink 中進行處理。

因爲整套架構很是實用，目前已普遍應用於多個業務場景，後面將舉例說明。

實時分析：Flink 架構

實時分析中使用 Flink 也有幾種常見的架構。

• 使用 Flink MySQL connector 解析 MySQL CDC

第一種架構，前端業務使用的是 MySQL，好比分庫分表方案，經過 Flink MySQL Connector 獲取MySQL 的數據變動，而後再將數據寫入 TiDB。

• 使用 Kafka 推送 Canal JSON 等格式

第二種架構，經過 MySQL binlog 處理的中間件，好比 Canal 等處理數據，而後寫入到 Kafka 供 Flink 消費，最後再寫進 TiDB，這種方式比較常見。

• 使用 TiCDC 推送 Canal JSON 到 Kafka

第三種架構，用戶前端已經使用了 TiDB，經過 TiDB 的 CDC 功能，輸出 Canal JSON 格式到 Kafka 中供消費，Flink 再將數據寫入到 TiDB 相似的數據庫或者其餘 sink 中。

• 數倉加速層 / ODS 層

還有一種常見的方案，數據倉庫的加速層或者說 ODS 層。

最多見的用法通常數據倉庫會將加速層分開，有了 TiDB 以後，兩部分是能夠合起來的，用戶的數據能夠經過各類各樣的方式寫進 TiDB，在 TiDB 裏面在進行一些 ETL 之類的操做而後寫入到離線計算中，最後再將結果反饋到 TiDB。TiDB 能夠直接對外提供實時數據分析的服務，這也是很是流行的架構之一。

應用案例

接下來，將分享一些現實中公司的案例。

中通快遞物流

首先是你們都比較熟悉的中通快遞，中通快遞如今應該是全球業務規模最大快遞企業之一。近幾年，他們開始嘗試使用 TiDB 來作包裹追蹤管理工做。早期，他們使用 TiSpark 進行計算，而後將數據拼成寬表寫到 TiDB 中，再進行一些聚合。最近，他們已經在測 5.0 的 MPP 架構，看看 TiDB 5.0 可否提供更多幫助。

• 中通快遞

  • 全球業務規模最大快遞企業。

• 物流全鏈路生命週期管理

  • 同一套 TiDB 平臺服務包裹追蹤管理與實時報表。

  • QPS 峯值 12萬+。

  • 實時統計分析。

  • 經過 TiSpark 銜接離線平臺。

中通快遞的架構如上。首先，包裹追蹤是線上業務，經過 Spark Streaming 訓練方式寫入到 TiDB 中，同時進行實時分析，而後 TiDB 的歸檔數據將發送到中通的大數據平臺進行計算，最後大數據平臺的計算的結果再寫回到 TiDB。在這個結構中，TiDB 是整個實時計算的整合層。

小紅書

小紅書是一個內容同時作垂直電商相關的平臺，目前用戶量和訪問量都也很是大。

小紅書的早期架構是業務使用 MySQL 分庫分表的方案，業務數據經過 ETL 寫入到離線產品，進行 T+1 的計算後，再寫回到另外一個 MySQL 的分庫分表集羣中，對外提供數據服務。同時，也會利用離線數倉來作風控相關的業務。

上述架構的痛點在於 T+1，業務和運維都很是難受。在嘗試 TiDB 以後，將架構進行了升級。

目前業務在線層仍然使用分庫分表，但業務數據會直接經過一些簡單的方式寫到 TiDB 中，同時 TiDB 將數據反饋給離線層，作完離線數據的處理再寫回到 TiDB。

上述結構直接使用 TiDB 進行數據分析或風控服務，總體架構從 T+1 變成了 T+0，而且據小紅書工程師反饋，用了 TiDB 以後，節省了不少 MySQL 分庫分表的運維精力，這也是 TiDB 的優勢之一。

智慧芽

智慧芽是提供 SaaS 服務的廠商，爲全球 50 多個國家超 10000 家科技公司、高校、科研與金融機構提供大數據情報服務。

• 智慧芽

  • 高速發展的科技創新 SaaS 服務商，爲全球 50 多個國家超 10000 家科技公司、高校、科研與金融機構提供大數據情報服務。

• 實時數倉

  • 部署於 AWS 雲環境。

• 經過 AWS Kinesis / AWS EMR Flink 進行數倉建模。

智慧芽的全部業務都部署在 AWS 之上。早期，智慧芽經過 AWS 的 Redshift 來進行數據分析，可是 Redshift 自己的速度並不特別理想，所以爲了得到更好的實時性，智慧芽開始嘗試使用 TiDB 構建實時數倉。在數倉架構上跟其餘公司很是類似，也是使用 Flink 進行實時數據處理，而後將各類各樣的數據寫入到 TiDB，最後直接呈現給數據應用。

以上幾個案例是很是典型的使用 TiDB 來作實時數據分析的場景，其中也有相對偏向於 HTAP 的業務如小紅書的架構，其線上業務數據會直接寫到 TiDB 中，能夠充分利用 TiDB 的 OLTP 能力。

看了這麼多案例以後，咱們也能夠想象一下 TiDB HTAP 的將來。

TiDB HTAP 的將來

首先，最重要的一點，5.0以後，TiDB 已經能夠用來作複雜計算了，同時咱們能夠提供更加實時的場景來驗證。

SQL MPP 意味着什麼？

有了 SQL 和 MPP 以後，咱們有了更快的計算速度，同時能夠承載更復雜的計算任務，再加上強實時性的數據，以及強一致性保證。有了這些以後，咱們能夠作到什麼？

直播場景

首先，直播場景。在某個大主播開播時，用戶會直接就涌進來，此時用戶的信息會插入到訪問的事實表中，主播的直播間也會對其維度表進行更新。這一套架構若是按照傳統的方式來，可能會使用 Flink 對數據進行處理，但同時也存在一個問題，操做的併發度將會很是高，而且須要在短期內完成。所以，若是要 Flink 進行處理，須要維護一些比較複雜的 Watermark 等，而且在進行預處理後，可能也會帶來一些延遲。

若是直接使用 TiDB 來承載這些負載，當數據寫進來時能夠立刻對它進行分析，生成分析報表，及時反饋到平臺或主播，以便及時進行業務上的調整。固然，直播場景的應用目前仍是假設，咱們期待着 TiDB 在直播場景的落地。

實時風控場景

另一個場景，以實時風控爲例。部分在線平臺常常會產生交易和轉帳類業務，但新聞中常常報道的詐騙事件也與此相關。事實上，金融或其餘交易平臺通常存在風控業務來檢測和規避相似事件的發生。

以前的風控可能存在的問題之一是做案過程很是迅速，以致於風控規則還未觸發但詐騙的流程已經結束了。不只形成用戶的經濟損失，也影響警察辦案效率。

若是將 TiDB 應用於風控業務中，在違規交易發生的瞬間，能夠直接進行分析，觸發風控策略。整個鏈路延遲將極大下降，也有助於相關部門能更快破案。

其餘更多 TiDB HTAP 的應用場景也歡迎你們來幫助咱們想象，共同暢想 TiDB 的將來。