外网版本： http://sd.jd.com/article/59590?shareId=458064&isHideShareButton=1

背景介绍

业务场景

促销优惠券数据是索引重要组成部分，优惠券数据存储的信息为一个优惠券batchId下绑定一批选品数据(如sku，类目(cid)，店铺(vender)等)，在对数据进行处理时需要将优惠券中台下发的选品数据按照优惠券batchId进行聚合，构建优惠券索引，下发到搜索引擎中进行商品召回，由于其结构化特性不能像商品数据一样进行统一处理。

• 产品形态

• 索引结构

业务需求及痛点

• 痛点一，全量两套架构，资源消耗高
1. 增量全量两套架构，容易引起数据不一致
2. 全量需要进行宽表join及数据聚合等操作，运行时间长10h，资源消耗高3万核/40T，严重阻碍了业务迭代速度

• 痛点二，核心存储为kv引擎，容易引起数据倾斜及数据不一致，丢数及延迟
1. 核心存储为kv引擎，需要面临维度反转及扩分片问题，容易引起数据不一致

2. 优惠券数据倾斜，大key问题

      优惠券个体之间选品数差异较大，以下为双十一期间优惠券绑定选品数量分布情况，优惠券总量级在200w左右，双十一时满200-20优惠券选品数可达达到6.6亿，选品总量级在百亿以上，数据倾斜问题严重

大促单个优惠券最高达到 6 亿 sku+ 选品存在多方面问题：

1. 超大券在出仓时容易由于网络波动造成的超时从而导致出仓失败，单分片sku达到三百万sku，单个券大小几十M
2. 在持久化时通过 jimdb 与 增量化数据处理服务进行数据交互，单分片数据大小过大造成了 jimdb 大 key，从而产生服务抖动；
3. 券促增量微批全数据出仓导致在线端磁盘存储压力过大；
4. 单个券促全量出仓方案已经不能满足业务方对于数据延迟需求。

架构演进

流批架构统一

技术选型

问题：KV存储是否合适？

kv存储及明细存储结构对比

Apache Doris 已在搜推登月数据分析场景中解决了大规模实时数据查询的问题，虽然OLAP引擎主要用于报表分析，但其优异的计算能力表现让我们思考是否索引数据处理也能使用Doris引擎来解决。在索引数据处理的场景中，Doris的一些优异特性比如高吞吐，低延迟，可灵活水平线性扩容，行列混存等技术与我们对底层存储引擎的需求极为契合。于是，我们考虑将Doris引擎作为索引数据处理的核心底座。

当数据存储在OLAP系统中时，我们直接利用Doris表来存储明细数据，将批量的查询结果直接返回到应用端，在应用端进行数据聚合。KV存储引擎的特点是可以在短时间内处理众多的点查询请求，可以实现百万级以上数据处理，但是每个查询返回的数据量不宜过大。 Doris引擎的特点是批量处理海量数据的能力比较强，虽然高qps的支持不如kv存储系统那么高，但是每次查询的结果可以返回大量的数据。我们处理数据的场景，目标是在指定时间内，完成海量数据的加工处理，比如1分钟之内需要处理多少个优惠券数据，因此，我们就可以利用doris引擎强大的数据批处理能力，进行微批查询，一次微批查询可以等价于kv系统的1000次点查， 从而达到和kv系统在同样时间内处理同样的数据量。

方案设计

我们将异构模块分为三部分，第一部分数据适配模块，由于数据来源有多种，实时topic及离线hive表，我们将消息适配后导入到doris中，第二部分为入仓模块，利用doris的sequence列保证消息时序，入仓成功后发出消息，通知下游发生更新的优惠券batchId，第三部分为聚合出仓模块，当接收到优惠券更新消息后，按优惠券batchId进行聚合出仓。

全增量统一： 聚合出仓模块有两种部署模式，一种为点查方式，部署方式为flink通过流处理方式进行增量数据更新，一种方式为批查，用于全量数据制备，部署方式为worker方式，代码复用，实现了全量与增量的统一。

优惠券流批一体重构收益

1. 接入效率提升50%
2. 统一全量与增量数据到Doris引擎，解决数据不一致问题；
3. 全量建库时长从10h->2h，全量数据时效从T+1->小时级，每天可以节省大数据离线计算资源约3万核*小时（该数据由大数据平台资产分析与治理的离线账单获取）；
4. 提升用户体验，优惠券单分片截断数从30万->不截断；
5. 数据均衡，解决热点更新问题。

抽象通用架构，赋能其他应用

1. LBS同城推荐底池重构
2. 订单搜索数据重构

稳定性建设

方案设计

• 架构改造
• 简化券促出仓链路，去除增量阶段与其他服务交互，券数据出仓后直接进行持久化到cfs；
• 调整 jvm 参数并新增背压及内存控制能力，保障全增量出仓服务稳定性；
• 增量化出仓对超大券单独存储，一定时间内只保留同一个券下最新数据将其他超大券历史数据删除；
• 支持指定部分券促id降低更新频率。

上线成果

1. os、ps券促迁移新架构去除Hadoop及HIVE依赖， 全量出仓整体速度提升约 96%（27h->1h）；
2. 解决了618期间大券难产问题；
3. 去除券促出仓对多个外部服务依赖，缩短了数据链路，提升了服务稳定性；
4. 服务单机负载降低，不再有fullgc出现；
5. 在线端磁盘占用大幅降低。

调整jvm参数&新增背压及内存控制

优化前：

优化后：

券促时效性优化

券促出仓增量化改造

随着业务发展业务侧提出了更高时效性要求，微批全量出仓方案已经无法满足业务发展需求，同时在线端磁盘使用问题也急需解决，需要升级为纯流式增量处理方式。

方案设计

方案概述：

1. 数据结构及消息消费调整，适配增量化处理能力；
2. 出仓调整增量数据推送方式，推送coupon对应skuList时只推送变动的sku；
3. 在线端基于推送信息动态更新coupon与skuList关系

上线成果

1. 资源方面
1. 彻底解决在线端磁盘存储问题，增量化降低存储95%以上
2. 性能方面
1. 增量化处理耗时大幅减少，双十二期间减少处理耗时96%以上
2. 消息延迟大幅降低，平均几十秒内处理完成，超大券增量更新延迟降低97%
3. 稳定性方面
1. 机器负载压力降低80%以上，稳定性大幅提升
2. 通过增量化查询极大降低了对底层doris压力

出仓延迟情况

旧版本：

新版delta增量（数据有五分钟窗口聚合）：

机器负载压力对比

历史版本：

delta增量化版本：

券促全量出仓时效性优化

随着业务发展券促数据量越来越大（优惠券千万级，绑定sku总量百亿规模，单券最大绑定sku6.6亿），全量出仓耗时越来越长而且极易失败。

券促出仓执行耗时越来越长

高频统计查询极易失败从而导致任务失败，券促出仓需要统计券促绑定sku数量用于区分大小券并用于分片及分策略执行绑定sku出仓，但统计后返回数据耗时较长而且容易失败

优化策略

基于预统计的全量出仓方案

预聚合功能&大小券拆分

收益

1. 优惠券新版方案上线
1. 优惠券searcher白单分片耗时从平均1h降低到20min，大小从11G降低到2.3G；
2. 优惠券zseacher白单分片耗时从平均1h降低到15min，大小从11G降低到2.1G；
3. 在线端降低内存存储降低10%（约38G，机器总内存380G）。
2. osearcher去除storeList 等方案上线
1. 本地盘存储单分片14G降低到400M。单分片执行耗时从1h降低到5min；
2. 在线端内存降低14%（约67G,机器总内存480G）启动时间降低 210 s（245s 降到 33s）；
3. 在线端稳定性提升不再有cpu消耗毛刺。
3. 时效性：优惠券searcher、zsearcher单分片耗时从平均1h降低至12min，券搜字典出仓任务耗时由20h降低至3h以内，产出时效提升85%以上。
4. 存储：底层存储Doris CPU负载平均降低60%以上，内存使用率降低50%以上，查询量降低90%以上。
5. 稳定性：券搜字典产出稳定性大幅提升，降低人工干预成本。
6. 解决问题：从数据架构层面彻底解决小券带来的券搜字典计算、产出困难的问题。

全链路自动化诊断及修复系统

背景

1. 券促数据规模增量迅速，而且业务场景越来越复杂，导致巡检、运维排查都带来一定人力消耗
2. 系统稳定性与可用率至关重要，及时发现问题并快速响应修复更是核心关键
3. 随着业务发展以及delta 增量化后券促入仓异常数据修复逻辑越发复杂
4. 自下而上的主动发现问题并及时通知到业务，一改往日业务自上而下提报问题到搜索的现状，主动赋能反推业务向前发展

鉴于上述几点，希望当线上无结果券促请求初现时，内部人员能第一时间感知问题、定位原因并吹响警报，推动团队快速干预止损显得尤为重要。

方案设计

方案概述

• 自动化巡检：定时巡检，将线上券促无结果及时发现
• 自动化诊断：自动化搜集相关信息进行诊断，非人工介入即可清楚知道无结果原因（接入autoBots基于AI自动化诊断&二次check）
• 自动化修复：如果诊断发现结果是可自动修复，那么及时将修复请求发送到指定服务（如券促同步服务），及时进行数据修复

部分场景问题汇总

效果展示

      目前整体诊断成功率在99%+，下图为无结果原因统计，同时可以看到最近三十天自动化诊断量在6w+，极大减少人工成本并能及时对数据进行自修复。

目前收到券促无结果告警，原因跟业务操作有关时，以私聊的方式去通知，效率较低，基于此创建券搜无结果周知群，线上单张无结果券促超过阈值时，自动获取对应业务erp并拉入群，推送告警信息，研发测试在群内做相关解答。

未来规划

paas化能力建设

业务现状

当前券促服务已在核心业务场景中完成体系化能力沉淀，覆盖券促在搜推的全链路流程，经过业务验证形成了稳定、可靠的系统化技术能力底座。同时，除核心券促场景外，黄流营销、个性化推荐等多个场景均提出了类似的券促及权益发放诉求，各场景对券种管理、规则配置、触达下发、数据统计等核心能力的需求高度重合。

核心诉求

• 能力复用，避免重复建设：基于现有券促服务沉淀的技术能力，搭建标准化PaaS平台，将通用能力封装为服务组件，供各场景按需调用，杜绝同类功能重复开发，提升技术投入产出比。
• 场景适配，支撑多元需求：兼顾券促核心场景与黄流营销、推荐等场景的差异化诉求，通过灵活配置、可扩展架构，实现“一套底座，多场景适配”。
• 高效迭代，降低业务门槛：提供标准化接入方式、可视化配置工具及完善的运维体系，让业务场景无需关注底层技术实现，快速完成券促能力集成，缩短业务上线周期。
• 统一管控，保障服务质量：通过PaaS平台实现全场景券促能力的统一管理、统一监控，确保各场景服务稳定性、数据一致性。

方案描述

基于现有券促全增量能力体系，秉持解耦复用、标准化封装、微服务架构核心思路，抽离黄流营销推荐场景中可复用的基础诉求能力，搭建 PAAS 化服务平台，实现多场景的快速支撑与高效运维。平台既可充分复用现有系统能力，大幅降低开发成本，又通过标准化设计保障服务的灵活性与可扩展性，同时依托现有自动化运维体系，从底层保障数据准确性与服务稳定性。

总结

通过对券搜数据架构的演进与优化，我们已经完成“搜推优惠券数据架构”全链路系统化建设：创新提出“消息+时间窗口Delta双驱动”的超大规模全量/增量出仓解决方案，彻底解决券促数据出仓滞后与时效瓶颈，实现百亿级券促数据场景下的分钟级更新，同时将计算与存储资源消耗降低90%以上，设计并落地自动化诊断与修复系统，构建“问题定位—数据校验—故障修复”的闭环能力，诊断成功率达99%，对可自修复类异常实现100%自动化修复；为业务侧建立异常券促消息推送与建券方即时反馈机制，显著提升问题发现与处理效率，降低对用户的潜在影响。同时将方案沉淀为行业级可复用实践方案（包含《券搜数据架构演进及未来规划》《搜推场景下券促出仓架构升级：时效优化与自动化修复实践》《券搜场景下全链路自动化诊断及修复系统》等专项文档及相关专利成果）并已在主站、垂站、外卖等多场景落地。

未来，我们将继续致力于AI赋能的自动化运维系统、paas化平台、数据核对等提升服务质量及数据质量方面的建设，进一步提升系统的可用性和稳定性，以满足业务快速发展的需求，推动技术与业务的深度融合。

作者

付剑生、米广树、曹安富 京东集团-京东零售-平台产品与研发中心-AI Infra与大数据计算部-搜推特征研发技术部-索引系统组

窦鹏飞 京东集团-京东零售-平台产品与研发中心-AI Infra与大数据计算部-搜推平台服务研发技术部-搜索服务研发组

路长红 京东集团-京东零售-平台产品与研发中心-搜推技术部-搜推质量保障部