|
|
@@ -565,3 +565,41 @@
|
|
|
- 产品坚持不改 → 数仓退守：在 ods 用映射表把长尾事件归一到行为大类（治标不治本）
|
|
|
- 引入半结构化无痛 schema 漂移的引擎（全 JSON + schema-on-read 贯穿），event explosion 的仓库代价下降
|
|
|
- 团队规模 / 分析诉求变化使具名事件 ROI 反超
|
|
|
+
|
|
|
+### ADR-14 小表小文件治理：全量快照（类 1）vs 增量 + raw TTL（类 2）分治
|
|
|
+
|
|
|
+- **状态**：草案（方向记录，待实施）
|
|
|
+
|
|
|
+- **背景**：raw 层小文件累积。查证实况：DataX 每分区落 **1 个文件**（`channel=10` 未 fan-out，并非"每 channel 一文件"），两大交易表分区 ~400KB、fillback 历史大分区 `dt=20211027` 114MB 均健康；碎点集中在**低量小表（panini KB 级）× 按天分区无限增长**。按 ADR-03，raw 是落地暂存、ods 是历史真源（跨 dt 多版本），且 ods 每日只读 `raw.dt IN (${dt}, ${pdt})` 两天——更老的 raw 日分区对日常链路是死重。
|
|
|
+
|
|
|
+- **决策**：按 OneData「全量表（df）/ 增量表（di）」判据（数据量 × 变更率 × 历史诉求）分两类分治，不一刀切统一。
|
|
|
+
|
|
|
+ **类 1 · 全量快照**（`panini_checklist_base` / `panini_checklist_version_config` / `prd_checklist_base` / `shp_tzy_merchant`）：
|
|
|
+ - raw + ods 均改**全量拉**（`where 1=1`，去 update_time 窗）
|
|
|
+ - 生命周期 = 每月末一张 + `dt=20991231` 最新，两任务实现：**月度任务**（每月 1 号跑，落 `dt=上月最后一天`）+ **日任务**（每日覆盖 `dt=20991231`）
|
|
|
+ - 下游维度读 `dt=20991231` 做 SCD1，要历史取月末快照 diff；不走 update_time 增量、不双源 union
|
|
|
+ - 分区数有界（12/年 + 1 哨兵）→ 小文件天然消除
|
|
|
+ - 命名随语义 `_inc_d` → `_ful_d`（DDL / ini / DS / ods 引用级联，另开实施工单）
|
|
|
+ - `prd_checklist` 归类 1 依据：jobs 无 dim/dws/下游消费；kb/24 §dim 明确 `category` 取自 `cgi.sport`、不经 checklist 反查，list 字段仅作快照冗余
|
|
|
+
|
|
|
+ **类 2 · 增量保留**（`usr_app_base_user` / `usr_app_user_cert_info` / `card_group_info` / `card_group_order_info`）：
|
|
|
+ - raw 维持 ADR-03 update_time 增量、ods 维持双源 union + 跨 dt 多版本（拉链底座，一律不动）
|
|
|
+ - raw 小文件用 **TTL 保留窗**：只留最近 N 天 raw 日分区，更老的 drop（复用 kb/90 待办 3 分区保留工具）；安全性由"数据已固化进 ods 真源"保证；代价是超窗的远期 ods 重算需从 PG 重抽（DataX `-backfill`）。N 取 14~30 天，可配
|
|
|
+ - fillback 历史大分区（`dt=20211027` 等）不入 TTL，单独留存 / 用完即删
|
|
|
+ - ods 不清理（历史真源全留）
|
|
|
+
|
|
|
+- **后果**：
|
|
|
+ - 正面：小文件根治（类 1 分区有界、类 2 raw 窗有界）；类 2 不动 ADR-03/08 增量链与拉链底座；对齐 OneData 全量 / 增量分治；类 1 快照模型下游 SCD1 更直观
|
|
|
+ - 负面：两类两套运维；类 1 需改全量 SQL + 表名级联（`_ful_d`）；raw TTL 超窗分区不可直接回溯（回退到 PG 重抽）；`dt=20991231` 是非标"哨兵日期"分区（换取下游免 `max_pt` 查询）
|
|
|
+
|
|
|
+- **候选方案**：
|
|
|
+ - **全表统一 ods 全量快照**（含 usr / 交易表）：usr 喂拉链、交易表是事件源，全量快照既贵又丢 update_time 版本史、废 ADR-03/08 底座——否决
|
|
|
+ - **全表统一增量**：小表低量按天分区无限碎，小文件无解——否决
|
|
|
+ - **分区内 `concatenate` 压实**：每分区已 1 文件，无可合；治不了"分区数太多"这一形态——否决（该工具仍留作类 2 ods 未来兜底，见 kb/90 待办 2）
|
|
|
+ - **`dt=20991231` 哨兵换 `max_pt(表)` 取最新**：省"假日期"分区，代价多一次元数据查询 + 下游需知晓最新分区名——本项目取哨兵图下游写死方便，可反悔
|
|
|
+ - **raw 也 TTL、类 1 不做快照**（仅靠 TTL 统一治理）：类 1 是静态维表，快照 + 月末归档天然留历史且分区更省，优于"增量 + TTL 丢历史"——否决类 1 用 TTL
|
|
|
+
|
|
|
+- **反悔条件**：
|
|
|
+ - 类 1 表出现需按天增量的下游 → 转类 2
|
|
|
+ - 迁 Iceberg / Hudi（原生小文件合并 + MERGE INTO + 分区生命周期）→ 快照 / TTL 两套方案可简化统一
|
|
|
+ - 表数据量级或变更率变化使 df / di 判据失效 → 重新分类
|
