我把GEO采样戳从落盘挪到入库，跑批分母从12变18，凌晨两点半才想明白问题在哪

兄弟们，凌晨两点半，我又在跟跑批日志大眼瞪小眼。

起因特简单：我们 G说了算的跑批任务，之前分母一直稳定在 12 条左右，结果今天改了一行代码——把采样戳的写入位置从「落盘时」挪到了「入库时」——分母直接跳到 18。多了 6 条，数据组那个哥们儿差点以为我埋了脏数据。

我扒了三个小时的日志，终于对上了。

先说结论：采样戳写在哪，直接决定了同一条问句会不会被重复计数。 我们的链路是「采集 → 落盘 → 入库 → 归一化」，之前采样戳在落盘时打，每条问句只有一个戳，去重没问题。现在挪到入库时打，问题来了——入库前有个缓冲队列，队列重试机制会把同一条记录再推一次。落盘的时候只落了一次，但入库重试的时候，每条都会被当成新记录再打一个采样戳。

所以分母从 12 变 18，多出来的 6 条全是重试记录。虚高 50%。

怎么发现的？ 我拿同一批问句跑了两次，一次旧逻辑一次新逻辑，然后用问句原文做 join。新逻辑里那 6 条多出来的，原文全都一模一样，只是采样戳差了 200 毫秒。

我的判断依据是三条：

1. 落盘文件的记录数是 12，入库表的记录数是 18，差异全在重试路径上。
2. 多出来的记录，采样戳都不是原始时间，而是重试时间。
3. 归一化之前没有对采样戳做去重，直接拿它当分母了。

所以现在有两个坑要填：

• 采样戳到底该在链路的哪个节点赋？落盘前赋，重试会带原始戳；入库时赋，重试会带新戳。我倾向于落盘前赋，但落盘前有些字段还没补全，很纠结。
• 归一化到底该在采样戳之前还是之后？如果归一化放在前面，能靠内容哈希去重，但采样戳就失去时间维度的意义了。

我现在暂时把采样戳挪回落盘前，分母回到 12，但心里不踏实。凌晨两点半的教训就是：改一个字段的位置，分母直接给你跳 50%，这种虚高只有拿原始日志逐条 join 才能抓出来。

问一下社区里跑过批的兄弟们，你们跑批链路的采样戳是在哪个节点赋的？归一化是放在赋戳之前还是之后？有没有人踩过类似的坑，最后是怎么收的？在线等，挺急的，明天还要给老板解释为什么数据对不上。