一、项目背景

在社区场景中，我们积累了丰富的用户互动数据。这些历史互动信息对 CTR/CVR 预估建模具有重要参考价值，用户的每次互动都反映了其特定维度的偏好特征。当前，已在多个业务实践中验证，基于用户历史互动特征进行未来行为预测是有效的。用户互动序列越长，包含的偏好特征就越丰富，但同时也带来了更大的技术挑战。

目前社区搜索领域已经在序列建模方向取得了一些应用成果，显著提升了搜索效率，但在该方向上仍有优化空间，主要体现在：

算法精排模型现状：长周期的用户互动特征尚未被充分利用，现有模型仅使用了基础标识信息，泛化能力有待提升。我们计划引入 SIM 方案来增强个性化序列建模能力，推动搜索效率提升。

迭代效率优化：当前互动特征优化依赖于实时数据采集链路，新增特征需要长时间数据积累（2 个月以上）才能验证效果。我们计划建设用户特征离线回溯服务，降低算法优化对实时数据的依赖，加快项目迭代速度，提高实验效率。

离线回溯主要解决迭代效率问题，本文重点探讨在社区搜索场景下开发离线回溯，并做离线一致性验证过程中发现的一些问题，针对这些问题做了哪些优化措施及思考。

二、架构设计

全局架构

序列产出流程链路

※  在线流程链路

在线链路通过实时数仓提供全量表和实时流两种数据源，在特征平台下构建 1w 长度的实时用户画像，召回阶段 SP，将画像传给 SIM 引擎，在引擎中完成对用户序列 hard/soft search 等异步加工，最终传给 Nuroe，完成在线序列 dump 落表。

※  离线流程链路

离线链路通过仿真在线的处理逻辑，利用请求 pv 表和离线数仓提供的 10w 原始序列，模拟在线序列 10w->1w->100 的过程，最终产出离线回溯序列。

最终通过在线/离线全链路数据的一致性验证，确认全流程数据无 diff（或 diff 可解释），序列流程可靠性达标，可交付算法团队用于模型训练。

序列产出全局架构

在线架构

在线侧抽象 GSU 模块支持社区搜索和增长搜索等多场景复用。该模块在 QP（Query Processing）阶段后，通过外调基于 DSearch 构建的 SIM 引擎进行用户序列处理。SIM 引擎内完成 hard/soft search 等用户序列加工，在精排阶段前获取 topk 序列特征及对应 sideinfo，并将其透传给精排模块，最终实现用户序列的落表存储。

在线通用 GSU 模块

离线链路

数据产出三阶段

※  原始序列预处理阶段

通过收集一个用户，按照 [月初 ts+1w,  月末 ts] 将序列进行预处理。

※  pv 表合并序列表阶段

按照 user_id 将画像和 pv 表合并，将每个 request_id 的数据按照 request_time 过滤处理。

※  用户序列加工阶段

完成 hard/soft search 等用户序列加工逻辑处理，包括对长期序列按照相似度过滤，对短期序列按照时间过滤等。

离线回溯链路图

三、问题与挑战

在离线回溯开发阶段，主要面临以下挑战。

挑战

※  任务执行问题

任务频繁失败或执行效率低下，数据规模达单表数 TB 级别，且序列分布不均，部分长尾用户序列过长导致严重数据倾斜；

※  一致性校验阶段问题

异常类型复杂多样，累计发现 25+种异常原因，导致数据 diff 形态复杂，一致性原因分析困难。修复链路冗长，涉及问题修复、在线索引重建、数据累计和离线数据回补，单次修复周期约需一周。

四、从踩雷到填坑的实战记录

离线任务运行耗时长的问题

问题说明

初步方案运行时存在两大问题：

1.任务处理延迟显著，单个任务运行 3-8 小时。

2.任务处理无法运行成功频繁 OOM。

任务执行慢

任务频繁 OOM

解决方案

※ 方案优化

任务执行慢主要是有长尾用户打满 10w 长序列，出现数据倾斜问题甚至 oom。

通过对链路优化，先将原始 10w 长序列做预处理，由于回溯一般按照一个月跑数据，可以利用 pv 表先统计有哪些有效用户，对有效用户按照 【月初 ts+1w,  月末 ts】截取原始序列，获取相对较短的预处理队列。

任务倾斜

原始序列预处理

※  ODPS 任务性能调优

a. 按照 CPU : MEM =  1 : 4 调整计算和存储的比例，可以最大化利用资源，因为我们申请的资源池都是按照这个固定比例来的。

资源没有最大化使用

b. 在固化计算/存储比例参数后，可以通过 xxx.split.size 和 xxx.num 共同调优。xxx.split.size 可以实现输入分片大小，减少 oom 机会。xxx.num 可以实现扩大并发数，加快任务的执行（xxx 代表 mapper、reducer、joiner 几个阶段）。

分批次完成阶段处理

c. 减少自定义 UDF 使用。在离线任务中有部分逻辑比较复杂，可能需要数据平铺、聚合、再内置函数等。最好的使用原则是内置函数>“数据平铺+内置函数”>自定义 UDF。由于自定义 UDF 运行在 Java 沙箱环境中，需通过多层抽象层 （序列化/反序列化、类型转换），测试发现大数据量处理过程性能相对最差。

一致性验证归因难的问题

问题说明

在线/离线全链路数据的一致性验证过程中，由于按照天级全量 dump 序列，需要验证 15 个序列，每个序列 diff 量在 10w～50w 不等，这种多序列大规模的 diff 问题人工核验效率太慢。

解决方案

※  整体 diff 率分析

通过统计全序列 diff 率并聚类分析高 diff 样本，定位共性根因，实现以点带面的高效问题修复。

※  diff 归因工具

通过建立数据 diff 的归因分类体系（如排序不稳定、特征穿越等），并标注标准化归因码，实现对 diff 问题的快速定位与根因分析，显著提升排查效率。

归因码分类

※  重复度统计工具

由于在线受当时环境的影响，离线回溯无法 100%复现原始序列，一致性差异在所难免。我们通过聚焦主要特征并统计其重复度，结合「diff 率+重复度」双维度评估方案，为算法决策提供量化依据，有效减少无效迭代。

重复度统计

现状梳理不足的问题

问题说明

由于前期对业务场景理解不足（如用户行为模式、异常数据、测试账户等），部分潜在问题未在开发阶段充分识别，直至数据一致性验证时才集中暴露，导致需紧急调整数据处理逻辑。由于单次全链路修复需 3-5 天，进而对项目进度造成一定延迟。

问题 case1：滑动图片：离线回溯数据分析时发现序列中大量重复且占比很高，后确定为滑动图片行为

解决方案：对滑动图片操作连续多次修改为只记录第一次

问题 case2：合并下单：测试购买序列有 id 重复，实时数仓反馈购买有合并下单的情况，ts 会相同

解决方案：为了保持离线回刷数据稳定性，将序列按照 ts/id 双维度排序

问题 case3：异常数据：有行为时间戳超过当前时间的异常数据

解决方案：数仓对异常数据丢弃

问题 case4：测试账户：数据不规范导致数据 diff

解决方案：测试账户数据忽略

问题 case5：query 问题：取归一化后还是原始的 query、空字符串问题

解决方案：query 为空过滤修复

问题 case6：数据穿越问题：画像原始数据 request_time 取 neuron 时间导致

解决方案：在线修改 request_time 获取时间，离线回溯前置 3s

修复周期长的问题

问题说明

数据问题的完整修复流程包含三个阶段，全流程通常需要 5-7 个工作日完成。

※  Diff 归因阶段（1-3 日）

• 需要定位数据差异的根本原因，区分是数据异常、处理逻辑错误还是业务规则变更导致

• 涉及多团队协作排查（数据/算法/工程）

• 复杂问题可能需要多次验证

※  问题修复阶段（1-3 日）

• 根据归因结果修改代码逻辑或数据处理流程

• 可能涉及历史数据修正

※  数据迭代阶段（2-3 日）

• 在线画像引擎部署新数据

• 累计在线数据

• 离线画像回补数据

解决方案

受限于初期人力投入，我们在当前方案基础上通过多轮版本迭代逐步完成数据一致性验证。后续将通过工具升级（数据边界划分+自动化校验框架）和数据采样策略，实现验证到修复的阶跃式提升。

※  数据边界划分

现行方案离线链路都是算法工程来维护，排查链路太长，需要数据源有稳定的保障机制。后续将划分数据边界，各团队维护并保障数据模块在离线的一致性。

数据边界划分

※  全链路采样方案减少验证时间

离在线一致性验证方面耗时较长，主要在于数据量太大，在数仓构建、特征平台构建、累计数据等流程消耗大量的时间，如果全链路先针对少量用户走通全链路，能快速验证流程可行性。

采样方案

平台基建的问题

问题说明

首次构建序列建模体系，由于缺乏标准化基础设施，被迫采用烟囱式开发模式，导致多链路验证复杂且问题频发。

平台待建能力

• 特征平台排序功能不足，只支持单一字段排序，不支持多字段联合排序，导致排序结果不稳定。

• 特征平台过滤功能限制，仅支持毫秒级时间戳过滤。

• 索引构建效率低,个性化行为序列表数据量过大（3TB），导致索引构建压力大，初始构建耗时约 28 小时。升级至 FS3 集群后，构建时间降至 12 小时左右,最短至 7 小时，但仍未达理想效率。

五、展望与总结

后续我们将深入研究行业内的优秀解决方案，并结合我们的业务特性进行有针对性的优化。

例如，我们会尝试实施离在线数据与逻辑一致性方案，这种方案包括以下几个特点：

1. 数据一致性：离线与在线共用同一套原始画像，能够解决数据源不一致导致的差异问题。

2. 逻辑一致性：离线与在线都调用 GSU 服务，实现统一的序列逻辑处理，避免逻辑差异。

3. 技术架构复杂性：新方案带来了新的技术挑战，比如在线处理 10 万序列可能引发的 I/O 问题、离在线的 sim 引擎采用存算一体和存算分离架构。

综上，没有绝对完美的技术方案，最终都是在成本、性能和效率多方面权衡后的相对最优解。

离在线数据与逻辑一致性方案

本次特征回溯虽面临性能与数据对齐等挑战，但团队通过攻坚积累了经验，为特征平台后续特征回溯工具化打下基础，也期待能为后续算法模型迭代带来质的飞跃。

往期回顾

1.从 “卡顿” 到 “秒开”：外投首屏性能优化的 6 个实战锦囊｜得物技术

2.从 Rust 模块化探索到 DLB 2.0 实践｜得物技术

3.eBPF 助力 NAS 分钟级别 Pod 实例溯源｜得物技术

4.正品库拍照 PWA 应用的实现与性能优化｜得物技术

5.汇金资损防控体系建设及实践 | 得物技术

文 / 野雨

关注得物技术，每周更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。