高性能實時數據分析平臺在航空公司收益提升中的應用

【摘 要】航空公司在銷售和服務領域使用的旅客服務系統（PSS：Passenger Service System）是一個OLTP系統，不適合進行在線分析處理（OLAP）。在線分析處理功能的缺乏限制了航空公司的快速分析能力和響應速度。通過解決這個問題，不僅可以提高航空公司的分析能力，還可以提高服務質量和速度，提高航空公司的資源利用率，以及提高旅客服務滿意度，這將對航空公司的綜合收益產生重大影響，是目前各大航空公司的發展重點。本文探索以面向對象數據模型以及NoSQL技術，解決實時的在線數據分析所面對的大容量、高性能、復雜業務/數據類型挑戰，介紹了目前已經實現的高性能實時數據平臺原型，及其在航空公司的收益輔助領域中的應用。最后，本文還探討了實時數據分析平臺的發展方向和在民航業其他領域中的可能應用。

【關鍵詞】航空公司；收益輔助；實時數據分析；ODBMS，NoSQL

一、前言

航空公司在銷售和服務方面使用的IT系統被稱為“旅客服務系統”，Passenger Service System，簡稱PSS。PSS是一個實時交易處理系統，也就是OLTP系統。實時交易處理系統的核心是交易。從技術角度看，交易是數據處理的最小單位。交易只有成功和失敗兩種狀態，能夠保證數據的一致性。從行業角度看，交易是最小的業務單位，在民航業普遍存在于諸如座位可利用狀態查詢、預訂、支付、出票、值機等業務中。實時交易處理系統的優勢在于高效、快速以及安全的數據操作，同時具有很高的穩定性。旅客服務系統經常需要為這種要求付出大量的出額外成本支出。

隨著民航市場競爭日益激烈、民航業務日趨復雜，航空公司旅客服務系統在提供高性能交易處理的同時，還需要對歷史數據進行分析和挖掘，為航空公司業務人員提供決策支持的能力，甚至通過業務規則引擎自動完成決策，實現商業智能化。這就要求旅客服務系統在提供OLTP功能的同時，還要支持

OLAP。但是在系統設計理念上兩者并不完全相同，前者偏重于交易處理、保證數據寫的高效和安全性、一致性；后者則偏重于強大的計算能力，需要高效的數據I/O能力和數據計算性能。通常鑒于系統效率、軟硬件成本考慮，不會將這兩類應用放在同一個系統中。交易處理系統和決策支持系統是分離的（見圖1）；后者從交易系統批量下載數據快照，經過挖掘、分析后形成業務規則，批量上傳到交易系統。

國內航空市場是一個激烈競爭的市場，航空公司不僅需要線下的決策支持能力，還要求實時的決策支持能力。本文的目標是給出一個滿足航空公司實時決策支持的在線數據分析平臺，幫助航空公司在瞬息萬變的市場上搶得先機。此時業務模型見圖2，實時數據平臺處于交易處理系統和數據倉庫之間，為航空公司業務人員提供只讀的實時數據分析和統計匯總能力。

二、實時數據平臺需要解決的主要問題

（1）實時數據同步：交易處理系統負責數據寫的安全性和一致性，高峰時間整個系統的處理量達到3000TPS（Transaction Per Second，每航空公司）。為實現實時數據分析，需要將這些數據從主系統中推送到實時數據平臺中。（2）高性能數據轉換：實時數據平臺不僅要處理高峰時間每秒3000次的入庫請求，每次入庫都需要將OLTP的數據模型轉換為結構化數據模型并入庫，同時要處理大規模、高并發的全庫查詢請求。（3）結構化復雜數據支持：實時數據平臺需處理的數據經過高度抽象后主要分為三類，即航班控制系統中的航班對象、訂座系統中的訂單對象以及支付后形成的電子票對象/結算對象。這三類數據對象每一類都非常復雜，一個簡化的訂單對象結構見圖3，通常這三類對象層級都可以達到8～10級。在本文場景中，我們通過引入新的技術，已經能夠比較好的解決該問題。通過OLTP系統的底層I/O模塊推送數據，數據接收者的延遲可以控制在20ms～200ms之間，基本滿足目標需求。同時，通過利用下一代的對象數據庫，可以高效實現高性能的數據轉換以及復雜數據結構的高性能數據處理。

三、旅客服務系統面臨困難的具體分析

數據規模、數據結構在類似旅客服務系統這樣的信息服務系統中可能會非常龐大。我們以兩種主要數據樣本，描述整體的數據規模情況。

數據1，航班：國內某大型航空集團每天航班量約3000個，可預售航班2年左右（710天），因而需要存儲的航班對象約213萬；依據航班容量不同，每個航班對象可能由數百或上千個航節、航段、艙位、座位、Bid Price對象構成。因而僅航班類數據，就需要存儲21.3億個對象。數據2：訂單，對于訂單數據，如該航空集團每年承運7000～8000萬航段，以平均2個航段/訂單計算，系統中有約4000萬訂單對象，每個訂單對象由旅客身份、航段、附加服務、代理信息、價格、機票、座位等上百個對象構成，需要存儲約20億個對象。此估算基于一年數據。整體考慮，實時數據平臺需要存儲的數據對象在60億～100億之間。

圖3 簡化的訂單對象

為了解決在復雜數據結構和大容量的條件下，仍然要實現高性能的問題，我們試用了NoSQL的對象數據庫。通過多方評測我們知道，對象數據庫能夠同時在數據復雜性、數據容量和并發性三個緯度上取得平衡。在傳統系統中，數據持久化基本采用關系模型。在單表查詢時，關系數據庫可以獲得極好的性能。但當數據結構變復雜，關系模型必須引入關聯查詢，此時性能隨著關聯層級增加呈指數下降。我們需要處理的三類數據都有8～10級繼承，如果將它們關系化為二維表，勢必造成多層級關聯。如果采用單個二維表存儲并建大量索引優化性能，會面臨兩個無法解決的問題，即每個表都有數千字段和大量數據冗余，都造成修改和維護困難，查詢效率底的問題。如果不對數據對象做結構化，而是將整個數據對象作為Blob存儲，就無法對目標數據進行靈活查詢；此時每增加一類查詢應用，都需要從Blob中結構化出相關字段（對象屬性），放入二維表。當支持所有類型的查詢時，就需要從Blob中結構化出所有字段（對象屬性）。實際上我們發現在具體實踐中也確實是這樣進行設計的。另一方面，現今絕大多數程序開發都采用面向對象模型，如果要保存數據到關系型數據庫，就需要在運行時在對象模型和關系模型之間進行轉換，即OR Mapping。對象-關系轉換會消耗大量處理器時間，降低系統的整體性能。雖然目前Hibernate等框架可以提升OR Mapping的編程效率，但無法解決OR

Mapping帶來的性能降低問題，而且在有些時候會造成額外的成本。

四、旅客服務系統實時數據平臺實現高性能和高可靠性的探索

圖4 Versant數據庫的多層架構

實時數據平臺采用與主系統相同的多層架構，從下往上依次是數據庫服務器（Database Server），應用服務器（Applica

tion/Web Service Server）以及Web服務器。其中，數據持久是目前的性能瓶頸所在。為解決這個問題，在數據庫層面，我們選擇了商業對象數據庫Versant，建立了高性能應用服務器緩存架構。圖4描述了基于高性能緩存的多層數據架構。

由于實時數據平臺向外提供服務的方式大部分為Web

Service，因而多層架構的核心是數據庫服務器和應用服務器緩存兩層。Versant提供的雙緩存技術在應用服務器上并提供無縫內存數據緩存能力，實現類似內存數據庫的功能。利用這一特性，我們讓一些訪問頻度高、不常變化數據對象常駐內存，例如圖5中的Airline對象、FlightNumber對象、FlightFrequency對象以及各類Index對象。由于應用服務器有足夠的內存空間（單機32G內存），配置Inventory對象也常駐內存。對于其他類型數據，如SuperPNR對象、ET對象和RAccounting對象，則采用動態緩存技術，查詢命中的數據緩存在內存中，規定時間內未使用同時又有新數據進入（例如5000ms）則purge老數據。

在部署上，采用4臺應用服務器對2臺數據庫服務器的結構，每臺應用服務器同時連接到2臺數據庫服務器。2臺數據庫服務器互為熱備，每臺服務器都擁有全數據，采用V/FTS技術實現同步復制。數據同時寫入兩個服務器，數據讀取可以在任意服務器上執行。V-Server（數據庫服務器）負責將數據對象讀出并發送到V-Client中；當進行數據寫操作時，V-Server檢查所有V-Server和Client中的數據，對受影響的數據對象加寫鎖，當寫操作完成后，將新的數據對象同步到其他V-Server和Client中。2臺數據庫服務器互為熱備的部署在單點失效時自動將應用切換到另一節點上；等失效節點恢復后自動追，直到兩臺服務器同步后自動切回初始狀態。因而在失效過程中不會丟失事務，保證了數據的安全性和一致性，整個系統實現零失效時間、7×24小時不間斷服務。

基于上述技術，實時數據平臺原型實現了非常好的性能。壓力測試給出的結果，在單線程下對復雜對象（SuperPNR）的寫入和查詢都能獲得極高性能：

五、旅客服務系統實時數據平臺實現對結構化的復雜數據的靈活支持的探索

實時數據平臺處理的數據種類較多，每類數據都有各不相同的復雜數據結構。面向對象的方法論適用于處理復雜數據和業務邏輯。圖5是簡化的數據模型。其中藍色部分是代表航空公司和航班的對象，Airline對象是對航空公司的抽象，Flight

Number對象和FlightFrequency對象在業務上是找到航班In

ventory對象的索引，為了提高查詢效率，又引入了FlightDateI

dx對象。SuperPNR對象是主訂單，為了高效訪問，引入了5類索引對象，即PAXNameIdx、PAXIdIdx、PNRLocator、IATANum

berIdx和TicketNumberIdx對象。電子票票面ETicket和支付結算RAccouting對象是同一數據的兩種視圖，提供了SuperPNR、TicketNumber和國際航協結算號IATANumber三種查詢入口。

圖5 實時數據平臺的簡化數據結構

這種索引方式是根據業務需要，按照面向對象的設計方法自然形成的。因而在運行時并不需要為了提升性能設計專門的索引，如在關系數據庫中必須要做的。當這種結構化了的復雜數據對象直接進行持久化、存入對象數據庫，我們使用這種天然索引就可以快速找到這些對象，并用對象的方法（與數據庫無關，對象數據庫只保存對象屬性或稱為對象狀態，方法是面向對象方法提供的另一個重要概念）進行高效的數據分析和統計。在編寫這些方法的時候，我們參考了OLTP系統中已有的代碼邏輯，這進一步縮短了開發和測試時間，提升了開發質量。

引入對象數據庫的另一個好處是數據Scheme可以在運行時進行修改。由于對象數據庫的scheme就是類圖，當類修改（對象屬性的增刪改）時數據scheme會跟著發生變化。Versant提供的一種機制可以讓不同版本的scheme同時存在，并在運行時修改scheme。當Server上的scheme成為新版本，Client內存中的數據仍然使用老版本。當內存中的數據超時purge之后，再次裝入的數據就已經是新版本了。這個方案提供了兩個能力，首先修改數據結構輕而易舉，當業務要求增加或改變任何字段時，只需要修改類，持久層是自適應的；其次由于數據修改不需要停機，如同時采用Java語言開發（我們就是這么做的），就可以做到應用程序更新、上線不停機，這樣能夠為客戶提供真正永不下線的服務。

上述技術不僅實現復雜數據結構化的存儲，也使持久層得到了巨大的靈活性，這使得應用系統也獲得了相當的靈活性。

六、旅客服務系統實時數據平臺實現海量數據的高效存儲

作為OLAP系統，實時數據平臺不僅需要實時同步來自OLTP的數據，還必須保留已經結束生命周期的數據。目前我們的實時數據平臺原型為國內某大型航空集團保留的數據量大致估算為：

上表中估算的數據量都是基于最頂層的數據對象進行的，這三類對象每一種都由數百甚至上千子對象組合而成，實際的存儲量是驚人的。實時數據平臺基于Versant提供的分布式對象管理機制，實現將不同類型的數據對象存入不同的數據庫中，而對應用服務器透明。這種能力就是通常在關系數據庫中的“分表分庫”操作。圖7是對該機制的簡單圖釋，數據對象A、

B、C、D在應用中（Client）是相關的，它們之間的關系由“對象管理器”維護，而在后臺數據對象實際存儲在不同的數據庫中，同時可以在幾個數據庫之中遷移。需要說明的是，對象管理器中對象關系模型需要由應用程序開發人員開發和維護。

圖6 分布式對象存儲

七、實時數據平臺在航空收益輔助中的作用方式和意義

技術上的創新可能會對業務系統的發展帶來革命性的影響，利用已經實現的高性能實時數據平臺，原有的一些看起來不太可能實現的業務需求現在已經成為可能。而新的業務必然會幫助航空公司提升服務質量，并且在激烈競爭中獲得領先地位。本文就已經相對比較成熟的場景進行了總結，也同時對實時數據平臺建設的意義進行再次確認。

應用場景一：實時自動清票。自動出票時限是依據航空公司設定的業務規則，在訂單生成時自動加入的。OLTP系統在夜間定時掃描所有訂單，將第二天到期的訂單編號記錄在一個數據表中，然后定時掃描（通常是每小時）該數據表及訂單內容，發現過期或已過期未支付出票的訂單，自動釋放被占用座位。這種解決方案的缺點顯而易見，一是因清票不及時會影響座位的再次銷售；二是集中消耗大量系統資源造成系統運行緩慢。最壞情況下過期一個多小時后才能清票，在旺季給航空公司造成大量收益損失。

在實時數據平臺環境中，當接收到同步的SuperPNR對象后，調用HasTimeLimit（）方法，如果對象中有“出票時限”項，則根據時限將對象指針插入一個有序鏈表。同時后臺有定時器，每分鐘從頭遍歷鏈表，將上一分鐘的鏈表節點移出，依次對鏈表頭上時限為當前這一分鐘的訂單對象進行處理。如果需要清票，則調用OLTP系統提供的座位釋放API，以訂單編號為參數完成清票操作。這樣使清票操作的實時性提升到分鐘級，最壞情況下延遲僅1分鐘，完全封堵了航空公司這方面的收益漏洞；同時OLTP系統不再需要掃描全數據庫，節省了昂貴的處理器資源；而整個開發投入非常少。目前該應用已經投入實際使用。

應用場景二：航班銷售監控和預警。OLTP系統雖然能夠處理銷售交易，但對于整個銷售過程中出現的異常狀況（指和收益管理系統的預測不符合的情況，如短時間內大量預訂或取消）無能為力。我們基于實時數據平臺，開發了航班銷售和預警模塊。該模塊的輸入是來自收益管理系統的預測曲線，包括全市場和目標航空公司的。當實際銷售曲線和預測曲線出現超出預定值的偏差時，可通過幾種方式通知銷售管控人員，以便后者進行銷售規則的調整。通知的方式包括客戶端彈出對話框、手機短信息以及電子郵件。該應用能夠有效幫助航空公司銷售實現管理精細化，快速對市場變化做出反映，是航空公司提升銷售的利器。

應用場景三：假票號驗證。有時代理人為了規避航空公司設定的自動出票時限業務規則，會輸入假票號。在OLTP系統中，甄別假票號是一件比較困難、高成本的事情。我們基于實時數據平臺開發了訂單中假票號的驗證功能，利用電子票票面數據和結算數據，在訂單中加入票號的時候對其進行校驗，并將假票號訂單報告出來，供航空公司業務人員進行手工或自動批量處理。目前國內市場上已經基本實現全電子票（ET），并大力推廣附加服務銷售的電子雜費單（EMD）應用，因而假票號校驗功能應用前景非常廣闊。

八、結論與展望

本文主要探討了實時數據應用平臺實現方面遇到的各種問題，以及如何基于對象數據庫和面向對象方法來以相對很低的成本實現系統的高性能、高穩定性、復雜數據結構化后存儲，同時還討論了海量數據存儲的高效解決方案。作為驗證，我們已經實現了一個原型系統，為航空公司提供了幾個有效應用，幫助航空公司提升收益，確實收到了良好的效果。

未來我們將基于該原型系統，一方面擴展數據種類，比如加入航班計劃（Schedule）數據；另一方面開發更多的服務接口，支持更多應用。在應用方面，我們可以支持航空公司CRM系統，為CRM系統提供旅客行程歷史，分析旅客價值等；支撐收益輔助（Revenue Integrity）系統，持續幫助提升航空公司收益。同時可以基于服務接口開發航空公司個性化應用，因為整個系統具有非常好的可擴展性和靈活性。另外，原型系統中使用的仍然是商業數據庫軟件，我們計劃試驗整套解決方案中底層數據庫的可替代性，使用開源數據解決方案（memcacheredis）進行兩個方案下的性能、成本、穩定性、靈活性對比，從而為進一步降低系統的成本進行探索。

參 考 文 獻

[1][美]AbrahamSilberschatz HenryF.Korth S.Sudarshan 楊冬青，唐世渭等譯.數據庫系統概念[M].北京：中國機械工業出版社，2000

[2]李磊.基于范式的查詢公式求值和優化算法[J].計算機工程.2000

[3][美]D.Solomon R.Rankins 熊桂喜，高峰，馮學民譯.Microsoft SQL

Server開發指南[M].北京：清華大學出版社，1998

[4]張在建.數據庫查詢優化技術[J].計算機學報.1999