现状梳理不足的问题
问题说明
由于前期对业务场景理解不足（如用户行为模式、异常数据、测试账户等），部分潜在问题未在开发阶段充分识别，直至数据一致性验证时才集中暴露，导致需紧急调整数据处理逻辑。由于单次全链路修复需 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 小时，但仍未达理想效率。
