📚 课程目录第1章数据湖仓概述

1. 数据湖仓概述：数据湖与数据仓库的演进、湖仓一体架构的诞生背景、核心优势与挑战

大家好，我是这次课程的主讲。咱们今天先聊聊数据湖仓的来龙去脉。

做数据架构这么多年，我见过太多团队在「选湖还是选仓」上反复折腾。有的公司先上了数仓，后来发现非结构化数据管不了；有的先建了数据湖，结果报表跑不出来，业务部门天天投诉。说白了，湖和仓各有各的脾气，但业务不会等你慢慢磨合。

这一节，我们就从数据仓库和数据湖的演进讲起，看看湖仓一体到底解决了什么问题，以及它现在还有哪些坑。

数据仓库的概念诞生于上世纪80年代末。那时候，企业数据主要来自关系型数据库，结构整齐，格式统一。数仓的核心思路就是「先建模，再入库」——ETL 清洗、转换、加载，一套流程走完，数据变得规规矩矩。

我早期参与过一个零售数仓项目，业务方要求 T+1 出销售报表。那时候我们用 Teradata，每天凌晨跑批处理，几百张事实表和维度表关联，跑完刚好赶上早会。嗯，那个年代，数仓就是数据世界的「秩序维护者」。

但数仓有个硬伤：它只认结构化数据。日志文件、图片、视频、传感器数据……这些非结构化或半结构化的东西，数仓基本不搭理。而且，存储成本高，扩展性差，想扩容得加硬件，周期长、费用贵。

  核心特征：
  Schema-on-Write：写入时强制定义 schema，数据质量高
ACID 事务支持：保证数据一致性和可靠性
高性能 SQL 查询：针对 BI 报表和 Ad-hoc 分析优化
存储成本高：通常使用专有硬件或高性能存储

到了2010年左右，Hadoop 生态兴起，数据湖的概念开始流行。湖的理念跟仓正好相反——先把数据扔进去，管它是什么格式，等要用的时候再处理。这就是所谓的 Schema-on-Read。

我记得有个客户，把几百 TB 的点击流日志、API 调用记录、甚至 CDN 的原始日志全丢进 HDFS 里。一开始大家觉得挺爽，想存什么存什么。但半年后，数据湖变成了数据沼泽——没人知道哪些数据有用，哪些是垃圾，查个东西要翻半天目录。

为什么会这样？因为数据湖缺乏治理。没有 schema 约束，没有事务保障，数据质量全靠自觉。你想想看，几十个团队往同一个湖里灌数据，格式不统一，命名不规范，时间一长，基本就废了。

避坑指南： 我曾经接手过一个数据湖项目，里面存了超过 2000 张 Parquet 表，但其中 40% 的表没有元数据描述，30% 的表字段类型不一致。最后我们花了三个月做数据治理，比重新建湖还累。所以，数据湖一定要配好元数据管理和权限控制，否则就是给自己挖坑。

既然湖和仓各有优缺点，那能不能把它们结合起来？这就是湖仓一体（Lakehouse）的诞生背景。大约在2019年前后，Databricks 提出了 Lakehouse 架构，核心思路是：在数据湖的低成本存储之上，实现数据仓库的 ACID 事务和 SQL 分析能力。

说白了，就是让湖拥有仓的「纪律」，让仓拥有湖的「灵活」。你不需要在两个系统之间来回倒数据，一份数据既能跑机器学习，又能出 BI 报表。

下面这张图展示了数据湖仓的核心架构逻辑：

我这两年接触的客户，超过 70% 都在评估或已经迁移到湖仓一体架构。原因很直接：

维度	传统数据仓库	数据湖	湖仓一体
存储成本	高（专有硬件）	低（对象存储）	低（对象存储）
数据格式	仅结构化	结构化/半结构化/非结构化	全类型支持
ACID 事务	完整支持	不支持或有限	完整支持
Schema 管理	Schema-on-Write	Schema-on-Read	两者兼顾
查询性能	高（索引、物化视图）	低（全表扫描）	中高（分区、索引优化）
数据治理	强	弱	强
开放生态	封闭（厂商锁定）	开放	开放

从表格里能看出来，湖仓一体在存储成本和开放生态上继承了数据湖的优势，在事务支持和数据治理上又向数据仓库看齐。说白了，它想两头都占。

个人经验： 我建议你在选型时重点关注「开放表格式」这一层。Iceberg、Delta Lake、Hudi 这三个主流方案各有侧重。Iceberg 在分区演进和兼容性上做得最好，Delta Lake 跟 Spark 生态绑定最深，Hudi 在增量处理上更擅长。没有银弹，得看你的实际场景。

说了这么多好处，也得泼点冷水。湖仓一体目前还不是完美的方案，我在项目中踩过不少坑：

性能瓶颈： 对象存储的延迟比本地 SSD 高一个数量级。虽然通过缓存和分区裁剪能缓解，但高并发低延迟的场景（比如实时风控）还是得用专门的 OLAP 引擎。
小文件问题： 流式写入会产生大量小文件，如果不做 compaction，元数据膨胀会拖垮查询性能。我曾经见过一个 Delta Lake 表，一天产生了 10 万个小文件，查询延迟从 2 秒飙升到 2 分钟。
事务冲突： 虽然支持 ACID，但乐观并发控制在写入冲突频繁时会导致大量重试。高并发写入场景需要仔细设计分区策略。
学习曲线： 表格式的配置参数很多，比如 Iceberg 的 commit 重试策略、Delta Lake 的 vacuum 保留时长，调优不当反而会出问题。

避坑指南： 我曾经在生产环境遇到过 Iceberg 的元数据表膨胀问题。原因是频繁的 schema 变更产生了大量历史快照，而自动过期策略没配好。最后手动清理了旧快照才恢复。所以，一定要给表格式配置合理的快照保留策略和 compaction 计划，别等出事了再补救。

数据湖仓不是凭空冒出来的概念，它是数据仓库和数据湖十几年博弈后的产物。它解决了「一份数据，多种用途」的核心矛盾，但也带来了新的复杂性。

接下来的课程，我们会深入剖析 Iceberg、Delta Lake、Hudi 这三种主流表格式的实现原理和最佳实践。嗯，准备好了吗？