1. 数据架构演进：从数据仓库到数据湖再到Lakehouse
聊数据架构，绕不开一个核心问题：数据到底该放哪儿？怎么管？怎么用？
我入行那会儿，企业数据基本都窝在数据仓库里。后来大数据来了，数据湖火了。再后来，大家发现两头都不太够用——于是Lakehouse出现了。
这一节，咱们就捋一捋这条演进路线。我会结合自己踩过的坑，把每个阶段的痛点、驱动力和关键变化讲清楚。
一句话总结：数据仓库解决“怎么管好数据”，数据湖解决“怎么装下所有数据”，Lakehouse解决“怎么既装得下又管得好”。
1.1 数据仓库时代：结构化世界的黄金法则
上世纪80年代末，数据仓库概念被提出。说白了，就是把业务系统的数据抽出来，清洗、转换、加载（ETL），然后放进一个专门的分析数据库里。
核心特征：
- Schema-on-Write：写入前必须定义好表结构
- ACID事务：保证数据一致性
- SQL接口：BI工具直接对接
- 高性能查询：列式存储、索引、物化视图
我在2012年做过一个零售行业的数仓项目。当时用的是Teradata，每天凌晨跑ETL，早上8点出报表。业务方很满意——直到他们想分析点击流日志和社交媒体数据。
我曾经踩过的坑：数仓对非结构化数据几乎无能为力。有一次业务要分析用户评论里的情感倾向，我们只能先把文本硬塞进VARCHAR字段，然后写一堆正则表达式去解析。效率极低，维护成本极高。
数据仓库的局限性：
- 存储成本高（通常用专有硬件）
- 扩展性差（垂直扩展为主）
- 不支持非结构化数据（文本、图片、音频）
- 数据加载频率低（通常是T+1）
1.2 数据湖时代：野蛮生长的数据沼泽
2010年前后，Hadoop生态成熟了。HDFS能存海量数据，MapReduce能跑批处理。数据湖的概念应运而生——把所有原始数据原样存进去，需要的时候再处理。
核心特征：
- Schema-on-Read：读取时才解析结构
- 低成本存储：普通服务器+分布式文件系统
- 支持所有数据类型：结构化、半结构化、非结构化
- 灵活的计算引擎：Spark、Hive、Presto
我记得2015年帮一家互联网公司搭数据湖。他们把服务器日志、App埋点、第三方API数据一股脑全扔进HDFS。存储成本确实低，但问题很快就来了。
数据湖的真相：很多数据湖最后变成了“数据沼泽”。数据进来了，但没人知道哪些数据是干净的、哪些是过期的、哪些是重复的。你想想看，一个100PB的湖里，如果50%是垃圾数据，那维护成本反而比数仓还高。
数据湖的痛点：
- 缺乏ACID事务：并发写入会导致数据不一致
- 元数据管理混乱：没有统一的Schema约束
- 查询性能差：没有索引和统计信息优化
- 数据质量难保证：脏数据、重复数据泛滥
我见过最夸张的一个案例：某团队在数据湖里跑了3天的ETL，结果发现源数据字段类型变了，整个管道全挂。因为没有Schema校验，错误直到下游报表出问题才被发现。
1.3 Lakehouse：融合的必然选择
2017年，Databricks提出了Lakehouse概念。本质上，它是在数据湖的底层存储上，叠加了数据仓库的治理能力。
核心思想：
- 用低成本对象存储（S3、ADLS、OSS）做统一存储
- 用开放文件格式（Parquet、ORC）做列式存储
- 用事务层（Delta Lake、Iceberg、Hudi）提供ACID保证
- 用元数据层（Unity Catalog、Hive Metastore）做统一治理
关键区别：Lakehouse不是“数据湖+数据仓库”的简单拼凑，而是从存储层开始重新设计。它保留了数据湖的低成本、高扩展性，同时实现了数据仓库的可靠性、事务性和高性能。
为什么是现在？核心驱动力：
| 驱动力 | 说明 |
|---|---|
| 存储成本断崖式下降 | 对象存储价格从2010年的$0.10/GB降到现在的$0.02/GB |
| 开放格式成熟 | Parquet/ORC + Delta/Iceberg/Hudi形成事实标准 |
| 计算与存储分离 | 云原生架构让弹性伸缩成为可能 |
| AI/ML需求爆发 | 数据科学家需要直接访问原始数据做特征工程 |
| 实时分析需求 | 批流一体架构成为刚需 |
我个人习惯把Lakehouse比作“精装修的数据湖”。湖还是那个湖，但有了物业管理（元数据）、水电煤（事务）、安保系统（权限控制）。
1.4 三种架构对比：一张表说清楚
| 维度 | 数据仓库 | 数据湖 | Lakehouse |
|---|---|---|---|
| 数据形态 | 结构化为主 | 所有类型 | 所有类型 |
| Schema策略 | Write时定义 | Read时定义 | Write时定义+Read时演化 |
| ACID事务 | 完整支持 | 不支持 | 完整支持 |
| 存储成本 | 高 | 低 | 低 |
| 查询性能 | 高（索引+物化视图） | 低（全表扫描） | 高（索引+缓存+优化器） |
| 数据治理 | 强 | 弱 | 强 |
| AI/ML支持 | 弱 | 强 | 强 |
| 实时能力 | 弱（T+1为主） | 中（流处理） | 强（批流一体） |
1.5 核心架构图：Lakehouse的逻辑分层
下面这张图是我自己总结的Lakehouse分层架构。你仔细看，每一层都有明确的职责边界。
嗯，这里要注意：每一层之间都是松耦合的。你可以单独升级计算引擎，也可以替换事务层实现。这就是Lakehouse的灵活性所在。
1.6 我的建议：什么时候该考虑Lakehouse？
根据我这些年的项目经验，如果你遇到以下场景，Lakehouse值得认真考虑：
- 数据种类多：既有结构化报表数据，又有日志、图片、文本等非结构化数据
- 分析场景混合：既要跑BI报表，又要做机器学习训练
- 实时性要求高：需要分钟级甚至秒级的数据可见性
- 成本敏感：不想在存储和计算上被厂商锁定
- 团队规模大：需要统一的数据治理和权限管理
一个小建议：不要为了Lakehouse而Lakehouse。如果你的数据量小于10TB，场景以固定报表为主，传统数仓可能更省心。Lakehouse的优势在大规模、多场景、高灵活性的场景下才能真正体现。
1.7 本章小结
从数据仓库到数据湖再到Lakehouse，本质上是数据架构对业务需求的一次次回应。
- 数据仓库解决了“数据怎么管”的问题，但太贵、太死板
- 数据湖解决了“数据怎么存”的问题，但太乱、太难用
- Lakehouse试图同时解决这两个问题——用数据湖的成本，实现数据仓库的治理
我个人觉得，Lakehouse不是终点，而是数据架构走向“统一、开放、智能”的一个里程碑。后面几章，我们会深入每个技术细节，看看Delta Lake、Iceberg、Hudi这些组件到底是怎么工作的。