TiDB 在攜程 - 實時標籤處理平臺優化實踐

攜程是全球領先的一站式旅行平臺，旗下擁有攜程旅行網、去哪兒網、Skyscanner 等品牌。攜程旅行網向超過 9000 萬會員提供酒店預訂、酒店點評及特價酒店查詢、機票預訂、飛機票查詢、時刻表、票價查詢、航班查詢等服務。

在十億級別數據量下，攜程藉助 TiDB HTAP 能力提升業務運營的效率，應用場景主要包括國際業務 CDP 平臺、酒店結算、風控等。

實時標籤處理平臺面臨挑戰

在國際業務上，由於面臨的市場多，產品和業務複雜多樣，投放渠道多，引流費用高，因此需要對業務和產品做出更精細化的管理和優化，滿足市場投放和運營需要，降低整體成本，提高運營效率與轉化率。爲此，攜程專門研發了國際業務動態實時標籤化處理平臺（以下簡稱 CDP ）。

攜程旅行的數據具有來源廣泛、形式多樣、離線數據處理與在線數據處理兼有等特點，如何通過系統對這些數據進行採集、管理、加工，形成滿足業務系統、運營、市場需求的數據和標籤。處理好的數據需要立刻運用到業務系統、EMD、PUSH 等使用場景中，對數據處理系統的時效性、準確性、穩定性以及靈活性提出了更高要求。

爲了解決以上問題，CDP 系統必須提升數據處理能力。過去傳統方案是通過數倉進行 T+1 計算，再導入 ES 集羣存儲，前端通過傳入查詢條件，組裝 ES 查詢條件查詢符合條件的數據。攜程已經上線的標籤有上百個，有查詢使用的超過 50% ，由於該方案是離線計算，所以數據時效性差，依賴底層離線平臺計算和 ES 索引，查詢響應速度較慢。

TiDB HTAP 雙引擎

滿足實時觸發、持久化儲存雙場景需求

CDP 希望在數據處理的過程中能提升數據處理時效性，同時滿足業務靈活性的要求，對於數據處理邏輯、數據更新邏輯，可以通過系統動態配置規則的方式來消費消息數據（Kafka 或 QMQ）動態更新標籤，業務層只需關心數據篩選邏輯及條件查詢。

根據業務需求，業務數據標籤篩選主要分爲兩大場景：

- 實時觸發場景。 根據業務需要，配置動態規則，實時訂閱業務系統的變更消息，篩選出滿足動態規則條件的數據，通過消息的方式推送到下游業務方；

基於以上需求，CDP 流式數據採用類 Kappa 架構，標籤持久化採用類 Lambda 架構，如下圖所示：

圖：CDP 系統架構

其中，標籤持久化場景需要解決業務標籤的持久化存儲、更新、查詢服務，攜程採用了 TiDB 來存儲業務持久化的標籤，並採用實時觸發場景中的動態規則配置方式消費業務系統數據變更消息，保證業務持久化標籤的時效性，通過 TiDB 對 OLTP 和 OLAP 不同場景查詢特****性的支持，來滿足不同業務場景中訪問業務特徵數據的需要。

系統借鑑了 Lambda 數據處理架構的思想，新增數據根據來源不同分別發送到不同的通道中，歷史全量數據通過數據批處理引擎（如 Spark）轉換完，批量寫入到數據持久化存儲引擎 TiDB 中。增量數據業務應用以消息形式發送到 Kafka 或 QMQ 消息隊列，將數據按照標籤持久化的邏輯規則處理完成，增量寫入到持久化存儲引擎 TiDB，以此解決數據的時效性問題。

TiDB 同時具有兩大持久化存儲方式，一種是行存 TiKV ，可以支持 OLTP 場景，另一種是列存 TiFlash ，可以支持 OLAP 場景。TiDB 數據存儲內部自動解決這兩個引擎的數據同步問題，客戶端查詢根據自身需要選擇查詢方式。同時，TiDB 還能保障兩種方式有着良好的隔離性，併兼顧數據強一致性，出色地解決了 HTAP 場景的隔離性及列存同步問題。

目前，CDP 已經與攜程各個業務系統進行深度整合打通，爲國際業務增長提供業務特徵標籤庫的數據與服務支持。

TiDB 應用價值

· HTAP 混合負載

完美支撐 OLTP + OLAP 混合負載，簡化 IT 系統架構，大幅提升業務的實時查詢性能。

· 水平彈性擴展

擺脫了 MySQL 分庫分表難題，幫助攜程隨時根據業務增長情況進行水平彈性擴展。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/CwSdJcl5FOiq7H5rMevPCA

猜你喜歡