数据架构演进：从数据仓库到数据湖再到Lakehouse
做数据这行十几年了，我亲眼看着数据架构从「一个库装天下」演变成今天这副模样。说实话，每次架构变迁背后都是血泪教训——不是性能扛不住，就是业务骂数据不准。
今天咱们就聊聊这段演变史。你想想看，为什么会有数据仓库？为什么后来又冒出数据湖？最后为什么大家又折腾出Lakehouse？
数据仓库时代：结构化数据的「温室」
上世纪90年代，数据仓库火了。那时候大家的需求很单纯：把业务系统的数据抽过来，做报表、看指标。
数据仓库的核心思路是「先建模，再存数据」。你拿到业务需求，设计好星型模型或雪花模型，然后ETL清洗、转换、加载。数据进了仓库，结构清晰，查询快，报表工具直接连上去就能用。
数据仓库的典型特征：
- Schema-on-Write：写入时定义数据结构
- 只支持结构化数据（关系表）
- 存储成本高（通常用专用硬件）
- 查询性能好（预聚合、索引优化）
- 数据治理成熟（血缘、质量、安全）
我在2010年做过一个零售数据仓库项目。当时业务方提了200多个指标，我们花了3个月建模、设计ETL流程。上线后跑得挺顺，但半年后业务变了——要分析用户评论、要接入社交媒体数据。嗯，问题来了。
数据仓库对非结构化数据基本没辙。你总不能把一段用户评论塞进关系表里吧？就算硬塞进去，文本分析、情感计算这些活，传统SQL也干不了。
数据湖时代：把一切数据「扔」进去
2011年左右，Hadoop生态成熟了。大家发现：为什么不把所有原始数据先存起来？管它结构化、半结构化、非结构化，一股脑扔进HDFS再说。
数据湖的理念是「先存数据，用时再定义结构」。这就是Schema-on-Read——读取时才解析数据格式。
| 对比维度 | 数据仓库 | 数据湖 |
|---|---|---|
| 数据格式 | 结构化 | 结构化 + 半结构化 + 非结构化 |
| 写入模式 | Schema-on-Write | Schema-on-Read |
| 存储成本 | 高 | 低（廉价对象存储） |
| 数据质量 | 高（ETL清洗过） | 低（原始数据直接存） |
| 适用场景 | BI报表、固定指标 | 数据探索、机器学习 |
数据湖确实解决了数据仓库的痛点：存储便宜、格式灵活、能跑机器学习。但问题也随之而来。
数据湖的「沼泽化」陷阱：
- 没有事务支持：多任务同时写数据，读到的可能是脏数据
- 缺乏数据治理：数据湖最后变成「数据沼泽」，没人知道哪些数据能用
- 查询性能差：没有索引、没有统计信息，跑个聚合要扫全量数据
- ACID缺失：数据一致性无法保证，ETL失败后恢复困难
我记得有个客户，数据湖里存了200TB数据，但分析师只敢用其中20TB——因为剩下的数据没人维护，字段含义不明，质量参差不齐。说白了，数据湖变成了「数据坟场」。
为什么需要Lakehouse？
2017年左右，我开始思考一个问题：能不能把数据仓库的可靠性和数据湖的灵活性结合起来？
这就是Lakehouse的出发点。它不是一个新系统，而是一种架构模式——在廉价对象存储上，构建具备ACID事务、数据治理、高性能查询的数据平台。
Lakehouse的核心能力：
- 事务支持：多任务并发读写，保证数据一致性
- Schema治理：支持Schema演化，但不允许随意破坏结构
- BI级查询性能：通过缓存、索引、统计信息加速查询
- 开放存储格式：Parquet/ORC + 元数据层（如Delta Lake、Iceberg）
- 统一数据管理：一份数据，同时服务BI、数据科学、机器学习
你可能会问：这不就是数据仓库换个马甲吗？
还真不是。数据仓库用专用存储格式和计算引擎，Lakehouse用开放格式（Parquet）和通用计算引擎（Spark、Presto）。数据仓库的存储成本是Lakehouse的5-10倍，而且扩展性受限。
我用一张图来展示这三者的关系：
Lakehouse解决了什么实际问题？
我挑几个亲身踩过的坑来说。
第一个坑：数据一致性
以前做数据湖ETL，凌晨跑批任务，如果中间失败，数据就处于「半写半不写」的状态。下游报表看到的数据要么缺失、要么重复。Lakehouse的ACID事务保证：要么全部写入成功，要么全部回滚。这个特性，做数据的人应该都懂有多重要。
第二个坑：数据治理
数据湖里1000张表，没人知道哪些是生产表、哪些是测试表、哪些已经废弃。Lakehouse引入统一的元数据层，可以记录Schema、血缘、质量分数。我曾经帮一个客户梳理数据湖，发现40%的表已经半年没人碰过——有了治理能力，这些「僵尸表」就能被识别和清理。
第三个坑：查询性能
数据湖上跑SQL，扫全量Parquet文件，一个简单的count(*)可能要跑几分钟。Lakehouse通过统计信息、数据跳过（data skipping）、缓存加速，让查询性能接近数据仓库。我见过一个案例：同样的查询，数据湖跑45秒，Lakehouse优化后只要2秒。
我的建议：不要一上来就搞全量迁移。先选一个业务场景做试点——比如把数据仓库里最头疼的非结构化数据迁移到Lakehouse，验证ACID事务和查询性能。跑通了再逐步扩大范围。
Lakehouse的典型技术栈
目前主流的Lakehouse方案有三个方向：
| 方案 | 存储层 | 表格式 | 计算引擎 | 典型产品 |
|---|---|---|---|---|
| Delta Lake | S3/ADLS/GCS | Delta Lake | Spark、Presto、Flink | Databricks |
| Apache Iceberg | S3/ADLS/GCS | Iceberg | Spark、Flink、Trino | Snowflake、Dremio |
| Apache Hudi | S3/ADLS/GCS | Hudi | Spark、Flink | Uber开源方案 |
这三个方案的核心思路一致：在对象存储上增加一层元数据管理，提供ACID事务、时间旅行、Schema演化等能力。区别在于实现细节和生态兼容性。
我个人习惯用Delta Lake，因为它的事务日志设计得比较清晰，而且和Spark的集成最成熟。但如果你用Flink做实时处理，Iceberg的流式写入支持更好。选哪个，取决于你的技术栈。
小结
数据架构的演进，说白了就是不断在「灵活性」和「可靠性」之间找平衡。数据仓库太死板，数据湖太松散，Lakehouse正好卡在中间——既有数据湖的灵活存储，又有数据仓库的治理能力。
嗯，这一章先聊到这里。记住一句话：Lakehouse不是银弹，但它解决了数据湖时代最痛的几个问题。后面的章节，我会带你一步步搭建一个真正的Lakehouse平台。