论文部分内容阅读
【摘 要】航空公司在销售和服务领域使用的旅客服务系统（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）系统，持续帮助提升航空公司收益。同时可以基于服务接口开发航空公司个性化应用，因为整个系统具有非常好的可扩展性和灵活性。另外，原型系统中使用的仍然是商业数据库软件，我们计划试验整套解决方案中底层数据库的可替代性，使用开源数据解决方案（memcache&redis）进行两个方案下的性能、成本、稳定性、灵活性对比，从而为进一步降低系统的成本进行探索。
参 考 文 献
[1][美]AbrahamSilberschatz HenryF.Korth S.Sudarshan 杨冬青，唐世渭等译.数据库系统概念[M].北京：中国机械工业出版社，2000
[2]李磊.基于范式的查询公式求值和优化算法[J].计算机工程.2000
[3][美]D.Solomon R.Rankins 熊桂喜，高峰，冯学民译.Microsoft SQL
Server开发指南[M].北京：清华大学出版社，1998
[4]张在建.数据库查询优化技术[J].计算机学报.1999
【关键词】航空公司；收益辅助；实时数据分析；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）系统，持续帮助提升航空公司收益。同时可以基于服务接口开发航空公司个性化应用，因为整个系统具有非常好的可扩展性和灵活性。另外，原型系统中使用的仍然是商业数据库软件，我们计划试验整套解决方案中底层数据库的可替代性，使用开源数据解决方案（memcache&redis）进行两个方案下的性能、成本、稳定性、灵活性对比，从而为进一步降低系统的成本进行探索。
参 考 文 献
[1][美]AbrahamSilberschatz HenryF.Korth S.Sudarshan 杨冬青，唐世渭等译.数据库系统概念[M].北京：中国机械工业出版社，2000
[2]李磊.基于范式的查询公式求值和优化算法[J].计算机工程.2000
[3][美]D.Solomon R.Rankins 熊桂喜，高峰，冯学民译.Microsoft SQL
Server开发指南[M].北京：清华大学出版社，1998
[4]张在建.数据库查询优化技术[J].计算机学报.1999