一、背景與挑戰(zhàn)

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

接下來，我們從生產(chǎn)者和消費者兩個角度具體看下有哪些挑戰(zhàn)。

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

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

二、原則與目標

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

數(shù)據(jù)生產(chǎn)者角度：

數(shù)據(jù)一致性：確保數(shù)據(jù)在各個環(huán)節(jié)保持一致性，避免偏差。

數(shù)據(jù)時效性：保障數(shù)據(jù)的實時更新，滿足業(yè)務對數(shù)據(jù)的即時性需求。

系統(tǒng)健壯性：構建穩(wěn)定可靠的系統(tǒng)架構，以應對各種運行環(huán)境和負載條件。

- 數(shù)據(jù)可追溯性：實現(xiàn)數(shù)據(jù)的全流程追蹤，便于問題定位和歷史分析。

- 數(shù)據(jù)可回滾性：提供數(shù)據(jù)版本控制，允許在出現(xiàn)問題時快速回退至穩(wěn)定狀態(tài)。

- 監(jiān)控完善性：建立全面的監(jiān)控體系，實時監(jiān)控數(shù)據(jù)流和系統(tǒng)狀態(tài)。

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

數(shù)據(jù)消費者角度：

優(yōu)化消費流程：簡化數(shù)據(jù)消費流程，提高數(shù)據(jù)處理的便捷性和效率。

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

- 統(tǒng)一數(shù)據(jù)模型：建立統(tǒng)一的數(shù)據(jù)模型，確保數(shù)據(jù)的一致性和可理解性。

解決環(huán)境問題：解決不同運行環(huán)境下的數(shù)據(jù)同步的問題。

- 測試環(huán)境完善：提供完善的測試環(huán)境，確保數(shù)據(jù)的準確性和穩(wěn)定性。

- 云服務便捷性：優(yōu)化云服務接入，提高數(shù)據(jù)服務的靈活性和可擴展性。

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

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

- 減少GC次數(shù)：優(yōu)化內(nèi)存管理，減少因數(shù)據(jù)更新引起的垃圾回收（GC）操作，提升系統(tǒng)性能。

三、關鍵技術實踐

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

3.1 數(shù)據(jù)一致性

3.1.1 版本控制

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

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

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

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

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

性能監(jiān)控：基于數(shù)據(jù)版本，構建性能監(jiān)控體系，以評估數(shù)據(jù)傳輸和處理的效率。

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

3.1.2 去中心化

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

圖1

圖2

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

圖3

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

圖4

3.1.3 數(shù)據(jù)組合策略優(yōu)化

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

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

3.1.4 單點數(shù)據(jù)生成策略

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

圖5

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

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

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

緩解網(wǎng)絡帶寬壓力：通過優(yōu)化數(shù)據(jù)生成和傳輸策略，減輕了整個網(wǎng)絡的帶寬負擔，確保了數(shù)據(jù)傳輸?shù)母咝浴?/span>

3.2 數(shù)據(jù)時效性

3.2.1 推拉機制

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

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

圖6

3.2.2 數(shù)據(jù)云端遷移

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

圖7

3.3 系統(tǒng)健壯性

3.3.1 數(shù)據(jù)校驗和攔截

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

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

圖8

3.3.2 數(shù)據(jù)回滾

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

圖9

3.4 消費流程優(yōu)化

3.4 1 統(tǒng)一數(shù)據(jù)模型

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

圖10

3.4.2 簡化接入方式

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

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

3.5 統(tǒng)一數(shù)據(jù)治理

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

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

四、技術架構概覽

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

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

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

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

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

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

6）Dispatcher 模塊：作為系統(tǒng)的調(diào)度協(xié)調(diào)中心，確保DataSource、BlobGenerator、BlobService等模塊的任務有序執(zhí)行，保障整個數(shù)據(jù)處理流程的順暢和同步。

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

圖11

五、成效

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

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

數(shù)據(jù)消費者角度：新數(shù)據(jù)源的接入效率提升了90%，上云過程無需進行特殊改造，加快了研發(fā)進度，提高了開發(fā)效率。解決不同運行環(huán)境下的數(shù)據(jù)同步的問題，減少了對生產(chǎn)環(huán)境的依賴。優(yōu)化了調(diào)度策略，減少了98%以上的無效調(diào)度任務，降低了GC的頻率。

六、未來計劃

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

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

2）穩(wěn)定性：加強系統(tǒng)的穩(wěn)定性，確保數(shù)據(jù)中臺在高并發(fā)和大數(shù)據(jù)量處理場景下的可靠性。

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

4）時效性：優(yōu)化數(shù)據(jù)更新和分發(fā)機制，確保數(shù)據(jù)的實時性和時效性。

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

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

- 處理流程可視化：實現(xiàn)數(shù)據(jù)處理流程的可視化展示，使用戶能夠清晰地追蹤數(shù)據(jù)處理的每個環(huán)節(jié)。