TiDB 在愛奇藝實時分析場景的應(yīng)用實踐

劉振東 2021-12-16

展開全文

隨著業(yè)務(wù)的規(guī)模化發(fā)展，數(shù)據(jù)實時處理的能力成為了限制企業(yè)數(shù)據(jù)變現(xiàn)的重要關(guān)口之一。本文結(jié)合愛奇藝在實時分析場景的實踐經(jīng)驗，分享了傳統(tǒng)實時分析架構(gòu)的不足，以及 TiDB 在安全風(fēng)控和 BI 運營分析系統(tǒng)中部署的經(jīng)驗，最后介紹了 TiDB 5.0 版本在訂單交易系統(tǒng)中的測試結(jié)果和對未來的展望。

與 TiDB 攜手的五年

愛奇藝早在 2017 年就和 TiDB 結(jié)緣。隨著愛奇藝業(yè)務(wù)規(guī)模的不斷地擴大，MySQL 單機性能和容量的瓶頸越來越明顯，急需一款分布式兼容 MySQL 協(xié)議的數(shù)據(jù)庫，TiDB 的出現(xiàn)讓我們看到了曙光。TiDB 作為一款分布式 NewSQL 數(shù)據(jù)庫具備水平的彈性擴展能力，支持 ACID 事務(wù)，同時兼容 MySQL 協(xié)議，這就是我們所渴望的數(shù)據(jù)庫。

在 2017 年年中，我們開始對 TiDB 進(jìn)行調(diào)研和測試，并陸續(xù)在測試環(huán)境以及內(nèi)部系統(tǒng)上線了 TiDB 集群。在隨后的幾年中，TiDB 每一個新版本的發(fā)布都給我們帶來了不同的驚喜，我們也緊跟著 TiDB 社區(qū)的步伐及時地對新版本進(jìn)行測試，同時也對線上的集群進(jìn)行同步升級。

截至目前，已經(jīng)有大量的 TiDB 集群支撐著愛奇藝各條業(yè)務(wù)線的穩(wěn)定運行，這要感謝 PingCAP 同學(xué)們對我們及時的響應(yīng)和支持。歷經(jīng)五年的時間，愛奇藝內(nèi)部 TiDB 集群的規(guī)模已經(jīng)超過 500 臺服務(wù)器，總計有 100 多個 TiDB 集群服務(wù) 30 多條業(yè)務(wù)線。

傳統(tǒng)實時分析架構(gòu)的痛點

談到實時分析不得不提到當(dāng)前比較經(jīng)典的兩個架構(gòu)，一個是 Lambda 架構(gòu)，另外一個就是 Kappa 架構(gòu)。

Lambda 架構(gòu)的主要思路就是在離線數(shù)倉的基礎(chǔ)上加上實時數(shù)倉。離線數(shù)倉作為批處理層，而實時數(shù)倉作為速度層。實時數(shù)倉里面的數(shù)據(jù)存儲在 Kafka 里面，通過像 Flink、Spark Streaming 這樣的計算引擎對數(shù)據(jù)進(jìn)行計算，把離線批處理層和實時數(shù)據(jù)進(jìn)行匯總，再將數(shù)據(jù)存到 MySQL、Redis 應(yīng)用層數(shù)據(jù)庫中，供業(yè)務(wù)進(jìn)行查詢和展示。

Kappa 架構(gòu)其實是在 Lambda 架構(gòu)的基礎(chǔ)上去掉了離線數(shù)倉的部分，只保留了實時數(shù)倉，通過調(diào)整 Kafka 中數(shù)據(jù)的保留期將歷史數(shù)據(jù)進(jìn)行留存。如果說我們要對離線數(shù)據(jù)進(jìn)行重新處理的話，那就要去重置 Kafka 日志消費的偏移量，然后再對數(shù)據(jù)進(jìn)行重新計算，最終計算的結(jié)果也是存儲到 MySQL 或者是 Redis 這些應(yīng)用層數(shù)據(jù)庫中，供業(yè)務(wù)進(jìn)行查詢和展示。

雖然這兩種架構(gòu)是經(jīng)典的，但這兩種架構(gòu)還是存在不同的痛點：Lambda 架構(gòu)相對來說比較復(fù)雜，需要去維護(hù)流、批兩套系統(tǒng)，對于運維和開發(fā)人員來說難度相對比較大，離線數(shù)據(jù)和實時數(shù)據(jù)也很難保持一致；對于 Kappa 架構(gòu)來說，它對消息中間件是強依賴的，這就注定其性能是有瓶頸的，另外，這個架構(gòu)下還存在丟數(shù)據(jù)的風(fēng)險。

TiDB 在安全風(fēng)控和 BI 運營系統(tǒng)中的應(yīng)用

了解 Lambda 和 Kappa 架構(gòu)現(xiàn)存的一些痛點后，再來看看愛奇藝在實際應(yīng)用中如何使用 TiDB 來做分析。

首先是愛奇藝內(nèi)部的安全風(fēng)控數(shù)據(jù)服務(wù)系統(tǒng)，它主要的功能是提供統(tǒng)一的標(biāo)簽服務(wù)，類似于一個風(fēng)控系統(tǒng)的數(shù)據(jù)倉庫，并且需要滿足 OLTP 和 OLAP 兩類查詢。標(biāo)簽的實時數(shù)據(jù)寫入并存在 TiDB 里面，然后通過解析 Binglog 的方式或是通過手動觸發(fā)的方式支持標(biāo)簽上浮，存儲到服務(wù)層的 Cache 里面，用風(fēng)控引擎進(jìn)行一些實時的查詢。ETL 模塊通過跑 Spark job 的方式把 TiDB 的數(shù)據(jù)放到 Hive 里面，確保 TiDB 和 Hive 里面都存有全量的數(shù)據(jù)。

下面是安全風(fēng)控系統(tǒng)中 TiDB 的部署架構(gòu)。通過 TiSpark SQL 將 TiDB 中的標(biāo)簽數(shù)據(jù)存入 Hive ，用來支持離線的 OLAP 數(shù)據(jù)分析，TiDB 支持 OLTP 類場景的查詢?？梢钥闯鲞@種架構(gòu)和 Lambda 架構(gòu)是有些類似，也存在一定的缺陷，架構(gòu)稍顯復(fù)雜，對 Hive 有依賴，同時還需要維護(hù)兩邊數(shù)據(jù)的一致性。

BI 運營系統(tǒng)主要目的是幫助運營人員去分析站內(nèi)劇集上線后的綜合表現(xiàn)，包括流量、導(dǎo)流、收入以及質(zhì)量等，對多個維度的數(shù)據(jù)進(jìn)行統(tǒng)計分析。這個系統(tǒng)的主要功能是提供站內(nèi)榜單的監(jiān)測、劇集詳情查詢、內(nèi)容質(zhì)量分析以及劇集的對比等。

這是 BI 運營系統(tǒng)場景下 TiDB 的部署架構(gòu)圖，可以看到 BI 運營系統(tǒng)的數(shù)據(jù)源來自內(nèi)部的內(nèi)容數(shù)倉以及用戶畫像的數(shù)據(jù)，通過 Spark 和 Hive 的清洗存到服務(wù)層，比如 ClickHouse 和 TiDB 里面。TiDB 負(fù)責(zé)詳情頁的查詢，為某專輯或者是視頻展示詳細(xì)的統(tǒng)計數(shù)據(jù)，數(shù)據(jù)可以展示每日的詳情，也可以展示該時段的實時數(shù)據(jù)統(tǒng)計。該系統(tǒng)目前的數(shù)據(jù)量比較大，大概有十幾個 T，TiDB 不但要滿足 OLAP 類的查詢，還需要滿足 OLTP 類的查詢。

先前我們部署了一個 TiKV 集群，發(fā)現(xiàn)上面跑的 OLAP 類的查詢會影響到 OLTP 的查詢，后來我們又部署了一個三節(jié)點的 TiFlash 集群。業(yè)務(wù) SQL 方面，通過加 hint 的方式，把查詢 SQL 打到 TiFlash 集群上。通過這個改造升級，OLAP 類的查詢和 OLTP 的查詢互相沒有干擾，同時 OLAP 查詢的性能也有一定的提升。

TiDB 5.0 測試情況

今年 4 月 TiDB 發(fā)布了 5.0 版本，相較于 4.0 版本，5.0 版本新增了 TiFlash MPP 、異步事務(wù)提交、聚簇索引等一系列新特性。經(jīng)過和 PingCAP 同學(xué)的溝通交流，我們啟動了對 TiDB 5.0 的 POC 測試。愛奇藝內(nèi)部有一個訂單交易系統(tǒng)，架構(gòu)如圖所示，通過 sharding jdbc 把 MySQL 分為了 16 個分庫，然后再通過內(nèi)部的數(shù)據(jù)同步工具把 16 個分庫里面的數(shù)據(jù)匯總到 TokuDB、MongoDB 和 TiDB 中。TokuDB 主要是為 BI 提供抽數(shù)用的，TiDB 是提供運營后臺的查詢統(tǒng)計分析以及訂單歷史的查詢，前端 16 個分庫的 MySQL 主要是支持實時的交易系統(tǒng)。

我們在 TiDB 4.0 的使用過程中存在一些痛點，例如在非 UID 維度查詢的情況下效率偏低，不能滿足業(yè)務(wù)的需求。同時 TiFlash 的效率不是很高，因此使用率也高。目前 BI 是從 TokuDB 里面抽數(shù)的，但我們希望 BI 后續(xù)可以從 TiDB 里面抽數(shù)，這樣的話，就可以把 TokuDB 省掉，減少整個架構(gòu)的復(fù)雜度。此外，訂單交易系統(tǒng)中的 MongoDB 是為一個較老的運營后臺提供查詢使用的，我們也希望使用 TiDB 來進(jìn)行替換。

為了解決業(yè)務(wù)的痛點，我們制定了相應(yīng)的測試目標(biāo)。首先是要滿足業(yè)務(wù) HTAP 的查詢需求，并且在不影響實時業(yè)務(wù)的場景下，實現(xiàn) BI 從 TiDB 里面去抽數(shù)。第二，評估 TiDB 5.0 的性能，在不增加機器的情況下，提升寫入的性能。我們陸續(xù)進(jìn)行了基準(zhǔn)測試，新特性測試以及業(yè)務(wù) SQL 的測試。

這里列了部分的測試結(jié)果數(shù)據(jù)。在基準(zhǔn)測試方面，我們做了 Sysbench、TPC-C、TPC-H 等測試，總體來說，TiDB 5.0 的性能比 4.0 有大幅的提升。比如在 TPC-C 超高并發(fā)（500）下，平均執(zhí)行的延遲降低超過 50%，毛刺基本消除了。異步提交事務(wù)開啟的情況下，SQL 的平均延遲降低了 40% 以上，寫入的 QPS 也提升了 70%。此外，測試業(yè)務(wù)的 SQL 性能也提升了 20% 到 40% 不等。

因為數(shù)據(jù)量和業(yè)務(wù)場景的關(guān)系，我們在測試中沒有用到 MPP 的特性。同時 BI 的抽數(shù)也沒有走 TiFlash，還是走了 TiKV，這和測試之前的制定的目標(biāo)不太一樣。后續(xù)，我們還會評估和驗證 TiDB 5.0 在 BI 抽數(shù)的場景中，走 TiKV 抽數(shù)的情況下對業(yè)務(wù) SQL 的影響。

整體來說 TiDB 5.0 的性能提升是有目共睹的，并且支持真正的 Real Time HTAP 場景，目前愛奇藝線上的輕集群已經(jīng)升級到了 TiDB 5.0 版本。

未來展望

最后是對 TiDB 的展望。首先是大事務(wù)場景下，集群有時會出現(xiàn)性能抖動或者是 OOM 的問題。第二是 BR 備份帶來額外的負(fù)載，不太容易控制。第三就是索引統(tǒng)計信息不及時或者缺失導(dǎo)致執(zhí)行計劃錯誤或者不穩(wěn)定，目前我們是采用跑定時任務(wù)的方式去做索引信息的統(tǒng)計。希望 TiDB 后續(xù)的版本在這幾個方面可以有更大的提升。

未來，愛奇藝先是會推動業(yè)務(wù)嘗試 TiFlash MPP 架構(gòu)來落地 HTAP 場景，降低業(yè)務(wù)架構(gòu)的復(fù)雜度，就像剛才講到的風(fēng)控系統(tǒng)，后續(xù)計劃升級到 TiDB 5.0，去除對 Hive 的依賴。我們還將持續(xù)推進(jìn)云原生的建設(shè)，進(jìn)一步提高資源的利用率。