在 Fabric 中选择 Lakehouse 还是 Warehouse？
发布: (2026年2月22日 GMT+8 01:03)
11 分钟阅读
原文: Dev.to
Source: Dev.to
请提供您希望翻译的文章正文（除代码块和 URL 之外的内容），我将把它翻译成简体中文并保持原有的 Markdown 格式。谢谢！
Source: …
核心概念
Data Warehouse
一个集中式仓库，用于存储来自多个来源的 已清洗、集成、结构化的数据，采用 schema‑on‑write，并针对 SQL 分析和 BI 进行优化。
- 强调高数据质量、统一维度、历史追踪以及严格治理。
- 通常使用 ETL 或 ELT 流程在 加载前 对数据进行转换。
Data Lakehouse
一种在 数据湖（对象存储）之上构建的架构，但加入了 仓库级功能——ACID 事务、模式强制、索引以及基于 Delta、Iceberg 或 Hudi 等开放表格式的 SQL 查询性能。
- 支持 结构化、半结构化和非结构化 数据在同一平台上共存。
- 实现 BI 与 AI/ML 工作负载的统一，无需分别部署湖 + 仓库堆栈。
架构差异
存储与模式
| 数据仓库 | 湖仓 | |
|---|---|---|
| 存储模型 | 关系结构（表、列、索引），采用 schema‑on‑write。在存储之前，数据会符合固定模式。 | 对象存储上的开放格式（例如 Parquet + Delta/Iceberg/Hudi），同时支持 schema‑on‑write 与 schema‑on‑read。 |
| 摄取 | 通常加载已清洗的结构化数据。 | 可以摄取原始文件（CSV、JSON、图像、日志），随后在其上添加模式/表定义。 |
计算与查询引擎
| 数据仓库 | 湖仓 | |
|---|---|---|
| 引擎 | 紧密集成的 SQL 引擎，针对分析工作负载进行优化（列式存储、向量化执行、基于成本的优化器）。 | 多种引擎可在相同数据上运行：Spark、专用 SQL 引擎、机器学习框架、流处理引擎。 |
| 访问模式 | 单一的“数据仓库引擎”入口点（即使在云端计算/存储逻辑上分离）。 | 同一 Delta/Iceberg 表既可被 BI 工具查询 也 可直接用于机器学习或流式管道。 |
数据类型与工作负载
| 数据仓库 | 湖仓 | |
|---|---|---|
| 主要数据 | 来自 OLTP 系统、ERP/CRM 等的结构化关系数据。 | 结构化、半结构化（JSON、日志）以及非结构化（图像、音频、文档）数据。 |
| 典型工作负载 | BI、仪表盘、监管/财务报告、临时 SQL 分析。 | 混合工作负载：BI、数据科学、机器学习特征工程、实时/流式、高级分析。 |
治理与可靠性
| 数据仓库 | 湖仓 | |
|---|---|---|
| 治理 | 强大且集中的治理，具备 RBAC、固定模式、数据质量规则以及平台内置的血缘追踪。 | 使用事务性表格式（如 Delta）为湖数据提供 ACID 保证和时光旅行功能。治理比原始湖更丰富，但比传统仓库更复杂。 |
| 可靠性 | ACID 事务和严格约束是标准——适用于金融/监管报告。 | 通过表格式提供 ACID 保证；可靠性取决于目录、元数据服务和治理工具的正确配置。 |
性能与成本
| 数据仓库 | 湖仓 | |
|---|---|---|
| 性能 | 对星型/雪花型模式、聚合、连接高度优化；对 BI 非常可预测。 | 利用廉价对象存储并实现计算与存储解耦。查询性能可非常出色，但可能需要细致调优（分区、Z‑ordering、缓存）。 |
| 成本模型 | 由于结构化存储和前置 ETL/ELT，通常 每 TB 更昂贵，但对纯 BI 工作负载，总成本可能更低。 | 更廉价的存储 在 PB 规模；计算独立，可按需扩展。运维成本转向工程优化工作。 |
对比表
| 方面 | 数据仓库 | 湖仓 |
|---|---|---|
| 主要数据类型 | 结构化 | 结构化 + 半结构化 + 非结构化 |
| 模式策略 | 写时模式 | 写时模式 与 读时模式 的混合 |
| 存储 | 关系型数据仓库引擎 | 对象存储上的开放格式（Delta/Iceberg/Hudi） |
| 工作负载 | 商业智能、报表、SQL 分析 | 商业智能 + 机器学习/人工智能 + 流式处理 + 探索 |
| 治理 | 强大、集中、刚性 | 强大但更复杂；需要精心设计 |
| 性能 | 对 SQL/星型模式 非常强 | 强大但需要更多调优；多引擎 |
| 成本模型 | 每 TB 成本更高；ETL 成本 | 存储更便宜；ELT 灵活；运维成本转移 |
| 团队关注点 | 商业智能开发者、SQL、数据建模 | 数据工程师、机器学习、混合 SQL + Spark/ML 技能 |
实践中的优缺点
数据仓库 – 优势与劣势
优势
- 对 企业级 BI 和报表 提供非常强大的支持，尤其是统一维度和一致指标。
- 可预测的 查询性能和 SLA，适合高管和运营仪表盘。
- 成熟的 治理、血缘、权限、安全 以及变更控制工具。
劣势
- 不太适合大规模原始/半结构化数据（IoT 日志、点击流等）。
- ETL/ELT 流程必须进行大量前期建模，导致新数据源的接入变慢。
- 对于重度 ML/AI 工作流不够自然，数据往往需要导出到其他系统。
数据湖仓（Lakehouse） – 优势与劣势
优势
- 单一平台 兼容所有数据类型和工作负载，减少湖（用于数据科学）和仓（用于 BI）之间的重复。
- 对 AI/ML 流程 和特征工程提供良好支持，直接在同一套数据上进行 BI。
- 规模化成本效益高，原始数据和已加工数据均存放在廉价的云对象存储中。
劣势
- 运维复杂度高：部件更多（Spark、SQL 引擎、目录、治理服务）。
- 对传统星型模型 BI 的查询性能可能需要比专用仓库更多的调优。
- 需要更强的 数据工程和平台技能，尤其是表格式、分区和治理方面。
何时选择哪种
当适合选择数据仓库时
- 主要工作负载是 经典商业智能和结构化数据的报告（ERP/CRM、财务系统）。
- 您需要 可预测的性能、严格的服务水平协议（SLA）以及强大的治理 来满足监管报告的要求。
- 您的团队专注于 SQL、数据建模和仪表板开发，而不是繁重的数据工程管道。
当适合选择湖仓时
- 您需要在单一平台上处理 结构化、半结构化和非结构化数据。
- 您的组织运行 混合工作负载（BI、数据科学、机器学习、流处理），受益于共享存储。
- 成本效益高的 PB 级存储以及 灵活的 ELT 管道是优先考虑的。
- 您拥有（或计划培养） 数据工程专业知识，以管理表格格式、分区和多引擎治理。
何时更适合使用数据仓库
- 稳定、定义明确的模式（例如，财务、人力资源、会员），结构可预测。
- 监管或财务控制需要对经过策划、变化缓慢的模式拥有高度信任。
- 团队主要是 SQL / BI 导向，交付稳定仪表盘的速度比实验灵活性更重要。
何时更适合使用 Lakehouse
- 您需要在管理关系型数据的同时处理 多样化的数据类型（日志、事件、文档、半结构化的 API 负载）。
- 除了商业智能（BI），还需要强烈关注 数据科学、机器学习（ML）和流式分析。
- 平台必须能够扩展到极大规模（多 TB / PB），同时保持存储成本低廉。
混合/统一架构
大多数现代模式推荐 混合方法：
- 使用 lakehouse（或湖泊 + lakehouse）来处理 原始层和增强层 以及机器学习/实验。
- 为 “单一真实来源” 的商业智能和合规报告提供 curated warehouse（或类似金层的仓库）。
Lakehouse 通常被描述为在仓库和湖泊之后的 “第三代”，它结合了许多优势，同时在某些场景下仍然为专用仓库留有空间。
在 Microsoft Fabric 中，这一模式表现为 以湖为中心的仓库模型：统一的 Delta 存储，Lakehouse 用于原始/工程层，Warehouse 用于面向 BI 的模型，全部在同一平台上。