数据工程全景知识图谱
批处理、流处理、ETL / ELT、数据湖仓、调度编排、治理质量与数据平台建设 (2025-2026)
Layer 1
数据源
DB/API/日志/埋点
→
Layer 2
采集传输
CDC/消息/同步
→
Layer 3
处理计算
批/流/SQL/转换
→
Layer 4
存储组织
湖/仓/湖仓/特征
→
Layer 5
消费治理
BI/模型/质量/权限
| 上层 | 依赖的下层 | 关系说明 |
|---|
| 采集链路 | 数据源 | 上游表结构、事件定义和埋点规范不稳定，后面的数据平台再高级也会持续返工。 |
| 计算处理 | 采集传输 | 批处理和流处理的稳定性、延迟和准确性都高度依赖输入数据的时序、完整性和重复控制。 |
| 数仓 / 湖仓 | 处理计算 | 没有干净一致的加工层，所谓统一口径、主题模型和指标体系很难真正成立。 |
| BI / AI / 特征消费 | 存储组织 | 报表、数据应用和模型训练效果最终取决于底层数据模型是否稳定、可解释、可追溯。 |
| 数据治理 | 全链路元数据 | 权限、血缘、质量、口径、留存和成本控制，都需要贯穿从采集到消费的元数据体系支撑。 |
| 数据平台 | 工程化能力 | 数据工程的难点不只是跑通任务，而是把依赖、回填、调度、质量和权限做成长期可维护体系。 |
1990s - 数据仓库兴起
企业开始系统建设以报表和决策支持为目标的数据仓库，ETL 成为核心能力。
2000s - Hadoop 时代
海量离线数据存储和批处理成本下降，数据平台从传统仓库扩展为大数据生态。
2010 - 实时数据处理增长
Kafka、Storm、Spark Streaming 等推动数据从 T+1 走向分钟级乃至秒级。
2015 - 云数仓与 ELT 扩大
Snowflake、BigQuery、Redshift 等让“先入仓再算”的 ELT 模式快速普及。
2018 - 数据湖与湖仓合流
Parquet、Iceberg、Delta Lake、Hudi 等技术推动湖和仓的边界重新定义。
2020 - 数据编排与转化工程成熟
Airflow、dbt、Dagster 等让数据任务、依赖和模型管理更工程化。
2022 - DataOps / 数据质量强化
团队开始把测试、可观测、版本化和发布治理引入数据管道，而不只是关注查询结果。
2023-2025 - AI 与数据平台融合
向量数据、特征平台、RAG、实时特征流和统一治理让数据工程的职责继续外扩。
采集方式
全量导出、增量同步、日志订阅、CDC、埋点上报、Webhook 拉取，适合的链路和一致性要求完全不同。
真正难点
难点通常不是“把数据拿过来”，而是处理 schema 演进、重复事件、乱序到达、补数回放和上下游版本差异。
经验判断
如果上游数据契约不稳定，后面的建模、报表和机器学习都会反复背锅。
批处理
适合大规模历史计算、复杂聚合和成本友好型任务，但实时性较弱。
流处理
适合实时指标、告警、推荐特征和事件驱动场景，但需要更严肃地面对状态管理、时间语义和容错。
批流一体
很多团队追求一套语义同时处理离线与实时，但真正难的是保证口径一致、延迟可控和开发复杂度不过载。
为什么需要分层
ODS、DWD、DWS、ADS 这类分层不是教条，而是为了隔离原始数据、清洗逻辑、主题加工和最终消费输出。
指标口径为什么常打架
很多组织的问题不是不会写 SQL，而是没有统一维度、指标定义、主键体系和业务口径归属。
经验原则
数据建模如果不服务消费场景，只会变成漂亮但没人真正用的抽象结构。
数据质量不只是空值检查
完整性、唯一性、时效性、分布异常、口径偏移、主外键一致性和 SLA 延迟都属于质量问题。
血缘的价值
没有血缘关系图，很难判断一个字段变更会影响哪些任务、看板、服务和模型。
治理的本质
权限、审计、留存、敏感数据分级和成本控制，决定数据平台能不能真正服务组织，而不是变成数据沼泽。
| 类别 | 主流工具 | 定位 | 适用场景 | 关键考量 |
|---|
| 数据采集 | Debezium / Fivetran / Airbyte / Kafka Connect | 数据库同步、CDC、SaaS 接入 | 异构源采集、日志订阅 | schema 演进和同步稳定性 |
| 消息与流 | Kafka / Pulsar / Redpanda | 事件流和实时传输 | 实时数据链路、事件总线 | 顺序、积压、重放和成本 |
| 计算引擎 | Spark / Flink / Beam / dbt | 批处理、流处理、SQL 转换 | ETL、实时加工、建模 | 资源成本、语义复杂度、可维护性 |
| 存储与分析 | Snowflake / BigQuery / ClickHouse / Iceberg / Delta Lake | 仓库、湖仓、分析存储 | 报表分析、主题建模、明细留存 | 性能、成本和开放性 |
| 编排调度 | Airflow / Dagster / Prefect / DolphinScheduler | 任务编排与依赖管理 | 批任务、回填、定时管道 | 依赖可视化与失败恢复 |
| 治理质量 | Great Expectations / DataHub / OpenMetadata / Amundsen | 质量校验、血缘、目录 | 数据资产管理、治理和协作 | 元数据覆盖率和组织采纳度 |
CDC
- 比定时全量同步更实时、更省资源
- 适合数据库变更订阅和增量入湖
- 要严肃处理主键变更、DDL、延迟和重复事件
数据编排
- 任务依赖、失败重试、回填、补数和 SLA 是核心
- 没有编排体系的数据平台，维护成本会快速失控
实时特征
- 推荐、风控、搜索和 AI 场景都需要低延迟特征供应
- 真正难的是在线离线口径一致和时效 SLA
元数据平台
- 目录、血缘、字段说明、责任人、敏感级别
- 元数据不是装饰，而是数据组织协作的索引层
BI 报表
- 关注统一口径、延迟可控、权限分层
- 重点是稳定而不是极限实时
实时监控
- 关注秒级更新、异常检测和事件联动
- 更依赖流处理和消息基础设施
机器学习 / 特征平台
- 关注训练与推理口径一致、特征复用、回放能力
- 数据质量缺陷会直接放大成模型效果波动
数据产品 API
- 把数据结果以服务形式供业务消费
- 需要兼顾性能、缓存、权限和版本治理
ETL
- 优点: 入仓前更容易把数据清洗干净
- 优点: 对传统数仓和严格治理更友好
- 缺点: 流程长、灵活性较差
- 缺点: 试错和迭代速度可能偏慢
- 适合: 口径严格、合规要求高的场景
ELT
- 优点: 原始数据先落地，后续建模更灵活
- 优点: 更适合云数仓和现代分析栈
- 缺点: 原始层容易变脏，治理要求更高
- 缺点: 成本和权限控制要更细
- 适合: 变化快、实验多、分析需求频繁变化的团队
| 方案 | 优点 | 代价 | 适合谁 |
|---|
| 离线数仓 | 稳定、成本可控、治理成熟 | 实时性弱 | 报表为主的团队 |
| 实时数仓 | 响应快、适合实时监控和推荐 | 链路复杂度高、维护成本高 | 实时业务强的团队 |
| 数据湖 | 开放灵活、适合多类型数据沉淀 | 管理和口径容易失控 | 数据规模大、格式多样的组织 |
| 湖仓一体 | 兼顾开放性与分析性能 | 生态和治理方案选择复杂 | 追求统一平台的中大型团队 |
| 引擎 | 强项 | 短板 | 建议 |
|---|
| Flink | 状态管理、时间语义、实时计算能力强 | 运维和开发心智较重 | 实时链路核心引擎优先考虑 |
| Spark | 生态成熟、批处理强、团队易上手 | 真流式能力和低延迟场景不如 Flink | 批处理和准实时场景很合适 |
| dbt | SQL 建模、依赖清晰、数据开发体验好 | 更偏仓内转换，不是通用计算引擎 | 现代 ELT 团队常见选择 |
任务 SLA
- 每条链路都要有延迟预期、失败阈值和补数机制
- 报表延迟和实时特征延迟不是一回事，SLA 必须分类定义
数据质量门禁
- 空值、重复、主键唯一、波动阈值、分布漂移都应自动检查
- 没有质量门禁的补数和发版，风险会持续叠加
回填与重放
- 数据平台一定会遇到补数、历史修正和重放需求
- 如果系统设计时没考虑回填，后期维护成本会极高
成本治理
- 扫描量、存储周期、冷热分层、任务资源配额都要持续优化
- 数据平台最常见的隐性问题之一就是成本失控
权限分层
库、表、字段、行级权限和脱敏规则需要清晰定义，尤其在敏感数据、跨部门协作和对外数据服务场景中。
血缘与审计
谁依赖了哪些字段、谁修改了哪些模型、哪些任务失败会影响哪些报表，应该能被快速追踪而不是靠问人。
经验原则
没有治理的数据平台，规模越大越容易演变成“数据很多，但没人敢完全相信”。
SQL + 建模
→
ETL / ELT
→
调度编排
→
质量治理
→
数仓交付
周期: 4-8 个月
前置: SQL 基础 + 一点业务理解
输出: 能独立搭建稳定的数据链路
关键: 先理解消费场景，再做建模抽象
Kafka / 流基础
→
时间语义
→
Flink / Spark
→
状态管理
→
实时链路治理
周期: 8-18 个月
前置: 并发、消息和分布式基础越扎实越好
输出: 能建设低延迟实时数据系统
关键: 口径一致比“绝对实时”更重要
数据资产盘点
→
模型与口径体系
→
质量与血缘
→
权限与成本
→
平台产品化
周期: 1-3 年
前置: 既懂业务又懂数据链路更占优势
输出: 建一个组织级可用的数据平台
关键: 数据平台首先是产品，其次才是工具堆叠
误区: 数据工程就是写 SQL
- 真正难点在链路稳定性、调度依赖、质量治理、口径管理和消费交付
- 只会写转换逻辑，不等于能维护长期可用的数据平台
误区: 实时一定比离线先进
- 实时的代价非常高，不是所有业务都值得为秒级延迟付出复杂度成本
- 很多组织真正需要的是更稳定的小时级和分钟级交付
误区: 有数据湖就自动有治理
- 没有元数据、权限、血缘和质量体系的数据湖，很容易变成数据沼泽
- 开放性和可维护性不是同一回事
误区: 指标口径问题靠多开会能解决
- 没有统一模型、维度定义和责任归属，再多沟通也只会反复拉扯
- 口径统一是工程和组织协作问题，不只是沟通问题
确定性趋势:
湖仓一体继续增强: 开放表格式、统一元数据和弹性计算会继续推动湖与仓的边界融合。
DataOps 继续成熟: 测试、发布、回填、观测和质量门禁会越来越像软件工程流水线。
AI 与数据平台进一步耦合: 特征、向量、训练数据集和 RAG 素材治理会进入数据工程主战场。
值得关注:
流批统一开发体验: 更好的 SQL 化、声明式编排和统一元数据层会降低实时链路门槛。
数据产品化: 越来越多团队会把数据结果以 API、特征服务和自助分析产品形式交付，而不只是交一张表。
需要警惕:
成本膨胀: 存储保留过长、扫描无节制和重复计算会让数据平台账单迅速失控。
平台过度复杂: 小团队过早全量引入大厂数据架构，往往会先被维护成本压垮。
治理后置: 等到数据量和协作复杂度起来后再补权限、口径和血缘，代价通常极高。
总结:
数据工程的本质，不是“把数据搬一下、洗一下”，而是建设一条从采集到消费都稳定、可追溯、可治理、可扩展的数据生产线。
给不同角色的建议:
- 数据开发: 先把采集、建模、调度和质量的基本盘打稳，再追更复杂的架构名词
- 实时数据工程师: 把注意力放在时间语义、状态管理和口径一致，而不只是低延迟本身
- 数据平台负责人: 优先补元数据、权限、血缘和成本治理，别让平台先长成“数据沼泽”
一句话判断这张图的价值:
它回答的不是“数据工具有哪些”，而是“一个组织怎样把数据从原材料，变成可持续交付的工程产品”。