通过

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

  • 项目

使用此参考指南和示例方案来帮助为 Microsoft Fabric 工作负荷选择数据存储。

数据存储属性

使用此信息可以根据数据量、类型、开发人员角色、技能集、操作和其他功能来比较 Fabric 数据存储，例如仓库、Lakehouse、Eventhouse、SQL 数据库和 Power BI Datamart。 这些比较分为以下两个表：

表 1/2 Lakehouse 仓库 Eventhouse
数据卷 无限制 无限制 无限制
数据类型 非结构化
半结构化、
结构化		 结构化、
半结构化 （JSON）		 非结构化、
半结构化、
结构化
主要开发人员角色 数据工程师，数据科学家 数据仓库开发人员， 数据架构师， 数据工程师， 数据库开发人员 应用开发人员、数据科学家、数据工程师
主要开发技能 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
通过快捷方式 访问数据 是的 是的，通过 SQL 分析端点 是的
可以是快捷方式的源 是（文件和表） 是（表） 是的
跨项查询 是的 是的 是的
高级分析 用于大规模数据处理、内置数据并行度和容错的接口 用于大规模数据处理、内置数据并行度和容错的接口 时序原生元素、完整的地理空间和查询功能
高级格式设置支持 使用 PARQUET、CSV、AVRO、JSON 和任何 Apache Hive 兼容的文件格式定义的表 使用 PARQUET、CSV、AVRO、JSON 和任何 Apache Hive 兼容的文件格式定义的表 用于自由文本和半结构化数据（如 JSON）的完整索引
引入延迟 立即可用于查询 立即可用于查询 排队式数据引入和流式数据引入具有几秒钟的延迟。

* Spark 支持使用快捷方式从表读取，尚不支持访问视图、存储过程、函数等。

表 2/2 Fabric SQL 数据库 Power BI Datamart
数据卷 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 创建新的数据仓库，并使用 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

Ash 是公民开发人员，是 Power BI 开发人员。 他们熟悉 Excel、Power BI 和 Office。 他们需要为业务部门构建数据产品。 他们知道，他们不太具备构建数据仓库或湖屋的技能，而且这些技能似乎太多，无法满足需求和数据量。 他们查看上表中的详细信息，并查看主要决策点是自己的技能，以及对自助服务的需求、无代码功能和数据量低于 100 GB。

Ash 与熟悉 Power BI 和 Microsoft Office 的业务分析师合作，并知道他们已有高级容量订阅。 在考虑更大的团队时，他们意识到此数据的主要使用者是分析师，熟悉无代码和 SQL 分析工具。 Ash 决定使用 Power BI datamart，这样团队就可以使用无代码体验快速交互构建功能。 可以通过 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 数据库。

相关内容