|
|
@@ -25,4 +25,24 @@
|
|
|
|
|
|
## 决策清单
|
|
|
|
|
|
-待补充
|
|
|
+### 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}` 单日传参。
|
|
|
+- **决策**:DataX 入口只接受单日语义(`start_date` / `stop_date` 对应一个 dt 分区);按天展开 / 批量补数 / 回溯全部交由 DS 工作流承担。
|
|
|
+- **后果**:
|
|
|
+ - 正面:DataX 层职责单一;补数、回溯、失败重跑在 DS 层统一可视化 / 可审计;DataX 不维护日期展开状态(哪天已做、哪天失败、重试)
|
|
|
+ - 负面:不走 DS 的一次性手工补 N 天需要外部 bash 循环或 `workspace/` 下临时 dispatcher
|
|
|
+- **候选方案**:DataX 入口层实现"日期范围自动展开 + 多 json 分发多 worker"——否决,理由是**重复 DS 职责** + 引入状态管理复杂度
|
|
|
+- **反悔条件**:项目从 DS 迁走到无补数功能的调度系统;或出现"必须在 DataX 层展开"的硬场景
|
|
|
+
|
|
|
+### 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 入口不做 worker 分发;分布式执行在 task 粒度靠 DS worker group 承担。DataX 入口的 `select_worker` 等同"返回 `current_host`",ssh 分支可删,`workers.ini` 可移除
|
|
|
+- **后果**:
|
|
|
+ - 正面:消除两层独立随机叠加打乱 DS 负载均衡;DataX 链路大幅简化(`worker.py` / ssh 远端执行 / `workers.ini` 可裁);维护成本下降
|
|
|
+ - 负面:单 DS 任务节点内部的批量(多 ini + `-parallel`)场景无法在 DataX 层散到多 worker,要分布式必须在 DS 层拆成多 task
|
|
|
+- **候选方案**:保留 DataX 两层分发——否决,"两层独立随机"破坏 DS worker group 语义
|
|
|
+- **反悔条件**:DS 换成无 worker group 支持的调度器;或单 task 内批量规模大到 DS 拆分成本过高
|