LabHub

博客

数据编排 2025 完全指南：dbt、SQLMesh、Dagster、Airflow、Prefect，数据契约，CI/CD（2025）

2026-04-15 · 17 分钟阅读 · #data-orchestration#dbt#sqlmesh#dagster#airflow#prefect#data-contracts#data-observability#deep-dive#series

한국어English日本語中文

Season 5 Ep 4 — 如果说 Ep 3 是“谁查询得更快”，那么 Ep 4 就是“谁来治理流水线”。2025 年的数据编排，正处在把工程原则（CI/CD、测试、契约）移植到数据之上的过程中。

Prologue — “数据流水线也是软件”

2010 年代的数据工程是“SQL 脚本 + cron”。2025 年不一样了：

这一变化催生了 Analytics Engineer 这个新岗位，而 dbt 站在了它的中心。但 2025 年不只有 dbt — SQLMesh 与 Dagster 已成为实质性的替代方案，而 Airflow 与 Prefect 依然守着通用编排的王座。

第1章 · 编排工具的分类

1.1 两个维度

1.2 主要工具

工具主要角色理念
dbt Core / CloudSQL 转换Analytics Engineer 的标准
SQLMeshSQL 转换版本、增量、状态
Dagster编排Asset-centric
Airflow 2/3编排Task DAG，通用
Prefect 3编排Pythonic，动态
Temporal工作流可靠性、状态机
Mage, Kestra编排新一代

第2章 · dbt — Analytics Engineer 的标准

2.1 身份

2.2 核心概念

2.3 依赖管理

-- models/fact_orders.sql
SELECT *
FROM {{ ref('stg_orders') }}
JOIN {{ ref('dim_customers') }} USING (customer_id)

2.4 2024–2025 动向

2.5 局限

2.6 使用场景

第3章 · SQLMesh — “是 dbt 的替代还是补充”

3.1 身份

3.2 核心差异点

3.3 理念

“dbt 的生产力 + 数据仓库的严格 + DevOps 的安全网”

3.4 示例 — 增量模型

MODEL (
  name core.fact_orders,
  kind INCREMENTAL_BY_TIME_RANGE (
    time_column order_date,
  ),
);

SELECT *
FROM raw.orders
WHERE order_date BETWEEN @start_date AND @end_date;

→ SQLMesh 会自动管理增量处理、回填与缓存。

3.5 局限

3.6 使用场景

第4章 · Dagster — “Asset-centric 的革命”

4.1 身份

4.2 核心差别

from dagster import asset

@asset
def orders(raw_data):
    return transform(raw_data)

@asset
def customer_lifetime_value(orders, customers):
    return compute_clv(orders, customers)

4.3 强项

4.4 2024–2025 动向

4.5 局限

4.6 使用场景

第5章 · Airflow — “依然是使用最广的那一个”

5.1 身份

5.2 Airflow 2.x

5.3 Airflow 3.0 (2024–2025)

5.4 托管选项

5.5 强项

5.6 局限

第6章 · Prefect — “Pythonic 的编排”

6.1 身份

6.2 Prefect 2.x → 3.0

6.3 强项

6.4 局限

6.5 使用场景

第7章 · Temporal — “工作流引擎的另一条谱系”

7.1 身份

7.2 与 Airflow 的差别

7.3 使用场景

第8章 · 数据契约（Data Contracts）

8.1 是什么

8.2 构成

8.3 工具

8.4 示例 (dbt Contract)

models:
  - name: dim_customers
    config:
      contract:
        enforced: true
    columns:
      - name: customer_id
        data_type: bigint
        constraints: [{type: primary_key}, {type: not_null}]
      - name: email
        data_type: varchar
        constraints: [{type: not_null}]

8.5 运维

第9章 · 数据流水线的 CI/CD

9.1 Git 与分支策略

9.2 CI 阶段

  1. Lint（sqlfluff, dbt lint）
  2. 编译（dbt compile, SQLMesh plan）
  3. 单元测试（模型级别的样本）
  4. 契约校验
  5. 在 Staging 环境部分执行
  6. 统计 diff（Datafold 等）

9.3 环境分离

9.4 部署策略

9.5 可观测性的整合

第10章 · 可观测性（Observability）与告警

10.1 五大支柱（Monte Carlo）

10.2 工具地形

10.3 告警设计

10.4 SLO

第11章 · 五种真实技术栈组合

11.1 Startup（小规模）

11.2 Scale-up

11.3 Data-heavy SaaS

11.4 Enterprise

11.5 韩国金融与公共部门

第12章 · 韩国企业实务贴士

12.1 招聘与组织

12.2 工具引入顺序

  1. dbt + 调度（先做简单的）
  2. 扩充测试与文档
  3. 编排（Airflow/Dagster）
  4. 可观测性（Monte Carlo/Metaplane）
  5. 契约（dbt Contracts/Soda）

12.3 语言与区域设置

12.4 安全与审计

第13章 · 十大反模式

13.1 原封不动地用“cron + SQL”

没有 Git、测试与文档 → 事故频发。

13.2 没有测试的 dbt

几百个模型 → 回归暴增。

13.3 手写增量逻辑

在 dbt 里手写增量 → 维护变成噩梦。可以考察 SQLMesh。

13.4 单体化的 Airflow DAG

一个 DAG 塞 100 个任务 → 故障扩散。

13.5 同时运行 Dagster、Prefect、Airflow

一家公司用三个就是过度工程。

13.6 没有契约却有大量消费方

一次变更打碎五个团队。

13.7 把可观测性放到最后

事故被用户先一步发现。

13.8 没有 CI 就直接部署到 Prod

省掉 PR 评审 → 犯下说不出口的错误。

13.9 没有环境分离

在 Dev 改动了 Prod 数据的事故。

13.10 只相信自动生成的文档

自动文档只能展示结构。业务说明要由人来写。

第14章 · 检查清单 — 数据流水线成熟度的 12 项

第15章 · 下一篇预告 — Season 5 Ep 5：“Semantic Layer、Metrics Store、Reverse ETL”

如果说流水线制造数据，那么 Semantic Layer 负责述说。Ep 5 讲的是把数据连接到业务语言的那条轴。

“数据的含义只定义一次”这一承诺的 2025 年版本。

下一篇文章再见。

总结：2025 年的数据编排，正是“流水线也是软件”这一原则走向完成的阶段。dbt 成为转换的标准，SQLMesh 以增量与版本加以补充，Dagster 则带着 asset-centric 编排登场。Airflow 借 3.0 大改造再度起飞，Prefect 3.0 是 Pythonic 的替代方案。数据契约与可观测性把工程质量往上推，CI/CD + SLO + on-call 成了数据团队的日常。技术栈会随规模与场景而变，但核心原则可以浓缩成五个词：“Git、测试、契约、可观测性、回滚”。下一篇讲的是压在这一切之上的“用业务语言说话的那一层”。

查看原文: https://www.youngju.dev/blog/culture/2026-04-15-data-orchestration-2025-complete-guide-dbt-sqlmesh-dagster-airflow-prefect-data-contracts-deep-dive-guide-2025.zh

评论

还没有评论。

登录后即可发表评论