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

PingCAP發表於2022-03-30

業務挑戰

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

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

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

解決方案

CDP 希望在資料處理的過程中能提升資料處理時效性,同時滿足業務靈活性的要求,對於資料處理邏輯、資料更新邏輯,可以通過系統動態配置規則的方式來消費訊息資料(Kafka 或 QMQ)動態更新標籤,業務層只需關心資料篩選邏輯及條件查詢。 根據業務需求,業務資料標籤篩選主要分為兩大場景:

  1. 實時觸發場景。根據業務需要,配置動態規則,實時訂閱業務系統的變更訊息,篩選出滿足動態規則條件的資料,通過訊息的方式推送到下游業務方;

  2. 標籤持久化場景。將業務系統的實時業務變更訊息按照業務需要,加工成業務相關的特徵資料,持久化儲存到儲存引擎。業務根據需要組裝查詢條件查詢引擎資料,主要有 OLAP (分析類)與 OLTP (線上查詢)兩大類查詢。

基於以上需求,CDP 流式資料採用類 Kappa 架構,標籤持久化採用類 Lambda 架構,如下圖所示:

攜程 CDP 架構.png

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

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

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

目前,CDP 已經與攜程各個業務系統進行深度整合打通,為國際業務增長提供業務特徵標籤庫的資料與服務支援。

應用價值

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

  • 水平彈性擴充套件:擺脫 MySQL 分庫分表難題,幫助攜程隨時根據業務增長情況進行水平彈性擴充套件。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69994146/viewspace-2884883/,如需轉載,請註明出處,否則將追究法律責任。

相關文章