1. 数据湖概念与演进：从数据仓库到数据湖的演变
1.1 为什么我们需要重新思考数据架构？
做数据架构十几年，我见过太多团队在数据存储上栽跟头。早期大家觉得数据仓库就是终点，后来发现不对——业务部门要的数据越来越「怪」，结构化表格满足不了，日志、图片、传感器数据全来了。
说白了，传统数据仓库是为「已知问题」设计的。你事先得把数据模型建好，ETL 流程定死，然后才能开始分析。但现实是，业务变化太快了。我曾在某电商公司经历过一次大促复盘，业务方突然要分析用户点击热力图的原始日志——数据仓库里根本没存，因为当初建模时没人想到这个需求。
这就是数据湖出现的根本原因：先存再说，用的时候再想怎么处理。
核心矛盾：数据仓库的「Schema-on-Write」模式（写入时定义结构） vs 数据湖的「Schema-on-Read」模式（读取时定义结构）。你选哪个，决定了你的数据架构长什么样。
1.2 从数据仓库到数据湖：一场必然的演变
我习惯把数据架构的演进分成三个阶段。每个阶段都有它的时代背景，也有它的局限性。
| 阶段 | 代表技术 | 核心特点 | 典型问题 |
|---|---|---|---|
| 第一阶段 | 传统数据仓库（Teradata、Oracle DW） | 结构化数据、强 Schema、ETL 预处理 | 扩展成本高、非结构化数据无法处理 |
| 第二阶段 | Hadoop 生态（HDFS、Hive、Spark） | 廉价存储、Schema-on-Read、支持任意格式 | 性能差、缺乏事务、数据沼泽 |
| 第三阶段 | Lakehouse（Delta Lake、Iceberg、Hudi） | 事务支持、ACID、SQL 分析、机器学习一体化 | 仍在演进中，生态碎片化 |
你想想看，第一阶段的数据仓库就像一座精装修的别墅——住进去很舒服，但想扩建一间房，得把整栋楼的结构改了。第二阶段的数据湖像一片荒地——你想怎么盖都行，但水电煤（事务、索引、一致性）全得自己拉。第三阶段的 Lakehouse，说白了就是在荒地上建了一个现代化社区——保留了土地的自由度，又提供了基础设施。
我的经验：2016 年我在一家金融科技公司主导数据平台迁移。当时我们选了 Hadoop 做数据湖，结果半年后数据质量一塌糊涂——重复数据、脏数据、半拉子作业到处都是。后来我才意识到，没有治理能力的数据湖，就是个「数据沼泽」。
1.3 数据湖的核心特征
聊到数据湖，很多人第一反应就是「存原始数据」。嗯，这没错，但太片面了。我个人认为，一个真正的数据湖应该具备以下五个核心特征：
- 统一存储：所有数据——结构化、半结构化、非结构化——放在同一个存储层。不需要为不同类型的数据搭建不同的系统。
- Schema-on-Read：数据写入时不强制定义结构，读取时再解析。这给了数据消费者极大的灵活性。
- 弹性扩展：存储和计算可以独立扩展。我见过一个场景：某 IoT 平台一天涌入 10TB 传感器数据，传统数仓根本扛不住，但数据湖可以轻松水平扩展。
- 低成本：通常基于廉价对象存储（如 S3、OSS、HDFS），存储成本是传统数仓的 1/10 甚至更低。
- 多模态分析：同一份数据，可以跑 SQL 做 BI 报表，也可以跑 PySpark 做机器学习，还可以直接丢给 AI 模型做训练。
注意：数据湖不是「垃圾桶」。我曾经见过一个团队，把所有日志、接口返回值、爬虫数据一股脑全丢进数据湖，没有任何目录规范、文件命名规则、元数据登记。结果三个月后，连他们自己都找不到数据在哪。这就是典型的「数据沼泽」——有数据，但没法用。
1.4 现代数据湖架构：Lakehouse 的诞生
为什么会有 Lakehouse？说白了，就是大家受够了数据湖的「三无」——无事务、无一致性、无性能。2019 年左右，Databricks 提出了 Lakehouse 的概念，核心思路是：在数据湖的廉价存储之上，加上数据仓库的事务能力和性能优化。
我参与过几个 Lakehouse 的落地项目，最直观的感受是：终于可以在数据湖上跑 ACID 事务了。以前用 Hive 做 ETL，跑着跑着作业挂了，留下一堆半成品数据，下游报表全乱套。有了 Lakehouse，至少能保证「要么全成功，要么全回滚」。
下面这张图是我自己总结的 Lakehouse 核心架构，你可以看到它如何把数据湖的「广」和数据仓库的「精」结合起来。
这张图里，最关键的其实是中间那层——表格式层。它就像数据湖的「操作系统」，在廉价存储上实现了数据仓库才有的能力。我举个例子：
- Delta Lake：Databricks 出品，事务日志基于 JSON，适合 Spark 生态。
- Apache Iceberg：Netflix 开源，表格式标准化的推动者，支持多种引擎。
- Apache Hudi：Uber 开源，擅长增量写入和 upsert 场景。
你可能会问：这三个怎么选？嗯，没有标准答案。我个人的建议是：如果你的团队 Spark 技术栈很重，Delta Lake 上手最快；如果你们有多引擎需求（Spark + Flink + Trino），Iceberg 更开放；如果你们有大量 CDC 和实时 upsert 场景，Hudi 值得一试。
1.5 Lakehouse 带来的关键能力
相比传统数据湖，Lakehouse 到底多了什么？我列个对比表，你一看就明白。
| 能力维度 | 传统数据湖 | Lakehouse |
|---|---|---|
| 事务支持 | 无，并发写入可能产生脏数据 | ACID 事务，支持并发读写 |
| 数据一致性 | 最终一致性，依赖外部协调 | 强一致性，内置快照隔离 |
| Schema 管理 | 无 Schema 或手动管理 | Schema 演进、版本控制、兼容性检查 |
| 查询性能 | 慢，依赖全表扫描 | 索引、分区裁剪、数据跳过（Data Skipping） |
| 数据版本 | 无版本概念 | 时间旅行（Time Travel），可回溯任意历史版本 |
| 流批一体 | 流批分离，两套系统 | 同一份数据，同时支持流和批处理 |
一句话总结：Lakehouse 不是推翻数据湖，而是给数据湖「装上引擎和刹车」。你仍然可以存任意格式的数据，但再也不用担心数据乱成一锅粥了。
1.6 落地 Lakehouse 的避坑指南
最后，分享几个我在项目中踩过的坑。希望能帮你少走弯路。
坑一：选型过早锁定生态。 我曾经在一个项目里选了 Delta Lake，结果后来业务方要用 Presto 做查询，发现兼容性有问题。建议先评估你的计算引擎生态，再选表格式。
坑二：忽视元数据治理。 Lakehouse 虽然解决了事务问题，但元数据管理仍然要靠自己。没有好的目录和血缘追踪，数据湖照样变沼泽。
我的建议：刚开始做 Lakehouse 时，不要追求「大而全」。选一个核心业务场景（比如实时报表或机器学习特征工程），先跑通一个端到端的 Pipeline。有了信心，再逐步扩展。