鐵路企業差旅酒店預訂系統數據治理技術研究

張 瑩，王運霞，易 超，張 智，張 蓓

（1. 鐵旅科技有限公司，北京 100081；2. 中國鐵道科學研究院集團有限公司 電子計算技術研究所，北京 100081；3. 中鐵程科技有限責任公司，北京 100081；4. 北京經緯信息技術公司，北京 100081）

由企業員工因公出差旅行（簡稱：差旅）衍生的相關服務行業發展迅速，是電子商務領域的一個細分產業。差旅平臺為大中型企業用戶提供了自助式的差旅管理服務，提供集出差申請、產品預訂、報銷、公司月結、差旅費用分析等一站式的差旅服務方案，可減輕長期出差員工的個人墊資壓力，簡化報銷流程。

當前，我國鐵路建設力度不斷增大，鐵路員工因公出行需求顯著增長。為此，中國鐵道科學研究院集團有限公司電子計算技術研究所（簡稱：鐵科院電子所）于2022年研發了鐵路差旅平臺，針對性地為鐵路企業員工及管理者提供智能化、信息化、專業化的差旅服務。鐵路企業差旅酒店預訂系統（簡稱：鐵路酒店預訂系統）是其重要的系統之一，面向鐵路企業管理者和因公差旅的員工，提供酒店查詢與預訂、訂單查詢與確認、客服工單管理、財務對賬結算、供應商管理等功能。因該系統數據具有海量、多源、異構的特點，當前遇到的問題包括：（1）使用傳統型關系數據庫無法滿足用戶高速檢索數據的需求；（2）與鐵路酒店預訂系統對接的各類供應商提供的酒店數據變更頻繁，多源數據同步延遲情況嚴重；（3）酒店供應商的數據沒有統一的數據標準，各類供應商的數據組成方式和字段各不相同，整合難度較高。因此，亟需對鐵路酒店預訂系統進行數據治理，解決系統數據在采集、處理、存儲、檢索、分析等全鏈路過程中的各類難題。

近年來，以Hadoop和Spark為代表的大數據生態圈組件已得到廣泛應用[1]。許多研究人員針對如何運用大數據技術進行數據治理進行了研究。張思思[2]設計的基于大數據分析的差旅系統中，采用Spark SQL和Spark Streaming實現對數據的計算功能，采用python語言進行建模，通過平穩性檢測和數據處理，保障數據穩定性；鄧奇山[3]在Hi Travel差旅平臺設計中，選用微服務分布式架構，使用Spark Streaming作為數據統計分析工具，顯著提高了數據的讀取速度和數據處理性能；何開品[4]闡述了大數據技術在智慧酒店中起到的整合數據資源、實現數據共享的作用。

基于上述研究，本文采用高速緩存和分布式搜索引擎，利用多源數據預同步和多源異構數據整合等技術進行數據治理，構建更加精準、高效的鐵路酒店預訂系統。

1 鐵路酒店預訂系統設計

1.1 總體架構

鐵路酒店預訂系統包括數據源層、數據采集層、數據存儲層和數據應用層，總體架構如圖1所示。

圖1 鐵路酒店預訂系統總體架構

（1）數據源層：系統數據來源主要包括從第三方系統（酒店供應商）獲取的酒店初始數據及用戶行為數據。

（2）數據采集層：對從數據源層獲取到的數據做預處理，將非標準格式的數據格式化為系統標準格式數據，并對來自不同供應商的同一酒店數據進行整合。

（3）數據存儲層：該層存儲的數據主要包括酒店數據與訂單數據，其中酒店數據分為靜態數據與動態數據。

（4）數據應用層：對數據存儲層中的數據進行檢索、分析和功能應用，并以報表的形式呈現出系統的整體運營情況。

1.2 功能模塊

鐵路酒店預訂系統的功能模塊包括預訂模塊、訂單模塊、客服模塊、結算模塊及供應商模塊，如圖2所示。

圖2 鐵路酒店預訂系統的功能模塊

（1）預訂模塊主要為用戶提供酒店查詢、比價、預訂與取消等服務，是整個系統的核心模塊；

（2）訂單模塊為運營人員提供訂單管理和統計功能，方便運營人員對本企業訂單進行統計，得出每個部門的出行數據規律，從而掌握企業員工的出行特征；

（3）客服模塊基于客服人員日常工作需求，提供座席管理、呼入與呼出、服務單管理等功能；

（4）結算模塊為財務人員提供對賬與結算功能；

（5）供應商模塊為運營人員提供供應商管理功能，方便在合同期間對供應商進行考核（價格準確率、訂單確認時長、拒單率等）；此外，本模塊還提供酒店資源整合功能。

2 酒店數據

酒店數據可分為靜態數據和動態數據2類。目前，鐵路酒店預訂系統每天處理靜態數據約11 000萬條，占用存儲空間約11 TB，動態數據450 000萬條，占用存儲空間約200 GB。

2.1 靜態數據

靜態數據的變化頻率較低，主要包括以下幾個部分。

（1）基礎數據。酒店的基礎信息，包括：酒店名稱、酒店簡介、所在城鎮、取消政策、酒店設施等。

（2）房型數據。酒店的臥室/客廳/衛生間，以及房間面積、樓層、禮遇等相關信息。

（3）興趣點數據。由電子地圖提供的酒店及其周邊的搜索服務，包括興趣點的名稱、地址、坐標、類別、服務介紹等。

（4）圖片數據。展示酒店實際場景及特色的各類圖片，能夠幫助員工更為直觀地了解住宿環境。

（5）訂單數據。包括預訂酒店過程中的待支付、已完成、已取消等各種狀態的訂單數據。

2.2 動態數據

動態數據是需要實時維護更新的數據，主要包括：

（1）房價數據。該數據受經濟、市場、氣候等多種因素影響，變動較為頻繁。

（2）房間狀態數據。指房間的當前狀態，包括：空房、走臟房（待清掃）、維修房、預退房等20種狀態。

（3）房量庫存數據。指現有可預訂狀態的庫存數量。

（4）點評數據。指用戶對酒店和房間的評價。

（5）問答數據。指關于入住酒店的一些疑問與解答。

3 數據治理方法

3.1 基于分布式緩存的高效檢索

本文提出一種基于分布式緩存技術的酒店數據高效檢索方法。在原有系統基礎數據庫的基礎上，設計Redis集群和ES（Elastic Search）集群。其中，Redis集群中存儲的數據為鐵路企業差旅熱門酒店數據；ES集群中建立了分布式索引，對酒店數據進行了抽象和分類，剝離常用搜索字段和基礎屬性字段[5]，使得服務器可在極短的時間內存儲、搜索和分析大量的數據；將PgSQL作為存儲所有酒店數據的基礎數據庫，對其進行分庫分表操作，從而提升單表的查詢能力，擴展系統的并發處理能力。數據治理后的酒店數據檢索業務流程如圖3所示。

圖3 酒店數據檢索業務流程

當用戶查詢酒店相關數據時，先判斷該查詢是否命中Redis集群緩存數據；若沒有命中，則判斷是否屬于復雜查詢，即基于酒店特征進行的組合查詢，若是，則查詢ES集群；若用戶查詢屬于簡單查詢，即指定某個酒店的查詢，則直接從系統數據庫中獲取數據。

3.2 多源數據同步

根據訪問頻率，酒店數據又可分為熱數據、溫數據和冷數據，本文針對該特點分別制定多源數據預同步策略[6]，并詳細闡述常見的靜態溫數據、動態熱數據和動態冷數據等3類數據的預同步方法。

3.2.1 靜態溫數據定時更新

靜態溫數據更新頻率較低，但較常被訪問，對于這類數據無需頻繁更新，每月更新1次，保持數據的時效性即可。

3.2.2 動態熱數據即時更新

針對房價、房態、房量庫存這類經常被訪問的動態熱數據，需要即時更新，保證數據的準確性和實效性，使用戶預訂不受影響，具體更新同步策略如下。

（1）熱門城市定時更新，對于我國搜索量前100名的熱門城市的酒店數據及搜索量前20 000名的酒店數據，設置定時器，固定時間和頻率，對其數據周期性地執行更新任務。由于熱門數據直接由供應商提供，短時間內即可完成更新，更新頻率為10 min/次。

（2）申請單審批完成后觸發更新，酒店預訂的先決條件是出差申請單的審批完成，可利用審批完成到用戶預訂之間的時間差，對出差申請單中的出差城市進行定向更新。

3.2.3 動態冷數據每天定時更新

問答、點評這類動態冷數據的用戶訪問頻率較低，時效性要求不高，但仍需要長期存儲，可每天定時對其進行更新。

3.3 基于映射機制的多源異構數據整合

對于一品多供的酒店商品，本文通過數據映射（Mapping）技術，從酒店數據映射和房型數據映射2個維度，準確識別不同供應商供應的同一家酒店及同一家酒店的同一個房型，整合多源異構數據[7]。鐵路酒店預訂系統供應商模塊中的資源整合功能示意如圖4所示。

當鐵路酒店預訂系統從第三方系統中拉取各個供應商的酒店資源信息后，先對其進行數據預處理，將不同數據格式的酒店數據轉換為標準數據；通過Mapping技術對地址、城市、經緯度、酒店名稱等維度進行匹配，從而整合酒店數據，實現對房型、設施、服務等信息的數據整合，將整合后的數據輸出到PgSQL基礎數據庫中，為后續酒店查詢及檢索提供數據支撐。

4 結束語

本文通過分析鐵路酒店預訂系統的數據特性，制定針對性的數據治理方案，實現鐵路酒店預訂系統對數據檢索的快速、高效反應。該數據治理方案已成功應用于鐵路酒店預訂系統的優化建設中，并于2022年4月上線運行。經數據治理優化后的鐵路酒店預訂系統可進行毫秒級的查詢響應，減少了鐵路企業員工預訂酒店的時間成本，顯著提升員工的差旅體驗。下一步，需要繼續研究鐵路酒店預訂系統的數據治理技術，實現數據治理動態化[8]，建立更加完整的鐵路差旅生態體系。