原始输入怎样变成可信明细？
用三种小而关键的处理，把原始账户余额快照整理成可核对的 DWD 明细。
原始快照多一行，指标就可能多算一笔余额
原始输入怎样变成可信明细？
进入稳定加工层前，只处理三件会直接改变结果的事：给重复快照找保留依据、保留缺失维度的余额、统一表达相同含义的币种编码。
清洗的目标不是把异常藏起来，而是让进入 DWD 的每一行都有可解释的来源。
核心概念
可信明细
可信明细保留稳定的数据粒度和金额来源：重复记录有保留依据，缺失关联不会静默丢失，字段编码在进入后续聚合前已经统一。
去重不是“随便留一条”
A001 在同一个快照日出现两条余额：98,000 和 100,000。它们不是两笔余额，不能直接相加。`updated_at` 给出了一个业务上可解释的选择依据：保留更新时间更晚的 100,000。
去重规则写不出依据时，结果就无法复核。`ROW_NUMBER()` 只是表达这个选择的工具，真正需要先确定的是业务键和保留规则。
- 业务键：account_id + snapshot_date。
- 保留依据：updated_at DESC。
- 变化证据：重复前 5 行，去重后 4 行；A001 只留一条。
DWD 明细 · 清洗前后对照
三类异常各自留下什么证据？
切换原始输入和 DWD 明细，查看行数、余额合计与异常标记。A003、A004 的余额仍在，只是缺失维度显示为 NULL。
正在加载交互实验…
LEFT JOIN 的价值是保住事实行
A003 的账户关系指向不存在的 Customer C404，A004 指向不存在的 Product P404。如果为了写法简短直接使用 INNER JOIN，余额记录会在关联时消失，最终只看到“少了两行”，却不知道少的是谁。
DWD 保留这两行，并把缺失的属性留为 NULL。后续是否纳入某张指标卡，可以根据指标条件决定；这和在加工中把事实行删掉是两件事。