Microsoft Fabric 决策指南:选择数据存储
使用此引用指南和示例方案可以帮助为 Microsoft Fabric 工作负载选择数据存储。
数据存储属性
此表基于数据量、类型、开发人员角色、技能集、操作来比较数据仓库、湖屋、Power BI 数据市场和 Eventhouse 等数据存储。 以及其他功能。
仓库 | Lakehouse | Power BI 数据市场 | Eventhouse | |
---|---|---|---|---|
数据量 | 无限制 | 无限制 | 最大 100 GB | 无限制 |
数据类型 | 结构化 | 非结构化、半结构化和结构化 | 结构化 | 非结构化、半结构化和结构化 |
主要开发人员角色 | 数据仓库开发人员、SQL 工程师 | 数据工程、数据科学家 | 平民开发者 | 平民数据科学家、数据工程师、数据科学家、SQL 工程师 |
主要开发人员技能集 | SQL | Spark(Scala、PySpark、Spark SQL、R) | 无代码、SQL | 无代码、KQL、SQL |
数据组织依据 | 数据库、架构和表 | 文件夹和文件、数据库和表 | 数据库、表、查询 | 数据库、架构和表 |
读取操作 | T-SQL、Spark(支持使用快捷方式从表读取,尚不支持访问视图、存储过程、函数等功能) | Spark、T-SQL | Spark、T-SQL、Power BI | KQL、T-SQL、Spark, Power BI |
写入操作 | T-SQL | Spark(Scala、PySpark、Spark SQL、R) | 数据流、T-SQL | KQL、Spark、连接器生态系统 |
多表事务 | 是 | 否 | 否 | 是,用于多表引入。 请参阅更新策略。 |
主要开发接口 | SQL 脚本 | Spark 笔记本、Spark 作业定义 | Power BI | KQL 查询集,KQL 数据库 |
安全性 | 对象级别(表、视图、函数、存储过程等)、列级别、行级别、DDL/DML、动态数据掩码 | 行级别、列级别(对于通过 SQL 分析终结点访问的湖屋)、表级别(使用 T-SQL 时),无(用于 Spark) | 内置 RLS 编辑器 | 行级安全性 |
通过快捷方式访问数据 | 是的,通过湖屋使用三部分名称 | 是 | No | 是 |
可以是快捷方式的源 | 是(表) | 是(文件和表) | 否 | 是 |
跨项查询 | 是,跨湖屋表和仓库表进行查询 | 是,跨湖屋表和仓库表进行查询;跨湖屋查询(包括使用 Spark 的快捷方式) | 否 | 是,使用快捷方式跨 KQL 数据库、湖屋和仓库进行查询 |
方案
查看这些方案,以帮助选择 Fabric 中的数据存储。
方案 1
Susan 是一名专业开发人员,不熟悉 Microsoft Fabric。 他们已准备好开始清理、建模和分析数据,但需要决定是构建数据仓库还是湖屋。 在查看上表中的详细信息后,主要决策点在于可用的技能集和对多表事务的需求。
Susan 在基于关系数据库引擎构建数据仓库方面拥有多年的经验,并且熟悉 SQL 语法和功能。 考虑到更大的团队,此数据的主要使用者也对 SQL 和 SQL 分析工具比较熟悉。 Susan 决定使用数据仓库,该方案使团队能够主要使用 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 执行查询,以比较当前和以前的时间段、快速识别新出现的问题或提供陆运和海运路线的地理空间分析。