1. 课程导学与 Lakehouse 前世今生：为什么需要实时入湖？
大家好，我是这次课程的主讲。做了十几年数据架构，从传统数仓到 Hadoop 再到 Flink，一路踩坑过来。今天咱们聊聊 Lakehouse 和实时入湖这件事。
先问个问题：你现在的数据架构，是不是还在用「T+1」跑批？每天凌晨等数仓跑完，第二天早上看报表。这在五年前还行，但现在业务要求「秒级响应」，这套模式就有点吃力了。
我去年帮一家电商公司做架构升级，他们的实时大屏延迟超过 5 分钟，运营总监直接拍桌子。后来我们用了 Flink + Lakehouse 的方案，延迟降到 3 秒以内。嗯，这就是咱们这门课要讲的核心。
1.1 从数据仓库到数据湖：为什么传统数仓不够用了？
数据仓库这个概念，最早是 Bill Inmon 在 90 年代提出的。它的核心思想是「ETL -> 建模 -> 报表」。数据经过清洗、转换，加载到关系型数据库中，形成星型或雪花型模型。
这套架构很成熟，但有个硬伤：数据必须先定义好 schema，才能入库。你想想看，业务部门今天要加个字段，明天要改个类型，数仓团队得排期、改模型、重新跑数据。一个需求下来，少则一周，多则一个月。
传统数仓的三大痛点：
- Schema 强约束：数据必须先建模，后存储。非结构化数据（日志、图片、JSON）基本没法直接存。
- 扩展性差：单机数据库撑死几十 TB，分布式数仓（如 Teradata）成本极高。
- 实时性不足：ETL 跑批通常是 T+1，无法支持秒级分析。
我记得 2016 年在一家金融公司，他们的数仓用的是 Oracle RAC，每天凌晨 3 点开始跑批，经常跑到早上 7 点还没跑完。业务方投诉说「你们的数据能不能快点？」我们只能苦笑——硬件瓶颈摆在那。
后来数据湖（Data Lake）的概念火了。它的思路很简单：先把数据存起来，需要的时候再处理。原始数据以文件形式（Parquet、ORC、Avro）存储在 HDFS 或对象存储上，schema 在读取时定义（Schema on Read）。
数据湖解决了「存得下」的问题，但带来了新麻烦：
- 数据沼泽：没有统一管理，数据质量堪忧。我见过一个数据湖里存了 2000 多个表，一半是重复的。
- 不支持 ACID 事务：多个任务同时写同一个目录，数据可能损坏。
- 查询性能差：直接扫描原始文件，比数仓慢一个数量级。
避坑指南：我曾经帮一家公司做数据湖迁移，他们直接把所有业务库的 binlog 丢到 HDFS 上，结果查询一个月的订单数据要跑 10 分钟。后来加了分区和索引，才勉强能接受。数据湖不是「垃圾桶」，该做的治理一样不能少。
1.2 Lakehouse 架构：融合数仓和数据湖的优点
Lakehouse 这个概念，最早由 Databricks 在 2020 年提出。它的核心思想是：在数据湖上实现数仓的能力。
说白了，就是既要数据湖的灵活性（存任意格式、低成本），又要数仓的可靠性（ACID 事务、高性能查询）。
Lakehouse 的关键技术栈包括：
| 能力 | 传统数仓 | 数据湖 | Lakehouse |
|---|---|---|---|
| 数据格式 | 结构化 | 结构化/半结构化/非结构化 | 全支持 |
| Schema 策略 | Schema on Write | Schema on Read | 两者结合 |
| ACID 事务 | 支持 | 不支持 | 支持（通过表格式） |
| 查询性能 | 高 | 低 | 高（通过索引/缓存） |
| 存储成本 | 高 | 低 | 低 |
| 实时写入 | 困难 | 可以 | 原生支持 |
Lakehouse 的底层依赖三个核心组件：
- 开放表格式：Apache Iceberg、Delta Lake、Apache Hudi。它们给文件目录加了一层「元数据层」，支持事务、版本回滚、时间旅行。
- 高性能查询引擎：Spark、Presto/Trino、Flink。Flink 在实时入湖方面有天然优势。
- 对象存储：S3、OSS、HDFS。低成本、高扩展。
我的建议：如果你从零开始选型，优先考虑 Apache Iceberg。它的设计最干净，社区活跃度也高。Delta Lake 跟 Spark 绑定太紧，Hudi 的 Merge on Read 性能有点坑。当然，这只是我个人经验，具体选型要看你的技术栈。
1.3 为什么需要实时入湖？
你可能会问：离线入湖不行吗？每天跑一次 Spark 作业，把数据从 Kafka 写到 Iceberg 表里，不也挺好？
嗯，这里要注意。离线入湖有几个硬伤：
- 延迟高：T+1 的延迟，对于实时监控、风控、推荐等场景完全不可接受。
- 数据一致性差：如果凌晨跑批失败，当天的数据就丢了。你得手动补数据。
- 资源浪费：每天集中跑一次，集群资源被撑满，其他任务得排队。
实时入湖的核心价值在于：数据从产生到可用，延迟控制在秒级。Flink 消费 Kafka 消息，实时写入 Iceberg 表，下游的查询引擎（如 Trino）立刻就能读到最新数据。
我去年做的一个项目，需要实时分析用户点击行为。数据链路是：
App 埋点 -> Kafka -> Flink（清洗+聚合）-> Iceberg（OSS）-> Trino（查询）-> 大屏
整个链路延迟不到 5 秒。运营同学可以实时看到每个活动的点击率，及时调整策略。这在以前用离线数仓根本做不到。
1.4 课程知识体系总览
这门课一共 30 章，我把它分成四个模块：
- 基础篇（第 1-5 章）：Lakehouse 原理、Flink 基础、Iceberg 核心概念。适合刚接触实时入湖的同学。
- 实战篇（第 6-18 章）：从零搭建实时入湖 pipeline。包括环境搭建、CDC 接入、数据清洗、写入优化、监控告警。
- 进阶篇（第 19-25 章）：性能调优、数据治理、多表关联、Exactly-Once 语义。这部分是我踩坑最多的。
- 案例篇（第 26-30 章）：电商实时数仓、金融风控、IoT 设备数据入湖。每个案例都来自真实项目。
下面这张图展示了 Lakehouse 实时入湖的整体架构：
1.5 学完这门课，你能得到什么？
这门课不是纯理论，也不是简单的「Hello World」。我的目标是：
- 掌握 Lakehouse 核心原理：Iceberg 的表格式、分区策略、快照机制。你不仅能写代码，还能解释为什么这么设计。
- 独立搭建实时入湖 pipeline：从 Kafka 到 Iceberg，包括 CDC 接入、数据清洗、写入优化。我会给出完整的 Flink SQL 和 DataStream 代码。
- 学会性能调优：写入吞吐、文件合并、小文件治理。这些是生产环境最头疼的问题。
- 理解数据治理：Schema 演进、数据质量监控、权限管理。Lakehouse 不是「写完就完事」，运维同样重要。
适合人群：
- 数据工程师：想从离线数仓转向实时架构
- 大数据架构师：正在做技术选型，评估 Lakehouse 方案
- Flink 开发者：想拓展实时入湖这个方向
- 技术负责人：需要了解实时入湖的落地成本和收益