技术评审：作弊明细报表五段查询、中奖报表扫码工具、签收激励延迟 3 个方案

项目	内容
日期	2026/01/07 15:20-15:44
参与人	罗洋-爱创研发、张喜-爱创研发、梁健-爱创研发、罗斌-爱创运营、刘莉-爱创测试、陈德智-爱创产品、马奇-爱创项目经理、石磊-爱创数据、孙传照、朱学通、李强、郑然然、王建朝
评审结果	⚠️ 有条件通过

评审结论

经过讨论，本次技术评审方案：原则通过，需要按照评审建议修改并与产品经理进行问题共识后进入下一阶段

核心讨论

一、作弊明细报表销售五段查询条件不生效 1、BC营销出货和扫码查证场景的作弊数据在作弊明细表数据落库时作弊人的销售五段字段为空，需要修复这2个场景的作弊数据处理逻辑，确保后续新产生的作弊数据在持久化时的数据的完整性。 2、涉及到的历史数据通过开发数据修复程序进行历史数据清洗修复，根据作弊人信息补全五段信息。 3、数据中台全量拉取作弊明细表cheat_detail。

二、消费者中奖报表扫码工具展示问题 1、消费者中奖报表中扫码工具展示均为经典，排查发现代码中扫码工具类型默认写死为经典。需增加映射关系根据APP ID参数自动映射扫码工具。 2、数据清洗范围为26.1.1后消费者中奖明细表安慕希相关数据。

三、签收激励发放延迟问题 1、问题表象签收激励发放延迟，原因是业务高峰期间StarRocks数据写入竞争高，采用大数据团队专家建议将insert into方式改为stream load方式，以提升写入效率。 2、长期规划建议在产品架构层面实现 OLAP 与 OLTP 的解耦，遵循‘专库专用’原则，充分发挥专业引擎在各自领域的性能优势。

需要与产品经理共识： 1、建议在后续的产品方案中增加方案的影响范围，尽量在设计初期就识别影响、识别风险，提升系统交付质量。 2、OLAP 与 OLTP 需要从产品架构的源头设计解耦，遵循‘专库专用’原则，充分发挥专业引擎在各自领域的性能优势。

技术方案文档： 1、作弊明细报表销售五段查询条件不生效 2、消费者中奖报表扫码工具展示问题 3、签收激励发放延迟问题

1、作品明细报表销售五段查询条件不生效

• 问题描述：作品明细报表在查询销售五段时条件不生效，特别是在营销出货和扫码查证场景下，销售五段数据未正确落库。
• 解决方案：在营销出货和扫码查证场景的作弊数据落库时增加销售五段字段的查询，并将数据同步到数据库。历史数据清洗需要通过程序批量处理，更新作弊表的销售五段字段。
• 讨论点：表结构中没有更新时间字段，仅有一个作弊时间字段，决定不更新业务时间。

2、消费者中奖报表扫码工具展示问题

• 问题描述：消费者中奖报表中扫码工具展示均为经典，排查发现代码中扫码工具类型默认写死为经典。
• 解决方案：通过小程序传递的APP ID动态判断扫码工具类型，避免前端改动。历史数据清洗仅需处理安慕希的数据，数据量较少。
• 讨论点：表结构中仅有抽奖时间字段，决定仅清洗元旦后的安慕希数据。

3、签收经历发货延迟问题

• 问题描述：高峰期间SR写入延迟，每次消费200条消息写入耗时约2秒，不稳定。
• 解决方案：将insert into方式改为stream load方式，预计写入效率将显著提高。若仍无法满足需求，需考虑更换数据库。
• 讨论点：当前SR写入速度无法满足高时效性需求，建议未来考虑使用关系型数据库如MySQL或PG。
• 优化建议：调整卡夫卡消费参数，增加等待时间以减少批次数量，提高写入效率。

会议待办

尝试使用streamload以提高写入效率，并观察是否能减少延迟

评估将数据提交方式从in sort into改为string load后是否能提高写入效率并减少延迟

为解决消费者中奖报表扫码工具类型固定为经典的问题，需要通过APP ID进行动态判断

为解决销售五段查询条件不生效的问题，需要增加作弊数据落库时的处理逻辑

修改张雪的fetch默认值设置为1秒以解决数据拉取延迟问题

沟通是否可以接受使用mysqlpg关系型数据库以应对streamload的延迟问题