rabbit-obsidian/.trash/work/ctrip/汇报.md

1.1 底层模型重塑，讲如何从模型上划分供应商-物理模型；

1.2 底层模型重塑，讲如何从字段上梳理废弃字段，精简模型；

1.3 总结收益；

2.1 搭建原始库，国内海外架构统一；

2.2 搭建原始库，助力业务接入，八大内资集团特有字段；

3.1 搭建统一数据服务，统一查询范式： kv，需要自建索引，然后抽象出两套方案：kv，全量增量构建；

3.2 具体的技术架构，如何保证数据服务多存储的数据一致性；如何保证增量并发问题，如何解决全量数据空洞问题

大家好，今天和大家汇报我们在静态信息国际化重塑项目上取得的一些关键进展。 首先简单和大家介绍一下酒店信息是什么，是酒店业务的底座模型，包含酒店的核心信息，房型名称图片等等。信息直接使用方高达600多，8条业务线。 随着集团出海战略的深入推进，原有的静态信息基础设施难以支撑未来的业务，暴露出一系列问题和挑战。右侧这个图可以简单看一下之前的问题： 这是一家ctrip上售卖的海外酒店，但是它的房型名称是英文的，多语言覆盖不全。其次房型的首图没有明显的体现房型的特征，首图质量不高。总结下来主要有以下三个问题：

1. 基础设施陈旧，整体效能低下：无论是多语言体系的翻译和管理、图库系统的图片处理与分发、还是优选系统的数据清洗与决策，都存在大量历史包袱、技术债以及由此导致的低效。尤其是母子酒店模型的耦合导致外部资源对接困难，开发周期长、上云成本高的问题。
2. 接下来两个问题是信息覆盖率和准确性低的问题：在海外市场拓展中，我们面临着“信息少、准确性低”的窘境。多语言覆盖不全、内容准确性不足、图片质量缺失、参差不齐等问题，严重影响了国际用户的预订转化和整体体验。

这些问题相互交织，共同构成了我们国际化道路上的巨大阻碍。面对如此盘根错节的挑战，我们开启了一系列的针对国际化战略的优化——包含多语言翻译的智能化、优选逻辑的精准化、投诉流程的效率提升，这些项目之前在其它会议上汇报过了。本次我们针对底层模型的精简整合、架构统一、原始库拆分；以及图库重建、向量能力的搭建和应用进行汇报。

今天，我将首先聚焦于底层模型和架构改造方面的进展，与大家深入探讨我们是如何应对挑战、进行技术选型和取得的显著成效。

“底层模型”是酒店、房型等核心信息承载的业务实体，是物理存储和外部访问的组织形式，是所有上层应用和数据处理的基石。

1.1 旧模型的三大核心痛点：为何必须重塑？

1. 上云成本高：过去，核心模型将“物理酒店”与“供应商酒店”的概念高度耦合。这种设计导致了极高的复杂度和维护成本，更关键的是，可扩展性极差。每当有新的业务需求或数据维度需要引入时，都可能牵一发而动全身，敏捷性严重不足。并且供应商信息与物理信息混杂，核心表记录数高达数亿行，其中随着业务发展，近一半字段已废弃。不仅浪费了大量存储资源，而且显著推高了上云成本。

2. 国内海外架构不统一，系统日益复杂：由于历史原因，国内业务和海外业务在数据存储、更新链路上存在诸多差异，未能形成统一的架构。这种国内海外架构不统一的局面，导致系统逻辑越来越复杂，维护成本和风险持续走高。

3. 外部资源对接困难，响应迟缓：高度耦合的内部模型，使得外部新资源的对接（尤其是多样化的海外供应商、新兴渠道）变得异常困难和低效，难以快速响应市场变化。

1.2 模型层面的战略分离：供应商模型 vs. 物理模型

• 核心思路：针对“模型耦合”和“外部资源对接困难”的问题，我们将代表“交易品规”的物理酒店/物理房型（我们的平台实体）与代表原始供给的供应商酒店/供应商房型（供应商实体）**从模型层面进行彻底解耦。

• 具体做法：

• 平台实体（物理模型）：聚焦于C端用户展现和交易所需的核心、标准、干净的信息。力求精简、稳定。

• 供应商实体（供应商模型）：完整保留供应商提供的原始信息，适应其多样性。

• 价值：简化C端模型，提升清晰度和可维护性，为后续差异化治理和灵活对接外部资源打下基础。

1.3 字段层面的整合 针对“数据冗余”和“模型复杂”问题，我们对近500个字段进行了逐一梳理：

• 下线废弃字段：坚决下线了大量因业务下线、功能迁移而已无实际业务承载的字段，例如酒店模型中的“环境描述”、“菜系”等。本次共计下线了282个无效字段。
• 合并重复字段：对于含义相近或重复的字段进行了整合，例如将UsedName、HotelSearchName、HotelNameAbbreviation、ShortName等一系列酒店别名进行了统一。
• 剥离可推导字段：对于可以通过其他字段计算或推导得出的信息，如PinyinHead（酒店名称拼音首字母），不再在核心底表冗余存储，减少存储压力。
• 整合过度拆分的表：例如，历史上为酒店与景区的多对多关系单独建表，而实际上参考文档型存储思路，可以将景区信息整合至酒店的某个属性字段中，简化了关联查询。

1.3 模型重塑的核心收益总结

• 提升研发效率与可维护性：开发人员面对的是更清晰、更少冗余的模型，理解成本降低，新需求开发和问题排查的效率得到提升。酒店核心表数量从23张锐减至9张，字段数从578个精简到282个。 降低废弃字段排查的时间。
• 大幅降低存储成本：最直接的体现是线上核心数据库存储减少了6.6TB，降幅高达82%。相关的Redis缓存占用也相应大幅下降（例如，从4.6TB降至0.4TB）。这不仅直接降低了私有云的运营成本，更为上云战略清除了一个重要的成本障碍。

2. 搭建原始库：统一纳管原始数据，驱动业务创新

在模型拆分的基础上，我们构建了独立的“原始信息库”，专门用于承载和管理来自各个供应商的原始数据。

模型拆分后，我们构建了独立的“原始信息库”。

2.1 国内海外统一架构，提升扩展与维护性

• 技术选型：KV存储与灵活Schema：

• 原始库核心存储采用KV（Key-Value）存储方案。

• 其高吞吐特性满足海量数据写入需求；灵活Schema则完美适应了国内外供应商数据结构各异的现状，使我们无需为不同区域、不同类型的供应商频繁变更表结构，从而以较低成本实现了架构的统一。

• 价值：显著降低了接入新数据源（尤其是海外数据源）的复杂度和维护成本，提升了系统的整体扩展能力。

• 统一的逻辑架构：原始库的设计理念是构建一个能够统一纳管国内、海外各类供应商原始信息的中央存储。这意味着无论是来自国际大型GDS、OTA，还是国内特定供应商，其原始数据都能以一种相对标准化的方式接入和管理。 [cite: 18]

• KV存储与灵活Schema：考虑到供应商数据海量（亿级别）、结构多样、更新频繁以及查询场景相对简单的特点，原始库的核心存储采用了KV（Key-Value）存储方案（如RocksDB）。 [cite: 1, 18] 这种方案：

• 高吞吐：能够满足大规模数据写入和简单查询的性能需求。 [cite: 18]

• 灵活Schema：KV存储对数据结构的要求更为灵活，便于我们快速接入不同供应商的异构数据，而无需频繁变更严格的表结构。这为“国内海外统一架构”提供了技术可行性，因为不同区域、不同类型的供应商其数据字段和格式差异巨大。 [cite: 18]

• 低维护成本：统一的接入层和标准化的内部处理流程，结合KV存储的灵活性，降低了针对不同数据源的定制化开发和后期维护的复杂度。 [cite: 18]

2.2 助力业务接入，支持特定业务场景

• 加速新供应商接入：原始库的建立，为新供应商、新数据源的快速接入提供了基础。标准化的接入流程和灵活的数据模型，使得我们可以更高效地对接例如海外直连供应商、新兴渠道等。 [cite: 16]

• 支持特定业务需求（如“八大内资集团特有字段”）：虽然原始文档未直接详述“八大内资集团特有字段”的具体案例，但原始库“灵活扩展的schema”设计原则，恰恰是为了满足这类特定业务需求的。 [cite: 18] 我们可以很容易地在KV结构中为特定供应商或供应商类型（如这些内资集团）扩展其独有的字段，而无需影响整体数据模型。这些特有字段可以直接在原始库中存储和管理，并在后续的数据处理和优选流程中，根据业务规则被正确地映射或应用于特定的物理酒店信息上。这提升了我们服务大型合作伙伴和满足其定制化需求的能力。

• • 支持特定业务需求（如“八大内资集团特有字段”）：原始库的“灵活Schema”能够轻松应对这类特定业务需求，在KV结构中为特定供应商或类型扩展独有字段，提升了我们服务大型合作伙伴和满足其定制化需求的能力。提升开发效率，减少开发周期；

3. 搭建统一数据服务（DaaS）：高效、可靠的数据中枢

为了解决历史上数据访问混乱、多点维护、数据不一致等问题，我们构建了统一的数据服务平台（DaaS）。

3.1 统一查询范式：兼顾多种场景，抽象高效方案

• 核心目标：收口所有对核心静态信息的访问，提供统一、标准、高效的查询服务。

• 挑战与应对：下游业务方对数据的需求多种多样，有的需要点查（KV式），有的需要批量获取，有的需要构建本地缓存并保持更新。

• 抽象出的两种核心数据构建与访问方案：

1. KV式点查服务 (在线服务)：

• 场景：针对需要根据主键ID（如酒店ID、房型ID）快速获取单条或少量实体详细信息的场景。

• 实现：底层主要依赖KV存储（如Redis）提供高性能缓存，对于缓存未命中的情况，则回源到持久化存储（如MySQL或原始库的KV存储）。 [cite: 1, 9]

• 自建二级索引：对于非主键的查询需求（例如根据城市查酒店列表），如果KV存储本身不支持复杂查询，我们会在DaaS层面或通过引入专门的搜索引擎（如图中所示的Elasticsearch）构建和维护二级索引，将查询请求转化为对主键的查询，再通过KV服务获取详情。 [cite: 10]

2. 全量/增量构建机制 (离线/准实时构建)：

• 场景：针对需要构建全量数据副本、或需要持续获取数据变更以更新本地缓存的下游系统。 [cite: 11]

• 实现：DaaS提供标准的全量数据导出接口/工具，以及基于消息队列（如QMQ）的增量变更通知机制。 [cite: 1, 15] 下游可以通过消费增量消息来实时更新其数据，也可以定期进行全量同步以保证数据最终一致性。

• 优化缓存构建效率：通过DaaS提供的标准构建机制，下游系统的缓存构建时间得到了大幅优化（例如，从16小时缩短到0.5小时）。 [cite: 15]

3.2 DaaS技术架构揭秘：保障一致性、并发与数据完整

（以下内容主要基于PPT末尾的“版本号比较”流程图和相关文字描述进行解读 [cite: 15]）

• 保障多存储间的数据一致性（最终一致性）：

• 核心机制：版本号控制。每一份核心数据（如单个酒店信息）都会带有一个单调递增的版本号。 [cite: 15]

• 更新流程：

1. 数据发生变更时（例如V1 -> V2），首先更新主存储（如MySQL）。 [cite: 15]

2. 同步或异步地更新其他副本存储（如Redis缓存、Elasticsearch索引）。 [cite: 15]

3. 通过可靠消息队列（QMQ）发送数据变更消息，消息中携带新的版本号。QMQ保证消息的有序性和事务性。 [cite: 15]

• 读取流程与一致性保证：

1. 下游系统通过DaaS查询数据时，可以携带其已知的版本号。 [cite: 15]

2. DaaS服务会比较请求版本号与当前最新版本号。如果请求版本号较旧，DaaS会返回更新的数据及版本号；如果版本号一致或更新，则可能直接使用缓存。 [cite: 15]

3. 对于依赖消息更新的系统，消费消息后，会用消息中的新版本数据更新本地存储。

• 一主多从：DaaS服务本身可以设计为一主多从架构，主节点负责写操作和数据分发协调，从节点提供读服务，提升可用性和读性能。 [cite: 11]

• 解决增量更新的并发问题：

• 单实体更新有序：通过在业务逻辑层面或数据库层面保证对同一个实体（如同一家酒店）的更新操作是串行化的，或者使用乐观锁机制配合版本号，确保其版本号单调递增。 [cite: 15]

• 消息队列的有序性：利用QMQ等消息中间件的特性，可以保证针对同一主键（如酒店ID）的变更消息是严格有序投递和消费的。这避免了因并发消息处理导致的旧数据覆盖新数据的问题。 [cite: 15]

• 幂等消费：下游消费者在处理增量消息时，需要设计为幂等操作，即多次处理同一条消息（例如因网络问题重试）与处理一次的效果相同，通常通过版本号校验或唯一请求ID实现。

• 解决全量数据空洞（Data Void/Gap）问题：

• 什么是数据空洞：指在全量构建或同步过程中，由于各种原因（如构建任务失败、网络分区、数据源部分不可达等）导致某一部分数据未能成功加载到目标系统，形成数据缺失。

• 解决与预防策略：

1. 可靠的全量构建机制：DaaS提供的全量构建工具和流程，需要具备**断点续传、失败重试、数据校验（如行数、关键字段汇总统计）**等能力，最大限度保证全量数据的完整性。

2. 监控与告警：对全量构建过程和数据同步状态进行严密监控，一旦发现数据差异或构建失败，立即告警。

3. 定期全量校对与修复：除了依赖增量更新外，应有机制定期（或在监控到异常时触发）进行全量或分区的数据校对，识别并修复数据空洞。

4. 版本回溯与快照：在极端情况下，如果发生大规模数据污染或空洞，可能需要依赖数据备份或快照进行回滚。

5. DaaS层面的数据补偿逻辑：DaaS服务在对外提供查询时，如果发现其依赖的某个下游存储（如某个缓存分片）暂时不可用或数据不完整，可以设计降级策略，例如回源到更可靠的主存储查询，或者暂时返回稍旧版本的数据（并标记），而不是直接报错或返回空，从而在一定程度上“掩盖”或“平滑处理”下游的暂时性数据空洞。

关于搭建统一数据服务（DaaS）及统一查询范式所带来的核心收益，我们可以从以下几个关键方面进行总结，这些很多也体现在您提供的“项目效果”图片中：

1. 大幅提升研发与运营效率：

• 缓存构建时间显著缩短（97%优化）：如下游系统构建自身数据缓存的时间从原先的 16小时大幅降低到0.5小时。这极大地提升了数据同步的效率和业务的响应速度。

• 统一入口与标准化：为所有下游业务方提供了统一、标准的数据访问接口。避免了各业务方重复造轮子、各自理解和对接底层数据源的复杂性，降低了对接成本和后续的维护成本。

2. 显著降低系统耦合度与复杂性：

• DB耦合点大幅减少（83%优化）：数据库的直接耦合点从 160个锐减到27个。这意味着DaaS有效地隔离了下游应用与底层数据库的直接依赖，使得底层数据架构的变更和优化更加灵活，降低了系统性风险。

• 简化了数据获取逻辑：下游不再需要关心数据具体存储在哪里（MySQL, KV, 缓存等），DaaS负责了数据的路由、聚合和转换，降低了消费方的理解和使用成本。

3. 提升数据一致性与可靠性：

• 统一的数据出口保证了数据源的权威性：通过DaaS作为唯一的数据出口，更容易保障数据的一致性和准确性，避免了因多源、多口径导致的数据差异问题。

• 内置一致性保障机制：如版本号控制、QMQ消息有序性等，确保了下游获取数据的最终一致性，提升了数据的可靠性。

• 高可用设计：如“一主多从”的架构，提升了数据服务的稳定性和可用性，保障业务连续性。

4. 优化资源利用，减少重复建设：

• 外部重复缓存减少（42%优化）：外部业务方重复构建的缓存数量从 7个减少到4个（或类似的比例）。这表明通过DaaS提供的统一缓存或标准构建机制，避免了不同团队各自维护功能相似的缓存，节约了存储和计算资源。

• 统一管理与监控：DaaS平台可以进行统一的访问控制、流量监控、性能优化，比分散管理更有效率。

5. 增强业务敏捷性与创新能力：

• 快速响应业务变化：当业务需求变更或新增数据消费场景时，基于统一的DaaS平台可以更快速地提供支持，缩短了新业务上线的周期。

• 支持多样化查询范式：通过抽象出KV点查、全量/增量构建等多种查询范式，能够灵活满足不同业务场景对数据的需求，为业务创新提供了更好的数据支持。

总结来说，搭建统一数据服务（DaaS）和统一查询范式，核心收益在于“提效（开发、运维、业务响应）、降本（维护、存储、重复建设）、增质（数据一致性、可靠性）、减耦（系统依赖）”，为整个静态信息体系乃至集团的数字化运营奠定了坚实、高效、可扩展的数据服务基础。