数据回补与修复方案评审会
| 项目 | 内容 |
|---|---|
| 日期 | 2026-05-12 |
| 参与人 | 梁健、王建朝、韩冬冬、孙传熙、马奇等12人 |
会议摘要
会议评审了日常开单与自主签收数据的全量回补方案，明确了2026年至今的时间范围及手机号字段的修复路径；针对鲜度盘点表缺失问题，要求细化根因分析并重新提交技术方案。
一、日常开单与自主签收数据回补方案
1. 数据范围与执行策略
- 全量回补范围确认：经讨论，决定对2026年1月1日至今的数据进行全量回补，涉及日常开单约 224万条，自主签收约 375万条。
- SQL执行可行性评估：针对一次性执行近600万条数据的SQL脚本，朱学通确认该方案可行，且新生成的数据逻辑已正常。
- 环境验证要求：要求在开发环境及PT环境进行验证，并维护验证结果记录。
2. 字段修复限制与后续处理
- 手机号与经纬度修复受限：由于出货表手机号为密文，签收表为明文，SQL脚本无法直接修复手机号字段；同时签收表无经纬度信息，无法回补至出货信息。
- 业务共识与代码修复：若业务侧坚持修复手机号字段，需编写代码进行解密转换后再回补，目前暂定为"先修复大部分数据，少量数据待定"。
- 业务侧确认：需与产品运营团队确认无法修复字段的接受度，以及是否必须修复手机号字段。
二、鲜度盘点表数据修复方案
1. 根因排查与范围界定
- 缺失原因分析：初步排查为历史数据迁移过程中，基础码表（Mongo）缺失了货权经销商名称信息，导致落表时无法获取五段及经营范围。
- 数据范围界定：当前涉及数据量约 17000条，需进一步确认是"编码和名称全为空"还是"仅有编码无名称"的不同情况。
2. 方案修正与待办
- 方案驳回与重写：王建朝指出当前方案未明确区分不同缺失场景，要求重新梳理技术文档，明确问题产生原因及修复逻辑。
- 数据统计要求：孙传熙要求补充修复数据的
take_stock_day字段的最早和最晚日期，以便后续手动拉取数据。
三、待办事项
| 序号 | 待办事项 | 负责人 |
|---|---|---|
| 1 | 与产品运营团队确认无法修复字段（手机号、经纬度）的接受度，并同步修复进度 | @张喜 @马奇 |
| 2 | 确认手机号字段是否必须修复，若必须修复则需变更技术方案编写代码 | @余建新 @辉哥 |
| 3 | 梳理鲜度盘点表数据缺失的具体原因（区分全空与仅缺名称），更新技术文档并重新提交评审 | @韩冬冬 @张喜 |
| 4 | 提供鲜度盘点表修复数据的 take_stock_day 字段日期范围 | @韩冬冬 |
技术评审-MAC-B端出货明细表日常开单/自主签收补数据
晓娜、建新： 已完成针对【B端出货明细表日常开单/自主签收补数据】的技术评审，现将评审结论、风险判断及后续执行安排同步如下，便于各方对齐认知并落实执行。
项目名称：营销活动中心 评审时间：2026/05/12 10:30 - 11:30 参与评审人：宋洋、粱健、吕杰、韩冬冬、贾继伟、王建朝、秦丽娜、孙传熙、朱学通、余建新、张喜、邱毅
评审结果：通过。
核心讨论：
- 回补内容共识：由于出货表手机号为密文，签收表为明文，SQL脚本无法直接修复手机号字段；同时签收表无经纬度信息，无法回补至出货信息。
- 全量回补范围确认：经产品经理确认并共识，决定对2026年1月1日至今的数据进行全量回补，涉及日常开单约 224万条，自主签收约 375万条。
- SQL执行可行性评估：数据清洗脚本分为2个SQL，分别对自助签收、日常开单两类数据进行清洗。学通已确认方案在StarRocks可行。
- 执行要求：先在PET环境进行验证，通过后再在生产实施变更。
方案地址： https://yldc.coding.yili.com/p/sip-mac/wiki/31997
技术评审-MAC-新鲜度盘点明细表清洗货权经销商信息
晓娜、建新： 已完成针对【新鲜度盘点明细表清洗货权经销商信息】的技术评审，现将评审结论、风险判断及后续执行安排同步如下，便于各方对齐认知并落实执行。
项目名称：营销活动中心 评审时间：2026/05/12 10:30 - 11:30 参与评审人：宋洋、粱健、吕杰、韩冬冬、贾继伟、王建朝、秦丽娜、孙传熙、朱学通、余建新、张喜、邱毅
评审结果：不通过。
技术方案中数据修复的内容与原因不匹配，方案的准确性不具备评审条件。需对齐问题后更新技术方案，再次发起评审。