加载顺序是什么
维度与事实的加载顺序指同一调度批次内必须先加载维度、再加载事实，保证事实能解析到对应的版本代理键；补数与回刷同样遵循先维后事。顺序颠倒的后果是事实大量落到未知成员键，等到回刷时才发现，而回刷又要改写历史分区，成本比一开始排对顺序高出几个数量级。分层上体现为 ods 到 dim，再到 dwd 事实，最后 dws 汇总。
基本信息
| 标准顺序 | ods 同步 → dim 合并 → dwd 事实 → dws 汇总 |
|---|---|
| 补数顺序 | 先确认维度已含目标时间的版本，再重跑事实 |
| 失败处理 | 维度作业失败时阻断下游事实作业，不要放行 |
| 检查手段 | 未知成员占比与零当前行校验放在事实加载之前 |
| 跨任务依赖 | 用调度依赖而非时间先后隐含保证 |
典型使用场景
- 日常调度：批次开始时先跑维度合并，再跑事实解析代理键
- 补数排期：重跑某天事实前，先确认该天的维度版本已生成
- 迟到维度兜底：维度确实到不了时先落未知成员键，维度到位后回刷
- 故障恢复：上游主数据断供时阻断下游，避免大面积未知成员
- 跨团队协作：外部团队负责的维度表要显式声明依赖，不靠时间猜
- 回刷联动：维度回刷后必须连带重跑受影响的事实分区
调度顺序
调度顺序
1. ods_customer 同步上游主数据
2. dim_customer 合并生成新版本（含当前行唯一性校验）
3. 校验 未知成员占比、零当前行检查
4. dwd_order 解析 customer_sk，关联当前版本
5. dws_* 按维度汇总
补数：先确认 dim_customer 已覆盖目标业务日期的版本，再重跑 dwd_order 对应分区顺序与后果
| 情况 | 表现 | 处理 |
|---|---|---|
| 维度先、事实后 | 正常，代理键解析成功 | 标准排法 |
| 事实先、维度后 | 事实大量落未知成员键 | 需回刷历史分区，成本高 |
| 维度作业失败仍放行下游 | 未知成员占比骤升 | 应阻断下游并告警 |
| 补数只重跑事实 | 目标时间版本不存在，仍然落未知成员 | 补数脚本必须包含维度步骤 |
| 维度回刷后不重跑事实 | 事实指向旧代理键，属性与事实不匹配 | 维度回刷后联动重跑事实 |
不要靠「上游通常半小时能跑完」这类时间经验来隐含保证顺序，必须写成显式的调度依赖。跨团队场景尤其如此：对方作业时间调整一次，就会造成一整批事实落在未知成员键上，而回刷影响的可能是几百个历史分区。