1.7 KiB
1.7 KiB
- [P20260216-235900] 2026-02-16 23:59:00 +0800
- summary: ### 怎么去重当前存在两套去重机制：- 主流方案（22/23 个任务）：表的 PK 为
(source_file, record_index)，即"同一批次文件 + 同一序号"视为同一条记录。`enable_content_hash_… - prompt:
- summary: ### 怎么去重当前存在两套去重机制：- 主流方案（22/23 个任务）：表的 PK 为
### 怎么去重当前存在两套去重机制：- 主流方案（22/23 个任务）：表的 PK 为 `(source_file, record_index)`，即"同一批次文件 + 同一序号"视为同一条记录。`enable_content_hash_dedup=False`（默认），content_hash 去重不生效。- 例外（`ODS_RECHARGE_SETTLE`）：表的 PK 为业务主键 `recharge_order_id`，`enable_content_hash_dedup=True`，content_hash 完整生效——同一业务主键的记录如果内容没变就跳过，变了才更新。冲突处理模式默认是 `update`（全字段对比，有变化才更新），也支持 `backfill`（只回填 NULL 列）和 `nothing`（跳过已存在记录），通过运行时配置 `run.ods_conflict_mode` 控制。### 怎么处理删除两种快照模式，默认都开启（`run.snapshot_missing_delete=True`）：- 全表快照（5 个任务）：API 返回全量数据，本次没返回但数据库里有的记录标记 `is_delete=1`。适用于维度表/档案表，数据量小。- 窗口快照（8 个任务）：只在指定时间列的窗口范围内做软删除。适用于流水表，数据量大，只能按时间段比对。- 无快照（10 个任务）：纯增量写入，不做软删除。软删除不是物理删除，只是把 `is_delete` 字段从 `0` 改为 `1`，下游 DWD 层可以据此过滤。---------------这时我最关注的。能再详细介绍么？我打算精简并标准化，给我点意见。