高性能實(shí)時(shí)數(shù)據(jù)分析平臺(tái)在航空公司收益提升中的應(yīng)用

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

【關(guān)鍵詞】航空公司；收益輔助；實(shí)時(shí)數(shù)據(jù)分析；ODBMS，NoSQL

一、前言

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

隨著民航市場(chǎng)競(jìng)爭(zhēng)日益激烈、民航業(yè)務(wù)日趨復(fù)雜，航空公司旅客服務(wù)系統(tǒng)在提供高性能交易處理的同時(shí)，還需要對(duì)歷史數(shù)據(jù)進(jìn)行分析和挖掘，為航空公司業(yè)務(wù)人員提供決策支持的能力，甚至通過業(yè)務(wù)規(guī)則引擎自動(dòng)完成決策，實(shí)現(xiàn)商業(yè)智能化。這就要求旅客服務(wù)系統(tǒng)在提供OLTP功能的同時(shí)，還要支持

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

國(guó)內(nèi)航空市場(chǎng)是一個(gè)激烈競(jìng)爭(zhēng)的市場(chǎng)，航空公司不僅需要線下的決策支持能力，還要求實(shí)時(shí)的決策支持能力。本文的目標(biāo)是給出一個(gè)滿足航空公司實(shí)時(shí)決策支持的在線數(shù)據(jù)分析平臺(tái)，幫助航空公司在瞬息萬(wàn)變的市場(chǎng)上搶得先機(jī)。此時(shí)業(yè)務(wù)模型見圖2，實(shí)時(shí)數(shù)據(jù)平臺(tái)處于交易處理系統(tǒng)和數(shù)據(jù)倉(cāng)庫(kù)之間，為航空公司業(yè)務(wù)人員提供只讀的實(shí)時(shí)數(shù)據(jù)分析和統(tǒng)計(jì)匯總能力。

二、實(shí)時(shí)數(shù)據(jù)平臺(tái)需要解決的主要問題

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

三、旅客服務(wù)系統(tǒng)面臨困難的具體分析

數(shù)據(jù)規(guī)模、數(shù)據(jù)結(jié)構(gòu)在類似旅客服務(wù)系統(tǒng)這樣的信息服務(wù)系統(tǒng)中可能會(huì)非常龐大。我們以兩種主要數(shù)據(jù)樣本，描述整體的數(shù)據(jù)規(guī)模情況。

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

圖3 簡(jiǎn)化的訂單對(duì)象

為了解決在復(fù)雜數(shù)據(jù)結(jié)構(gòu)和大容量的條件下，仍然要實(shí)現(xiàn)高性能的問題，我們?cè)囉昧薔oSQL的對(duì)象數(shù)據(jù)庫(kù)。通過多方評(píng)測(cè)我們知道，對(duì)象數(shù)據(jù)庫(kù)能夠同時(shí)在數(shù)據(jù)復(fù)雜性、數(shù)據(jù)容量和并發(fā)性三個(gè)緯度上取得平衡。在傳統(tǒng)系統(tǒng)中，數(shù)據(jù)持久化基本采用關(guān)系模型。在單表查詢時(shí)，關(guān)系數(shù)據(jù)庫(kù)可以獲得極好的性能。但當(dāng)數(shù)據(jù)結(jié)構(gòu)變復(fù)雜，關(guān)系模型必須引入關(guān)聯(lián)查詢，此時(shí)性能隨著關(guān)聯(lián)層級(jí)增加呈指數(shù)下降。我們需要處理的三類數(shù)據(jù)都有8～10級(jí)繼承，如果將它們關(guān)系化為二維表，勢(shì)必造成多層級(jí)關(guān)聯(lián)。如果采用單個(gè)二維表存儲(chǔ)并建大量索引優(yōu)化性能，會(huì)面臨兩個(gè)無法解決的問題，即每個(gè)表都有數(shù)千字段和大量數(shù)據(jù)冗余，都造成修改和維護(hù)困難，查詢效率底的問題。如果不對(duì)數(shù)據(jù)對(duì)象做結(jié)構(gòu)化，而是將整個(gè)數(shù)據(jù)對(duì)象作為Blob存儲(chǔ)，就無法對(duì)目標(biāo)數(shù)據(jù)進(jìn)行靈活查詢；此時(shí)每增加一類查詢應(yīng)用，都需要從Blob中結(jié)構(gòu)化出相關(guān)字段（對(duì)象屬性），放入二維表。當(dāng)支持所有類型的查詢時(shí)，就需要從Blob中結(jié)構(gòu)化出所有字段（對(duì)象屬性）。實(shí)際上我們發(fā)現(xiàn)在具體實(shí)踐中也確實(shí)是這樣進(jìn)行設(shè)計(jì)的。另一方面，現(xiàn)今絕大多數(shù)程序開發(fā)都采用面向?qū)ο竽Ｐ停绻４鏀?shù)據(jù)到關(guān)系型數(shù)據(jù)庫(kù)，就需要在運(yùn)行時(shí)在對(duì)象模型和關(guān)系模型之間進(jìn)行轉(zhuǎn)換，即OR Mapping。對(duì)象-關(guān)系轉(zhuǎn)換會(huì)消耗大量處理器時(shí)間，降低系統(tǒng)的整體性能。雖然目前Hibernate等框架可以提升OR Mapping的編程效率，但無法解決OR

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

四、旅客服務(wù)系統(tǒng)實(shí)時(shí)數(shù)據(jù)平臺(tái)實(shí)現(xiàn)高性能和高可靠性的探索

圖4 Versant數(shù)據(jù)庫(kù)的多層架構(gòu)

實(shí)時(shí)數(shù)據(jù)平臺(tái)采用與主系統(tǒng)相同的多層架構(gòu)，從下往上依次是數(shù)據(jù)庫(kù)服務(wù)器（Database Server），應(yīng)用服務(wù)器（Applica

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

由于實(shí)時(shí)數(shù)據(jù)平臺(tái)向外提供服務(wù)的方式大部分為Web

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

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

基于上述技術(shù)，實(shí)時(shí)數(shù)據(jù)平臺(tái)原型實(shí)現(xiàn)了非常好的性能。壓力測(cè)試給出的結(jié)果，在單線程下對(duì)復(fù)雜對(duì)象（SuperPNR）的寫入和查詢都能獲得極高性能：

五、旅客服務(wù)系統(tǒng)實(shí)時(shí)數(shù)據(jù)平臺(tái)實(shí)現(xiàn)對(duì)結(jié)構(gòu)化的復(fù)雜數(shù)據(jù)的靈活支持的探索

實(shí)時(shí)數(shù)據(jù)平臺(tái)處理的數(shù)據(jù)種類較多，每類數(shù)據(jù)都有各不相同的復(fù)雜數(shù)據(jù)結(jié)構(gòu)。面向?qū)ο蟮姆椒ㄕ撨m用于處理復(fù)雜數(shù)據(jù)和業(yè)務(wù)邏輯。圖5是簡(jiǎn)化的數(shù)據(jù)模型。其中藍(lán)色部分是代表航空公司和航班的對(duì)象，Airline對(duì)象是對(duì)航空公司的抽象，F(xiàn)light

Number對(duì)象和FlightFrequency對(duì)象在業(yè)務(wù)上是找到航班In

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

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

berIdx和TicketNumberIdx對(duì)象。電子票票面ETicket和支付結(jié)算RAccouting對(duì)象是同一數(shù)據(jù)的兩種視圖，提供了SuperPNR、TicketNumber和國(guó)際航協(xié)結(jié)算號(hào)IATANumber三種查詢?nèi)肟凇?/p>

圖5 實(shí)時(shí)數(shù)據(jù)平臺(tái)的簡(jiǎn)化數(shù)據(jù)結(jié)構(gòu)

這種索引方式是根據(jù)業(yè)務(wù)需要，按照面向?qū)ο蟮脑O(shè)計(jì)方法自然形成的。因而在運(yùn)行時(shí)并不需要為了提升性能設(shè)計(jì)專門的索引，如在關(guān)系數(shù)據(jù)庫(kù)中必須要做的。當(dāng)這種結(jié)構(gòu)化了的復(fù)雜數(shù)據(jù)對(duì)象直接進(jìn)行持久化、存入對(duì)象數(shù)據(jù)庫(kù)，我們使用這種天然索引就可以快速找到這些對(duì)象，并用對(duì)象的方法（與數(shù)據(jù)庫(kù)無關(guān)，對(duì)象數(shù)據(jù)庫(kù)只保存對(duì)象屬性或稱為對(duì)象狀態(tài)，方法是面向?qū)ο蠓椒ㄌ峁┑牧硪粋€(gè)重要概念）進(jìn)行高效的數(shù)據(jù)分析和統(tǒng)計(jì)。在編寫這些方法的時(shí)候，我們參考了OLTP系統(tǒng)中已有的代碼邏輯，這進(jìn)一步縮短了開發(fā)和測(cè)試時(shí)間，提升了開發(fā)質(zhì)量。

引入對(duì)象數(shù)據(jù)庫(kù)的另一個(gè)好處是數(shù)據(jù)Scheme可以在運(yùn)行時(shí)進(jìn)行修改。由于對(duì)象數(shù)據(jù)庫(kù)的scheme就是類圖，當(dāng)類修改（對(duì)象屬性的增刪改）時(shí)數(shù)據(jù)scheme會(huì)跟著發(fā)生變化。Versant提供的一種機(jī)制可以讓不同版本的scheme同時(shí)存在，并在運(yùn)行時(shí)修改scheme。當(dāng)Server上的scheme成為新版本，Client內(nèi)存中的數(shù)據(jù)仍然使用老版本。當(dāng)內(nèi)存中的數(shù)據(jù)超時(shí)purge之后，再次裝入的數(shù)據(jù)就已經(jīng)是新版本了。這個(gè)方案提供了兩個(gè)能力，首先修改數(shù)據(jù)結(jié)構(gòu)輕而易舉，當(dāng)業(yè)務(wù)要求增加或改變?nèi)魏巫侄螘r(shí)，只需要修改類，持久層是自適應(yīng)的；其次由于數(shù)據(jù)修改不需要停機(jī)，如同時(shí)采用Java語(yǔ)言開發(fā)（我們就是這么做的），就可以做到應(yīng)用程序更新、上線不停機(jī)，這樣能夠?yàn)榭蛻籼峁┱嬲啦幌戮€的服務(wù)。

上述技術(shù)不僅實(shí)現(xiàn)復(fù)雜數(shù)據(jù)結(jié)構(gòu)化的存儲(chǔ)，也使持久層得到了巨大的靈活性，這使得應(yīng)用系統(tǒng)也獲得了相當(dāng)?shù)撵`活性。

六、旅客服務(wù)系統(tǒng)實(shí)時(shí)數(shù)據(jù)平臺(tái)實(shí)現(xiàn)海量數(shù)據(jù)的高效存儲(chǔ)

作為OLAP系統(tǒng)，實(shí)時(shí)數(shù)據(jù)平臺(tái)不僅需要實(shí)時(shí)同步來自O(shè)LTP的數(shù)據(jù)，還必須保留已經(jīng)結(jié)束生命周期的數(shù)據(jù)。目前我們的實(shí)時(shí)數(shù)據(jù)平臺(tái)原型為國(guó)內(nèi)某大型航空集團(tuán)保留的數(shù)據(jù)量大致估算為：

上表中估算的數(shù)據(jù)量都是基于最頂層的數(shù)據(jù)對(duì)象進(jìn)行的，這三類對(duì)象每一種都由數(shù)百甚至上千子對(duì)象組合而成，實(shí)際的存儲(chǔ)量是驚人的。實(shí)時(shí)數(shù)據(jù)平臺(tái)基于Versant提供的分布式對(duì)象管理機(jī)制，實(shí)現(xiàn)將不同類型的數(shù)據(jù)對(duì)象存入不同的數(shù)據(jù)庫(kù)中，而對(duì)應(yīng)用服務(wù)器透明。這種能力就是通常在關(guān)系數(shù)據(jù)庫(kù)中的“分表分庫(kù)”操作。圖7是對(duì)該機(jī)制的簡(jiǎn)單圖釋，數(shù)據(jù)對(duì)象A、

B、C、D在應(yīng)用中（Client）是相關(guān)的，它們之間的關(guān)系由“對(duì)象管理器”維護(hù)，而在后臺(tái)數(shù)據(jù)對(duì)象實(shí)際存儲(chǔ)在不同的數(shù)據(jù)庫(kù)中，同時(shí)可以在幾個(gè)數(shù)據(jù)庫(kù)之中遷移。需要說明的是，對(duì)象管理器中對(duì)象關(guān)系模型需要由應(yīng)用程序開發(fā)人員開發(fā)和維護(hù)。

圖6 分布式對(duì)象存儲(chǔ)

七、實(shí)時(shí)數(shù)據(jù)平臺(tái)在航空收益輔助中的作用方式和意義

技術(shù)上的創(chuàng)新可能會(huì)對(duì)業(yè)務(wù)系統(tǒng)的發(fā)展帶來革命性的影響，利用已經(jīng)實(shí)現(xiàn)的高性能實(shí)時(shí)數(shù)據(jù)平臺(tái)，原有的一些看起來不太可能實(shí)現(xiàn)的業(yè)務(wù)需求現(xiàn)在已經(jīng)成為可能。而新的業(yè)務(wù)必然會(huì)幫助航空公司提升服務(wù)質(zhì)量，并且在激烈競(jìng)爭(zhēng)中獲得領(lǐng)先地位。本文就已經(jīng)相對(duì)比較成熟的場(chǎng)景進(jìn)行了總結(jié)，也同時(shí)對(duì)實(shí)時(shí)數(shù)據(jù)平臺(tái)建設(shè)的意義進(jìn)行再次確認(rèn)。

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

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

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

應(yīng)用場(chǎng)景三：假票號(hào)驗(yàn)證。有時(shí)代理人為了規(guī)避航空公司設(shè)定的自動(dòng)出票時(shí)限業(yè)務(wù)規(guī)則，會(huì)輸入假票號(hào)。在OLTP系統(tǒng)中，甄別假票號(hào)是一件比較困難、高成本的事情。我們基于實(shí)時(shí)數(shù)據(jù)平臺(tái)開發(fā)了訂單中假票號(hào)的驗(yàn)證功能，利用電子票票面數(shù)據(jù)和結(jié)算數(shù)據(jù)，在訂單中加入票號(hào)的時(shí)候?qū)ζ溥M(jìn)行校驗(yàn)，并將假票號(hào)訂單報(bào)告出來，供航空公司業(yè)務(wù)人員進(jìn)行手工或自動(dòng)批量處理。目前國(guó)內(nèi)市場(chǎng)上已經(jīng)基本實(shí)現(xiàn)全電子票（ET），并大力推廣附加服務(wù)銷售的電子雜費(fèi)單（EMD）應(yīng)用，因而假票號(hào)校驗(yàn)功能應(yīng)用前景非常廣闊。

八、結(jié)論與展望

本文主要探討了實(shí)時(shí)數(shù)據(jù)應(yīng)用平臺(tái)實(shí)現(xiàn)方面遇到的各種問題，以及如何基于對(duì)象數(shù)據(jù)庫(kù)和面向?qū)ο蠓椒▉硪韵鄬?duì)很低的成本實(shí)現(xiàn)系統(tǒng)的高性能、高穩(wěn)定性、復(fù)雜數(shù)據(jù)結(jié)構(gòu)化后存儲(chǔ)，同時(shí)還討論了海量數(shù)據(jù)存儲(chǔ)的高效解決方案。作為驗(yàn)證，我們已經(jīng)實(shí)現(xiàn)了一個(gè)原型系統(tǒng)，為航空公司提供了幾個(gè)有效應(yīng)用，幫助航空公司提升收益，確實(shí)收到了良好的效果。

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

參 考 文 獻(xiàn)

[1][美]AbrahamSilberschatz HenryF.Korth S.Sudarshan 楊冬青，唐世渭等譯.數(shù)據(jù)庫(kù)系統(tǒng)概念[M].北京：中國(guó)機(jī)械工業(yè)出版社，2000

[2]李磊.基于范式的查詢公式求值和優(yōu)化算法[J].計(jì)算機(jī)工程.2000

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

Server開發(fā)指南[M].北京：清華大學(xué)出版社，1998

[4]張?jiān)诮?數(shù)據(jù)庫(kù)查詢優(yōu)化技術(shù)[J].計(jì)算機(jī)學(xué)報(bào).1999