|
|
@@ -27,8 +27,9 @@
|
|
|
|
|
|
### ADR-01 DataX 入口不做日期展开，按天补数归 DolphinScheduler
|
|
|
|
|
|
-- **状态**：草案（2026-04-23 讨论成型，待正式拍板转"已采纳"）
|
|
|
-- **背景**：老 `spark-sql-starter` 的 `get_date_range` 支持 `20260401-20260410` 范围格式自动展开；DataX 入口从未用过。本项目调度用 DolphinScheduler，DS 原生支持**业务日期补数**（时间区间选定后，按调度周期逐日实例化 task）。用户老 DS 配置即 `-start-date=${dt} -stop-date=${cdt}` 单日传参。
|
|
|
+- **状态**：草案
|
|
|
+ 老 `spark-sql-starter` 的 `get_date_range` 支持 `20260401-20260410` 范围格式自动展开；DataX 入口从未用过。本项目调度用 DolphinScheduler，DS 原生支持**业务日期补数**（时间区间选定后，按调度周期逐日实例化 task）。用户老 DS 配置即 `-start-date=${dt} -stop-date=${cdt}` 单日传参。
|
|
|
+
|
|
|
- **决策**：DataX 入口只接受单日语义（`start_date` / `stop_date` 对应一个 dt 分区）；按天展开 / 批量补数 / 回溯全部交由 DS 工作流承担。
|
|
|
- **后果**：
|
|
|
- 正面：DataX 层职责单一；补数、回溯、失败重跑在 DS 层统一可视化 / 可审计；DataX 不维护日期展开状态（哪天已做、哪天失败、重试）
|
|
|
@@ -38,8 +39,9 @@
|
|
|
|
|
|
### ADR-02 分布式分发归 DolphinScheduler worker group，DataX 不重复随机
|
|
|
|
|
|
-- **状态**：草案（2026-04-23 讨论成型，待正式拍板转"已采纳"）
|
|
|
-- **背景**：DataX 老入口 `single-job-starter.sh` 内置 `-random` + `workers.ini` 权重加权随机选 worker + ssh 分发。DS 自身亦有 **worker group** 机制（group 绑定机器列表、task 落到 group 内一台 worker）。两层叠加：DS 选 node01 → node01 上 DataX 再 random 到 node03。【查证 kb/91 §4.4】：用户老 DS 配置不传 `-random`，说明 DS 层已完成分发，DataX 只在本机跑——两层分发在实际运营中就没被"同时启用"过
|
|
|
+- **状态**：草案
|
|
|
+ DataX 老入口 `single-job-starter.sh` 内置 `-random` + `workers.ini` 权重加权随机选 worker + ssh 分发。DS 自身亦有 **worker group** 机制（group 绑定机器列表、task 落到 group 内一台 worker）。两层叠加：DS 选 node01 → node01 上 DataX 再 random 到 node03。【查证 kb/91 §4.4】：用户老 DS 配置不传 `-random`，说明 DS 层已完成分发，DataX 只在本机跑——两层分发在实际运营中就没被"同时启用"过
|
|
|
+
|
|
|
- **决策**：DataX 入口不做 worker 分发；分布式执行在 task 粒度靠 DS worker group 承担。DataX 入口的 `select_worker` 等同"返回 `current_host`"，ssh 分支可删，`workers.ini` 可移除
|
|
|
- **后果**：
|
|
|
- 正面：消除两层独立随机叠加打乱 DS 负载均衡；DataX 链路大幅简化（`worker.py` / ssh 远端执行 / `workers.ini` 可裁）；维护成本下降
|
|
|
@@ -49,20 +51,18 @@
|
|
|
|
|
|
### ADR-03 零点漂移决策
|
|
|
|
|
|
-- **状态**：草案（2026-04-23 讨论成型；实施 ods 时迁入 kb/12-同步方案.md 对应节，本 ADR 届时撤回）
|
|
|
-
|
|
|
-- **背景**：
|
|
|
+- **状态**：草案
|
|
|
T+1 按 `update_time` 过滤单日窗口 `[day-start, day-stop)` 同步时，源库在同步执行期间持续写入——跨零点的记录 `update_time` 会从 N 号"漂到" N+1 号，单日窗口**无法捕获漂移记录**。
|
|
|
-
|
|
|
+
|
|
|
漂移概率和漂移数据量的相关变量：
|
|
|
- **漂移窗口 = 执行时刻距零点的小时数**。越晚跑漂移窗口越大
|
|
|
- 漂移窗口越大，单条记录的漂移概率越高
|
|
|
- 漂移窗口内用户越活跃（业务写入高峰落在漂移窗口内），漂移数据量越多
|
|
|
-
|
|
|
+
|
|
|
**业界一般做法**：小数据量、用户低活跃度的场景下，通常凌晨 0:30 前后跑 T+1，漂移窗口 30 分钟、活跃度低，单日固定窗口 `[day-start, day-stop)` 即可，**忽略极少量漂移数据**是可接受的工程权衡。
|
|
|
-
|
|
|
+
|
|
|
**本项目特殊性**：业务高峰在凌晨 6 点前，同步定时必须避开高峰定在 6 点后，漂移窗口 6 小时；且若干用户行为集中在 0-6 点，漂移窗口和活跃度两个放大因子都踩中，漂移不能忽略——需要单独设计。
|
|
|
-
|
|
|
+
|
|
|
极端场景佐证：某用户习惯 0-6 点更新自己的数据，若走业界做法的单日固定窗口，数仓永远只能看到该用户最早的 `create_time` 版本，最新状态永远抓不到。
|
|
|
|
|
|
- **决策**：
|
|
|
@@ -87,4 +87,4 @@
|
|
|
- 源库 `REPEATABLE READ` snapshot isolation：业务库长事务风险，**否决**
|
|
|
- CDC（PG 逻辑复制 / MySQL binlog 流读）：架构正路，需独立立项，**本阶段不取**（见 kb/12 CDC 演进节）
|
|
|
|
|
|
-- **反悔条件**：迁 CDC；或 1 天 buffer 的存储 + ods 计算成本显著超过 CDC 实施成本
|
|
|
+- **反悔条件**：迁 CDC
|
