GEO跑批把问题ID和时间源分开存，我踩了回填的坑，求大佬指点

各位大佬，求指点！我又来倒苦水了。

上周我们跑GEO批次，出了个特别诡异的事：同一批问题ID，早班跑出来43条异常，晚班重跑变成47条。我第一反应是脚本被人改了，查了git记录没人动。后来把日志拉出来逐行对，才发现问题不在脚本，在我们存问题ID的姿势上。

我们之前是把「问题ID」和「时间源」揉在一个字段里存的，形如 Q001_20240612T030000。设计的人当时说这样一眼能看出这条问题是几点几分抓的，方便排查。听着挺合理对吧？结果重跑的时候，时间源变了（换了一台机器，NTP对表差了快4秒），拼接出来的串就不一样了。系统按字符串去重，同一道问题被当成两条，分母直接虚高。43飘到47，飘的4条全是这么来的。

更坑的是回填。我们发现问题后想把旧批次的数据按新规则重算，结果因为ID变了，历史记录对不上，回填脚本跑一半就报主键冲突。技术说要么整批作废重跑，要么手动改ID。整批作废的话，那天的数据就断了；手动改ID的话，谁保证改完的时间源跟原始批次一致？改完的ID还能不能追溯到原始抓取？我卡在这两天了，越想越觉得当初就不该把问题ID和时间源塞一起。

我现在倾向的方案是：问题ID只保留业务语义部分（比如Q001），时间源单独开字段存，并且锁死——跑批开始前先把时间源快照写进批次元数据，同一批次内所有问题共用同一个时间源，不允许中途换。这样重跑时只要批次ID一致，时间源就一致，ID就不会飘。但我拿不准的是：如果时间源单独存了，那做时间维度分析的时候会不会反而变麻烦？比如我想看「下午三点的问题异常率」，是不是得join两次表？

还有个更细的坑我想顺便问：时间源到底该记抓取发起时间还是响应返回时间？我们现在记的是发起时间，但有一次网络延迟特别大，响应回来都过了快两分钟，那这条问题算三点的还是三点的？分母到底该按哪个口径？我真的是被这个「时间源」搞疯了，43飘47、分母虚高8到21条，每次都是它。

求大佬指点：问题ID和时间源到底该不该分开存？分开的话时间维度分析怎么设计才不绕？还有那个发起时间vs返回时间的口径，你们一般怎么定？跪谢！