题目重点：Uber 系统设计面经中的开放型数据平台题。拆解事件契约、采集去重、session/funnel、实时与离线特征、回填、数据质量和模型消费边界。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 核心输入为 App 行为事件，如按钮点击、转化、订单完成、退款、评价；每个事件包含 eventId、user/anonymous ID、eventTime、serverReceiveTime、schemaVersion、事件类型及业务关联 ID。
- 核心输出是可复用的清洗事件、session/funnel 指标和带时间语义的模型特征；具体模型标签、在线延迟和保留期题目未明确，需先与使用方确认。
- 同一 eventId 重试只能计一次；用户跨设备登录、匿名转实名、撤销同意及隐私删除须定义身份和治理规则，不能默认全量可联接。
解题路线
- 入口 SDK/服务端共同定义事件 schema、版本和字段来源；摄入层按身份/会话分区写持久日志，验证必需字段、合法时间与同意状态，将无效记录隔离到可排查队列。
- 流处理按 eventId/业务 ID 去重并在事件时间上设置水位线，生成 session、点击→转化→完成→退款等可配置 funnel；迟到事件触发受控修正或离线重算，不能只靠处理时间窗口。
- 原始不可变事件进数据湖用于重放与审计；清洗标准层、聚合指标层、特征层分别带 schema/代码/数据版本。在线特征更新需要与训练集同口径并监控新鲜度和缺失率。
- 模型使用方先明确预测时点与目标，做 point-in-time join 防未来信息泄漏；指标使用方需要可追溯分母、身份合并规则和退款回写口径。
手动走一遍
一次用户点击按钮、下单、支付完成、两天后退款。点击转订单的转化率以已定义的曝光/点击分母计算；退款不能凭后到事件改写原始点击记录，而应生成可追溯的订单状态变化与按版本重算的净转化/退款指标。训练特征只包含预测时点前已知信息。
规模与取舍
设事件摄入速率 E、单条平均大小 B、保留 T 秒，原始存储约 E×B×T（压缩和副本另计）；状态规模随活跃用户/session 数、去重保留窗口与未完成 funnel 增长。常见流式处理单事件期望 O(1) 更新，回填成本与需重算的事件区间线性相关。
易错点与追问
容易失分的边界
- 只画采集 API 和 dashboard，忽略如何把原始事件加工为模型可用的数据资产，正是题目所述面试追问。
- 训练/在线特征口径不一致或把未来退款结果并入过去特征，会造成数据泄漏和上线性能落差。
- 只按 eventId 去重不一定解决业务重复：客户端重试可换 eventId，重要业务动作要再以订单/支付业务键做幂等核对。
继续深挖
- 如果模型目标尚不清楚，先交付通用事件标准层与少数高价值漏斗/特征，并向下游收集目标、预测时点与 SLA，而不是预先制造海量无主特征。
- 针对 schema 演进和回填，实行兼容检查、双读或版本迁移、回填隔离资源及数据质量门槛；监控事件量、字段缺失、迟到率、漏斗守恒与训练在线特征偏差。
