问题背景

对于商旅用户而言，通过商旅系统进行酒店预订时，都希望酒店预订体验良好。并且商旅用户通过预订页面进行酒店预订时希望所见即所得（也就是说，所看见的酒店相关信息就是用户最终预订的结果），包括能查得到酒店相关信息、酒店报价正确、差旅产品信息实时更新等。

然而现实情况下，商旅用户在预订酒店时，经常出现下列问题：

所要预订的酒店查询不存在；

所要预订的酒店地址错误；

所要预订的酒店查询的价格与实际预订价格不一致；

所要预订的酒店房间不存在；

所要预订的酒店实际有房，但系统显示无房；或实际无房但显示有房。

本文基于上述问题背景，深入剖析问题发生背后的根本原因，从而给出一个比较全面完整的酒店数据治理解决方案。

酒店资源供应链

在深入剖析酒店问题背后的根本原因之前，我们先了解酒店供应链情况以及供应链上的各环节的系统对接链路。

如上图所示，上游为各酒店集团，作为供应商向下游提供酒店资源；中间为各酒店分销渠道，实现上下游连接，打通上下游酒店资源供应；下游主要为各类 OTA 旅游平台或商旅系统。

商旅平台在构建平台自身酒店资源池时，通常需要对接多家酒店供应商或酒店渠道分销平台，实现酒店聚合，统一对外提供酒店预订等服务。对于商旅平台来说，我们可以将这些酒店供应商和酒店渠道分销平台统称为酒店供应商。

对于这些渠道类别的酒店供应商，需要注意如下现实情况：

酒店资源可能存在重叠，同一家酒店可能被多家供应商提供；

不同的供应商的信息化建设水平不同；

渠道供应商也可能并非直连上游酒店供应商，也可能存在对接渠道供应商的情况；

不同的供应商酒店资源覆盖度、酒店丰富度不一样；

单店酒店资源可能由下游系统单独维护；

不同的供应商资源供应模式不一样。

正是因为上述现实情况的存在，终端用户在进行酒店预订时，容易发生各类系统体验问题。

酒店数据治理需求

对于企业商旅系统而言，一个很重要的特征就是，当用户在系统中选中某个酒店进入酒店详情页面后，系统会将不同供应商提供的预订信息（房型、房价等）通过列表形式聚合在一起展示给用户，为用户提供一站式实时比较预订服务，帮助用户快速找到性价比最高的供应商，形成良好酒店预订体验。

酒店聚合作为企业商旅系统中相关酒店业务实现的基础核心部分，会接入大量不同类型的供应商，从这些供应商拉取大量的酒店数据，并对这些数据进行整合。酒店聚合能力的强弱以及聚合结果的好坏（聚合成功率及数据准确率等），将直接影响终端用户体验。

从最上游酒店供应商，到用户终端，整个数据传输链路会经过全供应链路上不同的系统。结合前述酒店供应链的现实情况，对于酒店业务，我们主要需要关注如下几个指标：

酒店数据的完整性：对于酒店数据处理来说，我们需要完整地将各供应商所对外提供的数据完整的拉取到本地系统。否则，会导致用户在通过其他预订途径可以看见某个酒店，但在商旅终端系统无法查询到该酒店而无法预订该酒店。需要注意的是，有些情况需要排除在外：例如，有些酒店集团有价格保护或自留房型，官网或者指定平台房型最全、价格最低等等类似情况，可能其他平台或官网有酒店数据，但拉取到本地系统的酒店数据里出现房型没有或者价格偏高的情况。

酒店数据的准确性：酒店数据的准确性主要涉及的酒店标识和酒店房型。对于同一家酒店，不同供应商对该酒店和房型的描述可能存在偏差。如果在酒店聚合合并过程中出现错误，会导致用户在系统中看见的酒店不是实际想要预订的酒店，以至于在用户下单后，到店后发现酒店系统中无此订单，从而给用户带来很大的影响以及极差的体验。酒店房型合并亦是如此。

酒店数据的实时性：对于酒店数据的实时性，要求：

酒店房型数据及变化（房型开放/关闭等）能从源头酒店供应商通过渠道实时同步到用户终端；

酒店房态数据及变化（有房/无房）能从源头酒店供应商通过渠道实时同步到用户终端；

酒店房价及变化能从源头酒店供应商通过渠道实时同步到用户终端；要针对酒店房量（房型库存量）和房价。酒店房量及房价变化需要实时传递到用户终端。

酒店数据治理方案

方案目标

针对上述酒店问题分析，我们在给出解决方案之前，可设定如下方案目标：

确保供应商输出的酒店数据与本地拉取的数据保持一致性和完整性；

提高酒店合并数据处理结果的正确率和准确率到一个可接受程度；

所有的系统中产生的异常酒店数据均可归因为供应商本身的数据质量；

提供异常酒店数据人工处理通道；

酒店数据处理不影响运行时酒店相关业务系统。

解决方案

基于前述分析，酒店数据处理服务架构如下：

总体上，我们将酒店数据处理业务分为四个阶段：酒店数据拉取、酒店数据合并、异常数据修正、酒店数据上架。说明如下：

酒店数据拉取

本阶段，系统通过各供应商系统提供的数据接口以及数据对接规则，请求拉取供应商酒店数据，并缓存到本地系统，为后续酒店数据合并处理提供数据准备。对于供应商数据拉取，主要考虑几个关键问题：

数据拉取频率：每个供应商数据拉取频率，即多久拉取一次；

数据完整性保证：如何确保对于每个供应商每次拉取的数据是完整的；

数据差异处理：对于每个供应商，如何处理每次拉取的数据与上次拉取的数据之间的差异，并确保这些差异处理符合实际客观现实的；

数据拉取效率：供应商数据拉取的耗时；

数据拉取异常：如何处理数据拉取异常，如何设计数据拉取异常机制；

异常数据处理：数据拉取过程中如何识别异常数据，如何存储异常数据，如何处理异常数据。也即，酒店数据处理需要制定合理的异常数据处理机制；

供应商对接规范与机制：不同的供应商一般设计不同的对接规范与机制。因此，每个供应商的接入都对应特定的对接程序；

供应商对接性能与限制：各供应商的系统建设水平层次不齐、对外提供的对接模式也不一样，对于下游系统而言，需要考量供应商的对接性能与限制，从而影响本地系统的性能与设计。

酒店数据合并

酒店数据合并处理的主要目标和要解决的关键问题是，如何确保数据合并正确与准确性。

酒店相关信息缺乏统一的国家或行业级数据标准，数据规范化程度差，不同的酒店供应商系统或平台都有自己的信息标准和数据存储方式（甚至于没有标准规范），酒店信息很多情况下都是个性化命名。正因如此，这些现实情况给酒店数据合并带来很大的难度；并且，通过系统算法进行合并处理几乎很难达到 100%的准确率，必须通过人工介入处理异常数据。

目前，酒店合并算法主要根据酒店所在城市、酒店名称、地址、电话、酒店坐标定位等属性作为合并依据，酒店的这些数据质量直接决定合并结果的好坏。从这些酒店属性的输入源头来看，酒店的相关属性信息主要靠人工录入和维护，也可能在整个酒店供应链的任何环节进行。既然数据源头是人工录入与维护，并且各个环节的数据检查与验证机制不一样，数据正确性保证水平层次不齐，不可避免会出现数据维护错误和数据不一致的情况。对于本身数据录入错误的情况（如 A 酒店的名称等相关属性与 B 酒店的相关属性的相似度很高，导致 A 酒店和 B 酒店合并为同一家酒店，导致用户下单之后，等到前台入住时被告知订单不存在），不是系统能处理的，必须人工干预；对于数据录入不一致的情况，这是酒店数据合并算法的主要和重点解决的问题。

对于酒店数据合并处理，主要考虑如下几个关键问题：

合并相关特征信息选择：需要确定哪些酒店属性作为合并算法的基础特征信息：一般情况下，某个酒店数据属性的特征性越强、越具有标识性，则该属性越适合作为合并的基础指标；

选择合适的合并算法：合适的合并算法能提高合并结果的正确率与准确率，甚至于提高合并效率、降低合并成本。对于基于标准数据规范的数据合并算法比较简单，而对于酒店数据合并，需要考量数据的文本语义相似度进行一轮或多轮处理。常见的相似度算法包括：欧式距离相似度算法、余弦相似度算法、皮尔逊相似度算法等。数据合并一般要经过数据预处理、数据合并处理、合并结果验证等几个步骤。另外，我们可以利用 AI 算法进行酒店数据合并；

合并数据预处理：合并前需要进行酒店数据预处理，提高合并算法的输入数据质量；

合并结果验证：合并后，如何验证酒店数据合并结果。如果无法验证或无法有效验证数据合并结果，就无法保证酒店数据合并的正确性和准确性，无法在用户发现问题前预先知晓到底哪些数据合并成功、哪些数据合并失败，大大降低用户满意度；

合并异常处理：如何处理数据合并过程中的异常现象，如何设计数据合并异常机制；

合并异常数据处理：合并过程中如何识别异常数据，如何存储异常数据，如何处理异常数据。也即，酒店数据处理需要制定合理的异常数据处理机制。

异常数据修正

如前所述，在酒店数据拉取及数据合并两阶段过程中，可能抛出各种异常酒店数据，这些异常数据程序本身无法处理，但这些异常酒店数据本身是客观存在的。面对此种情况，就需要对这些异常数据进行修正。异常数据修正可以通过纯人工干预处理，也可以通过人工干预与自动化程序处理相结合的方式进行数据修正。

现实情况下，酒店数据合并后会产生大量的异常数据，纯人工干预的成本比较高。异常数据的量主要依赖于合并算法的优劣，而合并算法的优劣又依赖于合理的合并结果验证算法，这几者之间环环相扣、互相影响。

异常数据修正主要的操作包括：

将未合并的酒店指向并合并到正确的酒店上；

核实酒店信息，并将错误的酒店信息修改正确；

删除错误的酒店数据；

添加正确的酒店数据；

记录异常数据处理日志，以便后续运营跟踪。

酒店数据上架

我们知道，任何商旅系统中的酒店业务功能的运行都基于酒店基础数据，酒店基础数据是酒店业务系统的核心。因此，每一轮的酒店数据处理都不能基于运行时的酒店基础数据进行处理；否则，会给酒店业务系统的稳定运行和用户的使用体验带来很大影响，甚至于灾难性影响。

酒店数据处理服务需要包括两个核心数据库，其中一个服务于运行时业务系统，另外一个服务于数据处理业务。当本轮数据处理完毕之后，通过明确的酒店数据上架，来将酒店业务系统切换到本轮数据处理后的酒店基础数据库上（此处数据切换机制可以根据实际情况来定，此处不再赘述）。

总之，酒店数据上架动作标志着：

本轮酒店数据系统处理完毕；

异常数据依据实际情况得到有效处理；

运营人员可以依据实际情况酌情上架最新酒店数据。

酒店数据架构设计

整个酒店数据处理服务数据架构逻辑如下图所示。酒店数据处理服务中供应商对接程序负责对接供应商系统并将供应商酒店数据拉取存储到本地对应供应商数据库；酒店合并处理程序负责酒店数据整理、合并等，将处理成功的数据存储到处理成功酒店数据池，将异常酒店数据存储到处理异常酒店数据池。对于异常酒店数据池里的数据，通过数据修正处理程序进行修正，并将修正好的酒店数据转储到处理成功酒店数据池。到此为止，整个酒店数据处理与酒店业务系统完全隔离，不影响业务系统的正常运行。运营人员可根据实际情况触发数据处理服务替换运行时酒店静态基础数据。

需要特别注意的是，这里所处理的数据指的是酒店静态基础数据。对于酒店房量、房态、房价等动态酒店数据需要实时从供应商获取。如前所述，酒店动态数据是否能做到实时反映到用户终端，本地系统的处理机制是一方面，更多地受制于上游整个酒店供应链上各环节的系统建设水平。很多情况下，酒店动态数据经过整个供应链路各个环节，到达用户终端，往往无法达到实时性要求。因此，通常情况下，下游系统越靠近上游，实时性越好，比如下游平台选择与酒店集团合作，实现酒店系统直连，能一定程度上保证酒店的数据动态（房价波动、房型库存量变化等）实时传递到下游系统。

一般，酒店动态传递到下游系统主要包括两种方式：

上游系统主动推送酒店动态给下游系统（前提是上游系统具备并对外开放酒店动态推送能力）；

下游系统主动定时从上游系统拉取酒店动态数据。第 2 种方式很难做到绝对实时性，需要观察收集酒店动态数据变化的概率，依据概率结果确定定时拉取的时间间隔，问题相对也比较复杂。现实情况下，依赖于不同的供应商系统情况，两种方式都存在。

酒店接入管理

酒店数据处理的第一个环节就是与供应商进行数据对接。由于不同的供应商系统提供的对接标准、对接模式、对接流程等都不一样，因此，每个供应商都需要单独对接。为了统一管理与酒店供应商之间的数据对接，并统一对内统一输出酒店数据，需要提供统一供应商接入管理模块、酒店标准资源接入接口、统一供应商对接配置管理等，具体设计如下：

酒店异常处理机制

如前所述，酒店数据处理过程中，我们需要确保整个数据处理过程按照设计预期完整执行。同时，我们也需要对整个数据处理过程进行全面监控，目的是为了确保最终的数据处理结果正确，不会对最终用户的使用体验产生影响。

整个酒店异常处理机制的设计主要为了解决三部分问题：

监控处理过程

监控处理过程是为了跟踪各个数据处理节点和处理任务，及时发现各处理任务中发生的异常，以便自动干预程序或人工及时介入处理，确保各处理任务不会中断。

监控异常数据

在整个酒店数据处理过程中，对于处理异常或处理失败的数据，通过异常数据监控，及时捕获处理并推送到异常酒店数据池，待后续修正处理等。

输出异常报告

一方面，我们需要监控分析整个酒店数据处理结果，以便及时发现问题与解决问题、以及持续优化酒店数据处理算法；另外一方面，酒店数据处理需要与供应商系统之间的协同，并且依赖于上游系统的数据质量以及数据对接机制，因此，对于监控发现的外部供应商问题，我们需要及时进行接洽解决问题。综上，酒店异常处理机制需要能输出异常报告。

写在最后

酒店业务应该是商旅平台构建中最复杂的一部分，无论从酒店资源供应量、供应链的复杂性、行业标准的缺乏性以及各环节信息化建设能力与建设水平的层次不齐等，导致构建商旅平台酒店相关业务系统呈现了其相关的复杂性和难度。

本文主要对商旅行业酒店业务相关问题进行了深入剖析，并针对这些问题给出了完整的酒店基础数据解决方案。在方案中完整展示了酒店数据处理的不同阶段所要关注的关键问题、要达成的目标、以及相应的解决方案，比较全面完整地解决酒店相关问题。