1. 题目
公司希望了解桌面客户端哪些功能最常用、不同版本的崩溃类别和地区级性能分布。每天约有 2,000 万活跃设备，每台设备最多产生 200 条遥测事件；产品团队要求 24 小时内看到聚合趋势，但隐私团队禁止平台保存可还原的用户行为时间线。
请设计隐私保护的遥测与分析平台。重点说明端侧采集边界、事件格式、匿名化或本地随机化、中心侧差分隐私、用户级贡献上限、预算与查询接口、可靠性、删除请求、权限和验证。请明确哪些问题不能用“把 ID 哈希一下”解决。
2. 约束与澄清
- 隐私单位优先按用户或设备定义，而不是把每条事件视为独立个体；必须说明设备共享和多设备用户的边界。
- 只允许收集预先登记的事件名称、版本、粗粒度地区、性能桶和必要的错误类别；禁止原始 URL、自由文本、完整 IP、精确位置和内容载荷。
- 统计结果按至少 24 小时窗口发布，要求小群体抑制、差分隐私预算和可追溯的查询审计。
- 遥测允许丢失和延迟，但不能因为重试、缓存或多副本让单个用户贡献被无限放大。
3. 总体架构与数据流
端侧 SDK 先执行事件白名单、字段裁剪、值域限制和本地采样，再将批次写入带版本的遥测队列。入口服务验证签名、大小、时间窗和速率，但不把账号令牌当作分析键。流处理层做用户级去重、贡献上限、时间窗口聚合和异常过滤；原始短期缓冲区设置严格 TTL，长期仓库只保存受保护的聚合中间结果。
client SDK
-> schema/allowlist + local sampling + coarse buckets
-> encrypted batch with rotating upload token
-> ingestion gateway (auth, size, rate, replay checks)
-> stream buffer
-> privacy transform (user contribution cap, clipping, optional local noise)
-> aggregate store
-> DP query service (budget, minimum group, audit)
-> dashboards and export API端侧随机化可以在不可信收集器前保护单次报告，但会降低准确率；中心式差分隐私适合可信内部聚合器统一管理用户级预算。混合方案要明确每一层的威胁模型和保证，不能把多层噪声简单相加后宣称更强隐私。
4. 数据模型、最小化与去重
事件包含 event_type、客户端版本、粗粒度地区、性能桶、事件时间桶和协议版本。上传批次带随机批次 ID、过期时间和签名；服务端用短期内部键做幂等，不把稳定用户标识写进长期分析表。
同一用户在窗口内对某功能的多次事件应按预先规则计数，例如每个用户每天每功能最多贡献一次。贡献上限必须在用户级执行，不能只在机器或批次级裁剪；否则攻击者可以拆分批次绕过限制。崩溃堆栈、错误文本和 URL 需要在端侧分桶或丢弃，避免自由文本成为隐性身份标识。
删除请求需要定义可执行范围：若长期仓库只保留不可逆的差分隐私聚合，通常无法从聚合中准确删除单个用户；仍要删除短期原始缓冲、撤销后续采集，并在产品政策中说明聚合发布的不可逆边界。
5. 隐私预算、可靠性与查询接口
查询服务按隐私单位、数据集和时间窗口维护 epsilon/delta 预算。每个正式查询先校验预算、最小群体阈值和允许的维度，再从版本化聚合表生成带噪结果并写审计记录。相同逻辑查询的重试必须返回幂等结果或只记账一次；任意增加筛选维度都可能消耗额外预算。
事件上传采用至少一次传输。端侧批次可重试，入口以批次令牌去重；流处理按用户和时间桶去重，并将无法确认的迟到事件放入隔离队列。丢包、延迟和采样率必须进入质量指标，否则仪表盘的下降可能被误判为产品行为变化。
系统容量按 2,000 万设备、每台每天最多 200 事件估算理论上限为 40 亿事件/天；实际设计应使用采样、批量压缩和分区存储，并为版本发布、崩溃风暴和重放保留余量。查询层要限制高基数切片、并发导出和跨窗口 join，防止预算与资源同时被耗尽。
6. 追问与陷阱
- 哈希设备 ID 是否匿名？ 稳定哈希仍可跨事件关联，结合外部数据可能重识别；应优先短期令牌、粗粒度字段和用户级聚合。
- 端侧噪声和中心侧噪声如何选？ 端侧模型降低对收集器的信任要求但方差更大；中心模型便于统一预算和查询，前提是聚合器与原始缓冲的访问边界可信。
- 如何处理崩溃风暴？ 端侧采样和速率上限先保护用户与入口，网关隔离异常版本，队列背压和降级查询保护下游；不能只扩容数据库。
- 能否回答任意分析问题？ 不能。白名单指标、最小群体、预算会计和维度限制是产品契约；探索需求应走审批和独立预算。
7. 验证与运行指标
- 隐私性质： 用相邻用户数据集测试贡献上限、噪声校准、预算组合和查询拒绝，审计每个发布版本的参数。
- 数据质量： 监控采样率、覆盖设备数、重复率、迟到率、丢包率、版本分布和窗口完整度，并与受控合成数据对账。
- 可靠性： 故障注入入口、队列、聚合器和预算服务，验证重试幂等、背压、隔离队列、恢复点和无原始数据泄露。
- 滥用防护： 测试高维查询、并发导出、预算耗尽、权限越权、批次重放和自由文本注入，确认都有拒绝或降级路径。
8. 面试评分点
能画出隐私边界和数据流
候选人应明确端侧、入口、短期缓冲、聚合层和查询层分别信任什么、保存什么、何时删除。
能把用户级贡献落实到实现
应说明按用户和窗口去重、贡献上限、裁剪、批次幂等与迟到事件处理，避免只在文档里写“匿名化”。
能把预算与可靠性一起设计
应覆盖 epsilon/delta 会计、重试只记账一次、最小群体、查询维度限制、背压和故障恢复。
能给出量化验证方案
应使用 40 亿事件/天的上限估算，提出隐私性质、数据质量、可靠性和滥用测试，而不是只给组件清单。