4. 数据存储层设计：数据湖 vs 数据仓库 vs 湖仓一体
聊到数据存储层，很多团队都会纠结一个问题：到底该用数据湖、数据仓库，还是现在很火的湖仓一体？
说实话，这个问题没有标准答案。我见过不少公司，一开始拍脑袋选了数据湖，结果跑批查询慢得让人抓狂。也见过一些团队死守传统数仓，结果被非结构化数据搞得焦头烂额。
这一章，我就结合自己踩过的坑，把这三者的本质差异、适用场景，以及如何做技术选型，一次性讲清楚。
4.1 数据湖：存得下，但查得慢
数据湖的概念最早是 Hadoop 生态带起来的。它的核心思想很简单：把所有原始数据一股脑儿扔进去，不管结构化的、半结构化的、还是非结构化的。
数据湖的核心特征：
- Schema-on-Read：读取时才定义数据结构
- 低成本存储：通常基于对象存储（如 S3、OSS）或 HDFS
- 支持多种数据格式：Parquet、ORC、Avro、JSON、CSV 等
- 适合数据探索和机器学习
我在 2018 年参与过一个物联网项目，每天要采集上亿条传感器数据。当时我们选了数据湖方案，把所有原始数据以 JSON 格式存到 HDFS 上。存储成本确实低，但问题很快就来了——
业务方想查「过去一周某个设备的平均温度」，一个简单的聚合查询要跑十几分钟。为什么？因为每次查询都要全量扫描，而且 JSON 解析本身就很慢。
避坑指南：我曾经见过一个团队，把数据湖当成了「数据沼泽」。数据往里一丢，没有元数据管理，没有分区策略，最后谁也找不到自己想要的数据。数据湖一定要配合良好的元数据管理和数据目录，否则就是灾难。
4.2 数据仓库：查得快，但存得贵
数据仓库的理念正好相反。它强调 Schema-on-Write，数据在写入之前就要经过清洗、转换、建模。典型的数仓产品有 Teradata、Greenplum、Snowflake、Redshift 等。
| 维度 | 数据湖 | 数据仓库 |
|---|---|---|
| 数据模式 | Schema-on-Read | Schema-on-Write |
| 数据质量 | 原始数据，质量参差不齐 | 经过清洗，质量高 |
| 查询性能 | 慢（全量扫描） | 快（索引、物化视图） |
| 存储成本 | 低 | 高 |
| 典型场景 | 数据探索、机器学习 | BI 报表、固定报表 |
数仓的优势很明显：查询快、数据一致性好。但它的短板也很致命——对非结构化数据支持很差。你想想看，现在哪个业务系统不产生日志、图片、文本？把这些硬塞进数仓，要么存不进去，要么成本高得离谱。
我记得有个金融客户，他们把所有交易数据都放在 Teradata 里，查询确实快。但后来业务方想分析客服对话记录（文本数据），数仓就傻眼了。最后只能另搭一套 Elasticsearch 来做文本搜索，数据架构变得支离破碎。
4.3 湖仓一体：我目前最推荐的方案
湖仓一体（Lakehouse）是近几年兴起的概念，它试图融合数据湖和数据仓库的优点。说白了就是：用数据湖的存储底座，加上数据仓库的查询能力和事务支持。
典型的湖仓一体技术栈包括：
- 存储层：对象存储（S3、OSS、ADLS）
- 表格式：Delta Lake、Apache Iceberg、Apache Hudi
- 计算引擎：Spark、Presto/Trino、Flink
我的个人习惯：在做新项目选型时，我通常会优先考虑湖仓一体方案。原因很简单——它既能存原始数据，又能做高性能分析，还能支持 ACID 事务。一套架构解决多个问题，运维成本也低。
下面这张图展示了湖仓一体的核心架构：
4.4 三种架构的对比与选型建议
说了这么多，到底该怎么选？我整理了一个对比表格，方便你快速决策：
| 评估维度 | 数据湖 | 数据仓库 | 湖仓一体 |
|---|---|---|---|
| 数据多样性 | ★★★★★ | ★★☆☆☆ | ★★★★★ |
| 查询性能 | ★★☆☆☆ | ★★★★★ | ★★★★☆ |
| 数据一致性 | ★★☆☆☆ | ★★★★★ | ★★★★☆ |
| 存储成本 | ★★★★★ | ★★☆☆☆ | ★★★★★ |
| 运维复杂度 | ★★★☆☆ | ★★★☆☆ | ★★★★☆ |
| 实时能力 | ★★☆☆☆ | ★★★☆☆ | ★★★★☆ |
基于这些对比，我给出几条选型建议：
- 如果业务以结构化数据为主，查询模式固定：选数据仓库。比如金融行业的交易报表、财务核算。
- 如果数据种类多，主要用于探索和机器学习：选数据湖。比如 IoT 原始数据、用户行为日志。
- 如果两者都有，而且团队规模不大：选湖仓一体。这是目前最平衡的方案，也是我个人的首选。
一个真实案例：我之前帮一家电商公司做架构升级。他们原来用 Hive 做数据湖，用 MySQL 做报表查询。每次大促期间，数据延迟严重，报表出不来。后来我们迁移到 Iceberg + Trino 的湖仓一体方案，存储成本没增加，查询性能提升了 5 倍，而且支持了实时数据入湖。业务方非常满意。
4.5 湖仓一体的落地要点
如果你决定采用湖仓一体，有几个关键点需要注意：
- 表格式选型：Delta Lake 适合 Databricks 生态，Iceberg 兼容性更好，Hudi 在增量处理上有优势。我个人更倾向 Iceberg，因为它对 Spark、Flink、Trino 都支持得很好。
- 分区策略：按时间分区是标配，但要注意分区粒度。我见过有人按小时分区，结果小文件太多，查询反而变慢。一般建议按天或按周分区。
- 数据压缩：Parquet + Snappy 压缩是黄金组合。存储空间能省 70% 以上，查询性能也不受影响。
- 元数据管理：一定要上元数据服务，比如 Hive Metastore 或 AWS Glue。否则数据湖会变成数据沼泽。
我曾经踩过的坑：刚开始用 Iceberg 时，没注意配置自动清理过期快照。结果跑了三个月，存储空间暴涨了 5 倍。后来加了 spark.sql.extensions 和定期清理策略，才把成本降下来。嗯，这个细节很多人会忽略。
好了，关于数据存储层的三种架构，我就讲到这里。记住一点：没有银弹，只有最适合你业务场景的方案。选型时多花点时间做评估，比后期重构要划算得多。