题目重点：Salesforce MTS/SMTS 系统设计面经问类似 ChatGPT 的分析看板，并讨论 DAU、Latency；本文从指标定义、事件采集、预聚合和迟到补算设计可复查方案。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练场景为面向内部产品团队的 AI 聊天产品看板；按 tenant、日期、功能和版本切分。题目只是‘like chatGPT’类比，不能当作真实 ChatGPT 产品的内部指标定义。
- DAU 定义为租户本地自然日内至少发出一次有效用户消息的去重 user_id 数；机器账号、内部测试和删除用户的处理需产品确认。延迟示例定义为用户请求被网关接纳到完整回复完成的端到端时长，同时独立展示首 token 时间。
- 事件有 event_id、event_time、ingest_time、tenant_id、user_id、request_id、feature、model_version、状态和阶段耗时；不在分析事件里保存原始对话内容。
解题路线
- 先列指标契约与分母：DAU 按租户时区转换 event_time 后去重；请求成功率用同一 request_id 的终态去重；延迟只对符合定义的已完成请求计算分位数，并同时展示超时/失败比例，不能仅看成功请求的均值。指标契约写入版本号，定义变更可回溯。
- 客户端/网关产生带 schema 版本的事件，经耐久日志/流入湖仓原始层；校验 event_id 去重、字段类型和时间偏差，坏事件进入隔离队列。实时聚合层按短窗口生成近实时计数与延迟直方图/分位摘要，批处理层按事件时间重算权威日表；看板标记最近数据可能补算。
- DAU 精确去重可按 (tenant,date,user_id) 维护集合或批量 distinct；大量用户时可用近似基数草图，但需在 UI 标注误差。延迟分位数不能由各分区 p95 直接平均；保留可合并的摘要或从原始请求级数据重算。
- 处理迟到与修正：设一个允许晚到的窗口，窗口内增量更新；更晚到达或事件版本修复走补算任务并更新指标版本。租户时区变更按已生效规则记录，不让历史日期无声漂移。查询层保存按 tenant/date/feature 的预聚合，权限检查确保跨租户不可见。
- 上线验收用一小批已知 request_id 人工算 DAU、成功率和延迟，与看板结果对照；监控事件丢失率、重复率、流延迟、补算欠账、查询 p95 与源数据到展示的 freshness。
手动走一遍
训练例：租户纽约时区在 10 月 3 日 23:58 有用户 U 发消息，UTC 时间是次日；DAU 应按租户本地 10 月 3 日计。该请求 10 月 5 日才补到事件流，近实时看板先少 1，权威日表补算后修正。另一个请求完成耗时 8 秒但首 token 0.5 秒，应分开进入完成延迟与首 token 指标，不能混为一个 latency。
规模与取舍
示例若每天 5000 万请求、每请求平均 3 条事件，原始事件约 1.5 亿/日、平均约 1736 条/秒；存储还要按平均事件字节数、保留天数和副本数预算。高基数 user_id distinct 是 DAU 的主要状态成本，延迟分位聚合需可合并摘要；分区按租户/时间设计，既防大租户热点又满足权限与查询。上述数字均为训练假设。
易错点与追问
容易失分的边界
- 直接数消息条数作为 DAU，重复活跃用户被多次计入。
- 把各服务平均延迟或 p95 再求平均，得到不代表整体请求的数值。
- 只统计成功请求的延迟，却隐藏超时和错误造成的用户体验退化。
- 不区分 event_time 与 ingest_time，迟到事件被算进错误日期。
- 看板无指标口径和更新时间，用户把近实时估计误认为已结算的权威数据。
继续深挖
- 如果要看周活跃与留存，如何定义周起点、用户 ID 合并和跨设备去重？
- 若产品团队要求按模型版本看首 token p99，如何避免小样本分组误读并标注样本量？
- 若用户要求删除数据，原始事件、预聚合和缓存应如何按隐私要求追踪清除？
- 若一个超大租户占 80% 流量，如何拆分热分区并保持租户隔离与查询效率？
