一、数据湖是什么？

数据湖（Data Lake）是一个用于低成本存储海量原始数据，并支持后续分析、计算和加工的数据平台。

它可以保存：

结构化数据：MySQL、Oracle、订单表
半结构化数据：JSON、日志、CDC、消息
非结构化数据：图片、音频、视频、文档

常见底层存储包括：

HDFS
Amazon S3
阿里云 OSS
Azure Data Lake Storage
Google Cloud Storage

一句话理解：

数据湖先把各种数据以较原始的形式集中保存下来，再根据业务需要进行清洗、建模和分析。

它和传统数仓最大的区别是：数据湖通常先存储，后定义用途和结构；传统数仓则更强调先建模，再按模型写入数据。

---

二、为什么需要数据湖？

传统数据仓库通常主要处理结构化数据，例如：

用户表
订单表
商品表
交易事实表

但现代企业还会产生大量其他数据：

App 日志
Web 访问日志
IoT 设备数据
Kafka 消息
MySQL Binlog
图片和视频
第三方 API 数据

如果所有数据都先转换成固定的数仓表结构，通常会遇到：

• 开发周期较长；
• 数据格式转换成本高；
• 新需求响应慢；
• 非结构化数据难以保存；
• 原始数据丢失后难以重新处理。

数据湖可以先保留原始数据：

数据源
  ↓
原始数据入湖
  ↓
按需清洗和建模
  ↓
报表、机器学习、实时分析

这样，当业务规则变化时，可以重新从原始数据加工，而不必重新从数据源采集。

---

三、数据湖的典型架构

一个常见的数据湖架构如下：

业务数据库 / 日志 / Kafka / 文件 / API
                    ↓
              数据采集层
          Flink / Spark / CDC
                    ↓
              对象存储或 HDFS
                    ↓
          Bronze / Silver / Gold
                    ↓
      Spark / Flink / Trino / BI / ML

各层含义通常是：

1. Bronze：原始层

保存从数据源采集来的原始数据，尽量少做修改。

例如：

MySQL Binlog 原始事件
Web 访问日志
Kafka 消息
第三方接口返回的 JSON

特点：

• 接近源数据；
• 便于审计和回放；
• 可能存在重复、脏数据和不完整字段；
• 通常按照采集时间或事件时间存储。

---

2. Silver：明细清洗层

对原始数据进行清洗、去重、类型转换和关联处理。

常见处理包括：

字段类型统一
时间格式统一
处理空值
去除重复数据
解析 JSON
合并 CDC 变更
补充业务字段

例如把多个来源的订单数据统一成：

order_id
user_id
amount
status
event_time
update_time

---

3. Gold：汇总应用层

面向报表、指标和具体业务应用。

例如：

日销售额
用户活跃度
商品转化率
地区订单统计
客户生命周期指标

Gold 层的数据通常更接近数据仓库中的数据集市或宽表。

需要注意，Bronze、Silver、Gold 不是强制标准，而是一种常见的数据分层方法。不同公司也可能叫 ODS、DWD、DWS、ADS。

---

四、数据湖里存的是什么？

早期数据湖经常直接保存大量文件：

CSV
JSON
Avro
Parquet
ORC

其中：

• CSV 和 JSON 便于交换，但查询效率通常较低；
• Avro 更适合行式写入和消息传输；
• Parquet 和 ORC 更适合分析查询。

对于大规模分析，通常会将清洗后的数据保存为列式格式：

Parquet / ORC

它们支持：

• 列裁剪；
• 谓词下推；
• 压缩；
• 统计信息；
• 嵌套类型；
• 按文件或数据块跳过无关数据。

但是要注意：

Parquet 和 ORC 只是文件格式，不等于完整的数据湖表。

---

五、文件格式和表格式的区别

这是理解数据湖最重要的概念之一。

文件格式

负责“数据如何写进一个文件”：

Parquet
ORC
Avro
CSV
JSON

例如 Parquet 负责：

• 列式存储；
• 编码；
• 压缩；
• 文件内统计信息。

表格式

负责“多个数据文件如何组成一张可靠的表”：

Apache Iceberg
Apache Hudi
Delta Lake

表格式通常提供：

• 事务提交；
• 快照；
• Time Travel；
• Schema Evolution；
• Update、Delete、Merge；
• 增量读取；
• 文件清理；
• 并发控制；
• 表级元数据管理。

可以这样理解：

数据湖
├── 存储：S3 / OSS / HDFS
├── 文件格式：Parquet / ORC / Avro
├── 表格式：Iceberg / Hudi / Delta Lake
├── 计算引擎：Spark / Flink / Trino
└── Catalog：Hive Metastore / REST / Glue 等

例如：

Iceberg + Parquet
Hudi + Parquet
Delta Lake + Parquet

表格式是在普通数据文件之上增加表管理能力。

---

六、数据湖如何支持更新和删除？

对象存储中的 Parquet 文件通常是不可变的，不能像数据库一样直接修改某一行。

如果没有表格式，更新数据可能需要：

找到旧文件
  ↓
读取文件
  ↓
修改记录
  ↓
重写新文件
  ↓
替换旧文件

数据量较大时，这个过程成本很高。

Iceberg、Hudi、Delta Lake 会通过不同机制解决这个问题，例如：

重写受影响的数据文件
记录 Delete Files
写入增量日志
创建新的 Snapshot

查询时读取最新的表状态，维护任务再负责合并文件、清理旧版本和减少小文件。

---

七、数据湖的关键组件

1. 存储层

保存实际数据和元数据：

HDFS
S3
OSS
ADLS
GCS

对象存储通常具有容量大、成本低、扩展性强等特点。

---

2. 采集层

负责把数据导入数据湖：

Flink CDC
Debezium
Kafka Connect
Logstash
Sqoop
自定义采集程序

数据来源可以是：

MySQL
PostgreSQL
Oracle
Kafka
应用日志
文件系统
API

---

3. 计算层

负责清洗、转换、聚合和查询：

Spark
Flink
Trino
Presto
Hive
Snowflake

常见分工是：

Spark：批处理、复杂 ETL、大规模计算
Flink：流处理、实时计算、CDC
Trino：交互式 SQL 查询

实际部署中也可能由同一个引擎承担多种任务。

---

4. Catalog

Catalog 负责管理表名、表位置和表元数据。

例如查询：

SELECT * FROM lake.orders;

查询引擎需要通过 Catalog 知道：

orders 表在哪里
当前使用哪个 Snapshot
有哪些 Schema 和分区

常见方案包括：

Hive Metastore
AWS Glue Catalog
Iceberg REST Catalog
JDBC Catalog
Nessie

---

5. 数据治理层

数据湖规模扩大后，需要管理：

数据目录
血缘关系
数据质量
权限控制
脱敏
生命周期
审计

常见治理内容包括：

• 谁可以读取哪些表；
• 哪些字段包含个人信息；
• 数据从哪里来、被谁使用；
• 哪些数据可以删除；
• 原始数据保留多长时间；
• 表是否有重复、缺失或延迟数据。

---

八、数据湖和数据仓库的区别

对比项	数据湖	数据仓库
数据类型	结构化、半结构化、非结构化	主要是结构化数据
写入方式	可先存储后建模	通常先建模后写入
数据状态	原始数据和加工数据都可保存	通常保存清洗后的数据
存储成本	通常较低	通常较高
查询稳定性	需要较好的治理和建模	通常更稳定
使用人群	工程师、分析师、算法团队	分析师、报表用户、业务人员
主要用途	数据探索、ETL、机器学习、实时处理	报表、指标、经营分析
管理复杂度	原始数据多，治理要求高	模型较明确，管理相对集中

数据湖并不一定要取代数据仓库。

很多企业会采用：

数据湖保存明细和原始数据
        ↓
数据仓库或数据集市提供稳定指标

---

九、数据湖和数据湖仓的区别

数据湖早期更像：

把各种文件放进对象存储

但如果只有文件，没有事务、Schema 和治理，容易变成“数据沼泽”：文件很多，却没人知道数据是否可信。

数据湖仓（Lakehouse）是在数据湖基础上增加数仓能力：

开放低成本存储
+
事务和一致性
+
Schema 管理
+
可靠表格式
+
SQL 查询
+
数据治理

常见湖仓表格式：

Iceberg
Hudi
Delta Lake

可以简单区分：

数据湖：强调存储各种数据
数据仓库：强调结构化分析
数据湖仓：希望兼具两者能力

---

十、数据湖的优点

1. 存储成本低

对象存储适合保存海量数据，容量扩展简单。

2. 数据格式灵活

可以同时保存表格、日志、JSON、图片和音视频。

3. 保留原始数据

后续业务规则变化时，可以重新加工历史数据。

4. 支持多种计算引擎

同一批数据可以被 Spark、Flink、Trino 等不同引擎使用。

5. 适合机器学习和数据探索

算法团队可以使用较完整的原始特征和历史数据。

6. 容易接入流批一体架构

Kafka、Flink CDC 等产生的增量数据可以持续写入湖中。

---

十一、数据湖的常见问题

1. 数据沼泽

如果只负责把数据放进去，不定义标准和负责人，最终会出现：

表名混乱
字段含义不清
重复数据很多
没有质量监控
不知道哪些数据可信

2. 小文件问题

流式或频繁批量写入可能产生大量小文件，导致：

• 查询打开文件次数增加；
• 元数据压力变大；
• 任务调度变慢；
• 查询规划时间增加。

通常需要：

控制写入批次
调整并行度
合并小文件
执行 Compaction 或 Rewrite Data Files

3. 分区设计不合理

分区太细：

目录和文件数量爆炸

分区太粗：

查询需要扫描大量数据

常见分区字段包括：

event_date
dt
region
business_type

一般不要把高基数字段，例如用户 ID，直接作为目录分区字段。

4. Schema 混乱

不同批次写入的数据字段、类型和时间精度不一致，会导致读取失败或结果错误。

5. 维护任务缺失

表格式虽然提供了快照和版本，但仍然需要定期执行：

清理旧版本
合并小文件
清理删除文件
整理 Manifest
清理孤立文件

6. 权限和敏感数据泄露

数据湖集中保存大量原始数据，如果权限控制不足，风险可能比多个独立数据库更高。

---

十二、一个典型的数据流示例

以订单系统为例：

MySQL orders 表
        ↓
Flink CDC / Debezium
        ↓
Kafka
        ↓
Flink 或 Spark
        ↓
Hudi / Iceberg 表
        ↓
Trino 查询、Spark 聚合、BI 报表

具体分层可以是：

Bronze：保存原始 Binlog 事件
Silver：合并订单的最新状态
Gold：按天、地区、商品汇总销售指标

如果订单状态经常更新：

Hudi：通常适合直接做 Upsert
Iceberg：也可以通过 Merge、Delete Files 或文件重写实现

如果主要需求是多引擎访问、长期治理和分区演进：

Iceberg：通常更值得优先评估

---

十三、数据湖、Hudi 和 Iceberg 的关系

它们不是同一层的概念：

数据湖：整体架构和存储理念
Hudi / Iceberg / Delta Lake：数据湖表格式
Parquet / ORC：数据文件格式
Spark / Flink / Trino：计算和查询引擎
S3 / OSS / HDFS：底层存储

一个完整组合可能是：

OSS
  + Iceberg
  + Parquet
  + Flink
  + Spark
  + Trino

或者：

S3
  + Hudi
  + Parquet
  + Flink CDC
  + Spark

所以不能简单问“数据湖和 Iceberg 哪个选”，因为它们通常不是竞争关系。

---

十四、什么时候适合建设数据湖？

比较适合的场景：

数据来源多且格式复杂
数据规模增长很快
需要保存原始数据
需要批处理和流处理
需要支持机器学习
多个计算引擎共同访问
需要 CDC、Upsert 或增量读取

如果只是一个小系统、数据量不大、每天几张结构化表做报表，那么：

数据库 + 简单数仓

可能比建设完整数据湖更合适。

数据湖不是“数据量大了就一定要上”的产品，而是一套适合特定规模和数据复杂度的架构。

---

十五、学习顺序建议

可以按下面的顺序理解：

1. 了解对象存储和 HDFS
2. 学习 Parquet、ORC 等文件格式
3. 理解分区、列裁剪、谓词下推
4. 学习 Spark 或 Flink
5. 理解数据湖分层：Bronze / Silver / Gold
6. 学习 Iceberg、Hudi 或 Delta Lake
7. 学习 Catalog、事务和快照
8. 学习小文件、Schema 和数据治理

如果重点是通用数据湖和多引擎：

Parquet → Iceberg

如果重点是 CDC 和高频 Upsert：

Kafka / Flink CDC → Hudi

---

总结

数据湖的核心不是“把文件放到对象存储里”，而是建立一套能够长期保存、加工、查询和治理多种数据的系统。

可以用下面的公式概括：

数据湖
=
低成本存储
+
多格式数据
+
批流计算
+
表格式
+
Catalog
+
数据治理

其中：

Parquet / ORC：保存数据文件
Hudi / Iceberg / Delta Lake：管理数据湖表
Spark / Flink / Trino：处理和查询数据
S3 / OSS / HDFS：提供底层存储

最关键的一点是：

没有数据治理的数据湖，容易变成数据沼泽；真正可用的数据湖必须同时解决存储、计算、表管理、质量、权限和生命周期问题。