数据湖概念与演进

概述

从数仓到数据湖再到湖仓一体（Lakehouse），存储架构随业务演进。本文讲清 Data Lake、Data Warehouse、Lakehouse 三者的定位与差异，以及 Lambda/Kappa 两种处理架构的权衡。

---

一、三种数据架构

1.1 数据仓库（Data Warehouse）

结构化数据 → ETL → 规范化存储 → BI 报表

特点	说明
面向分析	预建模、预聚合
结构化	强 Schema
成本	高（存储贵）
价值	决策支持成熟

1.2 数据湖（Data Lake）

任意数据（结构化/半结构化/原始文件）→ 低成本存储 → 按需处理

特点	说明
原始存储	不预加工
Schema-on-Read	读取时定义
低成本	对象存储/分布式
问题	数据沼泽、无事务

1.3 湖仓一体（Lakehouse）

数据湖的存储 + 数仓的能力（事务、Schema、性能）

能力	说明
事务	ACID
Schema	强制/演化
性能	索引/优化
统一	数据湖与数仓同一份数据

1.4 三者对比

维度	Data Warehouse	Data Lake	Lakehouse
数据	结构化	任意	任意
Schema	写时强制	读时定义	写时+演化
事务	支持	无	支持
成本	高	低	低
适用	报表	原始存储/ML	湖仓统一分析

---

二、为什么需要数据湖

需求	数据湖解决
非结构化数据	图片、日志、文件
机器学习	原始特征
成本控制	廉价存储
弹性探索	先存后算

2.1 数据湖痛点

痛点	说明
无事务	并发写冲突
数据质量	无约束
性能	无索引优化慢
难以治理	无元数据血缘

→ 这些痛点推动 Lakehouse 出现。

---

三、Lakehouse 的关键能力

能力	实现
事务性	表格式（Iceberg/Delta/Hudi）
Schema 演化	表格式支持
快照/时间旅行	版本管理
性能优化	文件布局、Z-Order
开放格式	Parquet/ORC 等

Lakehouse = 对象存储（低成本）
          + 表格式（事务/版本/Schema）
          + 计算引擎（Spark/Flink/Presto）

---

四、Lambda 架构

4.1 结构

数据 → 批层（Batch Layer）→ 批视图
     ↘ 速度层（Speed Layer）→ 实时视图
                    ↓ 合并
                服务层（Batch 合并实时）

层	职责	特点
批层	全量计算	准确、延迟高
速度层	实时补充	快、近实时
服务层	合并输出	完整视图

4.2 优缺点

优点	缺点
准确 + 实时	两套代码
容错好	维护成本高
成熟	逻辑重复

---

五、Kappa 架构

5.1 结构

数据 → 流层（Stream Layer）→ 实时视图
       （重放历史数据也能算历史）

层	说明
流层	唯一计算层
重放	重新消费历史数据
结果	实时视图

5.2 优缺点

优点	缺点
一套代码	依赖流引擎吞吐
简化运维	历史重放耗时
实时一致	批处理能力有限

---

六、Lambda vs Kappa

维度	Lambda	Kappa
计算层	批 + 流两套	只有流
代码	两份	一份
复杂度	高	低
准确性	高（批校验）	依赖流
场景	传统数仓	流优先

场景	选型
需要精确历史	Lambda（或湖仓批流一体）
实时为主	Kappa
湖仓一体	批流共用一套表格式

---

七、演进趋势

数仓 → 数据湖 → Lakehouse
  └────── 数据网格（Data Mesh）：
        领域化、去中心化数据产品

趋势	说明
湖仓一体	统一存储 + 事务
流批一体	一套引擎/格式
数据网格	组织化治理
云原生	对象存储 + 弹性计算

---

常见问题速查

问题	要点
湖 vs 仓怎么选	成本/数据结构/事务需求
为什么加表格式	事务与版本能力
Lambda 何时淘汰	实时引擎成熟后
Lakehouse 核心	表格式 + 开放格式
数据网格	领域数据产品治理