第1章：数据湖基础

1.1 数据湖到底是什么？

先聊定义。数据湖，说白了就是一个集中式的存储仓库。

它能存任何格式的数据——结构化、半结构化、非结构化，来者不拒。我习惯把它想象成一个巨大的数字水库：上游的溪流（业务系统）往里面灌水，下游的农田（数据分析、机器学习）从中取水。水库本身不关心水是清的还是浑的，它只负责存着。

这个想法最早是2010年由Pentaho的CTO James Dixon提出的。当时大家还在热衷于建数据仓库，把数据洗得干干净净再存起来。他觉得这种模式太死板，不如先存下来，需要的时候再处理。

嗯，这里要注意一个问题。很多人以为数据湖就是“把所有数据往HDFS上一扔”，这就犯了大忌。我在项目中遇到过这种情况：某团队拉了50TB日志进来，没做任何元数据管理，三个月后谁也不知道这些文件是干嘛的。最后变成了“数据沼泽”。

1.2 数据湖 vs 数据仓库

这两个概念经常被放在一起比较。你想想看，一个是仓库，一个是湖，本质逻辑完全不同。

维度	数据仓库	数据湖
数据格式	结构化，高度规范化	原始格式，任意结构
处理模式	Schema-on-Write	Schema-on-Read
数据质量	写入前清洗，质量高	原始数据，质量参差
用户类型	业务分析师、报表用户	数据科学家、数据工程师
存储成本	高，通常使用专有格式	低，对象存储为主
典型场景	BI报表、固定KPI	机器学习、探索性分析

我个人的经验是：不要试图让它们互相替代。数据仓库擅长处理“已知问题”——你知道要查什么数据，用什么维度分析。数据湖擅长处理“未知问题”——你可能不知道会从数据中发现什么。

但这里有个常见的坑。我曾经见过一个项目，团队决定把所有数据仓库的ETL流程直接搬到数据湖上。结果呢？性能一塌糊涂，查询延迟从秒级变成了分钟级。为什么？因为他们忽略了数据湖的查询引擎（比如Spark、Presto）和传统MPP数据库的底层差异。

1.3 数据湖架构的演变

数据湖的架构不是一成不变的。从2010年到现在，大致经历了三个阶段。

1.3.1 原始阶段：批处理数据湖

最早的数据湖其实就是“HDFS + MapReduce”。一天跑一次批量作业，把日志、交易数据拉进来。典型的Lambda架构——批处理层做全量计算，加速层做实时计算。

缺点很明显：数据时效性差，实时查询几乎不可能。我记得有一次业务方问“我要看过去5分钟的实时漏斗”，我只能尴尬地告诉他“明天早上看昨天的数据”。

1.3.2 进化阶段：实时数据湖

随着Spark Streaming、Flink的成熟，大家开始往湖里灌实时数据。Kafka -> 数据湖的管道成了标配。这时候出现了Kappa架构，试图用一套流处理引擎同时搞定批和流。

但新的问题来了：实时写入和批处理读取之间产生了冲突。小文件问题、文件锁问题、ACID事务问题，一个个冒出来。说白了，底层的对象存储（S3、HDFS）本来就不是为频繁Upsert设计的。

1.3.3 现代阶段：湖仓一体

这就是我们现在所处的时代。以Apache Iceberg、Delta Lake、Hudi为代表的开源技术，给数据湖加上了事务层。让数据湖拥有了数据仓库的特性——ACID、Time Travel、Schema Evolution。

我简单画了个架构演进图，你看一眼就能明白脉络。

1.4 常见的架构模式

实际生产环境里，我见过这几种变体：

1. 单湖模式：所有数据放一个湖，通过目录/命名空间隔离。适合中小团队。
2. 多湖模式：按业务域拆分，比如营销数据湖、风控数据湖。适合大型企业，治理边界清晰。
3. 混合模式：数据湖 + 数据仓库共存。数据湖存原始数据，数据仓库存清洗后的报表数据。

1.5 元数据为什么重要？

聊完数据湖本身，得说说元数据。你想想看，数据湖里躺着几千个数据集，如果没有元数据，谁能找到想要的数据？

但这里有个常见的误解。很多人以为元数据管理就是“建个Excel表格记录数据字典”，这远远不够。

真正的元数据管理至少包含三个层面：

• 技术元数据：表结构、分区信息、文件格式、数据大小
• 业务元数据：数据定义、业务含义、数据所有者
• 操作元数据：血缘关系、数据质量指标、访问频次

嗯，这个我们后面章节会详细展开。今天你只需要记住一句话：没有元数据的数据湖，最终一定会变成数据沼泽。

我个人习惯在数据湖搭建的第一天就部署元数据系统。Apache Atlas、Amundsen或者简单的Hive Metastore，至少得有一个。别想着“等数据多了再管”，那时候就晚了。我之前有个项目就是吃了这个亏——半年后花了两周时间反推血缘关系，痛苦至极。