|
|
@@ -90,3 +90,26 @@
|
|
|
- CDC(PG 逻辑复制 / MySQL binlog 流读):架构正路,需独立立项,**本阶段不取**(见 kb/12 CDC 演进节)
|
|
|
|
|
|
- **反悔条件**:迁 CDC
|
|
|
+
|
|
|
+### ADR-04 DataX speed 三级注入(L1 conf / L2 ini / L3 CLI)
|
|
|
+
|
|
|
+- **状态**:草案
|
|
|
+ 老代码 `job_config_generator.py:60-67` 把 speed 三参(channel / byte / record)按工作时段硬编码:07:50-19:00 走 `channel=10 / byte=10MB / record=40k`(保护业务 DB),其余时段走 `channel=6 / byte=256MB / record=100k`。时段边界和各档值完全写死在 Python 代码里,调优需要改代码 + 发布。压测 / 回填场景下 speed 是高频调参项,需要运行时覆盖能力。
|
|
|
+
|
|
|
+- **决策**:speed 三参走三级合并,优先级 L1 < L2 < L3。
|
|
|
+ - **L1** `conf/datax-tuning.conf`:项目级默认,承载严格/宽松时段 start/stop 边界 + 两档各 3 个 speed 参值,共 8 个 key;时段配置用 `HH:MM` 字符串,代码解析为 HHMM 整数比较
|
|
|
+ - **L2** DataX ini 新增可选 `[speed]` 段:单 ini 级覆盖 channel / byte / record;一旦在 L2 显式写了,忽略时段判断直接使用
|
|
|
+ - **L3** CLI `-channel / -byte / -record`:本次运行级覆盖,`bin/datax-{hive-import,hdfs-export}-starter.py` 暴露,逐层透传到 `dw_base.datax.cli gen-json` 子进程,最终到 `JobConfigGenerator`
|
|
|
+ - 合并发生在 `JobConfigGenerator.assemble()` 内存里,结果写进生成的 json(`job.setting.speed` + `core.transport.channel.speed`);ini / conf 文件本身不动
|
|
|
+ - 时段判断采用左闭右开 `[start, stop)`;每 key 的来源打印到 stdout 便于审计
|
|
|
+
|
|
|
+- **后果**:
|
|
|
+ - 正面:压测 / 回填 speed 调参不用改代码;时段分档逻辑可配,业务高峰期调整不用发布;单 ini 特殊场景可用 L2 覆盖;ADR 级改动只加约 350 行代码 + 10 条单测
|
|
|
+ - 负面:参数语义复杂度上升(3 层合并规则)——通过 `[tuning]` log 逐层打印缓解;`conf/datax-tuning.conf` 是新文件需同步到所有 worker(sync-all.sh 已覆盖)
|
|
|
+
|
|
|
+- **候选方案**:
|
|
|
+ - 只做 L1(conf 外配,不要 L2 L3)——否决,压测高频调 speed 不想改 conf 再部署
|
|
|
+ - 参数全外配(speed + reader.fetchSize + writer.batchSize)——否决,fetchSize/batchSize 低频调,现有 `ini 覆盖硬编码` 够用,外配反而复杂
|
|
|
+ - CLI 用合成 flag `--datax-conf key=value,...`——否决,speed 高频用独立 flag 更直观,Spark 入口风格参考
|
|
|
+
|
|
|
+- **反悔条件**:三级注入使用场景长期 <5%(即 L2 L3 基本不用),退回单层 conf;或者 DataX 被替换
|