数据查询和业务流分开_TiDB HTAP 助力小红书业务升级
TiDB 在小紅書業(yè)務(wù)場景的應(yīng)用簡介
2017 年，小紅書已經(jīng)開始在生產(chǎn)業(yè)務(wù)中使用 TiDB ，真正成體系的去做 TiDB 的落地是在 2018 年，為什么要選擇使用 TiDB ？
當(dāng)今很多公司的業(yè)務(wù)都是數(shù)據(jù)驅(qū)動，面對小紅書 APP 每天數(shù)以億計的數(shù)據(jù)，我們希望有一個數(shù)據(jù)庫能夠提供以下特性：
第一，數(shù)據(jù)使用的多樣性，有時候需要在數(shù)據(jù)庫做一個 TP 的短查詢，做一些很高的寫入，有時候又希望做一些聚合分析，能夠展現(xiàn)匯總統(tǒng)計的結(jié)果， TiDB 的 HTAP 架構(gòu)正好滿足了多樣性的需求。
第二，更高的時效性，我們知道有很多數(shù)據(jù)分析的引擎雖然計算很快，但是對于實時分析的支持能力比較弱，TiDB 可以提供更高的時效性。
第三，TiDB 基于 Raft 的擴展性，小紅書 APP 每天的數(shù)據(jù)都是上億級別，單點的集群總有一天會被打滿，會被打爆，我們就期望能有一個擴展性極佳且擴容方便的數(shù)據(jù)庫，TiDB 非常契合，所以我們選擇了 TiDB。
TiDB 目前在小紅書的應(yīng)用涵蓋報表分析、大促實時大屏、物流倉儲、數(shù)倉應(yīng)用、電商數(shù)據(jù)中臺、內(nèi)容安全審核等多個業(yè)務(wù)場景。6 月 6 日是小紅書的周年慶大促，需要展現(xiàn)一些實時的銷量、店家成交總額排名、總銷量等信息，這個實時大屏的應(yīng)用后面連接的就是 TiDB。
TiDB 在這些業(yè)務(wù)當(dāng)中給我們解決了哪些問題？我從這些業(yè)務(wù)中挑選了三個非常典型的應(yīng)用場景來跟大家分享。
- 數(shù)據(jù)報表：數(shù)據(jù)報表其實很好理解，分析師經(jīng)常需要看一些數(shù)據(jù)，比如這周的走勢，看一些銷量情況，看一些用戶增長情況，看同比與環(huán)比數(shù)據(jù)。
- 線上業(yè)務(wù)庫的實時查詢：比如 300 億行的一個表，MySQL 肯定存不下，需要走分庫分表的邏輯，而且希望在做查詢或者分析的時候不能對在線業(yè)務(wù)產(chǎn)生影響，解決線上分庫分表 MySQL 的查詢問題。
- 反欺詐數(shù)據(jù)分析：所謂反欺詐舉個例子像黃牛薅羊毛，小紅書的電商平臺定期會發(fā)一些優(yōu)惠券，黃牛就最喜歡薅這些優(yōu)惠券，我們能否在短時間內(nèi)抓到這些黑產(chǎn)行為，將他們捕捉下來進行分析和阻攔。
傳統(tǒng) MySQL 與數(shù)倉方案的局限
在沒有 TiDB 的時候，我們怎么做？如上圖所示，從業(yè)務(wù)邏輯上來劃分，從上到下是業(yè)務(wù)在線層、數(shù)倉離線層和數(shù)據(jù)服務(wù)層。
首先在數(shù)據(jù)報表場景，采用 Hadoop 數(shù)倉對數(shù)據(jù)做一些預(yù)聚合，然后把這些高維度的數(shù)據(jù)簡單聚合一下放到 MySQL 里面再做查詢。對于數(shù)據(jù)報表，會把 Hadoop 里面的數(shù)據(jù)通過 Hive 以 T+1 的形式每天做一些預(yù)聚合放到 MySQL 里面，再搭建一些 BI 系統(tǒng)進行圖形展示化的報表查詢，分析師就可以看到他們定制化的一些報表。但是隨著業(yè)務(wù)的快速增長，報表的形式變得更加多種多樣，MySQL 的擴展性也是一個比較頭疼的問題，如果單純地增加一些 MySQL 的節(jié)點，到最后就會變成我們?nèi)绾喂芾砟敲炊?MySQL 節(jié)點的問題，搞過運維的同學(xué)都知道，這是一件比較煩瑣的事情。
再來看在線的 MySQL 分庫分表場景，我們要在上面做數(shù)據(jù)查詢，又不能影響線上庫，所以只能去查從庫，這個從庫當(dāng)然也是一個分庫分表的場景。這里產(chǎn)生了一系列問題：首先還是運維的問題，分庫分表 MySQL 那么多節(jié)點怎么管？怎么擴容？分片是不是要重新去做 Sharding？如何保證一致性？縮容怎么縮？元信息怎么管理？這是運維上面的復(fù)雜度。除此之外，我覺得有必要提的一點，比如說線上的一個分庫分表 MySQL，我在上面想做一個事務(wù)，分庫分表的中間件方便做嗎？如果我還想做一個 JOIN，甚至我還想做一個 Group by 聚合查詢，分庫分表中間件方便做嗎？可能可以做，但都不會很簡單，所以我們需要有一個能夠方便地做比較復(fù)雜分布式查詢的方案。
第三在反欺詐數(shù)據(jù)分析場景，我們比較關(guān)注時效性。在 TiDB 之前對于后端的一些打點數(shù)據(jù)，我們這些數(shù)據(jù)寫到數(shù)倉里面，等到 T+1 第二天的時候，業(yè)務(wù)方才能查到上面的數(shù)據(jù)，這樣 T+1 的時效性就比較差了。黃牛薅羊毛是一個很快的事情，到第二天可能直接薅完了你也沒辦法，所以非常希望最好能在半分鐘、十秒鐘，甚至秒級別，就能看到發(fā)出優(yōu)惠券的詳細(xì)使用情況。
引入 TiDB HTAP 方案，提升全場景數(shù)據(jù)服務(wù)能力
基于以上場景的種種挑戰(zhàn)，我們引入了 TiDB 3.0 HTAP 方案，來看看新的業(yè)務(wù)架構(gòu)，如下圖，我們看到數(shù)據(jù)服務(wù)層采用 TiDB 就可以提供業(yè)務(wù)所需的全部數(shù)據(jù)服務(wù)。
我們重新梳理一下引入 TiDB 之后的三個業(yè)務(wù)場景。
在數(shù)據(jù)報表場景，直接用 TiDB 直接替換 MySQL ，解決了隨著業(yè)務(wù)增長 MySQL 擴容復(fù)雜的問題。我覺得能實現(xiàn)無縫切換最重要的原因是 TiDB 一開始就支持 MySQL 協(xié)議，這是我覺得 TiDB 設(shè)計上非常牛的一點，很聰明的一點。前端的 BI 工具不用再開發(fā)一個所謂的 TiDB 驅(qū)動，直接用 MySQL 驅(qū)動就可以。在擴容層面，這是 TiDB 最擅長的事情，可以直接加個節(jié)點，數(shù)據(jù)自動做好重新均衡，非常方便。
在分庫分表的 MySQL 場景，分庫分表怎么做查詢？我們造了一條實時流，把 MySQL 的數(shù)據(jù)通過 Binlog 實時寫到 TiDB 里面，同步的延遲在一秒鐘以內(nèi)。實時流不僅僅是一個簡單的數(shù)據(jù)同步，還做了一個事情就是合庫，什么叫合庫？原來線上分了一萬個表，分表是因為 MySQL 存不下，現(xiàn)在一個 TiDB 集群是能夠存下的，就沒有必要分表了。實時流寫到 TiDB 里面的同時，還把這一萬張分表合成了一張大表，合的過程中可能還要處理一些特殊問題，比如說原來的自增主鍵怎么搞？自增主鍵合起來的時候是不是有問題？可能要做一些數(shù)據(jù)轉(zhuǎn)換，有一些數(shù)據(jù)要做格式或者映射之類的數(shù)據(jù)處理，總之在實時流里面都把這些事情處理好，最后我們看到一張大表，就沒有分庫分表這件事情。在 TiDB 上面再做一些查詢，不影響主庫，TiDB 實際上作為一個 MySQL 的大從庫，如果想做一個事務(wù)，也沒問題，TiDB 支持事務(wù)，想做一個 JOIN，想做一個聚合，TiDB 都能夠支持這類操作，最后就是一張大表呈現(xiàn)在 TiDB 里面。
最后看看反欺詐數(shù)據(jù)分析場景，應(yīng)用了 TiDB 之后我們把 T+1 的提交改成了由 Flink 的 SQL 實時來寫入，打點數(shù)據(jù)產(chǎn)生的速率很高，峰值的 QPS 大概能達(dá)到三四萬，單表一天大概寫入 5 億左右的數(shù)據(jù)，如果我們保存 10 天的數(shù)據(jù)大概會達(dá)到 50 億單表的量級。寫進來之后，怎么做查詢呢？主要是一些 Ad - Hoc 查詢，如果分析師想看這次優(yōu)惠券發(fā)下去的使用情況是怎么樣的，分發(fā)情況是怎么樣的，希望能在分鐘級別就能夠看到，每次 SQL 都可能有變化，我們直接繞過 Hadoop 數(shù)倉，通過 TiDB 來提供更加實時的查詢。
TiDB 4.0 HTAP 方案的應(yīng)用效果
通過引入 TiDB，我們在以上三個典型業(yè)務(wù)場景上解決了遇到的各種問題。這個方案有沒有不足？其實也是有的，如果 3.0 沒有不足的話，可能就不會誕生今天的 4.0 。我們使用下來的感受主要是 TiDB 3.0 在 OLAP 分析這一塊能力稍有些不足，TiKV 是一個基于行存的數(shù)據(jù)庫，去跟一些專門做分析的列存引擎去比較，其實是沒有可比性的。TiDB 如何解決這個問題？是不是 TiDB 引入一個列存引擎就可以？到了 4.0 的時候，TiDB 帶著 TiFlash 這么一個列存引擎來到了我們面前。
TiFlash 的設(shè)計有幾點我覺得非常棒：首先，作為一個列存引擎 TiFlash 能夠與 TiKV 共存，不是說只能選列存，只能選行存，兩個可以同時存在，既然能同時存在，中間這個行存到列存數(shù)據(jù)的復(fù)制和轉(zhuǎn)換怎么做？是不是需要再搭一條復(fù)制流去做？不用，TiDB 都幫我們做好了，通過 Raft Learner 復(fù)制機制直接采用一個較低延遲的方式把數(shù)據(jù)全部同步到 TiFlash 里面。從查詢端來看，是否需要做一些特殊的處理讓 TiFlash 走列存引擎呢？答案是都不需要，TiDB 有一個 CBO 執(zhí)行計劃的自動路由，可以知道這條 SQL 是 TiFlash 掃全表比較好還是走 TiKV 的索引查詢比較快，可以幫我規(guī)劃好。引入 TiFlash 的運維成本是非常低的，我要做的事情就是申請機器把 TiFlash 部署上去，然后就結(jié)束了，數(shù)據(jù)自動同步過去，查詢自動路由過去，什么事情都不用管。
我們也對 TiFlash 做了測試，拿物流場景作為例子，我們對其中的 393 條生產(chǎn)查詢進行評估，上圖的縱軸是 TiFlash 的性能提升，從聚合查詢來看，類似于 Group by、SUM 這些聚合查詢，大概有三到十倍的性能提升，平均時間減少 68% 左右。如果是非聚合查詢，平均時間減少 4% 左右，非聚合查詢基本上都命中了 TiKV 的索引，沒有走 TiFlash 的列存。
TiDB 4.0 還給我們帶來悲觀鎖，在物流場景很多表需要 JOIN ，JOIN 其實是代價比較高的一件事情。為了避免 JOIN，我們會把這些要 JOIN 的表提前給拼成一張大寬表。舉個例子，我把三張表拼成一張大寬表，那就有三個流就會同時更新大寬表，更新同一行，原來的 TiDB 3.0 是樂觀鎖的機制，就會產(chǎn)生事務(wù)沖突，對于客戶端的重試來說是不太友好。TiDB 4.0 有了悲觀鎖，很好地解決了這個問題。
我們平時和 PingCAP 的 TiFlash 團隊也有比較多的交流，我們也會經(jīng)常提出一些新的需求，例如最早的時候， TiFlash 是不支持 ditinct count 這一類場景的，效率很低，開發(fā)團隊在了解我們的需求后很快做出了優(yōu)化，支持了 ditinct count 場景。
TiFlash 與 ClickHouse 怎么選？
最后說一下 TiFlash 跟其他方案的對比，拿大家比較熟悉的 ClickHouse 列存引擎做個比較，ClickHouse 其實單從計算性能來說，確實是比 TiFlash 要快一點。為什么某一些場景我們還是選擇 TiFlash 呢？因為 ClickHouse 有一些問題，比如說 ClickHouse 的集群模式運維起來比較復(fù)雜，對數(shù)據(jù)更新的支持也比較弱，因為很多業(yè)務(wù)是事務(wù)型的，有很多更新需求，而 ClickHouse 更新的性能比較差，如果要改成 Append、Insert 這個邏輯，業(yè)務(wù)側(cè)就要做大量的改動，例如數(shù)據(jù)要做去重之類的事情，很多場景下為了支持高頻率的更新我們就選擇了 TiFlash。
本文整理自張億皓在 TiDB DevCon 2020 上的演講。總結(jié)
以上是生活随笔為你收集整理的数据查询和业务流分开_TiDB HTAP 助力小红书业务升级的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： linux怎样自动检查link文件_怎样
- 下一篇： mac运行linux命令,iOS:mac