使用此参考指南和示例方案可帮助你为 Microsoft Fabric 工作负载选择数据存储，这些数据存储都在 OneLake 的统一存储中提供。
| 理想的用例 | Microsoft Fabric 工作负荷 | 默认情况下，OneLake 中的数据以开放表格式提供 |
|---|---|---|
| 流式处理事件数据、高粒度（以时间、空间、详细信息 - JSON/文本）活动数据进行交互式分析 | Eventhouse | 是的 |
| AI、NoSQL 和矢量搜索 | Fabric 中的 Cosmos DB （预览版） | 是的 |
| 作事务数据库，OLTP 数据库 | Fabric 中的 SQL 数据库 （预览版） | 是的 |
| 企业数据仓库、基于 SQL 的 BI、OLAP、 完整的 SQL 事务支持 | 数据仓库 | 是的 |
| 大数据和机器学习、非/半结构化数据、 数据工程 | Lakehouse | 是的 |
角色和技能集
| Microsoft Fabric 工作负荷 | 主要开发人员角色 | 主要技能集，工具 | 主要语言 |
|---|---|---|---|
| Eventhouse | 应用开发人员、数据科学家、数据工程师 | 无代码，KQL，SQL | KQL （Kusto 查询语言）、T-SQL |
| Fabric 中的 Cosmos DB （预览版） | AI 开发人员、应用开发人员 | NoSQL 概念、REST API，类似于 Azure Cosmos DB | 通过 JavaScript/TypeScript、Python、C#、Java 等实现 REST API 集成 |
| Fabric 中的 SQL 数据库 （预览版） | AI 开发人员， 应用开发人员， 数据库开发人员， 数据库管理员 | 数据库管理和开发，类似于 Azure SQL 数据库、SSMS、VS Code 和与 SQL Server 兼容的查询工具 | T-SQL |
| Fabric 数据仓库 | 数据仓库开发人员，数据架构师，数据工程师，数据库开发人员 | 数据仓库概念、 星型架构数据库设计、SSMS、VS Code 和 SQL Server 兼容的查询工具 | T-SQL，无代码 |
| Lakehouse | 数据工程师，数据科学家 | PySpark、Delta Lake、笔记本 | Spark （Scala、PySpark、Spark SQL、R） |
方案
查看这些方案，获取有关在 Fabric 中选择数据存储的帮助。
方案 1
专业开发人员 Susan 是Microsoft Fabric 的新人。 他们已经准备好开始清理、建模和分析数据，但需要决定是构建数据仓库还是湖仓。 在查看上表中的详细信息后，主要决策点在于可用的技能集和对多表事务的需求。
Susan 多年来一直在关系数据库引擎上构建数据仓库，并且熟悉 SQL 语法和功能。 考虑到更大的团队，此数据的主要用户也具备 SQL 和 SQL 分析工具的使用能力。 Susan 决定使用 Fabric 仓库，这允许团队主要与 T-SQL 交互，同时允许组织中的任何 Spark 用户访问数据。
Susan 创建新的数据仓库，并使用 T-SQL 与其交互，就像她其他 SQL Server 数据库一样。 她为在 SQL Server 上生成仓库而编写的大多数现有 T-SQL 代码都将在 Fabric 数据仓库上工作，以便轻松转换。 如果她选择，她甚至可以使用相同的工具来处理其他数据库，如 SQL Server Management Studio。 利用 Fabric 门户中的 SQL 编辑器，Susan 和其他团队成员只需使用由三个部分组成的名称执行跨数据库查询，就能编写引用其他数据仓库和湖屋中 Delta 表的分析查询。
方案 2
数据工程师 Rob 需要在 Fabric 中存储和建模几 TB 数据。 该团队混合了 PySpark 和 T-SQL 技能。 运行 T-SQL 查询的大多数团队都是使用者，因此不需要编写 INSERT、UPDATE 或 DELETE 语句。 其余开发人员在笔记本中工作很自在，由于数据存储在 Delta 中，因此他们能够与类似的 SQL 语法进行交互。
Rob 决定使用湖屋，该方案使数据工程团队能够对数据使用多样化的技能，同时允许 T-SQL 技术娴熟的团队成员使用数据。
方案 3
Daisy 是业务分析师，使用 Power BI 分析大型全球零售连锁店的供应链瓶颈。 他们需要构建可缩放的数据解决方案，该解决方案可以处理数十亿行数据，并可用于生成可用于做出业务决策的仪表板和报表。 这些数据来自各种结构化、半结构化和非结构化格式的工厂、供应商、发货人和其他来源。
Daisy 决定使用 Eventhouse，因为它的可伸缩性、快速响应时间、高级分析功能（包括时序分析、地理空间函数和 Power BI 中的快速直接查询模式）。 可以使用 Power BI 和 KQL 执行查询，以便在当前和以前的时间段之间进行比较、快速识别新兴问题或提供陆地和海上路线的地理空间分析。
方案 4
Kirby 是一位应用程序架构师，擅长开发 .NET 应用程序以用于运营数据。 它们需要具有完整 ACID 事务合规性的高并发数据库，并强制实施外键实现关系完整性。 Kirby 希望利用自动性能优化带来的好处来简化日常数据库管理。
Kirby 决定使用 Fabric SQL 数据库，并使用与 Azure SQL 数据库相同的 SQL 数据库引擎。 Fabric 中的 SQL 数据库会自动缩放以满足整个工作日的需求。 它们具有事务表的完整功能，并且通过它们可灵活地处理从可序列化到读取提交的快照的各个事物隔离级别。 Fabric 中的 SQL 数据库根据一段时间内观察到的执行计划的强信号自动创建和删除非聚集索引。
在 Kirby 的方案中，操作应用程序中的数据必须与 Fabric 中的其他数据联接：在 Spark 中、仓库中，以及来自 Eventhouse 中的实时事件。 每个 Fabric 数据库都包含一个 SQL 分析终结点，因此使用 DirectLake 模式通过 Spark 或 Power BI 查询实时访问数据。 这些报告解决方案使主操作数据库避免承受分析工作负载的开销，并防止数据非规范化。 Kirby 还具有其他 SQL 数据库中的现有操作数据，并且无需转换即可导入该数据。 若要在不进行任何数据类型转换的情况下导入现有作数据，Kirby 设计了包含 Fabric 数据工厂的管道，以将数据导入 Fabric SQL 数据库。