1、数据湖的起源：从数据仓库到数据湖的演进，为什么需要数据湖？
1.1 数据仓库时代：那个“什么都得先想好”的年代
聊数据湖之前，得先说说数据仓库。我入行那会儿，数据仓库还是的主流。那时候做数仓，有个铁律叫“Schema-on-Write”——写数据之前，必须先定义好表结构。
说白了，就是数据还没进来，你就得想清楚：这个字段是字符串还是整数？长度多少？要不要建索引？
听起来挺合理对吧？但实际项目里，这玩意儿能把人逼疯。
我经历过的一个典型场景：
业务部门突然说：“我们想分析一下用户点击日志里的某个新字段。” 结果呢？数仓团队得先改ETL、改表结构、重新建模、测试、上线……一套流程走下来，少说两周。业务等不了，自己拿Excel去分析了。
数据仓库的优势很明显——数据质量高、查询性能好、治理规范。但它的短板同样致命：灵活性太差，成本太高。
你想想看，存储结构化数据用Oracle、Teradata，一TB的存储授权费能买一辆车。而且，非结构化数据（日志、图片、音视频）基本进不来，或者进来了也处理不了。
1.2 数据湖的诞生：先存了再说
大概2010年左右，Hadoop生态开始成熟。这时候有人提出了一个新思路：为什么非要先定义结构？先把数据存起来不行吗？
这就是数据湖的核心思想——Schema-on-Read。读数据的时候再定义结构，写的时候只管往里扔。
我记得第一次接触这个概念时，心里还犯嘀咕：“这不就是‘先上车后补票’吗？” 但实际用下来，真香。
数据湖的原始定义（James Dixon, 2010）：
“数据湖是一种以原始格式存储数据的大型存储库，不需要预先定义结构。” 说白了，就是你把所有数据一股脑倒进去，需要的时候再想办法处理。
1.3 为什么需要数据湖？四个字：降本增效
我总结了一下，数据湖之所以能火，核心原因就四个：
- 存储成本断崖式下降：HDFS、S3、OSS这些对象存储，价格是传统数仓的十分之一甚至更低。我2015年帮一家电商公司做架构，把冷数据从Oracle迁移到HDFS，存储成本直接降了80%。
- 数据类型不再受限：结构化、半结构化（JSON、XML）、非结构化（图片、视频、日志）——统统往里扔。以前数仓里处理不了的日志文件，现在直接丢进数据湖。
- 数据保留周期变长：以前数仓只保留最近3个月的数据，因为太贵。数据湖可以保留全量历史数据，想做回溯分析？随时可以。
- 分析工具更灵活：Spark、Presto、Flink……各种引擎都能直接读数据湖里的数据，不用再经过复杂的ETL。
| 对比维度 | 数据仓库 | 数据湖 |
|---|---|---|
| 数据写入方式 | Schema-on-Write（先定义后写入） | Schema-on-Read（先写入后定义） |
| 支持数据类型 | 结构化数据为主 | 结构化 + 半结构化 + 非结构化 |
| 存储成本 | 高（专用硬件 + 商业授权） | 低（通用硬件 + 开源软件） |
| 数据质量 | 高（ETL清洗后入库） | 低（原始数据直接存储） |
| 典型场景 | BI报表、固定维度分析 | 数据探索、机器学习、日志分析 |
1.4 数据湖的演进路线图
下面这张图，是我自己画的数据湖演进路线。从传统数仓到数据湖，再到后来的Lakehouse，每一步都有它的历史背景。
1.5 数据湖的“坑”：我踩过的那些雷
数据湖不是银弹。我见过太多团队，把数据湖搞成了“数据沼泽”。
我曾经踩过的坑：
- 没有元数据管理：数据往里一扔，没人记录这个数据是谁的、什么格式、怎么来的。三个月后，谁也看不懂这些文件是什么。
- 没有权限控制：所有人都能读写数据湖，结果有人误删了分区，恢复花了两天。
- 没有数据质量校验：脏数据进了湖，下游分析全错。我记得有一次，某个字段因为编码问题，所有中文都变成了乱码，报表直接崩了。
所以，数据湖虽然解决了“存”的问题，但“管”的问题更突出了。这也是为什么后来出现了Lakehouse——它试图在数据湖的灵活性和数据仓库的治理能力之间找到平衡。
1.6 小结：数据湖到底解决了什么？
一句话总结：数据湖让企业能以极低的成本，存储和分析任意类型的数据。
它打破了数据仓库的“结构牢笼”，让数据科学家、分析师可以更自由地探索数据。但代价是——治理难度增加了，数据质量下降了。
嗯，这就是数据湖的“原罪”。后面的章节，我们会详细聊Lakehouse是怎么解决这些问题的。