Microsoft Fabric 决策指南:选择数据存储

使用此引用指南和示例方案可以帮助为 Microsoft Fabric 工作负载选择数据存储。

数据存储属性

数据仓库 Lakehouse Power BI 数据市场 KQL 数据库 (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、动态数据掩码 行级别、表级别(使用 T-SQL)、对于 Spark 无 内置 RLS 编辑器 行级安全性
通过快捷方式访问数据 是(间接通过湖屋) No
可以是快捷方式的源 是(表) 是(文件和表)
跨项查询 是,跨湖屋表和仓库表进行查询 是,跨湖屋表和仓库表进行查询;跨湖屋查询(包括使用 Spark 的快捷方式) 是,使用快捷方式跨 KQL 数据库、湖屋和仓库进行查询
高级分析 时序本机元素、完整的地理空间存储和查询功能
高级格式设置 为自由文本和半结构化数据(如 JSON)编制完整索引
引入延迟 排队引入、具有几秒钟延迟的流式引入

注意

Eventhouse 是用于多个 KQL 数据库的工作区。 KQL 数据库已正式发布,而 Eventhouse 还处于预览版阶段。 有关详细信息,请参阅 Eventhouse 概述(预览)

方案

查看这些方案,以帮助选择 Fabric 中的数据存储。

方案 1

Susan 是一名专业开发人员,不熟悉 Microsoft Fabric。 他们已准备好开始清理、建模和分析数据,但需要决定是构建数据仓库还是湖屋。 在查看上表中的详细信息后,主要决策点在于可用的技能集和对多表事务的需求。

Susan 在基于关系数据库引擎构建数据仓库方面拥有多年的经验,并且熟悉 SQL 语法和功能。 考虑到更大的团队,此数据的主要使用者也对 SQL 和 SQL 分析工具比较熟悉。 Susan 决定使用数据仓库,该方案使团队能够主要使用 T-SQL 进行交互,同时允许组织中的任何 Spark 用户访问数据。

方案 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 决定使用 KQL 数据库,因为它具有可伸缩性、快速响应时间、高级分析功能(包括时序分析、地理空间函数和 Power BI 中的快速直接查询模式)。 可以使用 Power BI 和 KQL 执行查询,以比较当前和以前的时间段、快速识别新出现的问题或提供陆运和海运路线的地理空间分析。