2. 数据湖基础概念
大家好，我是你们的老朋友。今天咱们聊聊数据湖的基础概念。说实话，这个领域我摸爬滚打了七八年，踩过的坑比走过的路还多。但正是这些经历，让我对数据湖的理解越来越深。
数据湖这个概念，最早是2010年左右由Pentaho的CTO提出的。当时大家还在玩命建数据仓库，突然有人说「咱们把所有原始数据都存起来，以后再说怎么用」。嗯，这个想法在当时挺前卫的。
数据湖的定义与演进
数据湖是什么？说白了就是一个集中存储库，能存任何格式的数据——结构化、半结构化、非结构化，来者不拒。你想想看，传统数据库只能存表格，数据仓库也只能存结构化数据，但数据湖不一样，它像一个大水池，什么数据都能往里倒。
核心定义：数据湖是一种以原始格式存储大量数据的系统，采用扁平化架构和对象存储，支持批处理、实时处理、机器学习等多种计算模式。
数据湖的演进经历了三个阶段：
- 1.0 时代（2010-2015）： Hadoop HDFS 一统天下。我记得当时公司搭了个 Hadoop 集群，每天往里面灌日志，查询全靠 MapReduce，跑个任务要等半小时。
- 2.0 时代（2015-2020）： 云对象存储兴起。AWS S3、Azure Blob 成为主流，Spark 取代了 MapReduce。这时候数据湖开始真正好用起来。
- 3.0 时代（2020-至今）： 实时数据湖。Delta Lake、Apache Iceberg、Apache Hudi 这些技术冒出来了，支持 ACID 事务、时间旅行、增量查询。实时写入不再是梦。
个人经验：我在2018年帮一家电商公司迁移数据湖，从 HDFS 搬到 S3。当时最大的坑是 HDFS 的目录结构思维——大家习惯按「/year/month/day」建目录，但对象存储的扁平化架构根本不需要这样。后来我们改用分区表 + 分区裁剪，查询性能提升了3倍。
数据湖与数据仓库的区别
很多新手问我：「数据湖和数据仓库到底有啥区别？」我一般这么回答：数据仓库是精装修的房子，拎包入住但改格局很麻烦；数据湖是毛坯房，啥都能干但得自己装修。
来看个对比表：
| 维度 | 数据仓库 | 数据湖 |
|---|---|---|
| 数据格式 | 结构化，Schema-on-Write | 所有格式，Schema-on-Read |
| 存储成本 | 高（需要预处理和索引） | 低（对象存储，按量付费） |
| 数据质量 | 高（ETL清洗后入库） | 低（原始数据直接存） |
| 使用场景 | BI报表、固定分析 | 数据探索、机器学习、实时分析 |
| 变更成本 | 高（需要重建ETL） | 低（Schema-on-Read灵活） |
| ACID事务 | 原生支持 | 需要额外组件（Delta Lake等） |
为什么会这样？核心在于设计哲学不同。数据仓库是「先想清楚再用」，数据湖是「先用再想清楚」。我见过太多团队把数据湖当数据仓库用，结果ETL写了一堆，性能还上不去。记住：数据湖的优势在于灵活性，别用数据仓库的思维去管它。
避坑指南：我曾经帮一个金融客户做数据湖，他们坚持要把所有数据都清洗干净再入库。结果数据延迟从分钟级变成了小时级，实时场景完全没法用。后来我们改成「原始数据入湖 + 按需清洗」，延迟降到秒级。记住：数据湖的核心价值是「存原始数据」，别过早做Schema。
实时数据湖的架构特点
实时数据湖，说白了就是让数据湖能处理实时数据。传统数据湖只能做批处理，数据延迟至少几小时。但现在的业务场景要求秒级甚至毫秒级响应——比如风控、推荐、实时大屏。
这就引出了两种经典架构：Lambda 和 Kappa。
Lambda 架构
Lambda 架构是 Nathan Marz 提出的，核心思想是「批处理 + 流处理」两条腿走路。批处理层保证数据准确性，流处理层保证低延迟。最后通过服务层合并结果。
我画了张图，你看一眼就明白了：
Lambda 架构的优点很明显：批处理结果准确，流处理结果实时。但缺点也很致命——维护两套代码，逻辑容易不一致。我在项目中遇到过好几次，批处理和流处理的聚合逻辑对不上，排查起来特别痛苦。
Kappa 架构
Kappa 架构是 Jay Kreps 提出的，核心思想是「只用流处理」。所有数据都走流处理管道，需要重算时直接回放历史数据。说白了，就是把批处理当成流处理的特殊情况。
为什么能这么做？因为消息队列（如 Kafka）可以保存历史数据。需要全量计算时，从最早的消息开始重新消费就行。
Kappa 架构的优点：一套代码，逻辑一致，运维简单。但缺点也很明显——对消息队列的存储能力要求高，而且某些场景下流处理的状态管理比批处理复杂得多。
我的建议：如果你从零开始搭建实时数据湖，我建议优先考虑 Kappa 架构。原因很简单——维护两套代码的代价太大了。我见过一个团队，Lambda 架构跑了两年，批处理和流处理的结果对不上，最后花了三个月重构。但如果你有历史包袱（比如已有的批处理系统），Lambda 架构也是合理的选择。
两种架构的对比
| 维度 | Lambda 架构 | Kappa 架构 |
|---|---|---|
| 代码维护 | 两套代码（批+流） | 一套代码（流） |
| 数据准确性 | 高（批处理保证） | 中（依赖流处理状态管理） |
| 延迟 | 流处理低延迟，批处理高延迟 | 统一低延迟 |
| 运维复杂度 | 高（两套系统） | 低（一套系统） |
| 历史重算 | 批处理层直接重算 | 回放消息队列 |
| 适用场景 | 对准确性要求极高的场景 | 追求开发效率和实时性的场景 |
嗯，这里要注意：没有银弹。Lambda 和 Kappa 各有适用场景。我个人习惯是：如果业务对数据一致性要求极高（比如金融交易），我会选 Lambda；如果追求快速迭代和实时性（比如推荐系统），我会选 Kappa。
避坑指南：我曾经在一个物联网项目中选了 Kappa 架构，结果消息队列的存储容量不够，历史数据只能保留7天。后来需要重算一个月的数据，发现数据已经丢了。最后我们加了分层存储——热数据在 Kafka，冷数据在 S3，需要重算时从 S3 回灌。记住：选 Kappa 架构前，先算好你的消息队列能存多久数据。
实时数据湖的核心能力
不管选哪种架构，实时数据湖都需要具备几个核心能力：
- 增量读取： 只读取变更的数据，而不是全量扫描。CDC（Change Data Capture）就是干这个的。
- ACID 事务： 保证并发写入时数据一致性。Delta Lake 和 Iceberg 都支持。
- 时间旅行： 能查询任意时间点的数据快照。对数据回溯和审计特别有用。
- Schema 演化： 支持字段增删改，不影响已有数据。我见过太多因为加字段导致全量重跑的血泪史。
- 流批一体： 同一套 API 处理批和流。Spark Structured Streaming 和 Flink 都支持。
这些能力，说白了就是让数据湖既能存又能算，既能批又能流。后面的章节我们会逐一深入讲解，特别是 CDC 如何与这些能力结合。