1. 湖仓一体概述：数据仓库与数据湖的演进
大家好，我是这次课程的主讲。在正式开始之前，我想先聊聊数据架构这十几年的变迁。说实话，我入行那会儿，大家还在争论「用 Oracle 还是 Teradata」，谁能想到今天我们会坐在这里讨论 Flink 和 Lakehouse 的融合？
数据架构的演进，说白了就是一场「既要又要还要」的博弈。我们既想要数据仓库的强一致性，又想要数据湖的低成本存储，还想要实时计算的低延迟。嗯，这就是湖仓一体要解决的问题。
1.1 数据仓库：那个「规规矩矩」的时代
数据仓库（Data Warehouse）的概念诞生于 80 年代末。它的核心思想很简单：把业务系统的数据抽取出来，经过清洗、转换，加载到一个专门的分析型数据库中。
我最早接触数据仓库是在 2012 年，那时候做电信运营商的报表。每天凌晨跑批，T+1 出报表，业务方催得紧，我们只能加机器、调 SQL。你想想看，一个简单的用户流失分析，要等 24 小时才能看到结果，这在今天简直不可想象。
数据仓库的典型架构是这样的：
- ETL 层：从源系统抽取数据，做清洗和转换
- ODS 层：操作数据存储，保持原始细节
- DW 层：数据仓库，按主题域建模（星型/雪花型）
- DM 层：数据集市，面向特定业务线
它的优点很明显：数据质量高、查询性能好、权限管控成熟。但缺点也致命——贵。一个像样的数仓项目，硬件加软件许可，动辄几百万。而且扩展性差，数据量一上来，扩容就是伤筋动骨。
核心痛点：数据仓库无法处理非结构化数据（日志、图片、音视频），也无法弹性扩展。在数据爆炸的时代，它显得力不从心。
1.2 数据湖：那个「野蛮生长」的时代
2010 年左右，Hadoop 生态兴起，数据湖（Data Lake）的概念应运而生。它的口号是「存所有数据，用原始格式，想怎么分析就怎么分析」。
我记得 2015 年在一个互联网公司，我们搭建了基于 HDFS 的数据湖。当时觉得太爽了——日志直接往 HDFS 里怼，不用建模，不用设计表结构，想查什么跑个 MapReduce 就行。
数据湖的核心特征：
- 存储原始数据：不强制 schema，存成 Parquet/ORC/Avro 等格式
- 低成本：基于廉价硬件，按需扩展
- 支持多种计算引擎：Spark、Hive、Presto、Flink 都能跑
但问题很快就来了。没有 schema 约束，数据质量一塌糊涂。我曾经遇到过这样的情况：某个业务线的日志字段名改了，下游的报表直接跑不出来，排查了整整两天才发现是字段名不一致。这就是所谓的「数据沼泽」——数据倒进去了，但没人知道它是什么、怎么用。
避坑指南：我曾经在一个项目中看到，数据湖里存了 200TB 的日志，但 80% 的数据从未被访问过。数据湖不是垃圾桶，不是所有数据都值得存。一定要有数据治理策略。
1.3 Lakehouse 架构：那个「取长补短」的时代
2017 年，Databricks 提出了 Lakehouse 的概念。它的目标很明确：把数据仓库的 ACID 事务、schema 约束、高性能查询，嫁接到数据湖的低成本存储上。
Lakehouse 不是简单的「湖+仓」，而是一种全新的架构范式。它的核心组件包括：
| 组件 | 作用 | 代表技术 |
|---|---|---|
| 存储层 | 低成本、可扩展的对象存储 | HDFS、S3、OSS、MinIO |
| 表格式 | 提供 ACID 事务、schema 演进、时间旅行 | Delta Lake、Apache Iceberg、Apache Hudi |
| 计算引擎 | 批流一体、SQL 分析、机器学习 | Spark、Flink、Presto/Trino |
| 元数据层 | 统一管理表结构、分区、统计信息 | Hive Metastore、AWS Glue |
说白了，Lakehouse 就是在数据湖上「加了一层皮」。这层皮让数据湖拥有了数据仓库的「规矩」，但又保留了数据湖的「灵活」。
个人经验：我建议你在选择表格式时，先看你的主要计算引擎。如果主力是 Spark，Delta Lake 集成最好；如果主力是 Flink，Iceberg 和 Hudi 更成熟。没有银弹，只有最适合的。
下面这张图展示了 Lakehouse 的核心架构：
1.4 实时湖仓一体：核心价值
传统的 Lakehouse 主要解决的是「批处理」场景下的湖仓融合。但现实世界是实时的——用户点击、交易流水、设备日志，每时每刻都在产生数据。
实时湖仓一体（Real-time Lakehouse）要解决的核心问题就是：如何让数据在产生后，秒级甚至毫秒级就能被查询和分析，同时还能保证数据的一致性和可靠性。
它的核心价值体现在四个方面：
- 低延迟：从 T+1 到秒级。我做过一个金融风控项目，原来每天凌晨跑批计算用户风险分，现在用 Flink 实时计算，用户一操作就能触发风控规则。
- 统一存储：批数据和流数据存在同一份存储上。不用再维护「实时表」和「离线表」两套数据，避免了数据不一致的问题。
- 增量计算：只处理新增或变化的数据，而不是全量重跑。这大大降低了计算成本和资源消耗。
- 数据新鲜度：分析师可以查询到「刚刚发生」的数据，而不是「昨天」的数据。这对运营决策、异常检测至关重要。
核心观点：实时湖仓一体的本质，是把「流处理」的实时性和「湖仓」的存储能力结合起来。它不是简单的「流+批」，而是一种新的数据范式——数据从产生到分析，只有一次写入，一次存储，一次计算。
你可能会问：为什么不用传统的 Lambda 架构？Lambda 架构把数据分为「批处理层」和「流处理层」，两套代码、两套存储，维护成本极高。而且批流数据不一致是家常便饭。实时湖仓一体用一套存储、一套计算引擎（Flink），从根本上解决了这个问题。
下面这张图对比了传统架构和实时湖仓一体的区别：
我个人认为，实时湖仓一体是数据架构演进的必然方向。它解决了三个核心矛盾：
- 成本与性能的矛盾：廉价存储 + 高性能查询
- 实时与批量的矛盾：一套引擎处理所有场景
- 灵活与规范的矛盾：schema-on-read 的灵活 + schema-on-write 的规范
我的建议：如果你正在规划新的数据平台，直接上实时湖仓一体。如果已经在用传统数仓或数据湖，可以逐步迁移——先做实时入湖，再做实时查询，最后做实时分析。别想着一步到位，那容易翻车。