本专题覆盖现代数据工程完整技术栈：数据采集与集成、存储架构、处理引擎、实时数仓、数据治理与平台工程。共 44 篇深度文章，助你在数据架构演进中做出正确决策。
一、数据工程全景
🏗️
Modern Data Stack 全栈实践概述
Modern Data Stack 组件生态：ELT/ETL 选型、仓/湖/湖仓一体演进、编排与数据目录治理。
- 组件解耦与 SaaS 化服务组合是 Modern Data Stack 核心特征
- ELT 优先于 ETL 已成为云原生数仓的主流范式
- 数据目录（DataHub/Amundsen）是治理的可发现性基础设施
二、数据集成 ETL/ELT
🔀
ETL/ELT 架构设计与增量同步
ETL vs ELT 选型差异，批量/增量同步、CDC 捕获原理与流批一体实现方案。
- ETL 适合强一致性场景，ELT 依赖弹性算力实现仓内转换
- 基于查询 vs 基于日志的 CDC 在延迟与侵入性上有根本差异
- 流批一体是统一语义下的双模执行
🧱
dbt 数据转换与 DataOps 实践
dbt 完整指南：models/tests/docs/macros 核心概念、Jinja 宏、CI/CD 集成与部署。
- dbt 将软件工程最佳实践（版本控制、模块化、测试）引入数据转换
- Jinja 宏与 ref/source 机制实现 SQL 的可复用与可追踪
- dbt tests + docs 构建数据质量与可发现性的基础闭环
⚡
Debezium CDC 与 Kafka Connect 实战
MySQL/PostgreSQL Source/Sink Connector、Schema Evolution 与 SMT 单条消息转换实战。
- 基于日志的 CDC（binlog/WAL）延迟低且无源库侵入性
- Debezium 原生支持删除事件捕获与完整前后镜像
- SMT 在管道中实现轻量数据变形
🔌
现代数据集成平台：Airbyte、Fivetran 与 SeaTunnel
ELT 集成平台对比：Airbyte 开源连接器体系、Fivetran 托管服务、SeaTunnel 引擎选型，增量同步、Schema 变更与调度运维。
- 连接器数量与维护成本是集成平台选型的第一约束
- 增量同步依赖游标/CDC 语义，必须显式验证幂等与断点续传
- 集成平台只解决搬运，转换与治理仍要落在下游仓内
📄
非结构化文档 ETL 与多模态数据
非结构化 ETL 完整链路：文档解析工具选型与 PDF 三种形态差异、OCR 与版面分析、表格抽取、分块策略与重叠控制、元数据与血缘注入、嵌入生成与向量入库、增量重处理与幂等设计，以及质量评估与成本控制。
- 企业 80% 的数据躺在 PDF/扫描件/音视频里，SQL 无法直接查询
- 解析 → 分块 → 嵌入 → 入库，分块策略决定召回质量上限
- 增量重处理必须幂等，重嵌与版本管理是长期成本大头
三、存储架构
📐
数据仓库建模深度指南
Kimball、Data Vault 2.0、Data Mesh、Anchor Modeling 与 OBT 五大方法论，附星型/雪花模型实战。
- Kimball 以业务过程为中心，星型模型是 BI 查询的最优结构
- Data Vault 2.0 通过 Hub-Link-Satellite 实现高度灵活与可审计
- Data Mesh 将建模权责下放至领域团队，强调数据即产品
🏔️
数据湖技术深度对比
Iceberg、Delta Lake 与 Apache Hudi 三大湖技术对比：ACID、Schema Evolution 与 Time Travel。
- Iceberg 以开源中立性成为湖仓格式首选
- Delta Lake 在 Databricks 生态中深度优化，Time Travel 开箱即用
- Hudi 的 Merge On Read 模式在 CDC 流式入湖表现最优
🚀
Doris 与 StarRocks MPP OLAP 实战
Doris/StarRocks 的 MPP 架构、向量化执行、物化视图与联邦查询能力解析。
- MPP + 向量化执行使 Doris/StarRocks 达到亚秒级 OLAP 查询
- 物化视图与预聚合是报表场景的关键性能加速器
- 联邦查询支持跨 Lakehouse 与仓的统一 SQL 分析
📊
ClickHouse 高性能分析引擎
ClickHouse 列式存储：MergeTree 家族、sparse index、向量化执行、物化视图与查询优化。
- MergeTree 引擎家族覆盖时序、聚合与级联存储等多元场景
- 稀疏主键索引与主键排序实现极致扫描剪枝
- 物化视图与 Projection 为高频查询提供自动路由加速
🧊
湖仓一体架构：Iceberg/Delta/Hudi 统一底座
湖 vs 仓 vs 湖仓演进、Apache Iceberg 开放表格式（ACID/时间旅行/增量读取）、Delta 与 Hudi 对比、Bronze/Silver/Gold 分层、compaction 与 z-order 优化及批流一体写入。
- 开放表格式让对象存储拥有数仓级 ACID 与治理能力
- 湖仓为底座、OLAP 为加速层的存算分离是主流架构
- 定期 compaction 与快照清理决定湖仓查询性能的下限
🧊
Apache Iceberg 深度剖析：元数据层、ACID 与表优化
Iceberg 五级元数据模型（Catalog/Metadata/Manifest List/Manifest/Data File）、快照隔离与乐观并发、隐藏分区与分区演进、Schema 演化、小文件合并与生产调优。
- 五级元数据 + 快照隔离让对象存储获得数仓级 ACID
- 隐藏分区与分区演进避免用户手工管理分区路径
- 定期 compaction 与快照过期是表健康的必要运维
🗜️
数据湖运维：小文件合并、压缩与元数据维护
小文件问题成因与危害、Iceberg/Hudi/Delta 的 compaction 机制、文件大小与分区粒度调优、快照清理与孤儿文件回收、Z-Order 与聚类优化、运维调度与监控。
- 小文件拖垮查询与元数据，合并是湖仓第一运维项
- 目标文件大小需按扫描模式设定，过犹不及
- 快照过期与孤儿文件回收是成本治理的关键动作
🔍
SQL 查询优化：从执行计划到吞吐调优
EXPLAIN 读法与代价模型、索引设计、分区裁剪与分桶、谓词下推、Join 策略与数据倾斜、聚合与窗口函数优化，附慢查询定位与查询重写模式。
- 先解决"扫了多少"（分区裁剪/下推）再抠"每行多快"
- 数据倾斜用加盐摊平，小表广播免 shuffle
- 每次重写必须回归验证结果一致（语义不变）
🧬
Schema 迁移与数据演进
迁移工具（Flyway/Liquibase）与版本管理、expand-contract 安全迁移、双写与对账、NOT NULL 加列三步、大表在线迁移、流式 Schema 演进与兼容性策略。
- 破坏性变更拆成 expand-contract 多步，新老代码共存
- 双写期间对账收敛后才切流，永远可回滚
- 流式数据用 Schema Registry 管 BACKWARD 兼容
🛂
湖仓访问控制与权限治理
湖仓权限三层模型（存储层/表层/行列表级）、Iceberg 与 Delta 表级授权、统一 Catalog 与凭证下发机制、行过滤与列掩码、标签驱动的访问控制、跨引擎权限一致性、审计与合规落地，附最小权限推进路径。
- 对象存储让权限脱离数据库把守，必须补齐存储层授权
- 统一 Catalog + 凭证下发才能实现跨引擎一致的权限
- 行过滤与列掩码是行列级治理的最终落地手段
四、处理引擎
🔥
Spark 批处理与生产调优
RDD/DataFrame/Dataset 选型、Spark SQL 优化、Shuffle 机制、Catalyst 优化器与生产调参。
- DataFrame/Dataset 通过 Catalyst 优化器与 Tungsten 序列化实现执行优化
- Shuffle 是 Spark 性能瓶颈，理解 SortShuffleManager 是调优基础
- 动态资源分配与 AQE 自适应查询执行是生产环境必备配置
🌊
Flink 流处理与 Exactly-Once 语义
DataStream API 编程模型、Checkpoint 容错、Watermark 事件时间、窗口计算与 Exactly-Once 实现。
- Watermark 机制解决流处理中事件时间与处理时间的偏差问题
- Checkpoint 的 barrier 算法与两阶段提交保证 Exactly-Once 一致性
- 键控状态（Keyed State）与算子状态是实现复杂业务逻辑的基石
⏰
流处理进阶：窗口、水印与状态
事件时间 vs 处理时间、滚动/滑动/会话/计数窗口选型、水印与乱序容忍、迟到数据三策略、状态后端与 TTL、Exactly-Once 与检查点、流表 Join 与背压。
- 业务指标必须以事件时间聚合，水印容忍度按业务权衡
- 状态必须设 TTL，检查点必须监控，否则恢复即灾难
- 端到端 Exactly-Once 靠幂等 Sink 落地，不只在引擎内
⚙️
列存与向量化查询引擎：Doris、ClickHouse、StarRocks 与 Trino
列式存储与向量化执行原理、MPP 与联邦架构差异、CBO 与运行时过滤、向量化 vs 代码生成、四引擎能力矩阵与选型决策、混合部署策略。
- 向量化执行 + 列存是亚秒级 OLAP 的共同底座
- MPP 引擎胜在预聚合与物化视图，Trino 胜在联邦与弹性
- 选型先看查询模式（点查/宽表扫描/联邦）再比跑分
🐻❄️
Polars 与 DuckDB：单机现代数据处理栈
Polars 惰性求值与查询优化、表达式 API 与并行执行、DuckDB 嵌入式列存与 SQL 方言、Parquet/Arrow 零拷贝互操作、单机处理 GB 级数据与 pandas 迁移路径。
- Arrow 内存格式让 Polars/DuckDB/Parquet 之间零拷贝互通
- 单机栈已能处理数十 GB 数据，不必动辄上集群
- 从 pandas 迁移先改惰性管道与表达式，而非逐行改写
🔀
流批一体：从 Lambda/Kappa 到统一计算层
Lambda 与 Kappa 架构取舍、流批统一表抽象与统一 API、Flink 批流一体执行模式、Iceberg/Delta 作为统一存储底座、回填与重放、一致性语义对齐。
- 统一存储 + 统一 API 才能真正消灭双链路维护成本
- 批是流的特例：有界输入让调度与容错可以退化优化
- 历史回填必须与实时链路共享同一套代码与语义
♻️
流处理精确一次与状态后端：Checkpoint 与两阶段提交
Checkpoint 屏障对齐与增量快照、状态后端选型（内存/RocksDB）、两阶段提交 Sink 与幂等写入、端到端 Exactly-Once 落地、大状态调优与恢复时间治理。
- 端到端精确一次靠幂等或事务 Sink，引擎内只是必要条件
- 状态规模决定后端选型与恢复时长，须提前压测
- 增量 Checkpoint 与本地恢复是把 MTTR 压下来的关键
🧮
Spark 性能调优：Shuffle、内存与数据倾斜
从执行计划与 Spark UI 定位瓶颈，拆解 Shuffle 的落盘与网络代价及减少手段、统一内存管理与 executor 内存分配公式、GC 与序列化选择、数据倾斜的加盐/广播/AQE 三类解法、小文件与小分区治理，附参数基线与调优流程。
- Shuffle 太贵、内存不够、分布不均是 Spark 变慢的三大主因
- 先看执行计划与 Spark UI 定位瓶颈，再谈调参
- 加盐摊平 + 广播 Join + AQE 是消除倾斜的现代组合
💾
Flink 状态后端与 Checkpoint 调优
HashMapStateBackend 与 RocksDB 的取舍、Checkpoint 间隔/超时/并发/增量/非对齐的参数含义、State TTL 与状态规模治理、本地恢复把恢复时间从分钟压到秒，附监控指标、参数模板与踩坑清单。
- 状态后端选错直接 OOM，大状态必须 RocksDB + 增量快照
- Checkpoint 参数配错会让作业反复重启
- State TTL 与本地恢复是稳定性与 MTTR 的两条生命线
🧾
流式 SQL：Flink SQL 与 ksqlDB
流式 SQL 把无限流当作持续变化的表：动态表与 changelog 三种模式、Flink SQL 的 DDL 与连接器定义、事件时间与水位线声明、窗口 TVF 与各类 Join 的语义差异、状态与性能代价，并对比 ksqlDB 架构与 pull/push 查询。
- 动态表与 changelog 是流式 SQL 的语义基础
- 流表 Join 的语义与状态代价差异极大，须按场景选型
- Flink SQL 重生态与批流统一，ksqlDB 重 Kafka 一体化
五、DataOps 与数据质量
🛡️
数据治理与质量管理实战
数据血缘（OpenLineage）、质量监控（Great Expectations/Soda）、数据目录与 GDPR 合规设计。
- 每个数据集需明确 Data Owner（业务规则）与 Data Steward（日常维护）
- 字段级数据血缘才能支撑真正的根因分析
- Great Expectations 将质量规则声明式化并嵌入 CI/CD
🧪
数据质量监控实战：GX 与 Soda 完整体系
数据质量六大维度、Great Expectations 期望套件与 Checkpoint、Soda Core 与 SodaCL 规则、质量门禁进 CI/CD、基数与均值漂移异常检测，附生产配置与案例。
- 完整性/唯一性/一致性/时效性/准确性/有效性构成监控基线
- Great Expectations 管 CI 发布门禁，Soda 管运行期持续扫描
- 基数与均值漂移的统计式异常检测先于报表投诉预警
🗺️
数据目录与血缘追踪：元数据驱动治理
技术/业务/操作元数据模型、OpenMetadata/DataHub/Amundsen 对比、SQL 解析与 OpenLineage 血缘采集、Owner 分级治理与血缘驱动的变更影响分析。
- 字段级血缘才是根因分析与影响评估的基础
- OpenLineage 事件采集为主、SQL 解析为辅的混合血缘构建
- 血缘影响分析嵌入发布流程，大幅降低变更事故
🔭
数据可观测性：从管道监控到数据宕机预警
管道 Job 状态/耗时/失败率监控、数据新鲜度与数据宕机、Volume/Quality/Schema 指标、Airflow/Dagster 可观测性、日志追踪与告警分级及 on-call 机制。
- 数据宕机与服务宕机同样代价高昂，却长期被忽视
- volume/quality/schema/freshness 四类指标构成健康画像
- SEV 分级告警与 runbook 把 MTTR 从小时级压到分钟级
📏
指标层与语义层：让指标口径成为工程资产
指标口径不一致的根源、原子/派生/复合指标体系、语义层设计（实体/度量/指标）、dbt 语义层与 MetricFlow、指标生命周期与血缘治理、自助分析与指标 API。
- 单一定义、多路复用是语义层黄金法则，一处定义处处一致
- 指标四要素（口径/粒度/维度/过滤）缺失 = 治理失控
- 先 10 个最高频指标做起，小步快跑别全量迁移
🔐
数据安全与隐私合规：从加密到合规审计
数据分级与 PII 识别、传输与字段级加密、静态/动态脱敏、RBAC 与行/列级权限、GDPR/PIPL 落地映射、保留策略与删除权、审计与事件响应。
- 分级才能精准防护，重点保护 L3/L4 数据
- 测试环境绝不出现真实 PII，脱敏是默认属性
- 删除权沿血缘级联执行，审计日志防篡改可查
📜
数据合约与 Schema Registry：让数据接口可演进
数据合约与 Schema 的区别、Confluent Schema Registry 架构与主题策略、Avro/Protobuf/JSON Schema 对比、BACKWARD/FORWARD/FULL 兼容规则、消费者驱动契约测试、权限审计与端到端落地。
- Schema Registry 管格式能否解析，数据合约管语义有没有变
- 契约测试把兼容性从约定变成可证明的 CI 门禁
- 字段号与默认值是演进安全的底线
✅
数据管道测试与 CI/CD
管道测试金字塔的分层策略、dbt 与 pytest 的单元测试写法、容器化集成测试、数据 diff 与对账断言、契约与 Schema 兼容性校验、CI/CD 流水线设计（分支构建/制品晋级/幂等回滚），以及影子运行与灰度发布的生产验证方法。
- 管道测试分单元/集成/生产验证三层，不能照搬应用测试
- 数据 diff 与对账断言是转换正确性的最后一道门禁
- 制品晋级 + 幂等回滚让发布永远可退
六、实时方案
⏱️
实时数仓全链路实战
从零构建 Kafka + Flink + ClickHouse 实时数仓，涵盖采集、计算、存储与实时大盘全链路。
- Kappa+ 以流为主链路，批处理作为异常补偿与历史回溯兜底
- Flink 到 ClickHouse 的写入需控制批次大小与频率，平衡实时与性能
- 实时与离线指标的对齐是实时数仓最困难的质量挑战
🔄
Flink 实时计算引擎详解
Flink 在实时数仓中承担流式 ETL 与指标聚合，支持事件时间语义与 Exactly-Once 处理。
- Flink SQL 与 Table API 降低了流处理开发门槛
- 窗口聚合（Tumble/Session/Hop）是实时指标计算的核心算子
- Side Output 与 Late Data 处理策略保障输出确定性
📡
CDC 实时数据入仓
Debezium CDC 将 MySQL/PostgreSQL 变更实时推入 Kafka，作为实时数仓的源头数据层。
- CDC 流是实时数仓与源系统保持同步的唯一低延迟方案
- Schema Evolution 保证表结构变更不影响下游消费
- 事务边界感知确保批量变更的原子性投递
七、平台工程
🏢
数据平台工程核心范式
Data Mesh 架构设计、DataOps CI/CD 实践、FinOps 成本优化与平台工程模式，附生产落地经验。
- Data Mesh 的核心是领域自治的数据产品，而非集中式数据团队
- DataOps 将 DevOps 工程纪律（CI/CD、测试、监控）注入数据流水线
- FinOps 通过资源标签化、自动伸缩与存储分层实现云成本可控
📈
BI 可视化工具深度对比
Tableau、Power BI、Apache Superset 与 Metabase 对比：定位、建模、图表、嵌入集成与扩展。
- Tableau、Power BI 适合复杂分析，License 成本需纳入 TCO
- Superset、Metabase 以开源轻量见长，适合技术团队自建
- 嵌入集成能力（iframe/SDK/API）决定 BI 能否融入业务系统
🎼
数据管道编排：Airflow、Dagster 与 Prefect 生产实践
编排 vs 调度、三大框架对比与选型、DAG 设计（幂等/依赖/粒度）、动态任务与数据感知、重试与告警分级、并发与资源池、编排可观测性与测试、生产架构。
- 以分区参数贯穿全链保证幂等，数据依赖替代时间猜测
- 重试分型：瞬时重试/数据型不重试，指数退避 + 抖动
- 编排即操作日志：成功率、新鲜度、SLA 全量沉淀
🕸️
数据网格 Data Mesh：领域数据产品与联邦治理
Data Mesh 四原则（领域所有权/数据即产品/自助平台/联邦计算治理）、数据产品契约与 SLO、自助平台能力建设、联邦治理与全局标准、组织转型路径与常见失败模式。
- 数据网格是组织与权责设计，不是一套技术选型
- 数据产品必须有 Owner、契约、SLO 才算成立
- 联邦治理要在自治与统一标准之间显式划界
💰
数据平台成本与 FinOps：存储、计算与弹性降本
成本可见性（标签/分摊/单位成本）、存储分层与生命周期、计算弹性与 Spot 实例、查询成本归因、批流资源调度、降本优先级与组织机制。
- 先建立单位成本指标（每 TB/每查询/每用户），否则无从优化
- 存储降本靠分层与生命周期，计算降本靠弹性与调度
- FinOps 是持续机制，不是一次性压预算
🗄️
数据归档与生命周期：冷热分层与合规删除
热温冷分层模型与迁移触发、对象存储归档类（IA/Glacier）选型、保留策略与法定留存、合规删除与血缘级联、归档可查询性与恢复成本、自动化生命周期编排。
- 分层依据是访问频次与恢复时延要求，不是数据年龄
- 合规删除必须沿血缘级联并留痕，否则审计过不去
- 归档不是删除，恢复成本要提前写进 SLA
八、数据激活与 MLOps
🔁
反向 ETL 与数据激活
反向 ETL 概念与价值、RudderStack/Hightouch/Census 工具对比、CRM/SaaS/客服同步目标、受众分段同步、Webhook 与 API 激活、与 CDP 关系及实时批量混合架构。
- 反向 ETL 让数据仓库从分析资产升级为业务操作底座
- 身份映射（identity map）与幂等同步是受众分段的命门
- 批量为主、实时兜底是性价比最高的激活架构
🧬
特征存储（Feature Store）架构
特征平台概念、Training-Serving Skew 一致性、特征注册与版本、Redis/向量在线检索、批流特征计算、Feast 选型与特征血缘监控，附推荐系统实战案例。
- Point-in-Time Join 与单一特征定义是消除训练服务偏差的关键
- 在线 Redis 与向量库支撑毫秒级特征检索
- 特征血缘与 PSI 漂移监控守护模型长期健康
🧠
向量数据库与 RAG 数据管道：嵌入生成与检索服务
嵌入模型选型与批量生成、向量索引（HNSW/IVF/PQ）与召回调优、pgvector/Milvus/Qdrant 对比、增量更新与重嵌入、混合检索与重排序、RAG 管道的质量评估与成本控制。
- 嵌入质量决定召回上限，索引只决定召回效率
- 增量更新与重嵌入策略是 RAG 长期可维护的关键
- 混合检索（向量 + 关键词）+ 重排序通常优于纯向量
数据工程全链路架构图
┌──────────────────────────────────────────────────────────────────────────┐
│ 现代数据工程全链路架构 │
├──────────────────────────────────────────────────────────────────────────┤
│ 【集成层】 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 业务系统 │──│Debezium │──│ Kafka │────┐ │
│ │MySQL/PG │ │ CDC │ │ Connect │ │ │
│ └──────────┘ └──────────┘ └──────────┘ │ │
│ │ │ │
│ │ ┌──────────┐ │ │
│ └───│ API/SDK │────────────────────────┤ │
│ │ 埋点数据 │ ▼ │
│ └──────────┘ ┌──────────┐ ┌──────────┐ ┌──────┐ │
│ 【引擎层】 │ Kafka │ │ dbt │ │Spark │ │
│ ┌────────────────────────│ Topics │ │数据转换 │ │(批) │ │
│ │ └────┬─────┘ └────┬─────┘ └──┬───┘ │
│ ┌────┴──────┐ │ │ │ │
│ ┌───▼───┐ ┌────▼────┐ ┌────▼───┐ │ │ │
│ │ Flink │ │ Flink │ │Flink │ │ │ │
│ │实时ETL│ │窗口聚合 │ │实时ETL │ │ │ │
│ └───┬───┘ └────┬────┘ └───┬────┘ │ │ │
│ │ │ │ │ │ │
│ ▼ ▼ ▼ ▼ ▼ │
│ 【存储层】 │
│ ┌────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────┐ │
│ │ Iceberg│ │Hudi/Delta│ │ Doris │ │ClickHouse│ │StarRock│ │
│ │ 数据湖 │ │ 数据湖 │ │ MPP │ │ OLAP │ │实时OLAP│ │
│ └───┬────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ └───┬────┘ │
│ │ │ │ │ │ │
│ └───────────┴───────────────────┴──────────────┴────────────┘ │
│ │ │
│ 【服务层】 ┌────▼────┐ ┌────▼────┐ ┌────▼────┐ │
│ │数据治理 │ │数据目录 │ │ BI 工具 │ │
│ │OpenLineag│ │DataHub/ │ │Tableau/ │ │
│ │Soda Core │ │Amundsen │ │Superset │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ ↓ 数据消费 │
│ ┌──────────────┐ │
│ │ 业务用户/分析师│ │
│ │ 仪表盘/报表 │ │
│ └──────────────┘ │
└──────────────────────────────────────────────────────────────────────────┘
专题学习路线图
阶段一：基础认知 (3篇)
├── data-engineering-overview .......... Modern Data Stack 全景 [⭐⭐⭐]
├── etl-elt-design ..................... ETL/ELT 架构同步 [⭐⭐⭐⭐]
└── dbt-data-transformation ............ dbt 数据转换 [⭐⭐⭐]
阶段二：存储架构 (4篇)
├── data-warehouse-modeling ............ Kimball / Data Vault / Mesh [⭐⭐⭐⭐]
├── data-lake-technologies ............. Iceberg / Delta / Hudi [⭐⭐⭐⭐]
├── doris-starrocks .................... MPP 实时 OLAP [⭐⭐⭐]
└── clickhouse-analytics ............... 列式分析引擎 [⭐⭐⭐⭐]
阶段三：处理引擎 (2篇)
├── apache-spark-batch ................. Spark 批处理调优 [⭐⭐⭐⭐]
└── apache-flink-streaming ............. Flink 流处理 [⭐⭐⭐⭐⭐]
阶段四：实时数仓 (3篇)
├── kafka-connect-cdc .................. CDC 实时入仓 [⭐⭐⭐⭐]
├── apache-flink-streaming ............. Flink 实时计算 [⭐⭐⭐⭐⭐]
└── realtime-data-warehouse ............ 全链路实战 [⭐⭐⭐⭐⭐]
阶段五：治理与平台 (3篇)
├── data-governance-quality ............ 血缘/质量/合规 [⭐⭐⭐⭐]
├── data-platform-engineering .......... Data Mesh / FinOps [⭐⭐⭐⭐]
└── bi-visualization-tools ............. BI 可视化对比 [⭐⭐]
推荐学习顺序：全景概览 → 数据集成 → 存储架构 → 处理引擎 → 实时方案 → 质量治理 → 平台工程
快速参考：难度与推荐矩阵
相关专题
- 数据库深度专题 — 关系模型、事务、MVCC、分布式共识与存储引擎
- 后端架构专题 — 微服务、消息队列、缓存、网关与可观测性
- DevOps & SRE 专题 — CI/CD、容器编排、监控告警与混沌工程
- Python 专题 — Python 数据科学、异步编程与 FastAPI 实战