携程技术

转载 携程问道（workbuddy 合作版）技能接入与使用文档

本文档详细介绍携程问道（workbuddy 合作版）技能（wendao-partner-workbuddy-skill）的接入流程、使用方法、环境配置及注意事项，适用于需要集成该技能并调用携程问道 API 获取旅行相关信息的开发 / 运维人员。该技能针对各类旅行相关问询场景触发（如酒店 / 机票预订、景点推荐、行程规划、签证查询等），触发后通过调用携程问道 API 返回专业的旅行规划与攻略信息，不依赖通用知识库回答。用户的旅行相关自然语言查询（完整问句，如 “暑假去成都的景点推荐”）

原创 干货 | 9亿数据归因分析跑进15秒：携程智能归因系统如何用 Ray+DuckDB 破解算力危机？

通过 REST API 把节点任务提交后，Ray 的“任务分解器”会对节点逻辑再做一次更细粒度的拆解：解析用户输入的多维分析 SQL，依据其中的 Union/Join 键以及数据分布特征，将原本庞大的查询拆成数十甚至上百个完全独立的微任务。作为 Ray 集群的核心编排组件，通过 K8s 自定义资源（CR）RayCluster定义集群配置（如 Head/Worker 节点资源规格、副本数、镜像版本），实现 Ray 集群的自动化部署、扩容、缩容与销毁，无需人工干预集群生命周期。这是架构改造的第一步，也是基础。

原创 干货 | 携程 JDK25 升级踩坑记：一场由 G1GC “偷走”对象引发的数据静默损坏

生产环境中 Spark 已基于 JDK21 运行，为使用 JDK25 LTS 版本的新特性紧凑对象头（Compact Object Headers）（JEP 519，开启参数-XX:+UseCompactObjectHeaders），实现内存占用节省、GC 效率提升与性能优化，计划将运行环境升级至 JDK25，并完成了 Spark 对 JDK25 的适配工作，支持灰度切换。当 Native 的压缩代码正在向指定的内存地址写入压缩后的数据时，G1 GC 把这个 Java 数组的内存地址给转移了。

原创 干货 | 执行个 systemd 命令，竟然让容器CPU“打架”？一文看懂绑核错乱的根因

发布通过 systemd 管理的组件时，会执行 systemd daemon-reload , 这会触发 systemd 对账，将它自己持有的配置数据同步到 cgroup , 从上图我们可以看到它持有的配置数据是错的，同步到 cgroup 后就导致不同的绑核容器使用同样的 cpu 核了，这就是业务超时的原因。当时的 CPU 核上在做什么？容器创建时，systemd 拿到了错误的绑核信息，runc 拿到了正确的绑核信息，由于 systemd 先写入配置，runc 后覆盖写入，此时容器的绑核信息最终保持正确。

原创 AI专栏 | 告别“黑盒评审”：我们让LLM为数据仓库模型打了分，效率提升70%+

数仓建模本质上是面向业务的抽象过程，即便采用业界通用的维度建模方法论，不同工程师在实践中的理解与实现也存在显著差异，这使得建模质量的标准化评估成为行业难题。的数据仓库模型评价体系。其他模型特征包括：表名、任务ID、表类型、层级、数据域、业务域、业务过程、粒度、对应主表、字段明细、需求链接、飞书云链接、业务说明、关联关系、血缘明细、DQC明细等，均可通过公共元数据直接获取。重复建设探查是数据仓库的重复建设评价核心量化手段，是控制数据仓库规模，节约算力成本的深度手段，是保障数据仓库健康成长的重要指标。

原创 出海 | 携程《全球化技术架构与实战》一书火爆上市，看全球流量调度“最强大脑” UCS 如何破解合规与高可用难题

以下是一个基础的 UDL 策略模型，它描述的调度场景是：在ComplianceArea_1所标记的合规区下，目前包含两个Region（REGION_A、REGION_B）和四组UDL（UDL_A、UDL_B、UDL_C、UDL_D）的用户数据，其中所有来自 UDL_A 与 UDL_B 的用户都路由到 REGION_A ，来自 UDL_C 与 UDL_D 的用户都路由到 REGION_B。为了满足全球化架构下的流量调度需求，UCS 实现了灵活的策略模型，具备了描述全球流量调度策略的能力。

原创 出海 | 携程《全球化技术架构与实战》一书火爆上市：让全球用户“丝滑”跨域旅行，携程如何靠一套系统搞定数据合规与多活？

为了描述这种复杂性，我们引入合规区的概念。在合规区内采用如图12所示的简单多 Region 架构会有一定的缺陷：假如遇到单 Region 故障，用户的请求会被路由到同合规区内的其他可用 Region 进行处理，但是此时 Region 内没有该用户相关的数据，无法完成相关的业务处理。所以，为了让系统能够区分不同合规区的用户，并找到相关的用户数据位置，我们需要设计一套覆盖全链路的统一染色方案，在手机端、接入层、应用层、控制层、数据层等环节对数据进行标记，从而使得系统可以将用户的合规区信息不断传递，如图5所示。

原创 ＜span class=“js_title_inner“＞出海 | 携程《全球化技术架构与实战》一书火爆上市：让全球用户“丝滑”跨域旅行，携程如何靠一套系统搞定数据合规与多活？＜/span＞

为了描述这种复杂性，我们引入合规区的概念。在合规区内采用如图12所示的简单多 Region 架构会有一定的缺陷：假如遇到单 Region 故障，用户的请求会被路由到同合规区内的其他可用 Region 进行处理，但是此时 Region 内没有该用户相关的数据，无法完成相关的业务处理。所以，为了让系统能够区分不同合规区的用户，并找到相关的用户数据位置，我们需要设计一套覆盖全链路的统一染色方案，在手机端、接入层、应用层、控制层、数据层等环节对数据进行标记，从而使得系统可以将用户的合规区信息不断传递，如图5所示。

原创 出海 | 携程《全球化技术架构与实战》一书火爆上市，看 DRC 如何支撑全球旅游业务无缝切换

由于复制两端的 MySQL 实例执行 DDL 的过程存在时间差，目标端数据库的表结构与源端数据库的表结构可能存在差异，此时待复制的MySQL二进制日志可能和目标端表结构不匹配（举个例子，源端数据库在 T1 时刻执行完 DDL，目标端数据库在 T2 时刻执行完 DDL，则 T1 ～ T2 期间源端 源数据库产生的二进制日志对应的表结构与目标端数据库的表结构不一致），导致同步模块执行二进制文件中的SQL时报错。对于数据同步模块到目标数据库这条链路，在实际运维过程中，我们发现数据复制的瓶颈往往在对端数据库性能。

转载 干货 | 查询从秒级到毫秒级，携程 UBT 系统迁移 StarRocks 存算分离架构实战

该架构既提升了资源利用率，避免资源浪费，又显著降低了存储成本，同时也保证了查询速度。此外，利用 show proc compactions 命令，可以获取具体的 Compaction 任务信息，包括任务的开始与结束时间、总执行时长，以及本地与远端数据的扫描量。在 Compaction 层面，传统模式由于提交频繁，容易产生大量 KB 或 MB 级的小文件，频繁触发 Compaction，导致系统开销偏高。在 I/O 性能方面，传统写入以小文件为主，属于随机写入模式，读取时需要频繁打开大量小文件，效率低下。

原创 干货 | 从 T+1 到分钟级：携程基于 Flink 与 Paimon 的近实时湖仓建设实践

无论是基于时间戳的补数，还是带有条件的特殊补数，cdc 二阶段的作业都会在补数完成之后自动切换到增量消费的模式。用户可以通过配置，可以进行一键补数。从 MySQL 到 Kafka，再到 Paimon，数据流在各环节的出入口均增加了表级别的指标埋点，用户可基于这些指标配置数据断流、延迟等告警，实现了精细化的可观测性（图 9-图 10）。两者的深度融合有效提升了查询性能与数据一致性，实现了计算与存储的高效协同，进一步完善了湖仓一体的生态体系，为用户带来更灵活、更高效的数据分析体验， 如图 11 所示。

原创 AI专栏 | 携程数字人直播实战：成本降低90%，我们如何实现规模化落地？

系统感知到用户事件后进行策略判断，对于需要响应的事件由AI模型生成回复内容和回复形式，文字回复可以直接在评论区输出，如果需要主播语音回复，先获取当前直播的进度，找到正在播放的片段，然后根据生成回复视频所需时间计算回复需要插入的点，找到插入点的前一个视频，获取到其最后一帧画面，用于生成回复视频，生成好后插入到播放点，待直播进度到回复视频时就会进行播讲。数字人直播合成的视频可以设置循环规则，在之后的一段时间内进行不断的直播，直播的次数越多，则均摊的成本越低，相比实时合成推流的方式大幅降低了成本。

原创 AI论文 | 当旅游数据遇见二维 Transformer：TripCast 如何预测机票需求？

携程机票团队在模型迭代过程中，经历了从机器学习模型、深度学习模型，到自研模型的过程，并没有陷入惯性思维，去卷“更长序列、更复杂的模型结构”，而是从问题本身出发，思考手中的数据特点，从数据出发设计更匹配的模型，用简单的transformer encoder加上patch tokenization、progressive masking等技巧就打。传统的时间序列预测模型，像 ARIMA、LSTM、Transformer，都是基于“一维时间序列”设计的：过去的销量数据 → 预测未来的销量数据。

原创 干货 | 告别人工测试困局，携程 BDD 驱动的自动化测试落地与效能跃迁

为了提高代码质量，降低风险，必须采取更加系统化和自动化的测试方法，来弥补人工编写测试用例中的不足，确保更高的行覆盖率和分支覆盖率，从而提升软件的稳定性和可靠性。未来，随着跨端测试能力的完善和智能化技术的引入，自动化测试将在软件质量保障中扮演更核心的角色。当前 Mock 用例代码仓库的结构，可以较快实现已有数据的复用，例如 A 和 B 两个场景下所需的 Mock 数据中 10 个接口有 8 个接口数据完全相同，那仅需额外创建不同的 2 个接口数据，新增的 Mock 用例 B 可复用 A 的接口数据。

原创 干货 | 别让重试成为系统灾难，携程微服务重试治理之道

在某些场景下，会出现一些暂时性的错误，如网络抖动、服务重新部署等场景，可能立即发起重试结果依然是失败的，通常等待一段时间后再重试的话成功率会较高，并且也可以分散上游重试的时间，可以避免因为同时都重试而导致的下游瞬间流量高峰。我们假设微服务的调用方式如上图所示，当服务E出现异常时，服务E上报异常，随后触发服务C重试，而服务C调用服务E异常后同样选择抛出异常，这样子又会引发服务B重试，假设每个服务都接入重试机制，每个服务的重试次数为n，这样子就会导致最终的请求变成了n的4次方。

原创 AI专栏 | 提效4.7倍，携程机票前端迈向AI Coding自治

在做CRN转xTaro的时候，需要让大模型知道之前CRN上使用的组件，在xTaro上的平替是什么，比如在CRN工程使用View这个组件，在xTaro工程下使用的是XView，以及两个组件属性字段和API对应关系。我们基于这份数据做了可视化，方便我们检查生成质量以及后续维护，以ABTest组件为例，内容包括了组件转换概述，导入组件方式，API映射规则，相关代码样例few-shots，最后还有注意事项，是一些开发经验内容沉淀。非常期待AI Coding走向完全自治，而我们身在其中，是这一切的见证者。

原创 AI论文 | 携程提出多任务服务框架，让大模型“一人成军”，节省成本90.9%

提出一个三阶段框架：过滤不相似的任务、在高资源任务上进行微调，以及在所有任务的混合体上进行微调。在高资源任务上进行微调，然后在混合体上进行微调的策略，通过允许不同任务具有不同的训练轮次，从而有效实现提前停止，防止低资源任务的过拟合或高资源任务的欠拟合。进行了全面的实验，结果表明我们的方案在不同基准上都具有实用性，并能够替代单任务方法训练的任务。提出了一种多任务服务框架，该框架利用大语言模型（LLMs）来提升多任务方法的效果，该方法可以同时处理多个任务，并且性能与单任务方法相当。图 1: 两种在线服务策略。

原创 干货 | 准实时数仓落地实战：携程商旅基于Paimon的湖仓一体架构设计与批流融合实践

在我们内部实践中，基于Tag的增量计算替代全量ETL后，作业的处理速度提升了4～5倍，尤其在增量数据较少的ETL场景下，带来了显著收益。这不仅显著提升了计算效率，还增强了数据的可维护性和灵活性。在确保数据准确性的基础上，为提升数据新鲜度，我们设计了如图所示的实时与离线混合链路：订单票号等核心字段的加工使用Flink+Paimon准实时链路完成，最终的订单筛选则通过Spark批作业定时执行，产出的结果表通过携程内部DaaS服务注册为API，便于下游系统实时获取提醒订单，兼顾了数据的时效性与服务的稳定性。

原创 AI专栏 | 携程“AI测试员”已上岗：每秒生成一个高质量测试用例

如下是某团队2周的试点数据情况，按照该团队内历史测试用例编写情况统计，一年的测试用例编写量达到了3万+多个，根据目前的数据，2.8万+个用例已经可以由AI生成，将极大的提升测试用例的编写效率。如下是我们进行方案探索的主要路程：前期先进行有效方案调研及不同LLM模型的对比，找到最适合的模型，然后经过提示词框架构建、多维度增强和优化，再到测试工作的集成，最终实现了一套融合。为了提高测试用例生成的效率和质量，本项目设计了一套基于AIGC技术的智能化解决方案，实现从PRD到测试用例的自动化转化。

原创 AI专栏 | 告别人工写脚本！多模态大模型驱动携程UI自动化测试迈入“描述即生成”阶段

系统启动AI生成服务模块，开始核心的智能生成流程。该方法以页面截图、DOM树结构以及自然语言用例描述作为输入，充分利用多模态大模型的跨模态理解能力和逻辑推理能力，实现对UI元素的智能识别与定位，并自动生成可持续执行的UI自动化测试用例。在大模型技术发展的初期阶段，本研究采用大模型结合页面控件的文本属性信息和自然语言用例描述，实现UI自动化用例的自动生成。该阶段的核心技术是构建了一个基于多模态大模型的自主推理与动态调试框架，能够根据高层次的用例描述和页面截图信息，自动进行测试步骤的规划和分解。

原创 AI专栏 | 破局酒店搜索零结果！携程AI搜索实战，复杂查询召回率提升90%

在AI快速发展的浪潮中，传统的关键词搜索早已难以满足用户日益复杂的需求。结合携程酒店搜索业务的特点与实际需求，我们选择了基于Elasticsearch（ES）的方案，构建向量召回能力，以实现稳定可靠的向量检索与管理。这种向量搜索不仅突破了传统的关键字匹配限制，还深度理解用户的语义输入，将其需求与OTA系统中的海量信息高效关联，从而提供个性化和高度相关的搜索结果。如果在酒店搜索流程中进一步融入更智能、更贴合用户意图的语义搜索能力，将极大地改善用户的预订体验，使所有用户都能直观地感受到AI带来的便捷与精准。

原创 干货 | 破局传统埋点四大痛点！携程机票前端可视化埋点实践

事实上，可视化埋点支持多种类型的事件采集，这些埋点的主要区别在于触发时机不同，例如页面进入、离开、元素输入、失焦、曝光等。如上图所示，当用户点击节点 LA 触发埋点时，系统会顺着 fiberNode 节点的 return 属性向上查找父节点，并记录这条链路上的所有节点信息，最终组合成相对路径。河图现已融入公司内部的伏羲埋点管理系统（以下简称伏羲），作为其子系统，专注于可视化埋点领域，而伏羲则是一个集埋点开发、数据分析与管理于一体的综合系统。通过前文的阐述，相信读者已对可视化埋点的核心流程建立了系统理解。

转载 AI专栏 | AB实验新突破：携程提出图贪心分流算法，解决两大核心难题

通过图算法模块，降低实验组之间的流量交叉。用户端实验中，用户一般可以看做独立的个体，但非用户端实验则不然，如电商平台上的“鼠标”和“鼠标垫”显然不具备独立性，它们极易同时曝光给同一用户群体，这就导致若商品“鼠标”被分至实验组，而“鼠标垫”被分至对照组，且被同一用户看到，这两个商品之间就会互相影响，导致实验结论可信度降低。，在算法中额外给定用户和分流实体的历史交叉信息（如用户历史浏览的商品，下文用uv数据代指该信息），将交叉信息抽象为图，将原分流单位打包为新的分流单位，让新的分流实体之间流量交叉尽可能隔离。

原创 干货 | 携程机票Skip原生跨端框架探究

在移动应用开发领域，跨端开发框架一直备受关注。在转换代码中，SwiftUI的每个View都有一个body，这里返回的是SwiftUI的页面元素，转换之后需要提供的是可以调用的@Composable函数，这里包装了一层ComposeBuilder用于执行Compose方法返回@Composable函数的结果用于展示。SKIP包围的是Kotlin的代码，非SKIP的就是专属Swift的代码，同时有些关键字的替换，如Swift的构造方法init在转换后的代码中就是constructor等。

原创 干货 | 携程机票前端Web流式通信SSE全链路应用实践

仅仅只是简单接入SSE是远远不够的，离不开全链路（SSE技术选型，多层网络架构的适配，服务间的流式通信等等）的支持，所以最终决定联合携程框架、SRE、机票前后端团队共同来实现对SSE全链路的适配，真正意义上实现全公司通用的普适方案。关于SSE原生流解析 与 fes流解析是不同语言实现的这一点，我们也思考了语言差异对性能的影响，所以对响应数据的解析耗时做了实验，在相同机器和网络环境下，对比了原生 SSE 和 fes 处理数据流的耗时，实验结论是两者在耗时上没有明显差异（毫秒级）。

原创 干货 | 携程定制化路由代理网关实现

作者简介Tim，携程资深软件工程师，关注网关和代理技术领域。团队热招岗位：Java开发工程师-中间件本文主要介绍携程软负载产品，在业务增长及路由需求日渐复杂的背景下，如何从传统Nginx反向代理逐渐发展成支持多元化路由的网关产品。以及其中利用的开源框架OpenResty的主要功能，和我们在路由转发场景的落地实践及探索。一、背景二、流量链路2.1 多机房容灾2.2 多元化需求三、面临的问题3.1 路...

转载 来啦！2024携程研发效能年度报告

原创 干货 | 携程基于Kafka的数据校验代理在FinOps领域的应用

作者简介懿涵，携程HybridCloud团队云原生研发工程师，关注云原生、IaC领域。为了有效管理云成本，基于携程混合多云和自建PaaS为主的现状，混合云团队研发了FinOps计费系统。本文将介绍计费系统基于Kafka构建的接入体系在数据质量与治理方面的挑战，并分享基于自研Kafka Gatekeeper构建度量及治理自助化自动化的实践。一、现状与问题1.1 现状1.2 问题描述1.3 解决方案二...

原创 干货 | 携程从零构建多端一致的设计研发体系实践

作者简介Sheila，携程资深研发经理，关注前端性能优化、前端智能化。Wistoon，携程资深软件工程师，关注前端框架创新、跨平台开发。秋细雨，携程资深软件工程师，关注跨平台开发、前端基础建设架构设计及工程化体系搭建。雪刃，携程高级研发经理，关注前端工程标准化和协作流程规范。野原，携程高级视觉设计师，关注界面设计，优化用户体验与视觉细节。本文深入探讨了如何在多品牌、多终端的环境中，建立一个支持多个...

原创 干货 | 携程商旅在 Remix 模块预加载中的探索与优化实践

作者简介19组清风，携程资深前端开发工程师，负责商旅前端公共基础平台建设，关注NodeJs、研究效能领域。团队热招岗位：高级/资深前端开发工程师本文总结了携程商旅大前端团队在将框架从 Remix 1.0 升级至 Remix 2.0 过程中遇到的问题和解决方案，特别是针对 Vite 在动态模块加载优化中引发的资源加载问题。文章详细探讨了 Vite 优化 DynamicImport 的机制，并介绍了团...

原创 干货 | RN框架在携程旅行鸿蒙应用的全业务适配实践

作者简介携程鸿蒙框架技术团队，负责携程旅行鸿蒙系统原生应用开发，为鸿蒙生态用户提供一站式旅行服务。团队热招岗位：资深移动端工程师、高级iOS开发工程师携程作为鸿蒙生态在旅游行业的重要合作伙伴，早在鸿蒙服务卡片时期就和华为开始合作。2023年9月，华为宣布鸿蒙原生应用启动开发，同年12月，我们完成携程旅行鸿蒙Beta版本的开发，技术上基于Web+部分原生的方案实现。24年6月HarmonyOS Ne...

原创 干货 | 性能指标提升50%+，携程数据报表平台查询效率治理实践

作者简介携程OLAP引擎开发组，专注于大数据OLAP引擎trino/starrocks的开发与大规模部署和运维。团队热招岗位：资深大数据平台开发工程师、OLAP分析引擎高级/资深开发工程师本文概述了面对公司数据报表平台遇到的查询性能挑战，数据平台组围绕数据缓存、物化视图、查询策略、SQL质量等方向所做的一系列治理工作，以提升平台的查询效率和稳定性。通过这些工作，平台的查询响应时间得到了显著的改善，...

原创 干货 | 代码复用率99%，携程市场洞察平台Donut跨多端高性能技术实践

作者简介Brain，携程高级软件技术专家，关注前端技术框架、跨端技术方案、前端构建和工程化工具，致力于前沿技术和架构优化。团队热招岗位：高级前端开发工程师本文探讨了携程市场洞察平台基于Donut实现跨多端高性能移动端的技术实践。详细分析了跨平台开发的复杂性、多端登录态打通、大数据列表渲染支持等难点，以及新技术平台在功能覆盖率、基础设施和研发生态兼容性方面的挑战。Donut在小程序和App性能上的优...

原创 干货 | 携程弱网识别技术探索

作者简介Aaron，携程移动开发专家，关注网络优化、移动端性能优化。团队热招岗位：高级Android开发工程师、资深前端开发工程师、高级Java研发工程师网络优化一直是移动互联网时代的热议话题，弱网识别作为弱网优化的第一步，受到的关注和讨论也是最多的。本文从设计、开发、落地详尽的分享了携程在弱网识别方面的实践经验，如果你也有类似需求，这篇文章会是一个不错的实操指南。一、背景二、技术方案2.1 数据...

转载 让未来发生——2024携程极客文化节

原创 干货 | 携程国际机票基础数据中台化：构建高效的数据管理和应用平台

作者简介空歌白石，携程资深研发经理，关注性能和效率提升、架构优化。团队热招岗位：后端开发本文概述了携程机票在基础数据处理所做的中台化设计方案。第一部分阐述了中台化的背景和面临的挑战，第二部分介绍了中台化设计的原则以及目标，第三部分详细介绍了中台化架构的关键技术实践，涉及数据一致性、数据时效性、系统健壮性、系统自动化等方面的探索和尝试，最后是整体的技术架构概览以及线上运行效果。希望以上内容能够对大家...

原创 干货 | 结构化多元时序模型在携程业务量上的预测应用

作者简介Yiwen，携程数据分析师，专注用户增长、因果推断、数据科学等领域。团队热招岗位：高级数仓工程师、高级数据分析师、数据运营专员本文主要介绍SCNN模型及其代码的具体实现，以及如何将其应用在预测业务量上的实际操作过程，旨在面对一些拥有复杂时空结构的多元变量数据时，能更准确地进行预测。首先对模型原理进行简要阐释，随后展示代码逻辑，最后介绍在具体业务场景上的实践应用。一、背景二、现有方法及潜在问...

原创 干货 | 准确率89%，携程酒店大前端智能预警归因实践

作者简介SunnyZhou，携程资深测试开发工程师，专注于数据应用，以数据维度保障质量。zw_jin，携程算法工程师，关注自然语言处理算法、大模型AIGC。团队热招岗位：高级/资深Java开发工程师、资深前端开发工程师、前端技术专家、后端技术专家、高级算法工程师携程酒店前端存在大量监控，但对于监控问题的排查成本，随着量级的增加而变得不可控。因此引入了智能预警归因系统，以数据池统一数据结构及标准；...

原创 干货 | 能效变革，携程酒店前端BFF实践

作者简介携程酒店研发前端BFF组，专注BFF研发实践及效能提升；携程云函数研发项目组，专注新一代FaaS研发模式在携程的落地实践；团队热招岗位：前端技术专家、资深前端开发工程师本文概述了携程酒店前端BFF层在架构迁移及效能提升过程中面临的挑战和应对方案。第一部分描述了BFF实践过程中遇到的问题，分析了两种BFF模式的对比并提出了一码多端的BFF研发方案；第二部分通过介绍携程云函数平台能力来阐述其如...

原创 干货 | 携程度假商品千亿日志系统架构演进

作者简介cd，携程资深后端开发工程师，度假商品系统研发，专注于后端系统性能提升。团队热招岗位：资深后端开发/专家、资深后端开发-商品后台在携程旅游度假的线路类商品系统中，由于商品结构复杂，涉及底层数据表上千张，在日常供应商以及业务维护过程中，每日产生6亿+的数据变动记录。这些数据的变动留痕，不但可供录入方查看，也对日常产研的排障起着至关重要的作用，同时也可以提供给BI做数据进一步分析。商品日志系统...