一、湖仓一体架构概述：数据湖与数据仓库的演进

1.1 从数据仓库到数据湖：我踩过的那些坑

先聊聊数据仓库。十年前我刚入行时，数据仓库几乎是企业做报表的唯一选择。ETL 清洗、建模、分层，一套流程走下来，数据质量确实高。但有个问题——太贵了。

我记得第一次做大项目，光 Oracle 的 license 就花了几百万。而且数据仓库对非结构化数据基本没辙。日志文件、图片、传感器数据？对不起，存不进去。就算硬塞进去，查询性能也惨不忍睹。

后来 Hadoop 生态起来了，数据湖的概念开始流行。说白了，数据湖就是「先把数据扔进去再说」。原始格式、不强制 schema、低成本存储。听起来很美好对吧？

但我在项目中遇到过另一个极端：数据湖变成了数据沼泽。数据是存进去了，但没人知道哪些数据是干净的、哪些是垃圾。想跑个报表？得先花两周搞清楚数据血缘。想用 SQL 查？抱歉，数据湖原生不支持 ACID 事务。

1.2 湖仓一体：为什么是必然选择

湖仓一体（Lakehouse）这个概念，其实是被逼出来的。我个人的理解是：它试图把数据湖的廉价存储和数据仓库的 ACID 特性结合起来。

你想想看，一个理想的架构应该是什么样的？

• 能存结构化数据，也能存半结构化和非结构化数据
• 支持 ACID 事务，保证读写一致性
• 能用 SQL 直接查询，不需要额外搬数据
• 支持机器学习、流处理等多种工作负载

这就是湖仓一体的核心承诺。它不是在数据湖上盖个数据仓库，而是从底层重新设计存储和计算引擎。

1.3 湖仓一体的技术基石

要实现湖仓一体，底层需要几个关键组件。我列个表，方便你对比：

组件	作用	代表技术
开放存储格式	支持 ACID、时间旅行、schema 演进	Apache Iceberg、Delta Lake、Apache Hudi
统一元数据层	让不同引擎共享表结构	Hive Metastore、AWS Glue
高性能查询引擎	直接查询数据湖中的表	Spark SQL、Presto/Trino、StarRocks
弹性计算层	按需扩缩容，存储计算分离	Kubernetes、YARN

嗯，这里要注意：开放存储格式是湖仓一体的灵魂。没有它，你只是在数据湖上跑 SQL，本质上还是两套系统。

1.4 Lambda 架构与 Kappa 架构：流批之争

聊完存储，咱们说说计算架构。Lambda 和 Kappa 是两种经典的数据处理模式。我最早接触 Lambda 架构时觉得它很合理——批处理保证准确性，流处理保证低延迟。但实际用起来，问题不少。

Kappa 架构的思路就简单多了：只用流处理，所有数据都走实时管道。需要重算历史数据？重新回放一遍就行。

我画个对比图，你一看就明白：

1.5 两种架构的选型建议

说实话，没有银弹。我个人的经验是：

• 选 Lambda：你的业务对历史数据重算要求极高，且流处理框架还不成熟。比如金融风控场景，批处理跑 T+1 的准确报表，流处理做实时预警。
• 选 Kappa：你的团队规模不大，不想维护两套代码。而且你的消息队列（比如 Kafka）能保存足够长的数据，方便回放重算。

1.6 湖仓一体 + Kappa：未来的趋势

你可能会问：湖仓一体和 Kappa 架构能结合吗？当然可以。而且我个人认为这是未来的方向。

湖仓一体的开放存储格式（比如 Iceberg）天然支持增量读取和写入。流处理引擎可以直接往 Iceberg 表里写数据，批处理引擎也能读同一张表。这不就是 Kappa 架构的「统一存储」吗？

我在一个实时数仓项目里就是这么干的：Flink 消费 Kafka 数据，直接写入 Iceberg 表。Trino 负责查询，Spark 负责批量回刷。一套存储，多种引擎，代码只有一套流处理逻辑。