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

劉振東 2021-12-16

展開全文

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

與 TiDB 攜手的五年

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

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

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

傳統(tǒng)實(shí)時(shí)分析架構(gòu)的痛點(diǎn)

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

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

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

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

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

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

首先是愛奇藝內(nèi)部的安全風(fēng)控?cái)?shù)據(jù)服務(wù)系統(tǒng)，它主要的功能是提供統(tǒng)一的標(biāo)簽服務(wù)，類似于一個(gè)風(fēng)控系統(tǒng)的數(shù)據(jù)倉庫，并且需要滿足 OLTP 和 OLAP 兩類查詢。標(biāo)簽的實(shí)時(shí)數(shù)據(jù)寫入并存在 TiDB 里面，然后通過解析 Binglog 的方式或是通過手動(dòng)觸發(fā)的方式支持標(biāo)簽上浮，存儲(chǔ)到服務(wù)層的 Cache 里面，用風(fēng)控引擎進(jìn)行一些實(shí)時(shí)的查詢。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ù)雜，對(duì) Hive 有依賴，同時(shí)還需要維護(hù)兩邊數(shù)據(jù)的一致性。

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

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

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

TiDB 5.0 測試情況

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

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

為了解決業(yè)務(wù)的痛點(diǎn)，我們制定了相應(yīng)的測試目標(biāo)。首先是要滿足業(yè)務(wù) HTAP 的查詢需求，并且在不影響實(shí)時(shí)業(yè)務(wù)的場景下，實(shí)現(xiàn) BI 從 TiDB 里面去抽數(shù)。第二，評(píng)估 TiDB 5.0 的性能，在不增加機(jī)器的情況下，提升寫入的性能。我們陸續(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% 不等。

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

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

未來展望

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

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

本站是提供個(gè)人知識(shí)管理的網(wǎng)絡(luò)存儲(chǔ)空間，所有內(nèi)容均由用戶發(fā)布，不代表本站觀點(diǎn)。請(qǐng)注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購買等信息，謹(jǐn)防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請(qǐng)點(diǎn)擊一鍵舉報(bào)。

轉(zhuǎn)藏 分享

QQ空間 QQ好友新浪微博微信

獻(xiàn)花（0） +1

來自：劉振東 > 《PingCap實(shí)戰(zhàn)》

舉報(bào)/認(rèn)領(lǐng)