257 lines
18 KiB
Markdown
257 lines
18 KiB
Markdown
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）和统一查询范式，核心收益在于“提效（开发、运维、业务响应）、降本（维护、存储、重复建设）、增质（数据一致性、可靠性）、减耦（系统依赖）”，为整个静态信息体系乃至集团的数字化运营奠定了坚实、高效、可扩展的数据服务基础。** |