一、背景與挑戰

隨著攜程國際機票業務的快速發展與全球化戰略的深入推進，需要使用的數據種類以及對應的復雜度也隨之顯著增加。這一增長趨勢不僅帶來了數據管理的挑戰，同樣對數據準確性和實時性提出了更高的要求。

接下來，我們從生產者和消費者兩個角度具體看下有哪些挑戰。

生產者視角下的挑戰：對于基礎數據的生產者，每一種數據類型都有其獨特的業務邏輯，涵蓋數據的獲取、處理、存儲和匹配等環節。數據更新周期長，業務復雜性高，和基礎數據相關的應用就達到了幾十個，維護成本不斷攀升。同時，還存在著數據訪問效率低、上云過程復雜、數據回滾困難以及無法應對大規模機器重啟或數據刷新等問題。

消費者視角下的挑戰：對于基礎數據的消費者，每一個應用都或多或少依賴于基礎數據。任何一種數據的誤差都可能引發廣泛的線上問題，而且問題的發現往往滯后，導致生產問題被不斷放大。此外，還存在著業務開發接入復雜、測試環境不穩定、服務啟動緩慢、垃圾回收頻繁、上云過程繁瑣以及數據不一致等問題。

二、原則與目標

面對上述問題，構建一套中臺化系統是其中一個解決方案，我們希望實現數據資源的高效整合，消除數據孤島，提高數據處理效率，確保數據質量標準。在系統設計的初期階段，我們首先從數據生產者和消費者角度出發確立了一系列核心目標：

數據生產者角度：

數據一致性：確保數據在各個環節保持一致性，避免偏差。

數據時效性：保障數據的實時更新，滿足業務對數據的即時性需求。

系統健壯性：構建穩定可靠的系統架構，以應對各種運行環境和負載條件。

- 數據可追溯性：實現數據的全流程追蹤，便于問題定位和歷史分析。

- 數據可回滾性：提供數據版本控制，允許在出現問題時快速回退至穩定狀態。

- 監控完善性：建立全面的監控體系，實時監控數據流和系統狀態。

降低成本：通過優化資源配置，降低機器和存儲的成本；簡化系統維護流程，減少人力和時間的投入。

數據消費者角度：

優化消費流程：簡化數據消費流程，提高數據處理的便捷性和效率。

- 接入方式簡化：提供直觀易用的接入方式，降低數據使用的門檻。

- 統一數據模型：建立統一的數據模型，確保數據的一致性和可理解性。

解決環境問題：解決不同運行環境下的數據同步的問題。

- 測試環境完善：提供完善的測試環境，確保數據的準確性和穩定性。

- 云服務便捷性：優化云服務接入，提高數據服務的靈活性和可擴展性。

提升服務性能：通過技術優化，提升服務的響應速度和處理能力。

- 啟動耗時降低：減少服務啟動時間，提高系統的快速響應能力。

- 減少GC次數：優化內存管理，減少因數據更新引起的垃圾回收（GC）操作，提升系統性能。

三、關鍵技術實踐

在基礎數據中臺化建設的實踐過程中，遇到了一系列的問題，本章節將介紹一些關鍵的技術實踐。

3.1 數據一致性

3.1.1 版本控制

同一集群下不同的機器在更新緩存時由于調度時間不一致，會導致不同機器在同一時間使用的數據不一致，為解決此問題，我們使用數據版本控制策略來解決此問題。每當數據發生變更，我們便認定一個新的數據版本已經誕生。這個新版本可以是包含了變更和未變更數據的完整副本（下文簡稱為"全量數據"），也可以是僅包含變更內容的更新（以下簡稱為"增量數據"）。不論是全量數據還是增量數據，我們都會將數據記錄在BLOB（Binary Large Object）文件中，BLOB文件將作為數據傳輸的媒介。

實施數據版本控制后，我們能夠收獲以下收益：

版本追蹤：確保每一次數據更新都有跡可循，并且在新版本出現問題時能夠迅速恢復到之前的版本。

數據一致性：保證所有數據消費者能訪問到相同版本的數據，從而減少因數據版本不一致而引發的問題。

容錯與恢復：能夠快速識別出問題數據，并利用多種通知機制，促使產品或開發團隊及時介入，解決問題。

性能監控：基于數據版本，構建性能監控體系，以評估數據傳輸和處理的效率。

數據安全：在數據傳輸和存儲過程中，通過加密和訪問控制機制，確保數據安全，防止未授權訪問。

3.1.2 去中心化

在業界，如果某個服務想要消費基礎數據時，主流解決方案是采用直連數據庫或調用應用程序接口的方式，如下圖1和圖2，這兩者均屬于C/S架構。C/S架構雖被廣泛采用，卻面臨著如數據庫承載壓力大、數據一致性難以保障、系統擴展性不足、開發與集成過程復雜、硬件成本高昂、緩存穿透、中心服務的讀壓力，以及難以應對流量高峰等問題。

圖1

圖2

為了克服以上問題，我們引入了P2P架構（Peer-to-Peer Architecture）。與C/S架構相比，P2P架構實現了去中心化。在P2P網絡中，每個節點都具備客戶端和服務器的雙重身份，能夠直接與其他節點進行通信和數據交換，無需依賴中央服務器。同時，P2P架構下的數據查詢耗時并不會因為客戶端數量的增加而線性增長。圖3直觀地展示了C/S架構與P2P架構的本質區別。

圖3

基于前文提到的BLOB文件版本控制機制，我們選擇了BitTorrent協議作為P2P網絡中的文件共享與分發標準。BitTorrent以其高效的數據傳輸能力，特別適用于大規模數據的快速分發，具體架構如圖4，客戶端可以根據實際需求控制是否要加入Peer網絡，如圖4中的紅色機器就僅僅下載數據，并不分享給其他peer。

圖4

3.1.3 數據組合策略優化

在業務實踐中，我們有時候會需要處理多種基礎數據的組合場景，比如想要在消費國家數據時一同消費國家所在大洲數據，當組合中的數據版本出現不一致時，會導致數據不準確。

為應對這一挑戰，我們采取的方法是通過業務規則，將所有相關聯的組合數據整合到單一的torrent文件中，消費方可以一次性下載到所有關聯數據。這種整合方式的優勢在于，它允許消費方一次性獲取整個數據集合，而不需要分別從不同來源或版本中收集和協調數據。通過這種方式，我們不僅簡化了數據獲取過程，而且更重要的是確保了數據的一致性和準確性。

3.1.4 單點數據生成策略

集群內不同的機器間隔幾秒鐘查詢同一數據庫，查詢結果便可能會有所不同，為保證消費方數據一致性，我們在生成全量和增量數據時采取了單點數據加載模式，如圖5。僅有單一的機器負責從數據庫中查詢數據，這種設計一方面顯著降低了數據庫的讀取壓力，其效果相當于將壓力分散至消費方機器數量的1/n（n代表消費方機器的總數），另一方面結合版本控制策略，在同一時間內中臺系統中僅僅有一個有效的版本數據可以被使用。

圖5

此外，不同種類的數據更新頻率各異，這通常由具體的業務需求所決定。因此，中臺系統提供了自定義數據生成配置的功能，這種靈活性的好處在于：

減少不必要的數據加載：通過精確控制數據生成的頻率和時機，避免了資源的浪費。

降低客戶端緩存刷新壓力：減少了因頻繁數據更新導致的客戶端垃圾回收（GC）操作，從而提高了客戶端的性能。

緩解網絡帶寬壓力：通過優化數據生成和傳輸策略，減輕了整個網絡的帶寬負擔，確保了數據傳輸的高效性。

3.2 數據時效性

3.2.1 推拉機制

為確保數據生產至消費的全流程時效性，防止數據更新滯后對業務造成損失，我們在架構設計中引入了推拉接合模式。前序系統完成數據處理后，即通過消息中間件向后續系統發出通知，這一連貫流程在各子系統中依次觸發，直至數據被消費。

為提高流程可靠性，我們引入了可配置的基于定時任務中間件的拉狀態邏輯，確保了任何環節的延遲或異常都能被及時補償。

圖6

3.2.2 數據云端遷移

隨著攜程國際業務的不斷拓展，我們的系統架構正逐步向混合云模式轉型。傳統的基礎數據上云是復制數據庫到云端，雖然可行，但往往會帶來成本上升和數據復制延遲等問題。為應對這些挑戰，我們將Blob文件分發到不同的Region，避免了對昂貴數據庫實例的依賴，在保證數據時效性的前提下成本降低98%以上，榆次同時使用此架構消費方在上云過程中可以做到無縫遷移。具體架構如圖7。

圖7

3.3 系統健壯性

3.3.1 數據校驗和攔截

在數據的生命周期中，無論是業務維護的數據，還是由外部數據提供商提供的數據，數據錯誤總是一個不可忽視的問題。這些錯誤表現為非法字符、數據缺失、數據重復等。為有效解決此問題，我們開發了一套數據校驗機制，針對數據的每個字段執行嚴格的合規性檢查。系統一旦監測到異常數據，將立即通過TripPal（攜程自研的IM系統）、電子郵件、短信等多種通信渠道，向數據負責人發出警報，這樣可以迅速響應并處理問題。

在問題未解決前，系統會自動暫停出問題數據的更新，防止錯誤數據的擴散。此外，為了進一步提升數據校驗的準確性，我們結合了統計學算法和人工智能（AI）預測模型，對數據變化進行分析和智能判斷。具體的架構如圖8。

圖8

3.3.2 數據回滾

在生產環境中，面對突發的系統故障，實施回滾操作是最迅速且有效的應對策略。中臺系統為此提供了一套數據回滾功能，將回滾版本的數據視為一個完全正常的版本，通過中臺的Portal界面，用戶可以依據時間戳追溯并查詢到所需的歷史數據版本。其中，整個回滾過程無需對數據庫進行任何數據層面的修改，這一點與依賴于二進制日志（binlog）的回滾方法相比，提高了效率和安全性。如圖9。

圖9

3.4 消費流程優化

3.4 1 統一數據模型

數據模型會出現新增、修改和刪除字段的場景，通常我們會通過編碼的方式實現，不僅過程繁瑣，而且隨著時間推移，會顯著增加系統的維護成本。為了降低消費方消費數據的復雜度，需要支持任意數據模型的自動化生產和消費。我們通過腳本化手段實現自動化構建（build）和部署（deploy）jar包，從而簡化流程。具體的流程如圖10。

圖10

3.4.2 簡化接入方式

當需要消費某個數據時，引入通過圖10流程生成的獨立model包，通過以下代碼即可獲取全量數據集或者按條件查詢的數據集。

// 引入客戶端
@DataResource
private CityClient cityClient;
// 全量查詢
List<City> list = cityClient.queryList();
// 條件查詢
List<City> list = cityClient.queryList(cityCode);

3.5 統一數據治理

在實際的工作中，開發團隊和產品團隊常常面臨一個共同的挑戰：如何在種類繁多的基礎數據中找到目前生產上實際使用的基礎數據？一般會通過口口相傳或維護共享文檔的方式來解決，但是這種方法不僅效率低，而且容易因人為失誤或信息更新不及時導致生產問題，為此，數據中臺實現了一個統一的模型入口，簡化了數據和模型的搜索和引用過程。用戶可以在Portal中按照數據庫名、數據表名、接口名等檢索條件輕松搜索所需的數據類型，如果存在，可以直接引用；如果不存在，可以根據具體的業務需求新增。

對于新的業務接入中臺，我們也進行了流程的優化。優化后，接入中臺只需調整數據源，無需進行額外的開發工作。這一改進顯著減少了業務接入的復雜性和工作量，最小化了接入流程。與直接連接數據庫或調用應用程序接口的方式相比，中臺系統在數據接入效率上實現了90%以上的提升。

四、技術架構概覽

在前文所述的基礎上，本節從宏觀的系統架構視角，闡述攜程國際機票基礎數據中臺化建設的關鍵技術實現。我們的系統精心設計為若干個互相協作的核心模塊，每個模塊承擔著特定的職責，共同構成了數據處理和分發的中臺化平臺。

1）DataSource 模塊：作為數據流的起點，此模塊負責數據的初始寫入和確保數據一致性。它通過定時任務或消息通知機制觸發數據操作流程。

2）BlobGenerator 模塊：專注于數據的生產過程，提供全面的服務，包括數據校驗、BLOB文件生成、版本控制以及回滾操作的攔截。

3）BlobService 模塊：作為數據分發的核心，處理來自DataClient的數據請求，充當BlobGenerator與DataClient之間的橋梁，確保數據流暢、高效地傳遞。

4）DataClient 模塊：負責數據的消費端，提供包括BitTorrent下載、緩存管理、以及支持精確查詢等多種功能，滿足不同場景下的數據使用需求。

5）DataQuery 模塊：為那些無法通過BitTorrent下載方式獲取數據的消費者提供了API查詢接口，支持全量數據輸出、條件篩選輸出以及邏輯計算等高級功能。

6）Dispatcher 模塊：作為系統的調度協調中心，確保DataSource、BlobGenerator、BlobService等模塊的任務有序執行，保障整個數據處理流程的順暢和同步。

通過這些模塊的緊密協作，我們的技術架構不僅提升了數據處理的效率和準確性，還增強了系統的可擴展性和可維護性。

圖11

五、成效

數據中臺實現了從數據生成到消費的全生命周期覆蓋。系統化的數據治理舉措提升了數據系統在治理、成本控制、安全性和運營效率方面的性能。

數據生產者角度：我們對分散的業務流程進行了梳理和優化，根據優先級分批整合至中臺。在這一過程中，我們不僅重構了業務流程，還通過重寫和優化，挖掘并解決了多個之前未被發現的問題。數據分發的效率實現了質的飛躍，平均分發時間降至23秒，對于小規模數據，我們更是實現了5秒內的端到端快速傳輸，極大提升了數據的實時性和新鮮度；整體服務器成本降低了95%以上；系統的維護成本降低66%。

數據消費者角度：新數據源的接入效率提升了90%，上云過程無需進行特殊改造，加快了研發進度，提高了開發效率。解決不同運行環境下的數據同步的問題，減少了對生產環境的依賴。優化了調度策略，減少了98%以上的無效調度任務，降低了GC的頻率。

六、未來計劃

國際機票數據中臺在上線體現了一些在研發效能、數據治理、性能優化、業務提升、降低成本等方面優勢，未來我們計劃從以下幾個關鍵方面對數據中臺進行深入迭代和優化：

1）自動化：進一步提升數據處理流程的自動化程度，減少人工干預，提高整體效率，特別會利用大語言模型等技術進行數據校驗以及，增強數據準確性。

2）穩定性：加強系統的穩定性，確保數據中臺在高并發和大數據量處理場景下的可靠性。

3）健壯性：構建更加健壯的系統架構，提高系統對異常情況的容錯能力和自我恢復能力。

4）時效性：優化數據更新和分發機制，確保數據的實時性和時效性。

5）可視化：通過可視化技術，直觀展示數據流動和處理過程，提高數據可讀性和易用性。

- 更友好的Portal界面：設計和實現更加人性化的Portal界面，提升用戶體驗，簡化用戶操作。

- 處理流程可視化：實現數據處理流程的可視化展示，使用戶能夠清晰地追蹤數據處理的每個環節。