Airline Shopping [纯笔记] （1）
前言
航司的Shopping，尤其是直销渠道的Shopping，往往不同于OTA，例如携程，也不同于GDS，例如TTL。不仅仅是航班产品数量和组合等因素，更需要融入航司对于shopping的业务特征，乃至品牌运价的内容。
另外评定一个航司的Shopping引擎的优劣，不仅仅只是快和全，因为这个其实是个“伪命题”，因为其航班数量与OTA和GDS天壤之别，关键是要结合航司产品及内容品牌化诉求，将Shopping打造为航旅用户第一个能够感受到航司品牌的窗口。虽然IT技术的迅猛发展，从原来C/C++到现在MongoDB及Spark等，乃至云计算的使用，其实按理说应该极大的提升了Shopping的性能。但是技术增长的10年，航班、航线、市场、搜索喜好等等，也在发展，虽然其肯定不是几何的数字增长，但是其组合起来结构确实几何增长；与此同时依附于其上的运价、尤其是附加服务的丰富性，也造成某些实际情况下，技术还是赶不上业务的增长速度，技术人员只能说：不行，还是要减少组合之后的结果数量......
于此同时IATA NDC的Shopping Schema和实现接口，之前感觉也许真正给与了这个时代及未来的放之四海而皆准的红皮书。然而随着几年来不断的深入，和各个航司航企及自身参与的项目，都不断证明其确实是浓缩的大量的精华，而且标准化及国际化长度极高。但是其本质目标是提升分销能力，而非航司自身的直销或直接面向C端的能力。例如复杂及繁重的接口，从技术上就完全不适应C端的使用场景；同时Schema及数据契约上也无法满足真实的航司直销能力的提升和个性化，尤其是品牌化的应用；更重要的是其与真实C端用户的使用场景和“点”式的诉求还是有不少差距的。
在近期设计本司电商Shopping的时候，大量的进行了水平及垂直的多方对比，但是也无法优化及整理出一套优质的Shopping实现体系。但是仅此将堆积的知识点记录及分享出来，以期得到各类真诚的反馈并协助优化。
Shopping Ecosystem Blueprint（完善修订中）
以国内TTL为核心的航司航企及OTA等的Shopping基本如下图所示（注：部分环节还待修订及完善中），从航司航企特有应用系统之外，大量国际组织及航信Hosting的国外厂商产品涉足其中，构成一个复杂及极为个性化的动态数据及事务分布式系统。
但就TTL自身，其内部提供的各类数据，也不断在迭代，并为整个Shopping的交易提供基础。注：部分环节还待修订及完善中）
竞争&精准
航司/OTA/GDS等，都不是简单的把符合用户输入查询参数的航班及组合信息展示出来，其还要有优先级等排序等等诸多因素。
所以真正的竞争及精准，不是低价或者100%查询条件Match。而是首先满足查询参数的前提下，个性化的展示特殊意图的搜索结果、排序后的结果、乃至特殊过滤后的结果。同时更深层次需要预先感知用户的诉求，或根据客户能够提供的信息，去反馈其特殊关注的查询结果。谈到感知客户诉求，其实根本难于上青天，所以常规的办法就是事先细分旅客群体及出行诉求，为其建立针对性的搜索和搜索结果打包方式。例如常规有的Shopping有：Flight Shopping, Calendar Shopping, Trip Shopping, Vacation Shopping, Budget Shopping, Nearby Shopping, Theme Shopping等等，都是查询喜好或查询条件构成的查询行为。 但是不Guarantee。
所以即使结合NDC，我也暂时无法更优化和全新的规划及定义一个全面的Shopping API。只能根据C端的应用场景、使用诉求等等，构建一个一个针对性的个性化Shopping API Resource。同时也根据我司的产品，定义了Prediction Shopping这样的个性化Shopping API Resource。
但是确实参考了NDC的Schema。技术上虽然无法很容易的直接使用IATA的XML Schema去构造JSON Schema或者Swagger Contract，但是多多少少的参考XML Schema，手工去定义RESTful API的model contract，也还是可以的，只不过太手工，太低效了。
Shopping引擎
除去API的建设，更关键对于一般性的搜索，例如现代的OD Shopping。如何从设计、技术、业务上面融合，实现一整套航司自控的高效且精准的搜索引擎，其实是很难且耗时的任务。归结起来，现在基本有如下三类方案，将航班计划/航线网络规划、运价发布、OD Build之后的结果，逐步叠加AV及Fare，最后变为个性化的OD Shopping。
a) 清爽Pipeline式
简化及清洁化引擎流程，以单一Pipeline方式实现：
1) 输入航班计划/航线网络规划结果；
2) 经过一系列规则运算及叠加，并后续可以直接注入特定规则；
3) 获得最终OD Shopping结果。
结构很清晰，也隔离，一旦有新业务变化，就还是注入动态的规则，让规则序列化的流水执行。但是其浪费的是性能或很难去解决这样的性能问题。
并且其往往期望在规则环节，就包含航班共享、Interline、AV等数据规则的介入。这样在实际情况下，往往会极大的降低执行效率和执行时间。
b) 逐级经典式
航司航企大部分还是采用的根据业务的积累，将最基础的业务规则引入到数据拼接的环节之后，从原始航班计划/航线网络优化，构建第一层数据组合；然后再根据已有及能够预估的Shopping业务规则，注入到第一层数据的筛选，并最终得到一个准镜像全量OD组合信息。之后再接入航班动态进行准实时数据更新及修正。之后与AV及Fare数据进行两次经典融合。
预先构建的数据，可以认为是热启动的基础。后续的任何业务规则应用及过滤，以及最终C端的对接，都是在此基础上受益匪浅。
c) 算法优化式
倘若一个航司或业务方能够穷举及展望罗列全部业务规则，那如何高效的实现Shopping，其实交给专业的运筹优化/OR的专家及团队即可，其会根据数据的特征及各类业务规则，构建及实现最优的数据查询及组合算法模型，不仅仅最后得到正确的个性化诉求结果，更关键的是保障极高速的执行性能。
然而这个是痴人说梦，因为业务的准备不能一蹴而就，也无法合理及明智的预估未来。所以完全的算法优化，其实不存在的。但是实际过程中，将逐级警点式与OR优化融合，是存在可能的。即让数据的处理和流动架构化、Pipeline Staging化，但是将高速运算的环节用全新的技术来支撑，但是将OR用于其中去解决完全取决于业务及数据运算性能的因素。
评定标准
正如上述所诉，评定一个航司的Shopping引擎的优劣，不仅仅且也不能只是快和全，因为其航班数量与OTA和GDS天壤之别，关键是要结合航司产品及内容品牌化诉求，将Shopping打造为航旅用户第一个能够感受到航司品牌的窗口。
然而这需要航司电商业务部门及团队，需要实现将优化查询条件实现定义；技术团队在实现的过程中根据执行效能及运行性能等，综合考虑对应的优化查询条件在何时在何地在怎样调用顺序下，调整业务的实现环节和因素。
总结
Shopping不仅仅是需要高质量及高速的数据输入，例如ATPCO的Fare数据、Inventory之后的AV数据、最即时的航班动态，更需要业务的预先输入及展望分析，才能将最合适的IT技术用于实现高效及个性化的旅客诉求满足。
