Microsoft Fabric 决策指南：选择数据存储
使用此引用指南和示例方案可以帮助为 Microsoft Fabric 工作负载选择数据存储。
数据存储属性
使用此信息并根据数据量、类型、开发人员角色、技能集、操作和其他功能来比较 Fabric 数据存储，例如仓库、湖屋、Eventhouse、SQL 数据库和 Power BI 数据市场。 这些比较内容被整理为以下两个表：
| Lakehouse | 仓库 | Eventhouse | |
|---|---|---|---|
| 数据量 | 无限制 | 无限制 | 无限制 |
| 数据类型 | 非结构化、 半结构化、 结构化 |
结构化 | 非结构化、 半结构化、 结构化 |
| 主要开发人员角色 | 数据工程、数据科学家 | 数据仓库开发人员、数据架构师、数据库开发人员 | 应用开发人员、数据科学家、数据工程师 |
| 主要开发技能 | Spark（Scala、PySpark、Spark SQL、R） | SQL | 无代码、KQL、SQL |
| 数据组织依据 | 文件夹和文件、数据库和表 | 数据库、架构和表 | 数据库、架构和表 |
| 读取操作 | Spark、T-SQL | T-SQL、Spark* | KQL、T-SQL、Spark |
| 写入操作 | Spark（Scala、PySpark、Spark SQL、R） | T-SQL | KQL、Spark、连接器生态系统 |
| 多表事务 | 否 | 是 | 是，用于多表引入 |
| 主要开发接口 | Spark 笔记本、Spark 作业定义 | SQL 脚本 | KQL 查询集，KQL 数据库 |
| 安全性 | RLS、CLS**、表级别 (T-SQL)，对于 Spark，无 | 对象级别、RLS、CLS、DDL/DML、动态数据掩码 | RLS |
| 通过快捷方式访问数据 | 是 | 是 | 是 |
| 可以是快捷方式的源 | 是（文件和表） | 是（表） | 是 |
| 跨项查询 | 是 | 是 | 是 |
| 高级分析 | 用于大规模数据处理的接口、内置数据并行和容错 | 用于大规模数据处理的接口、内置数据并行和容错 | 时序本机元素、完整的地理空间和查询功能 |
| 高级格式设置 | 使用 PARQUET、CSV、AVRO、JSON 和任何 Apache Hive 兼容文件格式定义的表 | 使用 PARQUET、CSV、AVRO、JSON 和任何 Apache Hive 兼容文件格式定义的表 | 为自由文本和半结构化数据（如 JSON）编制完整索引 |
| 引入延迟 | 可立即用于查询 | 可立即用于查询 | 排队引入、具有几秒钟延迟的流式引入 |
* Spark 支持使用快捷方式从表中进行读取，但尚不支持访问视图、存储过程、函数等。
| Fabric SQL 数据库 | Power BI 数据市场 | |
|---|---|---|
| 数据量 | 4 TB | 最大 100 GB |
| 数据类型 | 结构化、 半结构化、 无结构的 |
结构化 |
| 主要开发人员角色 | AI 开发人员、应用开发人员、数据库开发人员、数据库管理员 | 数据科学家、数据分析师 |
| 主要开发技能 | SQL | 无代码、SQL |
| 数据组织依据 | 数据库、架构、表 | 数据库、表、查询 |
| 读取操作 | T-SQL | Spark、T-SQL |
| 写入操作 | T-SQL | 数据流、T-SQL |
| 多表事务 | 是，完全 ACID 合规性 | 否 |
| 主要开发接口 | SQL 脚本 | Power BI |
| 安全性 | 对象级别、RLS、CLS、DDL/DML、动态数据掩码 | 内置 RLS 编辑器 |
| 通过快捷方式访问数据 | 是 | 否 |
| 可以是快捷方式的源 | 是（表） | 否 |
| 跨项查询 | 是 | 否 |
| 高级分析 | T-SQL 分析功能、复制到 OneLake 中的 delta parquet 以进行分析的数据 | 用于通过自动性能优化实现数据处理的接口 |
| 高级格式设置 | 对 OLTP、JSON、矢量、图形、XML、空间、键值的表支持 | 使用 PARQUET、CSV、AVRO、JSON 和任何 Apache Hive 兼容文件格式定义的表 |
| 引入延迟 | 可立即用于查询 | 可立即用于查询 |
** 使用 T-SQL 通过 SQL 分析终结点在湖屋上提供的列级安全性。
方案
查看这些方案，以帮助选择 Fabric 中的数据存储。
方案 1
Susan 是一名专业开发人员，不熟悉 Microsoft Fabric。 他们已准备好开始清理、建模和分析数据，但需要决定是构建数据仓库还是湖屋。 在查看上表中的详细信息后，主要决策点在于可用的技能集和对多表事务的需求。
Susan 在基于关系数据库引擎构建数据仓库方面拥有多年的经验，并且熟悉 SQL 语法和功能。 考虑到更大的团队，此数据的主要使用者也对 SQL 和 SQL 分析工具比较熟悉。 Susan 决定使用 Fabric 仓库，该方案使团队能够主要使用 T-SQL 进行交互，同时允许组织中的任何 Spark 用户访问数据。
Susan 创建新的湖屋，并通过湖屋 SQL 分析终结点访问数据仓库功能。 使用 Fabric 门户创建外部数据表的快捷方式，并将其放在 /Tables 文件夹中。 Susan 现在可以编写 T-SQL 查询，这些查询引用了在湖屋中查询 Delta Lake 数据的快捷方式。 快捷方式自动显示为 SQL 分析终结点中的表，并且可以使用三部分名称通过 T-SQL 查询。
方案 2
Rob 是一名数据工程师，需要在 Fabric 中存储和建模几 TB 的数据。 该团队混合了 PySpark 和 T-SQL 技能。 大多数运行 T-SQL 查询的团队都是使用者，因此不需要编写 INSERT、UPDATE 或 DELETE 语句。 其余开发人员可以使用笔记本轻松工作，并且由于数据存储在 Delta 中，因此他们能够使用类似的 SQL 语法进行交互。
Rob 决定使用湖屋，该方案使数据工程团队能够对数据使用多样化的技能，同时允许 T-SQL 技术娴熟的团队成员使用数据。
方案 3
Ash 是一位平民开发者，是 Power BI 开发人员。 他们熟悉 Excel、Power BI 和 Office， 需要为业务部门构建数据产品。 他们知道自己在构建数据仓库或湖屋方面的技能不足，这些技能对他们的需求和数据量来说似乎有些大材小用。 他们查看了上表中的详细信息，发现主要决策点在于他们自己的技能和自助服务需求、无代码功能以及低于 100 GB 的数据量。
Ash 与熟悉 Power BI 和 Microsoft Office 的业务分析师合作，并知道他们已有高级容量订阅。 考虑到更大的团队，他们意识到，此数据的主要使用者可能是熟悉无代码和 SQL 分析工具的分析师。 Ash 决定使用 Power BI 数据市场，该方案允许团队使用无代码体验快速交互生成功能。 可以通过 Power BI 和 T-SQL 执行查询，同时允许组织中的任何 Spark 用户访问数据。
方案 4
Daisy 是一名业务分析师，具有使用 Power BI 分析大型全球零售链供应链瓶颈的经验。 他们需要构建一个可缩放的数据解决方案，该解决方案需要能够处理数十亿行数据，并可用于生成仪表板和报表，以便做出业务决策。 数据来自工厂、供应商、发运方和其他来源，采用各种结构化、半结构化和非结构化格式。
Daisy 决定使用 Eventhouse，因为它具有可伸缩性、快速响应时间、高级分析功能（包括时序分析、地理空间函数和 Power BI 中的快速直接查询模式）。 可以使用 Power BI 和 KQL 执行查询，以比较当前和以前的时间段、快速识别新出现的问题或提供陆运和海运路线的地理空间分析。
方案 5
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 数据库。