考察点
这是数据湖方向的开场题，几乎必问。面试官想看的不是背定义，而是你能否讲清两者在工程上的本质取舍：schema 何时定义、数据以什么形态存、算力和存储怎么解耦。答得好的人会把话题自然带到「为什么要搞湖仓一体」，追问通常就落在你公司到底用湖还是用仓、或者两者怎么配合。
参考答案
一句话先立住
数据仓库是「先建模再进数据」，数据湖是「先存数据再决定怎么用」。这个 schema-on-write 对 schema-on-read 的差异是根，其他区别都是它长出来的枝叶。
五个维度的展开对比
| 维度 | 数据仓库 | 数据湖 |
|---|---|---|
| 数据形态 | 结构化为主，进仓前完成清洗建模 | 结构化、半结构化、非结构化都收，原样落地 |
| Schema 时机 | schema-on-write，入库前强校验 | schema-on-read，读取时才解释 |
| 存储成本 | 专有格式或 MPP 引擎内，成本高 | HDFS/对象存储，副本廉价，可分层 |
| 查询性能 | 面向固定 SQL 场景深度优化，快 | 依赖引擎（Spark/Presto/Trino），裸查慢 |
| 适用场景 | 报表、BI、固定指标 | 探索分析、机器学习、原始数据归档 |
数据湖能兴起，现实原因是对象存储（S3、OSS）足够便宜，计算引擎（Spark、Flink、Trino）又足够强，「先把数据全倒进来，用的时候再说」在经济上成立了。而数仓的核心价值从来没变过：建模过程本身就是对业务的一次梳理，维度建模产出的宽表和指标体系，是业务方能直接消费的资产。
各自的坑要讲出来
只讲优点会显得没干过活。数据湖最大的坑是「数据沼泽」：没有治理的湖，数据进了没人知道有什么、谁能用、质量如何，最后变成只进不出的垃圾场。数仓的坑是「重」：建模周期长，业务一变就要改模型，历史数据回刷成本高，而且它基本处理不了图片、日志、音视频这类数据。
落地上的常见搭配
真实公司很少二选一。典型架构是湖仓分层：原始日志先进湖（比如 OSS 上的 Iceberg 表），ODS 层原样保留；然后在湖上或者同步进数仓做 DWD、DWS 建模，给 BI 用；机器学习团队直接读湖里的原始层。湖是「蓄水池」，仓是「精加工车间」。
收个尾：为什么都在谈湖仓一体
两套系统的维护成本、数据冗余、口径不一致问题积累到一定程度，行业就开始往湖仓一体收敛：在开放的湖格式上把 ACID、schema 演进、索引这些数仓能力补齐，让一份数据同时服务 BI 和 AI。这也是后面 Iceberg、Hudi 这些表格式火起来的根本原因，面试里主动提一句这个演进逻辑，答案就完整了。
可能的追问
- 你们公司现在用的是湖还是仓？为什么？ 结合业务答：以固定报表为主选仓，有大量日志/算法需求选湖，多数中大型公司是湖+仓或湖仓一体。
- 数据湖查询慢怎么解决？ 答表格式（Iceberg/Hudi）提供索引和文件级裁剪、分区设计、Z-Order/聚簇、加缓存层（Alluxio）或用 MPP 引擎（Trino/StarRocks）直查。
- 数据沼泽怎么避免？ 答元数据目录、数据血缘、质量监控、生命周期管理四件套，靠治理体系而不是靠自觉。