数据工程基础：从 ETL 到数仓与流处理

0. 元信息

• 主题路径：docs/topics/data-engineering-basics/README.md
• 主分类：数据与人工智能
• 辅助分类：工程技术
• 适合对象：会写 Python/SQL、用过 Docker 与 Linux 命令行，希望从「会用数据库」过渡到「能设计并运维一套端到端数据流水线」的工程师
• 建议周期：6～10 周（每周 10～14 小时，至少一半时间用于跑批/读计划/做故障演练）
• 前置知识：db-and-sql（关系模型、SQL、查询计划、事务隔离）、lang-python（脚本与类型）、docker-basics（镜像与 Compose）；熟悉 Linux 终端与 Git
• 最终目标：拿到一份业务需求（订单/点击流/日志/IoT 任一），能在 2 周内交付一条可重跑、可观测、可治理的数据流水线——包含分层数仓、批流两种执行模式、Schema 演进与数据质量门禁

1. 学习路线

ETL/ELT 编排与批处理（Airflow / Prefect / Dagster）
  → 数仓建模与 Lakehouse（分层架构 / 维度建模 / Iceberg / Delta Lake / Hudi）
  → 流处理与实时管道（Kafka / Pulsar / Flink / Spark Streaming）
  → 数据治理、质量与血缘（dbt / Great Expectations / Soda / OpenLineage）
  → Schema 演进、版本化与批流一体
  → 综合项目：端到端电商/IoT 数据流水线

按”先批后流、再治理、最后统一”的顺序学。每张子主题对应一段流水线环节，最后用综合项目把链路串起来。

2. 阶段周数分配

6 周方案只跑通最小可用路径；10 周方案有 2 周用来重做实验与故障演练。综合项目占最后 1 周。

3. 九阶段表

9.x 关键代码（冰山下示例）：一份 Iceberg 表的最小写入 + Time Travel 回滚片段——用于把”分层 + 表格式”两件套串起来。

-- 9.x.1 Iceberg 最小写入 + Time Travel 回滚（Spark SQL）
-- 阶段 1：建表
CREATE TABLE dw.orders (
    order_id BIGINT,
    user_id BIGINT,
    amount DECIMAL(10, 2),
    order_date DATE
) USING iceberg
PARTITIONED BY (days(order_date));

-- 阶段 2：写入两批
INSERT INTO dw.orders VALUES (1, 100, 99.50, DATE '2026-01-15');
INSERT INTO dw.orders VALUES (2, 101, 199.00, DATE '2026-01-16');

-- 阶段 3：故意写错
UPDATE dw.orders SET amount = -1 WHERE order_id = 1;

-- 阶段 4：回滚到上一个快照
CALL dw.system.rollback_to_snapshot('orders', <snapshot_id>);

-- 阶段 5：验证
SELECT * FROM dw.orders WHERE order_id = 1;  -- amount = 99.50

此示例呼应阶段 2（分层）、阶段 4（Lakehouse）、阶段 8（Schema 演进）三段决策；真实综合项目应在完整 dbt + Flink + OpenLineage 链路上扩展。

关键陷阱：把”搭好 Airflow”当数据工程；只做 ELT 不做数据契约；流处理只跑通 happy path 不测乱序与迟到；数据质量只在 dashboard 里看，不挂门禁；Schema 演进靠 ALTER TABLE，不走表格式版本化。

4. 第一周任务

Day 1 约定：本计划以 Linux + Docker + 8G 内存的机器为最小实验环境。所有流水线都在 Docker Compose 内启动，所有代码、SQL、配置都要进 Git。所有任务必须可重跑：清空状态后再跑一次产出相同结果。

Day 7 步骤 A 跑通业务流；步骤 B 每类故障先在测试环境复现，再讲清防护手段。

5. 阶段通用验收

1. 不看答案独立重写一条 5 任务的 ETL DAG + 一份 Iceberg 表的 Time Travel 演练；
2. 用自己的话解释”为什么分层""为什么流处理需要 Watermark""为什么 Schema 演进要走表格式”；
3. 画一张图：数据流水线架构图 + 血缘图 + 一致性状态机图（至少三件套之一）；
4. 测试空数据、迟到数据、乱序数据、Schema 漂移、节点下线 5 类边界；
5. 准备至少 3 组自定义数据画像并贴出实际产出与耗时；
6. 记录端到端 P50 / P99 延迟、吞吐、checkpoint 时长、数据质量失败率 4 个核心指标；
7. 能修改已有流水线（加一层、加一个数据测试、换一份表格式）并用同样指标验证。

6. 最终验收

• 独立设计并交付一条端到端数据流水线（订单/点击流/日志/IoT 任选），覆盖分层数仓、批流两种模式、Schema 演进、数据质量门禁；

• 至少完成 30 个实战项（分布建议）：

  子主题	题目数量	难度	平台建议
  ETL/ELT 编排	6	Easy / Medium	Astronomer Registry / Dagster examples
  数仓建模与 Lakehouse	6	Medium	Iceberg/Delta Lake 官方 Examples
  流处理与实时管道	6	Medium / Hard	Flink Forward / Kafka Summit 案例
  数据治理与质量	6	Medium	dbt + Great Expectations 官方 Examples
  Schema 演进与批流一体	6	Medium / Hard	Iceberg Spec / Hudi RFC

  约束：至少 18 项达到 Medium，至少 6 项达到 Hard；每项必须留可运行的代码与说明文档。

• 完成 1 个综合项目：端到端电商数据流水线，含分层数仓 + 实时管道 + 数据治理 + 故障复盘；

• 能用 15 分钟讲清整套数据流水线的分层、表格式、流处理语义、Schema 演进与数据质量门禁。

7. 综合项目

首选：电商端到端数据流水线（必做：分层数仓 + Kafka 实时管道 + dbt 转换 + Iceberg 表 + 数据测试）。

• 输入：订单 CSV + Kafka 实时点击流；
• 输出：必输出（1）分层数仓 schema：ODS（原始）→ DWD（明细）→ DWS（汇总）→ ADS（应用）；（2）批流两种模式：DAG（Airflow）+ 流（Flink/Spark Streaming）；（3）Iceberg 表 + Time Travel 演示；（4）dbt 数据测试 10 条；（5）OpenLineage 血缘；
• 关键指标：批处理 P95 延迟 < 30min、流处理端到端 P95 延迟 < 30s、数据测试失败 0%、Schema 演进 0 阻塞；
• 进阶可选：接入 Soda 做分布异常检测、Monte Carlo 做数据可观测、用 StarRocks/ClickHouse 做 OLAP 查询。

备选：IoT 设备遥测数据流水线（边缘采集 → Kafka → Flink → Iceberg → 告警）。
备选：日志分析平台（Filebeat → Kafka → Flink → Elasticsearch / Doris）。
备选：对一套遗留 cron 脚本做 Airflow 化重构并验证可观测与重跑。

任何综合项目都必须包含：

1. 需求说明与数据契约（源 schema、目标 schema、SLA）；
2. 分层架构图与命名规范；
3. 核心代码（Airflow DAG + Flink Job + dbt models + GE/Soda 检查）；
4. 边界测试（源缺失、Schema 漂移、迟到数据、节点下线、回填）；
5. 血缘与可观测（OpenLineage 事件 + Prometheus 指标）；
6. README（设计取舍、已知限制、下一步）；
7. 复盘记录（模拟 1 次 P0 故障，写 retrospective.md）。

8. 推荐开源资料

默认使用顺序：先读 Reis《Fundamentals of Data Engineering》第 1~6 章建立全景 → 用 Airflow 跑通第一批 DAG → 读 Iceberg 文档做 Lakehouse → 读 Flink 文档做流处理 → 用 dbt + Great Expectations 加质量门禁 → 用 OpenLineage 接血缘 → 写复盘到 notes/retrospective.md。

9. 学习资料汇聚（v0.3 自包含）

本节由本计划生成。链接指向原始材料或作者公开内容。规范会演进，记录时务必写明版本与日期。

9.1 背景与动机

数据工程的诞生是为了回答”数据从产生到产生价值中间发生了什么”。2003 年 Google 发表 GFS / MapReduce / Bigtable 三篇论文，把”分布式存储 + 计算 + 结构化”做成工业可用的三层。2006 年 Hadoop 开源，把这套思想带入主流。2010 年代初 Lambda 架构（Nathan Marz）提出批流双路，把”实时性”与”准确性”分开处理；2014 年 Kappa 架构（Jay Kreps）提出用单一日志流统一两者。2017 年 Delta Lake（Databricks）、2018 年 Iceberg（Netflix 开源）、2019 年 Hudi（Uber 开源）让 Lakehouse 成为现实——同一份存储既支持批 SQL 又支持流式更新。Martin Kleppmann 2017 年 Designing Data-Intensive Applications 把这一切讲透；Joe Reis 与 Matt Housley 2022 年 Fundamentals of Data Engineering 把数据工程生命周期定义为”生成 → 摄取 → 存储 → 转换 → 服务”五段。今天每一个数据团队都把”分层 → 表格式 → 流处理 → 治理 → 可观测”五个字拆成具体技术选型。

一句话总结：数据工程不是搭一条 Airflow，是把数据从产生到消费的全链路上每一段都能被调度、被治理、被观测。

9.2 概念地图

flowchart LR
  Source[数据源 DB/日志/IoT/API] --> Ingest[摄取 Airflow/Kafka/CDC]
  Ingest --> ODS[ODS 原始层]
  ODS --> DWD[DWD 明细层]
  DWD --> DWS[DWS 汇总层]
  DWS --> ADS[ADS 应用层]
  ADS --> Serve[服务 BI/API/ML]
  Ingest --> Stream[流处理 Kafka/Flink/Spark]
  Stream --> Lake[Lakehouse Iceberg/Delta/Hudi]
  Lake --> SQL[OLAP 查询 StarRocks/ClickHouse/Doris]
  Meta[元数据] --> Catalog[数据目录 Hive/Glue/Polaris]
  Quality[数据质量 dbt/GE/Soda] --> Gate[质量门禁]
  Lineage[血缘 OpenLineage/Marquez] --> Gate
  Lake --> Gate
  Serve --> Gate

关系说明：摄取决定分层入口；分层决定每层责任与命名；流处理与 Lakehouse 让批流共享存储；治理与血缘贯穿全链路；可观测提供反馈环。每一层都对应一个失败模式，必须在设计里写明应对。

9.3 基础知识讲解

9.3.1 经典论文 / 规范

9.3.2 经典书籍

9.3.3 优秀博客

9.3.4 核心人物

9.3.5 开发方法

9.3.6 重点训练材料

• DDIA 案例：第 5~9 章每章末尾的”案例研究”是顶级题源（批处理用 MapReduce、流处理用 Flink、事务用 Spanner）。
• Astronomer Registry：Airflow 官方 DAG 模板库，覆盖 S3 → Snowflake、Salesforce → BigQuery 等。
• Apache Iceberg Examples：官方仓库的 Spark/Flink/Hive 集成示例。
• dbt 项目模板：Jaffle Shop、Netflix dbt 示例、GitHub Archive 项目。
• Flink Forward Talks：每年大会的视频，覆盖 Exactly-Once、State、Savepoint 等。
• Reis《Fundamentals of Data Engineering》案例：第 7~12 章每章末尾的”案例研究”覆盖 Uber / Netflix / Airbnb 数据流水线。

9.4 经典问题与经典案例

9.5 学习难点

概念难点

思维难点

工程难点

9.6 技术标准与接口

9.6.1 Entity

9.6.2 Scope

• Airflow / Prefect / Dagster：编排层，不替代存储与计算。
• Iceberg / Delta / Hudi：表格式，不替代文件系统与计算引擎。
• Kafka / Pulsar：消息层，不替代流处理引擎。
• Flink / Spark Streaming：流处理引擎，不替代存储。
• dbt / Great Expectations / Soda：转换与质量，不替代编排。
• OpenLineage / Marquez：血缘标准与实现，不替代元数据目录。

9.6.3 Structure

• Airflow DAG：DAG → Task → Operator → Hook → Sensor，Task 间用 XCom 传值。
• Kafka topic：partition × replication_factor，offset 由 consumer group 管理。
• Flink Job：Source → Transform → Sink，State 后端用 RocksDB/HashMap。
• Iceberg：metadata.json + manifest list + manifest file + Parquet data file，支持 hidden partitioning。
• dbt model：sources → staging → intermediate → marts，测试用 schema.yml。
• OpenLineage event：run / job / dataset / facet 四元组，Facet 描述属性。
• 数据契约：源 schema + 目标 schema + SLA + owner + 版本。

9.6.4 Ecosystem

• 编排：Airflow、Prefect、Dagster、Argo Workflows、Temporal。
• 摄取：Kafka Connect、Flink CDC、Debezium、Airbyte、Singer。
• 存储：HDFS、S3、GCS、MinIO、Azure Blob。
• Lakehouse：Iceberg、Delta Lake、Hudi、Apache Paimon。
• 流处理：Flink、Spark Streaming、Beam、ksqlDB。
• OLAP：StarRocks、ClickHouse、Doris、Trino、Presto、DuckDB。
• 转换：dbt、SQLMesh、Coalesce。
• 质量：Great Expectations、Soda、Monte Carlo、Datafold、Bigeye。
• 血缘：OpenLineage、Marquez、DataHub、Apache Atlas、Unity Catalog。
• 调度监控：Airflow UI、Prometheus、Grafana、Dagster UI。

9.6.5 Depth Tiers

本计划目标：L3。综合项目可触及局部 L4，但不作为 6~10 周的硬门槛。

9.6.6 Source

• Apache Airflow 官方文档：DAG、Operator、Executor。引用快照日期：2026-07-30。
• Apache Iceberg 官方文档：表格式规范。引用快照日期：2026-07-30。
• Apache Kafka 官方文档：Producer/Consumer/Streams。引用快照日期：2026-07-30。
• Apache Flink 官方文档：DataStream / Table API。引用快照日期：2026-07-30。
• dbt 官方文档：转换与测试。引用快照日期：2026-07-30。
• OpenLineage 规范：血缘标准。引用快照日期：2026-07-30。
• Reis《Fundamentals of Data Engineering》：数据工程生命周期。引用快照日期：2026-07-30。

10. 常见误区

• 把”搭好 Airflow”当数据工程；缺分层、缺质量门禁、缺血缘；
• 只做 ETL 不做 ELT；数据便宜时先入仓再转换；
• 流处理只跑通 happy path，不测乱序与迟到；
• 数据质量只在 dashboard 看，不挂门禁；
• Schema 演进靠 ALTER TABLE，不走表格式版本化；
• 维度建模用雪花型，雪花型难维护；
• Iceberg / Delta / Hudi 当裸 Parquet 用，不配 schema evolution；
• Kafka 用 at-most-once 当 exactly-once；
• Flink State 后端用 HashMap，处理大状态 OOM；
• dbt 全量重算不开 incremental；
• 数据契约只在文档里写，不入 Schema Registry；
• 血缘只画表级不看列级；
• 批流结果不一致当”小问题”，不验证；
• 流处理 checkpoint 配置不当，状态恢复丢数据；
• 数据测试只测 unique / not_null，不测分布异常；
• 综合项目只跑通 DAG 不做故障演练；
• 学完不复盘，下次面试依然答不上来。

11. 所有知识点分类（统一规则）

1. 编程语言
2. 数据结构与算法
3. 计算机基础
4. 工程技术
5. Web 与后端
6. 前端与客户端
7. 数据与人工智能
8. 项目与职业能力
9. 安全与可靠性

本计划归属：数据与人工智能 主 + 工程技术 辅。