|
@@ -353,3 +353,45 @@
|
|
|
- 迁 Spark 3+ / Iceberg / Hudi / Delta Lake 后改 MERGE INTO（更优）
|
|
- 迁 Spark 3+ / Iceberg / Hudi / Delta Lake 后改 MERGE INTO（更优）
|
|
|
- dim 表数据量增长导致 sche shuffle 性能下降，评估改"分区裁剪 + 局部重算"
|
|
- dim 表数据量增长导致 sche shuffle 性能下降，评估改"分区裁剪 + 局部重算"
|
|
|
- 业务库消除"主动置 NULL" 场景后，可放宽到字段级 COALESCE 简化写法
|
|
- 业务库消除"主动置 NULL" 场景后，可放宽到字段级 COALESCE 简化写法
|
|
|
|
|
+
|
|
|
|
|
+### ADR-09 DWD 事件表跑批回算窗口 N=2
|
|
|
|
|
+
|
|
|
|
|
+- **状态**：已采纳
|
|
|
|
|
+
|
|
|
|
|
+ 本项目 ods 层按 ADR-03 严格按 `update_time` 归位 dt（双源 union 完整捕获 `update_time ∈ [T-1, T)` 范围所有版本），dwd 事件表理论上单分区扫 `ods.dt=T-1` 即可拿到所有"业务时间 T-1 + update_time T-1"的事件。
|
|
|
|
|
+
|
|
|
|
|
+ 但业务库 OLTP 写入业务事件时间（如 `payment_success_time`）与 `update_time` 不一定严格同步刷新——典型场景：跨零点支付，`payment_success_time = T-1 23:59:59.500`，业务库 ORM 延迟 600ms 刷 `update_time = T 00:00:00.100`，该行落 `ods.dt=T`；事件本应归 `dwd.dt=T-1`，但 dwd 单分区扫 `ods.dt=T-1` 拿不到。这种漂移在业务高峰跨零点场景下不可忽略。
|
|
|
|
|
+
|
|
|
|
|
+ 本项目第一张 dwd 事件表 `dwd_trd_order_pay_apd_d` 落地反复讨论后定下范式（5/9 一度采纳"信 OLTP 契约不回算" → 5/10 自破契约编漂移场景 → 复盘 sessions 5/9 T8-T10 发现违反共识 → 用户重新拍"后端不可信"→ 业界范围 N=2/3 拍 N=2 → commit `a9b6eaa`）。
|
|
|
|
|
+
|
|
|
|
|
+- **决策**：DWD 事件表跑批回算近 N=2 日：
|
|
|
|
|
+
|
|
|
|
|
+ - sche sched=T 时，扫 `ods.dt IN (${dt}, ${pdt})`（即 T-1 + T-2）
|
|
|
|
|
+ - 过滤业务时间 `DATE(business_event_time) IN (${dt}, ${pdt})`（如 dwd_pay 用 `payment_success_time`）
|
|
|
|
|
+ - 写入 dwd `dt IN (${dt}, ${pdt})`：`INSERT OVERWRITE PARTITION (dt)` 动态分区，kb/26 §8 项目默认 DYNAMIC mode 只覆盖 SELECT 出现的 dt，不动其他历史分区
|
|
|
|
|
+ - `dwd.dt=T-1` 在 sched=T 跑批时首次写入；sched=T+1 跑批时通过扫 `ods.dt=T` 兜回业务时间 T-1 漂移到 `ods.dt=T` 的事件，重写 `dwd.dt=T-1`
|
|
|
|
|
+ - N=2 业界主流（阿里 OneData / 字节 / 美团默认）
|
|
|
|
|
+
|
|
|
|
|
+- **后果**：
|
|
|
|
|
+
|
|
|
|
|
+ - 正面：
|
|
|
|
|
+ - 兜底跨零点 ods 漂移（业务库 `update_time` 不严格同步刷新场景）
|
|
|
|
|
+ - 不依赖 OLTP 应用层契约的强假设
|
|
|
|
|
+ - 与 kb/20 §7.3 通用兜底一致
|
|
|
|
|
+ - 负面：
|
|
|
|
|
+ - 每个 dt 分区被回算 2 次（首次 + 次日兜底），写入 / 计算成本上升 2×
|
|
|
|
|
+ - 动态分区写入需注意 dynamic mode 默认行为（kb/26 §8 已实测）
|
|
|
|
|
+
|
|
|
|
|
+- **候选方案**：
|
|
|
|
|
+
|
|
|
|
|
+ - **N=1 单分区不回算**（5/9 一度采纳）：基于"业务库 update_time 与业务事件时间同步刷新 OLTP 契约"假设；OLTP 后端实际不可信，跨零点漂移会永久丢失事件——否决
|
|
|
|
|
+ - **N=3 回算近 3 日**：偏保守，金融 / 强稳定性场景；本项目业务侧无此强稳定性需求，2× 写入对齐业界默认即可——否决但留作"业务库延迟 > 1 天频繁时上调"反悔触发
|
|
|
|
|
+ - **N=7 回算近 7 日**：极端保守，少见——否决
|
|
|
|
|
+ - **MERGE INTO**（Spark 3+ / Iceberg / Hudi / Delta Lake）：不需回算逻辑，引擎原生 upsert 处理漂移——本项目 Spark 2.4 不支持，本阶段不取
|
|
|
|
|
+ - **延后 1 天跑批**（sched=T+1 写 dwd.dt=T-1，扫 ods.dt IN (T-1, T)）：dwd 数据延迟 1 天可用，下游标签延迟，业务侧不可接受——否决
|
|
|
|
|
+
|
|
|
|
|
+- **反悔条件**：
|
|
|
|
|
+
|
|
|
|
|
+ - 业务库延迟 > 1 天的漂移场景频繁出现（如系统升级 / 故障恢复多日数据回流），N 上调到 3 或更大
|
|
|
|
|
+ - 迁 Spark 3+ / Iceberg / Hudi / Delta Lake 后改 MERGE INTO（更优）
|
|
|
|
|
+ - 业务侧能严格保证 OLTP 应用层契约（update_time 与事件时间同步刷新），可降到 N=1（实际很难保证）
|
