数据湖与数据仓库：数据湖架构设计、数据仓库分层模型、湖仓一体实践
这一章，我们来聊聊数据湖和数据仓库。说实话，这两个概念在业界吵了很多年。有人觉得数据湖就是个“垃圾场”，也有人认为数据仓库太死板。我的看法是——没有银弹，只有合适的场景。
我在2018年帮一家电商公司搭数据平台时，就踩过这个坑。一开始他们想用纯数据湖，结果业务方抱怨“查个订单明细要等半小时”。后来改成纯数仓，数据科学家又说“我想用的特征字段你们都没建模”。最后怎么解决的？嗯，就是现在大家常说的——湖仓一体。
数据湖架构设计
数据湖的核心思想很简单：存原始数据，等需要时再处理。跟数据仓库的“先建模再存储”正好相反。
数据湖 vs 数据仓库 核心差异
| 维度 | 数据湖 | 数据仓库 |
|---|---|---|
| 数据格式 | 原始格式（CSV、JSON、Parquet、Avro） | 结构化、预建模 |
| Schema | 读时模式（Schema-on-Read） | 写时模式（Schema-on-Write） |
| 主要用户 | 数据科学家、数据工程师 | BI分析师、业务报表 |
| 存储成本 | 低（对象存储为主） | 较高（需要计算资源） |
| 数据质量 | 参差不齐 | 高（经过ETL清洗） |
我个人习惯把数据湖架构分成三层：
- 存储层：通常用对象存储（S3、OSS、HDFS），存原始文件。我建议按
/raw/{数据源}/{日期}/{文件}这种结构组织，别一股脑全扔一个目录。 - 计算层：Spark、Flink、Presto这些引擎。它们直接读存储层的数据，做ETL或即席查询。
- 元数据层：这是最容易忽略的。没有元数据管理，数据湖真的会变成“数据沼泽”。我推荐用Apache Hive Metastore或AWS Glue Catalog。
这里有个避坑指南——千万别让业务方直接查原始数据湖。我曾经见过一个团队，把几十TB的原始日志直接开放给分析师查询，结果一个SQL跑了两个小时，还把集群搞挂了。后来我们加了数据采样和缓存层，才解决问题。
数据仓库分层模型
数据仓库的分层模型，说白了就是把数据从“脏乱差”一步步变成“干净整齐”的过程。业界最经典的是三层架构：ODS、DWD、DWS。
我的分层建议：不要死磕“必须三层”。我见过一些团队硬套五层模型，结果每层都在做重复的清洗工作。根据业务复杂度，2~4层都合理。
来，我们看一个具体的分层设计：
| 层级 | 全称 | 做什么 | 数据粒度 |
|---|---|---|---|
| ODS | 操作数据存储 | 原样接入业务库、日志、消息队列 | 与源系统一致 |
| DWD | 数据明细层 | 清洗、去重、维度退化、标准化 | 业务明细粒度 |
| DWS | 数据汇总层 | 按主题聚合（日、周、月） | 轻度汇总 |
| ADS | 应用数据层 | 面向具体报表或应用 | 高度汇总 |
你想想看，为什么需要这么多层？直接查ODS不行吗？
行，但代价很大。ODS里的数据可能有重复、有空值、有格式不一致。比如同一个用户ID，在订单表里是user_12345，在日志表里是12345。如果不做DWD层的标准化，后面所有分析都会出问题。
我在项目中遇到过最典型的一个案例：某金融公司做用户流失分析，ODS层直接关联了交易表和用户表，结果因为用户ID格式不统一，关联出来只有60%的匹配率。后来我们在DWD层做了ID映射，匹配率提升到99.5%。
湖仓一体实践
湖仓一体（Lakehouse）这个概念，其实是想同时拥有数据湖的灵活性和数据仓库的可靠性。说白了，就是“我全都要”。
它的核心思路是：用数据湖的存储（低成本、开放格式），加上数据仓库的元数据管理和事务能力。
注意：湖仓一体不是简单的“数据湖+数据仓库”。如果你只是把数据湖的数据ETL到数仓，那叫“数据管道”，不叫湖仓一体。真正的湖仓一体，是在同一份数据上同时支持BI查询和机器学习训练。
目前主流的湖仓一体方案有：
- Delta Lake（Databricks）：支持ACID事务、时间旅行、Schema演进。我最早用Delta Lake时，最惊艳的是它能做
MERGE操作——这在传统数据湖里几乎不可能。 - Apache Iceberg：开源、高性能、支持隐藏分区。它的分区裁剪做得特别好，查询效率比Hive表高一个数量级。
- Apache Hudi：擅长增量处理，适合CDC场景。如果你有大量实时写入需求，Hudi的
upsert能力很香。
下面这张图是我自己总结的湖仓一体架构：
在实际落地时，我建议你从增量场景开始。别一上来就想把整个数仓迁移到湖仓一体架构上。我在一家物流公司就是这么做的——先选了一个实时轨迹表，用Hudi做增量写入，跑通后再逐步扩展。三个月后，整个ODS层都跑在湖仓一体上了。
我的经验：湖仓一体的元数据管理是关键。不管你用Delta Lake还是Iceberg，一定要把元数据服务搭好。我见过一个团队，数据湖里存了200TB数据，但没人知道哪些表是干净的、哪些是测试数据。后来我们加了数据血缘追踪，才把这个问题解决。
最后说一句：技术选型没有标准答案。如果你的团队以BI报表为主，数据仓库可能更合适。如果你们有大量数据科学和机器学习需求，数据湖或湖仓一体会是更好的选择。关键是——想清楚你的数据消费者是谁，他们需要什么。