数据架构演进：从数据仓库到数据湖再到 Lakehouse

聊数据架构，绕不开一个核心问题：我们到底想把数据放在哪，怎么管，怎么用？

过去二十年，这个问题的答案变了三次。从数据仓库到数据湖，再到现在的 Lakehouse。我亲身经历了这三次变迁，踩过不少坑，也看到过很多团队在选型上反复折腾。今天咱们就把这条演进路线捋清楚。

1. 数据仓库时代：一切为了报表

上世纪 90 年代到 2010 年左右，数据仓库是的主流。那时候企业的数据量还没那么夸张，主要需求就是做 BI 报表、出经营分析。

数据仓库的核心特征：

• Schema-on-Write：数据写入前必须先定义好表结构（ETL 清洗、转换、加载）。
• 强一致性：ACID 事务保证，数据质量极高。
• 面向分析：用星型模型、雪花模型组织数据，专门服务 OLAP 查询。

我记得 2012 年在一家金融公司做数仓项目，每天凌晨跑批处理，几百张事实表、几十个维度表，调度链写得密密麻麻。那时候最怕的就是跑挂了——重跑一次要等四五个小时。

但数据仓库的短板也很明显：

• 存储成本高，扩展困难（纵向扩展为主）。
• 只能处理结构化数据，半结构化、非结构化数据基本没辙。
• 数据加载慢，实时性差，T+1 是常态。

说白了，数据仓库是个「精装修的别墅」——住着舒服，但盖起来贵，改起来难。

2. 数据湖时代：先存了再说

2011 年左右，Hadoop 生态开始爆发。大家发现，与其费劲巴拉地先建模再存数据，不如先把原始数据扔进去，需要的时候再处理。这就是数据湖的核心理念——Schema-on-Read。

数据湖的核心特征：

• 存储廉价：基于 HDFS/S3 等对象存储，成本极低。
• 格式灵活：支持结构化、半结构化、非结构化数据（JSON、Parquet、Avro、图片、日志等）。
• 计算与存储分离：Spark、Presto、Hive 等引擎可以共享同一份数据。

我曾经在一个互联网公司看到，数据湖里存了上千 TB 的日志，但 80% 的数据从来没人查过。数据湖变成了「数据沼泽」——数据还在，但没人知道怎么用。

数据湖的主要痛点：

• 缺乏事务支持：并发写入容易产生脏数据。
• 数据质量难保证：没有 Schema 约束，坏数据、重复数据泛滥。
• 查询性能差：直接查原始文件，没有索引和统计信息，慢得让人抓狂。
• 不支持 ACID：做增量更新、删除操作非常麻烦。

你想想看，数据仓库太贵太死板，数据湖太乱太慢。那有没有一种架构，能结合两者的优点？

3. Lakehouse 时代：鱼与熊掌兼得

2017 年以后，Databricks 提出了 Lakehouse 的概念。说白了，就是在数据湖的廉价存储上，加上数据仓库的 ACID 事务、Schema 约束、索引优化等能力。

Lakehouse 的核心特征：

• ACID 事务：支持并发读写、快照隔离、回滚。
• Schema 管理：支持 Schema 演进（增加/删除字段），保证数据质量。
• 高性能查询：通过文件索引、统计信息、缓存加速。
• 开放格式：基于 Parquet/ORC 等开放存储格式，避免厂商锁定。
• 流批一体：同一份数据，既支持批处理也支持流处理。

我去年帮一家电商公司做架构升级，他们原来用 Hive + HDFS 做离线数仓，Kafka + Flink 做实时链路，两套系统数据不一致，运维成本极高。迁移到 Iceberg + Spark + Flink 的 Lakehouse 架构后，实时和离线共用同一份数据，终于不用再「对账对到天亮」了。

4. 核心驱动力：为什么非变不可？

架构演进不是技术人员的自嗨，背后有实实在在的业务驱动力。我总结为以下四点：

驱动力	说明	我的观察
数据量爆炸	从 TB 级到 PB 级，传统数仓存不下、扩不起。	我见过一个客户，单日日志量 50TB，Oracle 数仓直接崩了。
实时性要求	从 T+1 到秒级响应，批处理模式跟不上业务节奏。	实时风控、实时推荐、实时大屏，都是刚需。
数据类型多样化	结构化 + 半结构化 + 非结构化，数仓搞不定。	日志、埋点、图片、文本，全都要分析。
降本增效	对象存储比 SAN/NAS 便宜 10 倍以上。	用 S3 替代 EMC，存储成本直接砍掉 80%。

5. 一张图看懂演进脉络

下面这张图是我自己画的，把三者的核心差异和演进关系说清楚了。

6. 我的选择建议

如果你现在要做一个新的数据平台，我的建议是：

• 数据量 < 10TB，以结构化数据为主，实时性要求不高 → 传统数仓（如 ClickHouse、Doris）仍然够用。
• 数据量大、类型杂、需要探索性分析 → 数据湖 + 查询引擎（Trino/Spark）可以先用起来。
• 既要低成本存储，又要 ACID 事务，还要流批一体 → 直接上 Lakehouse 架构，别走弯路了。