题目重点：根据多篇广告报表设计记录，拆解 click/view 事件统一、按地域和人群维度聚合、历史重算与指标口径。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版原始两源都包含稳定 eventId、eventTime、adId、userId 和 click/view 类型；若真实源缺字段，须定义合成去重键与误差。
- 报表以事件时间的 UTC 日为基准，按 adId、日期、地域、性别、年龄段聚合；用户人口属性取事件时快照，不用当前属性回写历史。
- 历史一年查询可分钟级完成，近实时看板和账务级精确性分开；这些是训练设计目标。
解题路线
- 为两路 logging API 建适配层，统一 schema 与事件类型，验证时间戳和 ID，并保留 sourceId、原始 payload 引用用于追溯。
- 先按全局 eventId（或可证明等价的业务键）去重，再按事件时间与统一维度口径聚合；click 和 view 分开计数，CTR 从两者比值得出。
- 原始事件写可回放存储，流处理按 watermark 处理迟到数据并更新近实时增量；每日批处理从原始分区重算，可纠正延迟和重复。
- 查询层保存预聚合立方体或按常用维度物化表，支持日期范围及过滤；罕见高维组合可回退列存扫描，防止维度爆炸。
- 定义版本化指标口径、人口属性隐私处理与小人群阈值，监控双源丢失、重复率、迟到率和流批对账差。
手动走一遍
同一 click 在 SDK 和网关日志各出现一次，带相同 eventId 时只计 1；用户事件时在 25–34 年龄段，半年后年龄进入下一段，重算去年报表仍归事件时年龄段。某天迟到 3 万条 view，批处理重算该日分区并记录报表版本，CTR 随分母变化。
规模与取舍
设日事件数 E、常用维度组合数 G，摄入与去重处理 O(E)，原始存储 O(E×保留期)，预聚合 O(G×日期数)；若随意对所有维度求全组合，G 可能远高于实际查询需求。源日志规模题目未明确，容量应由采样流量推算。
易错点与追问
容易失分的边界
- 将两源计数直接相加，重复曝光和点击被双算。
- 只存聚合，无法对过去一年修正或审计。
- 用查询时的人口属性给历史事件分组，报表会随时间漂移。
- 把所有维度组合预计算，造成巨大存储与维护开销。
- 未说明 CTR 分母、去重和迟到数据口径。
继续深挖
- 两源缺共同 eventId 时，能否保证精确去重？
- 报表需要去年整年但原始日志只保留 90 天，如何满足修正？
- 如何限制小人群切片泄露个人信息？
