📚 课程目录第1章湖仓一体概述

1. 湖仓一体概述：数据仓库与数据湖的演进、湖仓一体架构定义、Lambda与Kappa架构对比

数据仓库这个概念，最早是 Bill Inmon 在 90 年代提出的。说白了，就是想把企业里散落各处的业务数据，统一存到一个地方，方便做报表和分析。

我刚开始做数据时，接触的就是传统数仓。那时候的架构很清晰：ETL 抽取、清洗、转换，然后加载到关系型数据库里。数据是结构化的，Schema 是提前定好的。你想想看，这种模式在业务稳定、数据量不大的时候，确实好用。

但问题很快就来了。我记得有一次，业务部门突然要接入一批日志数据，格式乱七八糟，字段每天都在变。传统数仓的 Schema-on-Write 模式，根本扛不住。改一次表结构，要审批、要重建、要重新跑数据，折腾好几天。

避坑提醒： 我曾经在一个金融项目中，因为数仓表结构设计过于僵化，导致业务方一个新需求等了整整两周。从那以后，我养成了一个习惯——任何数仓设计，都要预留至少 20% 的扩展字段。

数据湖的出现，就是为了解决数仓的「僵化」问题。它提倡 Schema-on-Read，数据先存进来，用的时候再解析。Hadoop 生态的 HDFS、Hive、Spark 就是典型代表。

数据湖的好处很明显：

但用久了你会发现，数据湖也有自己的坑。我见过太多团队，数据湖最后变成了「数据沼泽」——数据往里一丢，没人管、没人理，质量一塌糊涂。

为什么会这样？因为没有事务支持，没有强一致性，没有 Schema 约束。你往湖里写数据，可能写到一半就失败了，留下一堆脏数据。你想更新一条记录？对不起，数据湖不支持 ACID。

核心矛盾： 数据仓库太「死板」，数据湖太「随意」。企业需要一种既能灵活存储、又能保证数据质量和一致性的方案。

湖仓一体（Lakehouse），就是在这个背景下诞生的。它把数据仓库的 ACID 事务、Schema 约束、数据治理能力，嫁接到了数据湖的低成本存储上。

我个人习惯把湖仓一体理解为：用数据湖的存储底座，跑数据仓库的活。

它的核心特征包括：

目前主流的湖仓一体技术，包括 Apache Iceberg、Delta Lake、Apache Hudi。这三者各有侧重，但核心思路是一致的。

我的建议： 选型时不要只看技术热度。我在一个项目中踩过坑——团队选了某个技术，但它的 Spark 版本兼容性有问题，导致上线延期。一定要先做 PoC，验证你的核心场景。

聊湖仓一体，绕不开 Lambda 和 Kappa 这两个架构模式。它们解决的是同一个问题：如何同时处理实时数据和批量数据。

Lambda 架构把数据处理分成两条路：

听起来很合理对吧？但实际用起来，维护成本很高。你想想看，同一套业务逻辑，要在批处理和流处理里各写一遍。万一逻辑不一致，结果就对不上。

我记得有一次，批处理层和流处理层的聚合逻辑差了一个字段，导致报表数据对不上。排查了整整两天，最后发现是代码没同步。嗯，这种问题在 Lambda 架构里太常见了。

Kappa 架构的思路更激进：只用一套流处理引擎，搞定所有数据。历史数据也当作流来处理，通过重放（Replay）的方式，把数据从 Kafka 等消息队列里重新消费一遍。

Kappa 的好处很明显：

但它的局限也很突出：流处理引擎的容错和状态管理，在处理海量历史数据时，性能往往不如批处理。说白了，Kappa 更适合数据量可控、实时性要求高的场景。

选型建议： 不要盲目追求「架构先进」。我在一个 IoT 项目中尝试过纯 Kappa，结果历史数据重放时，流引擎的内存直接爆了。最后还是老老实实加了批处理层。架构没有银弹，适合你的才是最好的。

湖仓一体的出现，其实是对 Lambda 和 Kappa 架构的一种「融合升级」。它用统一的存储层，同时支撑批处理和流处理，避免了数据在多个系统间来回拷贝的问题。

我个人认为，未来的趋势是：湖仓一体 + 流批一体。底层用 Lakehouse 统一存储，上层用 Flink、Spark Streaming 等引擎统一计算。这样既保留了 Lambda 架构的灵活性，又降低了 Kappa 架构的运维成本。

下面这张图，展示了湖仓一体在数据架构中的核心位置：

从这张图你可以看到，湖仓一体并不是要取代数据仓库或数据湖，而是把它们的长处融合在一起。数据源进来后，统一落到湖仓一体存储层，然后根据业务需求，选择不同的计算引擎去处理。

嗯，这里要注意一点：湖仓一体不是银弹。如果你的场景就是纯 BI 报表，传统数仓可能更合适。如果你的场景是纯数据探索，数据湖也够用。湖仓一体的价值，在于「既要又要」的场景——既要低成本存储，又要高数据质量。

一句话总结： 数据仓库是「先建模再存」，数据湖是「先存再建模」，湖仓一体是「存和模一起管」。