作者介紹：張億皓，小紅書基礎技術部資深開發工程師，負責數據庫相關的研發和落地工作。

TiDB 在小紅書業務場景的應用簡介

2017 年，小紅書已經開始在生產業務中使用 TiDB ，真正成體系的去做 TiDB 的落地是在 2018 年，為什么要選擇使用 TiDB ？

當今很多公司的業務都是數據驅動，面對小紅書 APP 每天數以億計的數據，我們希望有一個數據庫能夠提供以下特性：

第一，數據使用的多樣性，有時候需要在數據庫做一個 TP 的短查詢，做一些很高的寫入，有時候又希望做一些聚合分析，能夠展現匯總統計的結果， TiDB 的 HTAP 架構正好滿足了多樣性的需求。

第二，更高的時效性，我們知道有很多數據分析的引擎雖然計算很快，但是對于實時分析的支持能力比較弱，TiDB 可以提供更高的時效性。

第三，TiDB 基于 Raft 的擴展性，小紅書 APP 每天的數據都是上億級別，單點的集群總有一天會被打滿，會被打爆，我們就期望能有一個擴展性極佳且擴容方便的數據庫，TiDB 非常契合，所以我們選擇了 TiDB。

TiDB 目前在小紅書的應用涵蓋報表分析、大促實時大屏、物流倉儲、數倉應用、電商數據中臺、內容安全審核等多個業務場景。6 月 6 日是小紅書的周年慶大促，需要展現一些實時的銷量、店家成交總額排名、總銷量等信息，這個實時大屏的應用后面連接的就是 TiDB。

TiDB 在這些業務當中給我們解決了哪些問題？我從這些業務中挑選了三個非常典型的應用場景來跟大家分享。

• 數據報表：數據報表其實很好理解，分析師經常需要看一些數據，比如這周的走勢，看一些銷量情況，看一些用戶增長情況，看同比與環比數據。
• 線上業務庫的實時查詢：比如 300 億行的一個表，MySQL 肯定存不下，需要走分庫分表的邏輯，而且希望在做查詢或者分析的時候不能對在線業務產生影響，解決線上分庫分表 MySQL 的查詢問題。
• 反欺詐數據分析：所謂反欺詐舉個例子像黃牛薅羊毛，小紅書的電商平臺定期會發一些優惠券，黃牛就最喜歡薅這些優惠券，我們能否在短時間內抓到這些黑產行為，將他們捕捉下來進行分析和阻攔。

傳統 MySQL 與數倉方案的局限

在沒有 TiDB 的時候，我們怎么做？如上圖所示，從業務邏輯上來劃分，從上到下是業務在線層、數倉離線層和數據服務層。

首先在數據報表場景，采用 Hadoop 數倉對數據做一些預聚合，然后把這些高維度的數據簡單聚合一下放到 MySQL 里面再做查詢。對于數據報表，會把 Hadoop 里面的數據通過 Hive 以 T+1 的形式每天做一些預聚合放到 MySQL 里面，再搭建一些 BI 系統進行圖形展示化的報表查詢，分析師就可以看到他們定制化的一些報表。但是隨著業務的快速增長，報表的形式變得更加多種多樣，MySQL 的擴展性也是一個比較頭疼的問題，如果單純地增加一些 MySQL 的節點，到最后就會變成我們如何管理那么多 MySQL 節點的問題，搞過運維的同學都知道，這是一件比較煩瑣的事情。

再來看在線的 MySQL 分庫分表場景，我們要在上面做數據查詢，又不能影響線上庫，所以只能去查從庫，這個從庫當然也是一個分庫分表的場景。這里產生了一系列問題：首先還是運維的問題，分庫分表 MySQL 那么多節點怎么管？怎么擴容？分片是不是要重新去做 Sharding？如何保證一致性？縮容怎么縮？元信息怎么管理？這是運維上面的復雜度。除此之外，我覺得有必要提的一點，比如說線上的一個分庫分表 MySQL，我在上面想做一個事務，分庫分表的中間件方便做嗎？如果我還想做一個 JOIN，甚至我還想做一個 Group by 聚合查詢，分庫分表中間件方便做嗎？可能可以做，但都不會很簡單，所以我們需要有一個能夠方便地做比較復雜分布式查詢的方案。

第三在反欺詐數據分析場景，我們比較關注時效性。在 TiDB 之前對于后端的一些打點數據，我們這些數據寫到數倉里面，等到 T+1 第二天的時候，業務方才能查到上面的數據，這樣 T+1 的時效性就比較差了。黃牛薅羊毛是一個很快的事情，到第二天可能直接薅完了你也沒辦法，所以非常希望最好能在半分鐘、十秒鐘，甚至秒級別，就能看到發出優惠券的詳細使用情況。

引入 TiDB HTAP 方案，提升全場景數據服務能力

基于以上場景的種種挑戰，我們引入了 TiDB 3.0 HTAP 方案，來看看新的業務架構，如下圖，我們看到數據服務層采用 TiDB 就可以提供業務所需的全部數據服務。

我們重新梳理一下引入 TiDB 之后的三個業務場景。

在數據報表場景，直接用 TiDB 直接替換 MySQL ，解決了隨著業務增長 MySQL 擴容復雜的問題。我覺得能實現無縫切換最重要的原因是 TiDB 一開始就支持 MySQL 協議，這是我覺得 TiDB 設計上非常牛的一點，很聰明的一點。前端的 BI 工具不用再開發一個所謂的 TiDB 驅動，直接用 MySQL 驅動就可以。在擴容層面，這是 TiDB 最擅長的事情，可以直接加個節點，數據自動做好重新均衡，非常方便。

在分庫分表的 MySQL 場景，分庫分表怎么做查詢？我們造了一條實時流，把 MySQL 的數據通過 Binlog 實時寫到 TiDB 里面，同步的延遲在一秒鐘以內。實時流不僅僅是一個簡單的數據同步，還做了一個事情就是合庫，什么叫合庫？原來線上分了一萬個表，分表是因為 MySQL 存不下，現在一個 TiDB 集群是能夠存下的，就沒有必要分表了。實時流寫到 TiDB 里面的同時，還把這一萬張分表合成了一張大表，合的過程中可能還要處理一些特殊問題，比如說原來的自增主鍵怎么搞？自增主鍵合起來的時候是不是有問題？可能要做一些數據轉換，有一些數據要做格式或者映射之類的數據處理，總之在實時流里面都把這些事情處理好，最后我們看到一張大表，就沒有分庫分表這件事情。在 TiDB 上面再做一些查詢，不影響主庫，TiDB 實際上作為一個 MySQL 的大從庫，如果想做一個事務，也沒問題，TiDB 支持事務，想做一個 JOIN，想做一個聚合，TiDB 都能夠支持這類操作，最后就是一張大表呈現在 TiDB 里面。

最后看看反欺詐數據分析場景，應用了 TiDB 之后我們把 T+1 的提交改成了由 Flink 的 SQL 實時來寫入，打點數據產生的速率很高，峰值的 QPS 大概能達到三四萬，單表一天大概寫入 5 億左右的數據，如果我們保存 10 天的數據大概會達到 50 億單表的量級。寫進來之后，怎么做查詢呢？主要是一些 Ad - Hoc 查詢，如果分析師想看這次優惠券發下去的使用情況是怎么樣的，分發情況是怎么樣的，希望能在分鐘級別就能夠看到，每次 SQL 都可能有變化，我們直接繞過 Hadoop 數倉，通過 TiDB 來提供更加實時的查詢。

TiDB 4.0 HTAP 方案的應用效果

通過引入 TiDB，我們在以上三個典型業務場景上解決了遇到的各種問題。這個方案有沒有不足？其實也是有的，如果 3.0 沒有不足的話，可能就不會誕生今天的 4.0 。我們使用下來的感受主要是 TiDB 3.0 在 OLAP 分析這一塊能力稍有些不足，TiKV 是一個基于行存的數據庫，去跟一些專門做分析的列存引擎去比較，其實是沒有可比性的。TiDB 如何解決這個問題？是不是 TiDB 引入一個列存引擎就可以？到了 4.0 的時候，TiDB 帶著 TiFlash 這么一個列存引擎來到了我們面前。

TiFlash 的設計有幾點我覺得非常棒：首先，作為一個列存引擎 TiFlash 能夠與 TiKV 共存，不是說只能選列存，只能選行存，兩個可以同時存在，既然能同時存在，中間這個行存到列存數據的復制和轉換怎么做？是不是需要再搭一條復制流去做？不用，TiDB 都幫我們做好了，通過 Raft Learner 復制機制直接采用一個較低延遲的方式把數據全部同步到 TiFlash 里面。從查詢端來看，是否需要做一些特殊的處理讓 TiFlash 走列存引擎呢？答案是都不需要，TiDB 有一個 CBO 執行計劃的自動路由，可以知道這條 SQL 是 TiFlash 掃全表比較好還是走 TiKV 的索引查詢比較快，可以幫我規劃好。引入 TiFlash 的運維成本是非常低的，我要做的事情就是申請機器把 TiFlash 部署上去，然后就結束了，數據自動同步過去，查詢自動路由過去，什么事情都不用管。

我們也對 TiFlash 做了測試，拿物流場景作為例子，我們對其中的 393 條生產查詢進行評估，上圖的縱軸是 TiFlash 的性能提升，從聚合查詢來看，類似于 Group by、SUM 這些聚合查詢，大概有三到十倍的性能提升，平均時間減少 68% 左右。如果是非聚合查詢，平均時間減少 4% 左右，非聚合查詢基本上都命中了 TiKV 的索引，沒有走 TiFlash 的列存。

TiDB 4.0 還給我們帶來悲觀鎖，在物流場景很多表需要 JOIN ，JOIN 其實是代價比較高的一件事情。為了避免 JOIN，我們會把這些要 JOIN 的表提前給拼成一張大寬表。舉個例子，我把三張表拼成一張大寬表，那就有三個流就會同時更新大寬表，更新同一行，原來的 TiDB 3.0 是樂觀鎖的機制，就會產生事務沖突，對于客戶端的重試來說是不太友好。TiDB 4.0 有了悲觀鎖，很好地解決了這個問題。

我們平時和 PingCAP 的 TiFlash 團隊也有比較多的交流，我們也會經常提出一些新的需求，例如最早的時候， TiFlash 是不支持 ditinct count 這一類場景的，效率很低，開發團隊在了解我們的需求后很快做出了優化，支持了 ditinct count 場景。

TiFlash 與 ClickHouse 怎么選？

最后說一下 TiFlash 跟其他方案的對比，拿大家比較熟悉的 ClickHouse 列存引擎做個比較，ClickHouse 其實單從計算性能來說，確實是比 TiFlash 要快一點。為什么某一些場景我們還是選擇 TiFlash 呢？因為 ClickHouse 有一些問題，比如說 ClickHouse 的集群模式運維起來比較復雜，對數據更新的支持也比較弱，因為很多業務是事務型的，有很多更新需求，而 ClickHouse 更新的性能比較差，如果要改成 Append、Insert 這個邏輯，業務側就要做大量的改動，例如數據要做去重之類的事情，很多場景下為了支持高頻率的更新我們就選擇了 TiFlash。

本文整理自張億皓在 TiDB DevCon 2020 上的演講。

總結

以上是生活随笔為你收集整理的数据查询和业务流分开_TiDB HTAP 助力小红书业务升级的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。