- [P20260217-003557] 2026-02-17 00:35:57 +0800
  - summary: 2、优化方案方案 0：决策基线（推荐）保留 ODS 多版本追加（PK = (id, content_hash)），但把“无意义重复版本”压掉、把“取最新版本”跑快、把 spec 误导项清理掉。方案 1：清理 spec 中“误导/无效配置”（…
  - prompt:
```text
2、优化方案方案 0：决策基线（推荐）保留 ODS 多版本追加（PK = (id, content_hash)），但把“无意义重复版本”压掉、把“取最新版本”跑快、把 spec 误导项清理掉。方案 1：清理 spec 中“误导/无效配置”（纯重构，不改运行语义）删除 conflict_columns_override运行时不生效（冲突列来自 DDL），保留只会误导新人以为它决定去重逻辑。PK 信息应只有一个权威来源：DDL。更新数据库与DDL.软删除策略字段标准化：用枚举替代组合字段把 snapshot_full_table + snapshot_window_columns 合并成一个枚举（外加可选时间列）：NONE：不做软删除FULL_TABLE：全表快照 diffWINDOW：窗口快照 diff（需要时间列）好处：配置更可读，__post_init__ 校验更清晰，减少“组合状态爆炸”。删除全局恒定的冗余字段include_site_column/include_page_no/include_page_size 全部 False → 直接硬编码include_source_endpoint 少数 True → 保留但默认 False以上属于“让 spec 说人话”，不改表结构不改数据，只减少误解成本。方案 2：减少“无意义版本”——默认开启 skip unchanged（轻度改行为，但更符合多版本语义）把 enable_content_hash_dedup 改名成更直观的 skip_unchanged（或保留原名但改注释），并考虑：默认改为 True（强烈建议）逻辑：内容没变就不新增版本；内容变了依然会插入新行（多版本语义不受影响）这能直接解决你们最烦的“版本膨胀里混了很多无变化重复”的问题。方案 3：给“取最新版本”提供索引与标准写法（性能关键）每张 ODS 表加复合索引：(business_id, fetched_at DESC)（business_id 指各表主业务主键列）。目标查询模式通常是：“每个 id 取最新一行”“按时间增量抽取 + 每 id 最新”没索引会导致排序/去重代价大；有索引后能极大减少扫描与排序成本。业务下游是需要“最新且未删除”，所以：维护一个 latest 视图/物化视图（例如 ods_x_latest），统一封装 DISTINCT ON / window function 逻辑。或者在 DWD 落地时统一做“latest 快照表”，让业务查询不直接扫 ODS 多版本表解决的不是多版问题，而是“没有为最新版本访问模式建索引”问题。方案 4：软删除语义在多版本下的“规约”已经指出：多版本下软删除会出现“多行一起标删”的复杂性。但我认为删除也使更新的一种，应该是新增一行，记录为改ID的最新记录，本记录的is_delete = 1ODS 层语义：业务实体被删 → 该id的最新版本 is_delete=1 合理。下游取数规约（给 DWD/数仓同事一个确定的规则）：先按 id 取 latest（按 fetched_at）再过滤 is_delete=0（或者反过来，但要统一）此举会带来一个问题，Hash不能单纯计算Payload,还需要把综合判断后的is_delete判断进去。方案 5：中长期治理冷数据归档例如保留最近 90/180 天的历史版本；更早版本移到归档表或冷存储（如果合规允许）。目的不是省磁盘，是减少索引膨胀、vacuum 压力、备份恢复时间。版本保留策略（按表分级）维度表：可能只需要少量版本（比如仅保留变更点）流水/事实：可能需要更长版本链可以按任务 spec 增加 retention_days / retain_versions 之类，但这是后话，先把现有的跑稳。--------------以上表达是否有问题？
```