题目重点：DE 电面明确要求把 SaaS app sources 汇入单一 analytics layer；本文从实体映射、原始层、增量同步、模型口径与回填验收展开。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练场景有 CRM、billing 与 support 三类 SaaS 源，分别有客户、订阅与工单；统一分析层需要按 tenantId 隔离。源种类是示例，不冒充题目细节。
- 目标为小时级新鲜度、日级历史重算；源 API 可能只提供游标分页或 updatedAt，不保证每个源都有 log-based CDC。业务方需先定统一 customerId 和指标版本。
解题路线
- 先列出业务查询：按客户看收入、工单和生命周期。为每个 SaaS 源建 connector，记录授权范围、速率限制、游标、高水位和 API 快照语义。
- 原始层按源保留不可变 payload、sourceRecordId、extractAt 与版本；增量层以源主键+更新版本去重，删除需有 tombstone 或全量对账，不能只扫 updatedAt。
- 在 staging 做类型、时区、币种、枚举与身份映射，给每条记录留 lineage；分析 mart 维护按 tenantId 和业务时间的事实/维度表，SCD 处理可变客户属性。
- 对 schema evolution 分兼容新增列与破坏性变更；回填时重用同一转换代码与指标版本，写入隔离分区，校验行数、金额和唯一键后原子切换。
- 对外查询限定权限与成本，监控采集延迟、异常率、缺失率、重复率、对账差异和 query latency；上游故障时显示数据新鲜度。
手动走一遍
CRM 的 customer C1 与 billing 的 account B7 经映射到内部 customerId U9；billing 更新一条 100 美元订阅后，原始层保留 payload v2，staging 用 (source,id,version) 去重，mart 的本月收入增加 100。若旧 v1 迟到，不覆盖 v2；若身份映射修正，用同一版本转换从原始层重算 U9 的指标。
规模与取舍
设每小时输入 R 条、保留 D 天、平均原始记录 S 字节，原始存储约 O(24RDS)；每条规范化与去重若按键索引通常期望 O(1)，身份 join 与聚合成本依热点和分区而变。示例每小时 100 万条、1KB、30 天约 720GB 原始 payload，未计副本和索引。
易错点与追问
容易失分的边界
- 把所有 SaaS 的 email 当统一身份主键，忽略换邮箱、共享邮箱和租户边界。
- 只凭 updatedAt 拉增量，漏掉删除、迟到和上游时钟错误。
- 回填直接覆盖在线 mart，导致查询在新旧指标版本间混用。
- 原始层不留 source/version，指标错时无法追查和重算。
- 只讲 ETL 计算而不定义目标分析查询和权限。
继续深挖
- 上游 API 没有删除事件，怎样检测删除且控制全量扫描成本？
- 同一客户在三个 SaaS 源有冲突属性，谁拥有字段优先级？
- 小时级新鲜度降到分钟级，对 API 配额与架构有何影响？
- 历史汇率和货币换算应放在什么层，如何重算？
