1. 课程导入：湖仓一体与CDC实时入湖的背景、价值、学习目标与整体框架
1.1 数据架构演进：从数据仓库到湖仓一体
过去十年间，企业数据处理架构经历了从传统数据仓库向数据湖、再向湖仓一体演进的清晰路径。传统数据仓库以结构化数据为核心，依赖ETL流程将数据加工后存储，虽然保证了数据质量和查询性能，但面对日益增长的半结构化、非结构化数据（如日志、JSON、图片元数据、IoT信号）时显得力不从心。数据湖以低成本存储海量原始数据为优势，却往往陷入“数据沼泽”——缺乏事务保障、数据质量难以治理、BI查询性能不佳。
湖仓一体（Lakehouse）架构应运而生，它融合了数据仓库的事务性、数据治理、查询性能与数据湖的开放性、低成本、多模态存储能力。在湖仓一体中，数据以开放格式（如Parquet、ORC、Delta Lake）存储在对象存储或分布式文件系统上，通过元数据层（如Hive Metastore、Iceberg Catalog）提供表结构定义和ACID事务能力，上层引擎（Spark、Flink、Presto）统一进行批流处理与交互式查询。
1.2 CDC实时入湖：为什么需要“实时”
传统批量入湖通常采用T+1调度，即每日凌晨将前一天的业务增量数据导入数据湖。这种模式在报表分析场景中尚可接受，但面对实时风控、实时推荐、异常检测、大屏监控等场景时，T+1的数据延迟直接导致业务决策滞后。例如，电商大促期间，运营团队需要实时监控订单量、库存水位和支付成功率，若数据延迟数小时，异常无法及时暴露，损失不可估量。
CDC（Change Data Capture，变更数据捕获）技术通过解析数据库事务日志（如MySQL的binlog、PostgreSQL的WAL、Oracle的Redo Log），实时捕获插入、更新、删除操作，并将变更记录以流式方式传递给下游。CDC实时入湖的本质是：将数据库的每一次变更在秒级内同步到湖仓一体存储中，使数据湖中的数据与业务库保持近乎一致的状态。
1.3 典型业务场景与价值体现
| 场景 | 传统T+1痛点 | CDC实时入湖价值 |
|---|---|---|
| 金融实时风控 | 欺诈交易无法及时拦截 | 毫秒级捕获交易流水，实时规则引擎联动 |
| 电商大促监控 | 库存超卖发现滞后 | 订单/库存变更秒级入湖，实时大屏预警 |
| 用户行为分析 | 用户画像更新延迟 | 行为日志+业务数据实时关联，动态画像 |
| IoT设备监测 | 设备状态异常无法感知 | 传感器数据流式入湖，阈值实时触发告警 |
1.4 实时入湖链路的核心挑战
构建一条健壮的CDC实时入湖链路并非易事，实践中常遇到以下挑战：
- 断点续传与一致性：CDC工具崩溃后如何从上次位点继续，不丢数据不重复。
- Schema变更同步：业务表增加字段、修改类型时，如何自动演进湖上表结构。
- 延迟与吞吐权衡：小批量高频写入保证低延迟，但会增加小文件数量，影响查询性能。
- 数据格式兼容：CDC产生的变更流如何映射为Delta Lake/Iceberg的ACID事务操作。
- 全量+增量衔接：首次入湖需要全量快照，后续切换增量，衔接处不能丢数据或重复。
1.5 课程学习目标与整体框架
本课程共30章，围绕“设计一条生产可用的CDC实时入湖链路”这一核心目标，从原理、工具、架构、实战、调优五个维度展开。完成本课程后，你将能够：
- 理解CDC核心技术原理：掌握binlog/WAL解析机制、Flink CDC与Debezium的底层实现差异。
- 设计湖仓一体入湖架构：根据业务延迟要求、数据量级、一致性需求，选择合理的链路拓扑。
- 熟练使用主流工具链：独立配置Flink CDC、Canal、Maxwell等工具，并接入Iceberg/Delta Lake。
- 解决生产级问题：处理Schema变更、小文件治理、数据回溯、性能调优等真实场景问题。
课程整体框架分为四大模块：基础篇（第1-8章）讲解湖仓一体与CDC基础概念；工具篇（第9-16章）深入Flink CDC、Canal、Debezium等工具实战；架构篇（第17-24章）聚焦链路设计、一致性保障、性能优化；实战篇（第25-30章）通过电商、金融等完整案例串联全部知识点。