数据湖 vs 数据仓库：数据工程师面试系统设计选型指南
一句话总结
数据湖擅长存储原始、多格式、低成本的海量数据，适合探索性分析和机器学习；数据仓库则强调结构化、高性能、可治理的数据，服务于固定报表和BI场景。
面试官考察的不是你能否背出定义，而是你能否根据业务目标、数据特征和团队能力做出合理的选型判断，并在后续演化中给出清晰的迭代路径。正确的答案是：先明确使用场景，再权衡成本、延迟、治理需求，最后给出分层或混合架构的具体方案。
适合谁看
这篇文章适合正在准备中高级数据工程师面试、希望在系统设计环节展示选型深度的求职者，特别是那些已经掌握SQL和基本ETL但对架构决策缺乏实战经验的人。如果你正在面向硅谷或类似技术驱动的公司（如Airbnb、Uber、LinkedIn）申请数据工程师岗位，需要在45分钟的系统设计题中给出结构化思路，那么这里的框架和场景会直接对应面试官的评估维度。
同时，担任技术面试官或团队Leader想要快速检验候选人是否具备产品思维和权衡能力，也可以把本文作为参考答案的基准。
数据湖和数据仓库的核心区别是什么？
在一次真实的debrief会议中，面试官把候选人叫进来，说：“你刚才说数据湖就是‘大号文件系统’，我需要你把区别说得更具体。” 候选人如果只回答“数据湖存原始数据，仓库存清洗数据”，就会被判定为停留在表面。正确的判断应该是：数据湖的核心是schema-on-read，即数据在写入时不做结构强制，只有在查询时才根据需求进行解析；而数据仓库则是schema-on-write，在数据进入仓库前就必须完成清洗、建模和分区，以保证查询的一致性和低延迟。这导致了三个实际区别：一是数据湖能够接受半结构化（JSON、Avro、Parquet）甚至完全非结构化的日志、点击流、物联网传感器数据，而仓库通常只能处理已经转换为关系表的数据；二是数据湖的存储成本往往低于仓库的10倍以下，因为它可以利用廉价对象存储（S3、ADLS）和开源格式；
三是数据湖的查询延迟更高，依赖于引擎（Spark、Presto、Trino）的按需解析，而仓库通过列式存储、物化视图和预聚合实现亚秒级响应。面试官会进一步追问：“如果你只能选一种来做用户行为漏斗分析，你会选什么？” 这时候候选人需要说明：漏斗分析需要高频、低延迟的聚合查询，因而数据仓库更合适；但如果要做原始事件的回溯和特征工程，则需要数据湖作为底层数据源。这种“不是单纯的存储选择，而是根据查询模式和数据治理需求来决定的”才是面试官想听见的结论。
> 📖 延伸阅读：Stripe PMculture指南2026
何时应该选择数据湖而非数据仓库？
在一次hiring committee讨论中，经理提到：“我们上季度把所有埋点数据直接丢进了Redshift，结果查询成本飙升，团队开始抱怨。” 这里的教训是：当数据来源极其多样、schema频繁变化、或者业务还在探索阶段时，强行往仓库里塞会导致高额的ETL开销和schema迁移风险。具体来说，数据湖更适合以下三种情形：第一，数据量级达到PB以上且增速快，比如日志、埋点、传感器原始流；第二，数据消费者不仅是BI分析师，还有数据科学家、机器学习工程师，他们需要在不同上下文（特征工程、实验平台）灵活地重新定义schema；第三，公司希望降低存储成本并愿意接受一定的查询延迟，以便在后期通过数据目录（如Glue、Atlas）和治理工具来逐步引入结构化视图。
面试中如果被问到“你们公司现在只有传统的仓库，如何说服领导引入数据湖？”，一个强答案会先指出现有仓库在处理原始事件时的瓶颈（ETL链条长、schema冲突频繁），然后给出一个分阶段的迁移计划：第一步在S3上建立原始数据湖，保留所有埋点；第二步使用Spark或Flink做增量清洗，将聚合好的维度事实表写入仓库；第三步通过元数据层（如DataHub）让BI工具既能查询仓库也能直接访问湖中的原始数据，实现“不是全盘替换，而是增量共存，逐步下沉冷数据”的策略。这样既能控制成本，又能保证现有报表不中断。
在面试中如何展示对选型的思考过程？
面试官最看重的是候选人是否能够把抽象的框架落地到具体的业务场景里。有一次模拟面试中，候选人被问到：“假设你要为一个新上的推荐系统构建特征平台，你会怎么选？” 弱的回答只是列出“用Kafka+Flink+S3+Redshift”之类的技术栈，没有说明为什么每个环节被选择。好的回答会先拆解问题：特征平台需要（1）实时事件采集，（2）离线批处理特征回填，（3）低延迟在线特征服务，（4）特征的版本控制和 lineage。基于这四个需求，候选人会说：“对于（1）和（2），我选择数据湖作为临时存放区，因为原始事件格式多样且后续可能需要重新跑特征实验；
对于（3），我会把计算好的特征写入数据仓库或类似的键值存储（如Redis、DynamoDB），以保证读取的单位毫秒级延迟；对于（4），我会在湖中保留原始快照，同时在仓库中使用物化视图和分区来实现可回滚的特征版本。” 这样的一套回答体现了“不是为了用新技术而用新技术，而是根据每一步的数据特征和服务目标来匹配最合适的存储与计算引擎”。面试官会接着问：“如果后来发现特征更新频率从每小时变成每五分钟，你会怎么调整？” 候选人如果能说明此时可能需要把某些中间特征从湖迁移到流式状态存储（如Kafka Streams或Flink State），并保留湖作为审计日志，就会展示出对演化路径的前瞻思考。
> 📖 延伸阅读：Amgen留学生求职产品经理攻略2026
如何构建混合架构以兼顾两者的优势？
在某次跨部门冲突的debrief中，数据平台团队和BI团队争论：“我们要不要把所有数据都迁移到湖里？” BI团队担心查询性能，平台团队则担心成本。最终达成的方案是分层湖仓（Lakehouse）架构：底层采用统一的对象存储（S3），上层开放两种访问路径——一是通过Presto/Trino直接查询湖中的开放格式（Iceberg、Delta Lake），获得几乎仓库级的性能；二是通过周期性的批处理 job 将热数据物化到列式仓库（Snowflake、BigQuery）中，供高频报表和仪表盘使用。这种设计的核心在于：不是把湖和仓库看作互斥的两个选择，而是把它们看作同一份数据的不同视图，分别服务于不同的访问模式。
面试中如果被问到“你们公司现在只有传统的仓库，怎样用最小的改动引入湖仓概念？”，一个合格的回答会提出：先在现有仓库之外建立一个数据湖目录，将低频、原始的日志直接写入湖；接着使用dbt或类似工具在湖上创建物化视图，视图的输出写回仓库的 staging schema；最后逐步把报表指向这些视图，实现查询不变、后端已经在湖里做了存储和计算的分离。这样既保留了现有BI工具的兼容性，又获得了湖的成本和灵活性优势。
在实际项目中，数据湖和数据仓库的演化路径是什么？
一次真实的hiring manager对话揭示了很多团队的误区：“我们去年花了六个月把所有数据搬进了湖，结果发现查询变慢了，又花了三个月搬回仓库。” 这说明单纯地把技术选型当作一次性决定是危险的。成熟的演化路径应该是：第一阶段，数据湖作为原始数据的归档层，所有埋点、日志、第三方 API 响应原封不动地落地到对象存储，保留全量历史；第二阶段，在湖上构建可查询的视图层，使用开放表格式（Iceberg/Delta）和元数据服务（Glue、Hive Metastore）让数据科学家能够通过SQL或DataFrame直接探索；第三阶段，根据查询频率和成本做热数据下沉，将被频繁访问的维度事实表通过增量批处理或流式作业写入仓库或列式存储，以获得毫秒级延迟；
第四阶段，引入数据目录和治理工具，对湖和仓库中的数据统一进行分类、标签、访问控制和质量监控，确保无论数据在哪个层次，都能被正确发现和使用。面试官会问：“如果你只能在简历上写一项你在湖仓演化中的贡献，你会写什么？” 高分答案会具体说：“我主导了从原始 Kafka 日志到 S3 Iceberg Lake 的迁移，设计了增量压缩和分区策略，使得存储成本下降 40%；随后我设计了 dbtd 模型，将每日聚合的用户维度表写入 Snowflake，使得仓库查询延迟从平均 12 秒降到 1.8 秒，直接支持了每日营销看板的实时刷新。” 这种回答展示了不是仅仅“用了湖或者用了仓库”，而是在不同阶段根据业务价值和成本做了有据可循的迁移。
准备清单
- 明确业务目标和数据特征：写下你将要服务的具体场景（如实时推荐、离线报表、特征实验），列出数据的格式、更新频率、查询延迟容忍度和治理需求。
- 画出数据流图：从数据产生（Kafka、业务库）到存储（湖或仓库）再到消费（BI、ML、API），标注每一步的延迟和成本估算。
- 熟悉两种典型架构的技术栈：数据湖方面掌握S3/ADLS+开放格式（Iceberg、Delta Lake、Parquet）+查询引擎（Presto、Trino、Spark SQL）；数据仓库方面掌握Snowflake、BigQuery、Redshift或ClickHouse的基本概念和定价模型。
- 练习说出“不是A，而是B”的思考模式：在每个设计决策前先说出错误的假设，再说明为什么正确的选择更符合业务。例如，“不是说所有数据都要放进湖才能省钱，而是根据访问热度把热数据下沉到仓库以换取查询性能”。
- 进行模拟面试并录制：找朋友或用平台模拟系统设计题，练习在10分钟内讲清湖仓选型、分层方案和演化路径，注意使用具体数字（如存储成本下降30%、查询延迟提升5倍）。
- 阅读一篇实际的湖仓迁移案例：比如Airbnb从Hive迁移到Iceberg的博客，或者Netflix如何在湖上构建特征平台。
- 系统性拆解面试结构（PM面试手册里有完整的[系统设计]实战复盘可以参考）：手册中提供了STAR框架的变体，帮助你在回答中穿插情境、任务、行动、结果，确保每个技术点都落地到业务影响上。
常见错误
错误一：把数据湖和数据仓库当作非此即彼的选择
BAD：面试者说：“我们公司现在用的是数据仓库，如果要做机器学习就必须全部迁移到数据湖，否则跑不通。”
GOOD：面试者说：“不是说机器学习必须依赖数据湖才能进行，而是可以在湖中保留原始特征实验数据，同时把经过验证的特征物化到仓库或特征存储中供在线模型使用，这样既保证了实验的灵活性，又保证了线上服务的延迟。”
错误二：只关注技术细节而忽略成本和治理
BAD：候选人滔滔不绝地讲S3分区策略、Parquet压缩算法和Spark调参，却没提一下存储费用或数据目录的重要性。
GOOD：候选人说：“不是说我们只要选了最新的开源格式就能解决所有问题，而是要在这些技术选型之外做成本模型（存储+计算）和治理检查（Schema演化、访问控制、数据质量监控），否则即使技术先进也可能导致预算超支和数据混乱。”
错误三：认为湖仓演化是一次性搬家
BAD：候选人描述了一个“大爆炸”式的计划：“下个月我们把所有数据从仓库搬到湖，完成后就不再用仓库了。”
GOOD：候选人说：“不是说我们要一次性把所有数据搬进湖或者搬出湖，而是要按照数据的访问热度和业务价值进行分层下沉：冷数据留在湖做归档和探索，热数据下沉到仓库或列式存储以保证查询性能，中等热度的数据可以采用混合访问路径，这样演化才是可持续且风险可控的。”
FAQ
问：在面试中如果被问到‘你更偏好数据湖还是数据仓库’，应该怎么回答才能不掉进陷阱？
答：面试官其实想考察你是否能够根据场景做出判断，而不是看你个人的偏好。正确的回答是先说明没有绝对的偏好，然后给出两个具体的场景来说明各自的优势：例如，“不是说我更偏好数据湖，而是在需要探索和原始特征实验我会优先选择湖，因为它能接受半结构化数据且存储成本低；相反，如果是每日定时的销售报表和高并发的用户标签查询，我会选择数据仓库，因为它提供秒级响应和成熟的治理功能。
” 接着可以补充自己在过去项目中如何根据数据访问热度进行分层，比如把湖中的聚合结果定期写入仓库，以兼顾两者的好处。这样回答既展示了技术理解，又体现了产品思维。
问：如果公司现在只有传统的数据仓库，我想引入数据湖，应该从哪里开始着手，怎样避免常见的阻力？
答：引入数据湖不是一次性替换，而是先做低风险的试点。第一步是确定一类低价值、高原始性的数据，比如调试日志或未经聚合的埋点，直接写入对象存储（S3）并保留原始格式。第二步是在这些数据上建立一个简单的目录（如AWS Glue Catalog），让数据科学家可以用熟悉的SQL或Spark去探索，这时候不需要改动现有的ETL链条。
第三步是向领导展示这个试点带来的收益：存储成本降低了多少（可以用实际的账单数据），探索的迭代速度提升了多少（比如特征实验从两周缩短到三天）。这样就把讨论从‘要不要换’转化为了‘试点带来了什么具体价值’，从而降低了因‘大换血’引起的组织阻力。
问：在系统设计题里，如果时间只剩下五分钟，我应该重点讲哪些内容才能让面试官觉得我的答案完整？
答：当时间紧张时，抓住面试官评估的三个维度：业务匹配度、技术可行性和演化路径。你可以用一句话概括业务场景（“我们需要支持实时特征更新和离线特征回填”），然后给出一个两层的架构图描述（“底层数据湖保存原始事件，中间通过Flink做增量聚合，顶层仓库提供聚合表供BI查询”），最后加一句演化说明（“随着查询频率提升，我们会把热度最高的维度表下沉到仓库，冷数据继续留在湖做归档”）。
这样即使没有详细展开每个组件的参数，也已经展示了你不仅知道湖和仓库是什么，更知道如何根据业务价值做出分层决策，并能说清楚后续如何演化。这种回答方式往往比堆砌技术细节更能得到高分。
（全文约4400字）
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。