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

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

• Prologue — “数据流水线也是软件”
• 第1章 · 编排工具的分类
  • 1.1 两个维度
  • 1.2 主要工具
• 第2章 · dbt — Analytics Engineer 的标准
  • 2.1 身份
  • 2.2 核心概念
  • 2.3 依赖管理
  • 2.4 2024–2025 动向
  • 2.5 局限
  • 2.6 使用场景
• 第3章 · SQLMesh — “是 dbt 的替代还是补充”
  • 3.1 身份
  • 3.2 核心差异点
  • 3.3 理念
  • 3.4 示例 — 增量模型
  • 3.5 局限
  • 3.6 使用场景
• 第4章 · Dagster — “Asset-centric 的革命”
  • 4.1 身份
  • 4.2 核心差别
  • 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)
  • 8.5 运维
• 第9章 · 数据流水线的 CI/CD
  • 9.1 Git 与分支策略
  • 9.2 CI 阶段
  • 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 工具引入顺序
  • 12.3 语言与区域设置
  • 12.4 安全与审计
• 第13章 · 十大反模式
  • 13.1 原封不动地用“cron + SQL”
  • 13.2 没有测试的 dbt
  • 13.3 手写增量逻辑
  • 13.4 单体化的 Airflow DAG
  • 13.5 同时运行 Dagster、Prefect、Airflow
  • 13.6 没有契约却有大量消费方
  • 13.7 把可观测性放到最后
  • 13.8 没有 CI 就直接部署到 Prod
  • 13.9 没有环境分离
  • 13.10 只相信自动生成的文档
• 第14章 · 检查清单 — 数据流水线成熟度的 12 项
• 第15章 · 下一篇预告 — Season 5 Ep 5：“Semantic Layer、Metrics Store、Reverse ETL”

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

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

• 流水线由 Git 管理
• 变更要经过 PR + 评审 + CI 测试
• 数据模型具备类型、约束、测试
• 故障通过OpenLineage 与数据契约来预防

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

第1章 · 编排工具的分类

1.1 两个维度

• 数据转换（Transformation） vs 工作流编排
• SQL 中心 vs 代码（Python）中心

1.2 主要工具

第2章 · dbt — Analytics Engineer 的标准

2.1 身份

• 用 SQL 把数据转换当作代码来管理
• 自动生成依赖图、测试与文档
• 拥有 Snowflake/BigQuery/Databricks/Redshift/Postgres/DuckDB 等适配器

2.2 核心概念

• Model：用 SELECT 语句定义的表/视图
• Source：外部系统的数据定义
• Seed：加载 CSV 数据
• Snapshot：SCD Type 2
• Test：列与模型级别的校验（not_null, unique, accepted_values, 关系）
• Macro：用 Jinja 编写可复用逻辑

2.3 依赖管理

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

• 用 ref()、source() 声明依赖
• 自动生成 DAG → 按正确顺序执行
• 用 dbt build 跑完整条流水线

2.4 2024–2025 动向

• dbt Cloud：提供 IDE、调度、环境与协作的 SaaS
• dbt Semantic Layer / MetricFlow：指标的中心化
• dbt Mesh：多个项目的联合
• dbt-fusion 引擎发布（2024）：性能与开发体验的改善

2.5 局限

• 增量（incremental）逻辑越复杂越难维护
• 状态追踪较弱（运行历史、变更检测）
• Jinja 宏难以调试
• 大型项目上的构建时间问题

2.6 使用场景

• 几乎所有现代数据团队的默认选择
• BI 与 ML feature 建模

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

3.1 身份

• 2022 年登场，2024 年受到关注
• 改善 dbt 的弱点（增量、版本、测试）
• Tobiko Data 提供商业支持

3.2 核心差异点

• Virtual environments：在虚拟环境中先行测试变更
• Automatic incremental：增量逻辑自动化
• State tracking：模型版本 + 变更影响分析
• Backfill：内置历史数据重跑的工作流
• dbt 兼容：可以导入既有的 dbt 项目

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 局限

• 生态与社区相比 dbt 仍然较小
• 连接器与适配器数量有限
• 学习资料与示例不足

3.6 使用场景

• 以增量、版本、backfill 为中心的团队
• 被 dbt 的局限折磨的中大型团队
• 从零开始的团队的备选方案

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

4.1 身份

• 2018 Elementl → Dagster Labs
• 以数据资产（Asset）为中心的模型
• 比 Airflow 的 task 中心更进一步

4.2 核心差别

• Task DAG (Airflow)：“执行完 A 再执行 B”
• Asset DAG (Dagster)：“生成这张表的函数” + 依赖自动化

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 强项

• 流水线被建模成数据资产的集合
• 物化状态、freshness、元信息都是一等概念
• 与 dbt、Fivetran、Hightouch 等的集成很丰富
• 本地开发体验出色

4.4 2024–2025 动向

• Dagster+：云端 SaaS
• Dagster Components：可复用的流水线积木
• Asset-based scheduling：基于新鲜度的调度
• 强化 AI/ML 流水线的整合

4.5 局限

• 学习曲线（新概念）
• 生态与插件相比 Airflow 更小
• 大型企业的案例仍在积累中

4.6 使用场景

• 以数据产品为中心的团队
• 在 dbt 与 Airflow 的“接缝处”受折磨的团队
• 从零搭建现代数据栈

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

5.1 身份

• 2014 Airbnb → Apache
• 用 Python DAG 定义工作流
• 拥有最大的生态与社区

5.2 Airflow 2.x

• 用 TaskFlow API 直接把 Python 函数变成任务
• Dynamic task mapping
• Datasets（以数据为中心的调度）
• 数百个 provider（AWS、GCP、Snowflake、dbt、Databricks 等）

5.3 Airflow 3.0 (2024–2025)

• 架构大改造（Task Execution Interface, Task SDK）
• 与语言无关的任务执行（不限于 Python）
• DAG Versioning
• 更好的 UI、安全与多租户

5.4 托管选项

• Astronomer (Astro)
• AWS MWAA
• GCP Cloud Composer
• Azure Data Factory managed Airflow

5.5 强项

• 到处都能跑，provider 数量庞大
• 已在企业中得到验证
• 通用编排（数据之外的任务也行）

5.6 局限

• 以 Task 为中心（数据资产追踪较弱）— 正被 Datasets 缓解
• 规模变大时复杂（Celery/Kubernetes Executor 的调优）
• UI 与开发体验相比 Dagster、Prefect 被评价为偏重

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

6.1 身份

• 2018 Prefect → Prefect Cloud
• 以 Airflow 的替代者身份出发
• Python-native，动态工作流

6.2 Prefect 2.x → 3.0

• 2024 年发布 Prefect 3.0
• 性能、UI、安全的大幅改进
• Flow 与 Task 的抽象
• 默认异步，动态图很自然

6.3 强项

• Python 代码本身就是工作流
• 本地与云端体验一致
• 调度、重试、告警都很简单

6.4 局限

• 生态相比 Airflow 更小
• 企业案例仍在积累中
• 在 dbt 与 ML 的整合上 Dagster 更强

6.5 使用场景

• 以 Python 工程师为主的团队
• 动态流水线（参数、运行时决定）
• 初创与中型企业

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

7.1 身份

• 2020 年从 Uber Cadence 分叉
• 以长时间运行、状态机、可靠性为中心
• 通用工作流（支付、订单）+ 数据工作流

7.2 与 Airflow 的差别

• Airflow：批处理 ETL、周期性执行
• Temporal：事件驱动、长时间运行、由用户发起的工作流

7.3 使用场景

• LLM Agent 的编排（2024–2025 持续扩大）
• 订单、支付、配送的状态机
• 用户旅程的工作流

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

8.1 是什么

• 数据生产者与消费者之间明确写下模式、SLA 与负责人的约定
• 代码里 API contract 的数据版本
• 2022–2025 年间浮现的概念

8.2 构成

• Schema：列、类型、约束
• SLA：freshness, completeness, uniqueness
• Owner：数据团队、业务团队
• Lifecycle：变更策略、版本、deprecation

8.3 工具

• Soda：数据质量 + 契约
• Schemata / Monte Carlo / Metaplane / Datafold：可观测性 + 契约
• OpenLineage：血缘标准
• dbt Contracts：在 dbt 模型上声明契约
• Great Expectations：校验标准

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 运维

• 在 PR 中评审契约变更
• Breaking change → 升版本 + 发布 deprecation 通知
• 消费方表出现契约违规时自动告警

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

9.1 Git 与分支策略

• main：生产流水线
• dev：开发环境
• Feature branch → PR → 评审 → CI 通过 → 合并

9.2 CI 阶段

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

9.3 环境分离

• Dev / Staging / Prod 的数据集要分开
• 访问权限严格区分
• Staging 可以使用 Prod 的部分样本

9.4 部署策略

• Blue-Green（表的新版本 + 切换）
• Canary（只让部分用户/查询用新版本）
• Shadow（新版本只计算，用于比对）
• 回滚计划

9.5 可观测性的整合

• 部署后监控新鲜度、失败与延迟
• 告警 → Slack、PagerDuty
• 事故之后写 Postmortem

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

10.1 五大支柱（Monte Carlo）

• Freshness：数据是否是最新的
• Volume：行数是否正常
• Schema：列与类型有没有变
• Quality：取值的分布与缺失
• Lineage：上下游依赖

10.2 工具地形

• Monte Carlo, Metaplane, Bigeye, Anomalo：SaaS 可观测性
• Datafold：部署前的数据 diff
• Great Expectations：开源校验
• Soda：开源 + 商用
• OpenLineage + Marquez：血缘标准

10.3 告警设计

• Severity 等级：P1（流水线全面停止）/ P2（延迟）/ P3（质量）
• 限流：防止同一告警反复触发
• on-call 轮值：数据团队最少 2 人

10.4 SLO

• 按流水线定义新鲜度与成功率 SLO
• 管理每月的错误预算
• 违规时冻结部署并复盘

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

11.1 Startup（小规模）

• 存储：BigQuery / Snowflake
• 转换：dbt
• 编排：dbt Cloud 的调度 or GitHub Actions
• 可观测性：dbt tests + Elementary

11.2 Scale-up

• 存储：Snowflake / Databricks + Iceberg
• 转换：dbt + 部分 SQLMesh
• 编排：Dagster or Airflow
• 可观测性：Monte Carlo / Metaplane

11.3 Data-heavy SaaS

• 存储：Iceberg + ClickHouse
• 流式：Flink/RisingWave
• 转换：dbt + Spark
• 编排：Dagster
• 可观测性：Datadog + OpenLineage

11.4 Enterprise

• 存储：Snowflake/Databricks + Iceberg
• 转换：dbt + 自定义
• 编排：Airflow (Astronomer) + 部分 Dagster
• 契约：OpenLineage + Monte Carlo
• 治理：Unity/Polaris + Collibra

11.5 韩国金融与公共部门

• 存储：本地部署 Iceberg + StarRocks / Snowflake Private
• 转换：dbt（开发）+ Spark（生产）
• 编排：Airflow on Kubernetes
• 安全与审计：自建 + Ranger/OPA

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

12.1 招聘与组织

• Analytics Engineer 岗位的采用在增加（Kakao、Toss、Karrot、Coupang 等）
• 数据工程师 + 分析工程师 + 数据科学家的三层结构
• 团队规模达到 5 人以上时就需要标准化工具栈

12.2 工具引入顺序

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

12.3 语言与区域设置

• 避免使用韩语列名（兼容性问题）
• 时区按 UTC 存储，分析时再转成 KST
• 节假日与周末逻辑单独管理

12.4 安全与审计

• PII 的检测与脱敏流水线
• 访问日志的长期保存
• 部署历史要能被审计追溯

第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 项

• 所有转换代码都在 Git 里
• PR + 评审 + CI 是标准流程
• dbt tests（或同等）覆盖率 70%+
• 已配置新鲜度、体量、模式的告警
• 数据契约与负责人已文档化
• 环境分离（Dev/Staging/Prod）
• 血缘（Lineage）自动追踪
• SLO/SLA 的定义与监控
• on-call 轮值
• 回滚与回填的 playbook
• 成本仪表盘（查询、存储）
• 入职文档与培训材料

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

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

• Semantic Layer 的历史与再发现
• dbt Semantic Layer / MetricFlow
• Cube / AtScale / Looker 的语义论
• Metrics Store 模式
• Headless BI（Transform, Lightdash）
• Reverse ETL (Hightouch, Census, Grouparoo)：把分析数据送回运营工具
• Data activation 策略
• 与软件工程之间界限的消失
• 韩国企业的 Semantic Layer 成熟度
• AI 与 Semantic Layer 的相遇

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

下一篇文章再见。

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