题目重点：从 Netflix VO 的大数据上传受众定向题出发，设计上传会话、校验、去重、版本发布、在线 membership 查询与隐私删除链路。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练例广告主上传的是经授权的 pseudonymous audience member IDs，而非明文 PII；题目只说 big data upload，真实隐私与合同要求需确认。
- 在线投放按 (audience_version,member_id) 查询是否命中，目标是低延迟；受众变更先构建新版本后原子切换，不让半成品对线上可见。
- 训练示例用 100M ID、每天一次全量或增量上传来做容量讨论，数值非题目数据。
解题路线
- 上传服务创建带幂等 id 的 session，签发分片对象存储上传地址，客户端并行上传 chunk；记录校验和、大小和完成清单。避免请求处理线程直接接收超大文件，过期未完成 session 可回收。
- 异步校验格式、权限、ID 范围、重复率、恶意/损坏文件和预估规模；流式去重后按 audience id 与 hash(member_id) 分片建索引。匹配所需的 hash/salt 版本和身份映射要一致，不能假设不同来源 hash 可直接相等。
- 完成构建和抽样校验后发布 immutable audience_version，线上服务从当前版本指针读取，部署采用 canary 与回滚。缓存可用 Bloom filter 做否定预筛，但阳性仍查精确索引；若业务允许误投需另明示。
- 删除/撤销受众时先停止新投放、切换指针，再向缓存、索引、对象存储、离线副本传播删除与审计；保留期限和用户 opt-out 必须纳入数据生命周期。监控上传完成率、索引延迟、命中率、版本滞后与删除传播时间。
手动走一遍
训练例 audience v7 正在线上使用，广告主上传 v8 的 100M ID。分片上传和去重完成前所有查询仍用 v7；v8 校验通过后指针原子切换，灰度发现匹配率异常即可回滚 v7。若 v8 中有 opt-out 用户，删除事件应压过版本快照，避免回滚重新使其可投。
规模与取舍
N 个上传 ID，流式解析/去重与索引构建预期 O(N)，存储和网络也至少 O(N)；精确 membership 查询可通过分片哈希索引预期 O(1)，但分片 RPC 和缓存命中决定实际延迟。Bloom filter 的内存与假阳性率须按 N 和目标误判率估算。
易错点与追问
容易失分的边界
- 上传过程中直接更新线上集合，导致用户看到一半旧版一半新版。
- 把相同 hash 当成可跨平台互通身份，不核对 salt 和授权。
- Bloom filter 阳性直接投放，误投不可控。
- 只删除主库而忽略缓存、离线副本与旧版回滚。
- 把示例 100M/每日更新当作面经给定规模。
继续深挖
- 广告主上传增量 add/remove 如何合并到版本？
- 用户 opt-out 与广告主批量上传竞态时谁优先？
- 跨区域在线投放需要多新鲜的 audience 版本？
- 如何在高基数与热点 audience 之间分配索引和缓存？
