|
|
@@ -162,9 +162,18 @@ RDS PG / ES ──DataX──▶ RAW ──SparkSQL──▶ ODS ──▶ DWD
|
|
|
|------|----------------------|----------------------|
|
|
|
| 订单履约（下单 → 支付 → 发货 → 签收，单向） | 4 张 `_apd_d` | `dim_trd_order_zip_d` |
|
|
|
| 拼团（发起 → 审核 → 审核拒绝 → 重新提交 → ……，循环） | 每个动作一张 `_apd_d`（含"审核拒绝"、"重新提交"等可重复事件） | `dim_trd_group_zip_d`，每次状态变更生成新拉链行 |
|
|
|
-| 浏览 / 点击 / 加购（独立事件流，无状态实体） | 各一张 `_apd_d` | 无 |
|
|
|
+| 浏览 / 点击 / 加购等行为日志（埋点） | **一张统一事件明细表**（见下"行为日志域例外"），非各拆一张 | 无 |
|
|
|
| 订单 vs 订单明细行（一对多） | 各一张 `_apd_d`（粒度不同必拆） | 无 |
|
|
|
|
|
|
+**行为日志域（埋点）例外——不按业务过程拆，走统一事件明细表**：
|
|
|
+
|
|
|
+上表"每业务过程一张"是 **业务过程事实（交易/履约域：下单/支付/发货/退款）** 的范式——过程少、语义重、结构各异，拆开干净。**行为日志（埋点点击/浏览/曝光/分享）是另一个域，反着来**：
|
|
|
+
|
|
|
+- 行为事件**种类极多**（HS 现 197+ 且在长）、浅、结构同构（公共属性 + `params`）。沿用"每动作一张表"会表爆炸；且 event explosion 下同名"点击"含异构 params，拢不进一张 typed 表。
|
|
|
+- **正确做法：一张统一埋点事件明细表**——`event_name` 作列承载行为大类，公共维度拍平成列，`params` 保持半结构化（`map`/`json`）、不 per-event 拍平。要"点击表/浏览表"用 `WHERE event_name=...` 过滤，不必物理分表。
|
|
|
+- **核心业务转化事件**（支付/退款等真业务过程）从日志表**毕业**，按本节范式独立成 typed 事实表（如 `dwd_trd_order_pay_apd_d`）。
|
|
|
+- 前提：事件粒度已收敛为行为大类；未收敛前（当前 event explosion）用统一表 + `params` map 兜底。详见 `93-架构决策.md` ADR-13。
|
|
|
+
|
|
|
**循环状态机的处理**：业务流程若存在循环（如拼团审核可能多次反复："提交 → 拒绝 → 修改 → 再提交"），事件流水（`_apd_d`）天然支持任意次重复——每次状态变更追加一行，完整还原过程；DIM 拉链表（SCD Type 2）每次状态变更生成新行，旧行 `end_date` 置变更前一天，状态历史完整可回溯。
|
|
|
|
|
|
**何时可考虑 acc**：固定线性里程碑场景（不循环、里程碑可枚举且单向推进，如严格不可逆的合同审批流程），如有具体场景按需单独评估，**不一刀切禁用**。新建 acc 表时在 PR / 设计稿里说明选型理由。
|
