1. 数据湖概述：从定义到Lakehouse架构
大家好，我是老张。做数据架构十几年了，今天咱们聊聊数据湖。
说实话，数据湖这个概念刚出来的时候，我也挺懵的。什么湖啊仓啊的，听着像搞水利的。但干久了你就发现，名字虽然花哨，背后解决的问题其实很实在。
1.1 数据湖到底是个啥？
数据湖，说白了就是一个集中存储海量原始数据的系统。你可以把各种格式的数据——结构化的、半结构化的、非结构化的——全都往里扔。
我习惯这么定义：数据湖是一个以原始格式存储数据的中央存储库，支持任意规模的数据，并且可以按需进行处理和分析。
嗯，这里要注意几个关键词：
- 原始格式：数据进来什么样，存进去就什么样。不像数据仓库，得先做ETL清洗转换。
- 任意规模：从几GB到几百PB，都能撑得住。
- 按需处理：用的时候再定义schema，这叫"读时模式"（Schema-on-Read）。
1.2 数据湖 vs 数据仓库：别搞混了
很多新人问我：数据湖和数据仓库到底啥区别？
我一般这么解释：数据仓库是"先想好再存"，数据湖是"先存了再说"。
你想想看，传统数据仓库建表之前，得先设计好维度、度量、星型模型。数据湖呢？文件往里一丢，后面想怎么用都行。
下面这张表，是我在项目里经常给业务方看的对比：
| 对比维度 | 数据仓库 | 数据湖 |
|---|---|---|
| 数据格式 | 结构化，经过清洗转换 | 原始格式，包括JSON、CSV、Parquet、图片、日志等 |
| Schema模式 | 写时模式（Schema-on-Write） | 读时模式（Schema-on-Read） |
| 处理方式 | ETL（抽取-转换-加载） | ELT（抽取-加载-转换） |
| 主要用户 | 业务分析师、报表用户 | 数据科学家、数据工程师 |
| 存储成本 | 较高（需要高性能存储） | 较低（通常用廉价对象存储） |
| 数据质量 | 高（经过严格治理） | 参差不齐（需要后期治理） |
| 典型场景 | 固定报表、BI分析 | 探索性分析、机器学习、实时流处理 |
我曾经在一个电商项目里，两边都用了。订单交易数据走仓库，因为要出财务报表，一分钱都不能差。用户行为日志、点击流数据走数据湖，因为数据量大、格式乱，而且分析需求天天变。
1.3 数据湖的典型架构
数据湖架构这些年也进化了不少。我把它分成三个阶段来讲：
第一阶段：原始数据湖（2010年左右）
那时候的架构很简单：
- 存储层：HDFS或S3
- 计算层：MapReduce或Spark
- 元数据层：Hive Metastore
问题也很明显：数据质量没人管，数据血缘一团糟，查个数据来源得问三个人。
第二阶段：带治理的数据湖（2015年左右）
大家发现光存不行，得管。于是加了：
- 数据目录（如Apache Atlas、AWS Glue）
- 数据质量框架（如Apache Griffin、Deequ）
- 访问控制（如Ranger、Sentry）
这个阶段，数据湖开始"像样"了。但还有个硬伤：不支持事务。你想想，两个任务同时写同一个分区，数据就乱了。
第三阶段：Lakehouse架构（2020年至今）
Lakehouse，就是数据湖+数据仓库的合体。它解决了数据湖最头疼的几个问题：
- ACID事务：支持原子性、一致性、隔离性、持久性
- Schema演进：表结构可以平滑变更
- 高效更新：支持upsert、merge操作
- 数据版本控制：可以回滚到任意历史版本
实现Lakehouse的核心技术，就是开放表格式。目前主流的有三个：
| 技术 | 创始公司 | 核心特点 | 适用场景 |
|---|---|---|---|
| Delta Lake | Databricks | 事务日志、时间旅行、Schema强制 | Spark生态、批流一体 |
| Apache Iceberg | Netflix | 隐藏分区、分区演进、多引擎支持 | 跨引擎场景（Spark、Flink、Trino） |
| Apache Hudi | Uber | 增量处理、记录级别索引、近实时写入 | CDC场景、实时数仓 |
我个人习惯用Delta Lake。为啥？因为它在Spark生态里集成得最好，而且事务日志的设计很优雅。但如果你需要跨引擎查询，Iceberg可能更合适。
下面这张图，是我在给团队培训时画的Lakehouse架构：
这个架构图，我建议你保存下来。后面讲数据质量监控的时候，你会反复看到它。
1.4 数据湖质量监控为什么难？
聊完架构，咱们说说痛点。数据湖的质量监控，比数据仓库难在哪？
我总结了几点：
- 数据格式杂：Parquet、Avro、JSON、CSV、甚至图片二进制流。每种格式的校验方式都不一样。
- Schema变化快：业务一改，字段就加。没有仓库那么严格的变更管控。
- 数据量大：动不动几百TB，全量校验不现实。
- 血缘关系乱：数据从哪来、经过哪些转换、被谁用过，经常说不清楚。
- 缺少事务保障：虽然Lakehouse加了ACID，但很多老的数据湖还在用原始方式，脏数据问题频发。
我曾经在一个项目里，因为数据湖里一个分区被重复写入，导致下游的报表连续三天数据对不上。排查了整整两天，才发现是调度系统配置错了。从那以后，我就在每个数据湖项目里强制加上了数据质量监控这个环节。