DolphinScheduler 作业架构

1️⃣ 问题分析

现状风险

1. 重复依赖

   • 如果 50 个 DWD 分别在工作流里单独依赖 ODS 抽取，会导致同一 ODS 表被重复触发或检查。
   • 这样既浪费调度时间，也增加资源占用。

2. 执行效率低

   • ODS 抽取量大（100 张表），如果每个 DWD 流都等完全部 ODS 才跑，会出现长尾阻塞。

3. 维护成本高

   • 表多的时候，单一大工作流很难维护（找问题、补数、重试都难）。
   • 任务依赖链太复杂，修改某表链路容易影响其他任务。

---

2️⃣ 架构设计原则

我们要满足：

• 抽取一次，多处复用（ODS）
  → 把 ODS 抽取单独成流，避免重复执行。
• 按主题域分流（ODS 和 DWD分组）
  → 每个工作流范围有限，减少长尾影响。
• 触发机制清晰
  → 下游利用 ODS 完成信号启动。
• 易补数
  → 可以针对单个主题域补数，而不必全链路跑。

---

3️⃣ 建议架构

Step 1：ODS 流拆分

• 你有 100 张 ODS 表，可以按 业务主题域拆，比如：
  1. 交易域（order、order_detail、sku…）
  2. 用户域（user、account、addresses…）
  3. 商品域（product、category…）
  4. 支付域（payment、refund…）
  5. 营销域（promotion、coupon…）
• 每个主题域做一个 ODS 工作流（可能 10~20 张表）。
• 每个 ODS 流完成后，会写一个分区完成标记到“状态表”或发一个 DS 全局事件。

---

Step 2：DWD 流按主题域拆分

• DWD 并不一定要把所有 50 张放一个流，这样会有长尾问题。
• 建议对应主题域的 ODS，做一个 DWD 流，例如：
  • DWD_交易流 ➡ 依赖 ODS_交易流完成信号 + 静态维度流完成信号。
  • DWD_用户流 ➡ 依赖 ODS_用户流完成信号。
  • DWD_商品流 ➡ 依赖 ODS_商品流完成信号。
• DWD 内部也是并行加工，比如交易流里：
  • dim_sku_processed
  • fact_order
  • fact_order_detail
  • fact_payment

---

Step 3：中间成果共享（减少重复加工）

• 在 DWD 加工过程中，如果某个维度或事实表是多个主题域要用的（如 dim_sku），可以单独成DIM 流，供多个 DWD 流依赖。
• 调度时只计算一次，然后多个下游直接依赖 DIM 流结果。

---

Step 4：触发和依赖管理

• 使用 DolphinScheduler 事件触发（Event Trigger） 、或在 Hive 建一个 完成标记表：
  • 每个 ODS 流完成后写 status_table：【domain_name, dt, status='done'】
  • DWD 流在启动前检查对应 domain 的 status='done'。
• 这样 ODS 和 DWD 是独立流，但数据上有强依赖，不会重复执行抽取。

---

4️⃣ 架构效果

• 减少重复执行：ODS 表只抽取一次，后续所有使用它的 DWD/DIM 流都复用。
• 提高效率：DWD 流按主题域并行启动，避免“全链路全部等完”而产生长尾。
• 易补数：可以单独补某个主题域的 ODS + DWD，而无需跑全链路。
• 易维护：每个流规模有限（10~20 表），调度图清晰可控。