一、湖仓一体概述：从数据孤岛到统一底座
大家好，我是这次课程的主讲。在数据架构这个领域摸爬滚打十几年，我见过太多团队在「选数仓还是选数据湖」这个问题上反复折腾。今天咱们聊的湖仓一体，说白了就是想把这两者的优点合二为一。嗯，先别急着看概念，咱们从架构演进说起。
1.1 架构演进：为什么会有湖仓一体？
我刚开始做数据工程师那会儿，企业基本就两种路子：要么用传统数仓（比如 Teradata、Oracle RAC），要么用 Hadoop 生态搭数据湖。但这两条路都有各自的坑。
传统数仓的痛点：
- 存储和计算绑定，扩容成本高得吓人。我记得有个金融客户，每次加存储都得连带买 CPU，预算根本批不下来。
- 对非结构化数据支持差。日志、图片、音视频？数仓基本说「不」。你想想看，现在哪个业务离得开这些数据？
- 数据模型固定，schema-on-write 模式让迭代变得很慢。业务变了，改表结构要排期，一等就是两周。
数据湖的痛点：
- 缺乏事务支持。多个任务同时写同一份数据，很容易读到脏数据。我曾经遇到过 Spark 任务写到一半失败，下游报表直接跑飞的情况。
- 数据质量难保证。没有 schema 约束，数据湖很容易变成「数据沼泽」。你往里扔什么都能存，但想拿出来用？得先花两周清洗。
- 查询性能差。Hive 跑个简单的 count，动不动就几分钟。业务方等不了。
所以你看，数仓和数据湖就像两个极端。一个太「死板」，一个太「随意」。湖仓一体就是在中间找平衡点——既要数仓的 ACID 和性能，又要数据湖的灵活性和低成本。
1.2 核心概念：湖仓一体到底是什么？
我个人习惯把湖仓一体理解成「在数据湖上长出来的数仓」。它不是一个具体产品，而是一种架构理念。核心要素就这几条：
- 统一存储层：所有数据（结构化、半结构化、非结构化）都放在同一个低成本对象存储上，比如 S3、OSS、HDFS。
- ACID 事务：支持并发读写，保证数据一致性。这是数据湖做不到的。
- Schema on Read + Schema on Write：既保留数据湖的灵活性，又提供数仓的约束能力。
- 开放格式：用 Parquet、ORC、Avro 等开放格式存储，避免被某个厂商锁定。
- 高性能查询：通过索引、缓存、物化视图等手段，让查询速度接近传统数仓。
避坑指南： 我曾经见过一个团队，把湖仓一体理解成「把 Hive 表改成 Iceberg 格式就完事了」。结果呢？查询性能没提升，事务支持也没用起来。湖仓一体是系统工程，存储格式只是第一步，计算引擎、元数据管理、权限体系都得跟上。
1.3 与传统数仓/数据湖的对比
咱们直接看表，这样最清楚：
| 维度 | 传统数仓 | 数据湖 | 湖仓一体 |
|---|---|---|---|
| 存储格式 | 专有格式（如 Teradata 的 FSL） | 开放格式（Parquet/ORC） | 开放格式（Parquet/ORC） |
| 事务支持 | 强 ACID | 无或弱 | 强 ACID |
| Schema 模式 | Schema on Write | Schema on Read | 两者结合 |
| 数据种类 | 结构化为主 | 全类型 | 全类型 |
| 查询性能 | 高（秒级） | 低（分钟级） | 中高（秒级到分钟级） |
| 扩展性 | 差（垂直扩展） | 好（水平扩展） | 好（水平扩展） |
| 成本 | 高（专有硬件） | 低（通用硬件） | 低（通用硬件） |
| 典型代表 | Oracle、Teradata、Greenplum | Hadoop/Hive、AWS S3 + Athena | Apache Iceberg、Delta Lake、Apache Hudi |
为什么会有这些差异？说白了，传统数仓是为「已知的、稳定的查询模式」设计的。数据湖是为「存储一切、以后再说」设计的。湖仓一体则是为「既要存储一切，又要即时分析」设计的。你想想看，现在的业务场景哪个不是这样？
1.4 主流产品介绍
目前市面上主流的湖仓一体方案，我按技术路线分了三类：
1.4.1 开放表格式方案
这类方案不绑定计算引擎，核心是改造存储层的表格式。我个人最常用的是这三种：
- Apache Iceberg：我最推荐的一个。它的快照隔离做得特别好，支持分区演进和隐藏分区。我在一个电商项目中用 Iceberg 替代了 Hive，查询性能提升了 3 倍，而且再也没出现过脏读。
- Delta Lake：Databricks 出品，和 Spark 集成最紧密。如果你团队 Spark 技术栈很重，Delta Lake 是首选。不过要注意，它和 Flink 的集成目前还不太成熟。
- Apache Hudi：Uber 开源，擅长增量处理。适合 CDC 场景，比如实时入湖。我有个做实时数仓的朋友，用 Hudi 的 MOR（读时合并）模式，把数据延迟从小时级降到了分钟级。
1.4.2 商业化平台方案
不想自己搭基础设施？可以考虑这些：
- Databricks Lakehouse：业界标杆，Unity Catalog 做元数据和权限管理，性能确实好。但价格也「好」——小团队慎入。
- Apache Doris：国产开源，MPP 架构，查询性能极快。我最近在帮一个互联网客户做 POC，Doris 在百亿级表上的聚合查询，响应时间基本在 1 秒以内。
- StarRocks：Doris 的分支，性能同样出色，社区更活跃一些。
1.4.3 云原生方案
如果你已经上了云，这些方案可以无缝集成：
- AWS Lake Formation：和 S3、Glue、Athena 深度集成，权限管理做得不错。
- Azure Synapse：微软的湖仓一体方案，和 Power BI 配合得很好。
- 阿里云 EMR + DLF：国内用得比较多，支持 Iceberg 和 Hudi。
注意： 选型时别只看功能列表。我见过一个团队，因为听说 Delta Lake 性能好，就全量迁移过去。结果他们的主要计算引擎是 Flink，而 Delta Lake 对 Flink 的支持当时还很弱，最后不得不回滚。选型一定要结合自己的技术栈和业务场景。
1.5 湖仓一体核心架构图
下面这张图是我自己总结的湖仓一体分层架构，你可以看到每一层负责什么：
从这张图你能看到，湖仓一体不是推翻重来，而是在现有数据湖基础设施上「加层」。最底层还是对象存储，往上加开放文件格式，再加表格式提供事务能力，然后才是元数据、查询引擎和应用。每一层各司其职，这也是为什么湖仓一体能同时兼顾灵活性和性能。
1.6 小结
这一章咱们把湖仓一体的来龙去脉理清楚了。从架构演进到核心概念，从对比分析到主流产品，你应该对「湖仓一体到底是什么」有了一个整体的认识。嗯，这里要特别提醒一句：不要为了用湖仓一体而用湖仓一体。如果你的业务场景就是简单的 ETL + 固定报表，传统数仓完全够用。湖仓一体的真正价值，在于那些「数据种类多、查询模式多变、对实时性有要求」的场景。