通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

使用 Microsoft Fabric 设计企业 BI 解决方案

Microsoft Fabric
Azure Blob 存储
Microsoft Entra ID
Power BI

本文介绍如何将数据从本地数据仓库传输到云环境，然后使用商业智能（BI）模型为数据提供服务。 可以将此方法用作最终目标，或作为使用基于云的组件实现全面现代化的第一步。

本指南基于 Microsoft Fabric 端到端方案。 有多种选项可用于从本地 SQL 服务器提取数据，例如 Fabric 数据工厂管道、镜像、复制任务，以及用于 SQL 的 Fabric 实时事件流更改数据捕获 (CDC)。 提取后，数据将转换以供分析。

Architecture

显示使用 Fabric 的企业 BI 体系结构的示意图。

下载此体系结构的 Visio 文件 。

Workflow

以下工作流对应于上图。

数据源

  • Azure 中的 SQL Server 数据库包含源数据。 若要模拟本地环境，此方案的部署脚本将配置 Azure SQL 数据库。 AdventureWorks 示例数据库用作源数据架构和示例数据。 有关详细信息，请参阅 从 SQL Server复制和转换数据。

引入和数据存储

  • Fabric OneLake 是整个组织的单个统一逻辑数据湖。 此 SaaS 提供各种数据存储选项，例如用于数据工程 Lakehouse 工作负荷的 Fabric Lakehouse 、用于数据仓库工作负荷的 Fabric Warehouse ，以及用于大容量时序和日志数据集的 Fabric Eventhouse 。

  • 结构数据工厂管道 允许生成复杂的提取、转换、加载（ETL）和数据工厂工作流，这些工作流可以大规模执行许多不同的任务。 控制流功能内置于数据管道中，可用于生成提供循环和条件的工作流逻辑。 在此体系结构中，元数据驱动的框架可以大规模地增量引入多个表。

  • Fabric Data Factory镜像 允许您避免复杂的 ETL 进程，并将现有的 SQL Server 环境与 Fabric 中的其余数据集成。 可以直接将现有的 SQL Server 数据库复制到 Fabric OneLake。 利用 Fabric 数据工厂 的复制作业，可以轻松地将数据从源移动到目标，而无需使用管道。 可以通过批处理和增量复制的内置模式配置数据传输，并支持可缩放的性能。

  • Fabric 事件流 使用 CDC 提取法从虚拟机（VM）上托管的 SQL Server 数据库中实现高吞吐量的实时数据引入。 此模式适用于需要实时仪表板和警报的用例。

分析和报告

Components

  • Azure SQL 数据库 是 Azure 托管的 PaaS SQL 服务器。 在此体系结构中，SQL 数据库提供源数据，并演示迁移方案的数据流。

  • OneLake 是一个统一的基于云的数据湖，用于跨组织存储结构化和非结构化数据。 在此体系结构中，OneLake 充当中央存储层。 它使用 Fabric Lakehouse、Fabric Warehouse、Fabric Eventhouse 和镜像数据库等项目来持久保存和组织各种类型的数据进行分析和报告。

  • Fabric 数据仓库 是一种 SaaS 产品/服务，用于托管大型数据集的数据仓库工作负荷。 在此体系结构中，Fabric 数据仓库充当维度数据集的最终存储，并支持分析和报告。

  • Power BI 是一种托管在 Fabric 计算上的商业智能工具。 它在此方案中呈现和可视化数据，使业务用户能够基于 Fabric 数据仓库和其他源的数据与仪表板和报表进行交互。

  • Microsoft Entra ID 是支持身份验证和授权流的多云标识和网络解决方案套件。 在此体系结构中，Microsoft Entra ID 为连接到 Power BI 和 Fabric 资源的用户提供安全访问。

方案详细信息

在此方案中，组织有一个包含大型本地数据仓库的 SQL 数据库。 组织希望使用 Fabric 引入和分析数据，并通过 Power BI 向用户提供分析见解。

何时使用此体系结构

可以使用各种方法来满足企业商业智能的业务要求。 各方面都定义了业务要求，例如当前的技术投资、人类技能、现代化时间线、未来目标，以及你更喜欢平台即服务（PaaS）还是软件即服务（SaaS）。

请考虑以下设计方法：

本文中的体系结构假定使用 Fabric Lakehouse 或 Fabric 仓库作为企业语义模型的持久层，并且将 Power BI 用于商业智能。 此 SaaS 方法可以灵活地适应各种业务要求和首选项。

Authentication

Microsoft Entra ID 对连接到 Power BI 仪表板和应用的用户进行身份验证。 单一登录（SSO）将用户连接到 Fabric 仓库和 Power BI 语义模型中的数据。 授权发生在源头。

增量加载

运行自动化 ETL 或 ELT 进程时，应仅加载自上一次运行以来已更改的数据。 此过程称为 增量加载。 相比之下，完整负载会加载所有数据。 若要执行增量加载，请确定如何标识已更改的数据。 可以使用 高水印 值方法，该方法跟踪日期时间列的最新值或源表中的唯一整数列。

可以在 SQL Server 中使用 临时表。 时态表是系统版本化的表，用于存储数据更改的历史记录。 数据库引擎会在单独的历史记录表中自动记录每项更改的历史记录。 若要查询历史数据，可以将 FOR SYSTEM_TIME 子句添加到查询。 在内部，数据库引擎会查询历史记录表，但此操作对于应用程序而言是透明的。

临时表支持维度数据，这些数据可能会随时间而变化。 事实数据表通常表示不可变的事务，例如销售，其中保留系统版本历史记录没有意义。 相反，交易通常有一个表示交易日期的列。 该列可用作水印值。 例如，在 AdventureWorks 数据仓库中，SalesLT.* 表具有 LastModified 字段。

以下步骤描述了 ELT 管道的常规流：

  1. 针对源数据库中的每个表，跟踪最后一个 ELT 作业的运行截止时间。 将此信息存储在数据仓库中。 在初始设置时，所有时间都设置为 1-1-1900。

  2. 在执行数据导出步骤期间，截止时间作为参数传递给源数据库中的一组存储过程。 这些存储过程查询在截止时间后更改或创建的任何记录。 对于示例中的所有表，你可以使用 ModifiedDate 列。

  3. 完成数据迁移后，更新存储截止时间的表。

数据管道

此方案使用 AdventureWorks 示例数据库作为数据源。 增量数据加载模式可确保仅加载最近管道运行后修改或添加的数据。

元数据驱动的导入框架

Fabric 数据工厂管道中的 元数据驱动引入框架 以增量方式加载关系数据库中包含的所有表。 本文将数据仓库称为源，但可以将其替换为 Azure SQL 数据库作为源。

  1. 选择水印列。 在源表中选择一个有助于跟踪新记录或更改的记录的列。 此列通常包含添加或更新行时增加的值（例如时间戳或 ID）。 使用此列中的最高值作为 水印 来了解你离开的位置。

  2. 设置一个表格来存储最后的水印值。

  3. 构建包含以下活动的管道：

    • 两个查找活动。 第一个活动获取最后一个标记值（我们上次停止的地方）。 第二个活动获取新的水印值（这次停止的位置）。 这两个值都传递给复制活动。

    • 一个复制活动，用于查找水印列值介于旧水印和新水印之间的行。 然后将此数据作为新文件从数据仓库复制到 Lakehouse。

    • 一个存储过程活动，用于保存新的水印值以确定下一个管道运行的起点。

    此图显示了用于检索、使用和更新水印值的活动的流程图。

下图显示了已完成的管道。 有关详细信息，请参阅 增量引入。

屏幕截图显示了一个媒体引入管道，其中包含查找活动以获取水印值、新数据的复制活动以及更新水印的存储过程。

将数据加载到 Fabric 数据仓库中

复制活动将数据从 SQL 数据库复制到 Fabric 数据仓库。 此示例的 SQL 数据库位于 Azure 中，因此它使用在 Fabric 门户中的 “管理连接”和“网关”下设置的连接。

使用Fabric Data Factory管道

Fabric 数据工厂中的管道定义一组有序的活动，以完成增量加载模式。 手动或自动触发器启动管道。

转换数据

如果需要转换，请使用 Fabric 数据流 设计可重塑数据的低代码 AI 辅助 ETL 转换。 Fabric 数据流依赖于 Power Query 引擎来应用这些转换，并将结果写入 Fabric 数据仓库。

在生产环境中，使用 Fabric 笔记本 来实现 ETL 转换，通过 Apache Spark 驱动的分布式计算框架，使其能够高效处理大型数据集。

注释

使用 本机执行引擎 运行数据工程或 ETL 工作负荷。

将 Power BI 与 Fabric 性能配合使用来访问、建模和可视化数据

Power BI 中的构造容量支持用于连接到 Azure 数据源的多种存储模式：

  • 导入： 将数据加载到 Power BI 语义模型中进行内存查询。

  • DirectQuery： 直接针对关系存储运行查询，而无需将数据加载到内存中。

  • 复合模型： 将某些表的导入模式与同一数据集中的其他表的 DirectQuery 组合在一起。

  • Direct Lake： 从 Fabric 工作区语义模型查询 OneLake 中存储的 Delta 表。 它通过按需将数据加载到内存中，针对大型表的交互式分析进行了优化。

此方案使用 DirectQuery 仪表板，因为它具有少量数据和低模型复杂性。 DirectQuery 将查询委托给基础计算引擎，并在源上使用安全功能。 DirectQuery 可确保结果始终与最新的源数据保持一致。

导入模式可以提供最低的查询延迟。 如果以下条件满足，请考虑导入模式：

  • 该模型完全适合 Power BI 的内存。
  • 刷新之间的数据延迟是可以接受的。
  • 需要源系统与最终模型之间的复杂转换。

在这种情况下，用户希望完全访问最新数据，且 Power BI 刷新时没有延迟，并且他们希望所有历史数据超过 Power BI 数据集容量。 Power BI 数据集可以处理 25 GB 到 400 GB，具体取决于容量大小。 专用 SQL 池中的数据模型已在星型架构中，不需要转换，因此 DirectQuery 是一个合适的选择。

屏幕截图显示了一个 Power BI 仪表板，其中包含销售指标、趋势图、筛选器和详细的数据表。

使用 Power BI 管理大型模型、分页报表和部署管道。 利用内置的 Azure Analysis Services 终结点。 还可以具有具有独特价值主张的专用 容量 。

当 BI 模型增长或仪表板复杂性增加时，可以通过 混合表和导入预聚合数据切换到复合模型并导入查找表的各个部分。 可以在 Power BI 中为导入的数据集启用 查询缓存，并将 双表 用于存储模式属性。

在复合模型中，数据集充当虚拟直通层。 当用户与可视化效果交互时，Power BI 会生成对 Fabric 数据仓库的 SQL 查询。 Power BI 根据效率确定是使用内存中存储还是 DirectQuery 存储。 引擎决定何时从内存中切换到 DirectQuery，并将逻辑推送到 Fabric 数据仓库。 根据查询表的上下文，它们可用作缓存的（导入）或非缓存复合模型。 可以选择要缓存到内存中的表、合并一个或多个 DirectQuery 源中的数据，或合并 DirectQuery 源数据和导入的数据。

当您将 DirectQuery 与 Fabric 数据仓库或 Lakehouse 配合使用时，请执行以下操作：

  • 使用 Fabric Z-Order 和 V-Order 优化以 Delta 格式文件存储的基础表数据，从而提高查询性能。

  • 使用 Fabric lakehouse 物化视图 来预计算、存储和维护数据，如同表一样。 在具体化视图中使用所有数据或部分数据的查询可以实现更快的性能，而无需直接引用定义的具体化视图来使用它。

注意事项

这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改进工作负荷质量的指导原则。 有关详细信息，请参阅 Well-Architected Framework。

Reliability

可靠性有助于确保应用程序能够履行对客户的承诺。 有关详细信息，请参阅可靠性设计评审核对清单。

可靠性 文章介绍了 Fabric 如何支持可靠性，包括通过可用性区域实现区域复原，以及跨区域恢复和业务连续性。 Fabric 在“容量设置”页上提供灾难恢复开关。 可在 Azure 区域配对与 Fabric 服务的存在相符的位置使用。 启用灾难恢复容量设置后，跨区域复制将作为 OneLake 数据的 灾难恢复功能 启用。

安全性

安全性提供针对故意攻击和滥用宝贵数据和系统的保证。 有关详细信息，请参阅可靠性设计审查检查表。

云现代化引入了安全问题，例如数据泄露、恶意软件感染和恶意代码注入。 你需要一个云提供商或服务解决方案来解决你的问题，因为安全措施不足可能会造成重大问题。

此方案通过使用分层安全控制（包括网络、标识、隐私和授权控制）的组合来解决最苛刻的安全问题。 Fabric 数据仓库存储大部分数据。 Power BI 通过 SSO 通过 DirectQuery 访问数据。 使用 Microsoft Entra ID 进行身份验证。 预配池中的数据授权也有广泛的安全控制。

请考虑以下常见安全问题：

  • 定义谁可以查看哪些数据。

    • 确保数据符合联邦、本地和公司指南，以缓解数据泄露风险。 Fabric 提供全面的 数据保护功能 来支持安全性和提升合规性。

    • OneLake 安全 通过从父项或工作区权限继承的不同权限来控制对 OneLake 数据的所有访问。

      • 工作区 是用于创建和管理项的协作环境。 可在此级别管理工作区角色。

      • 项 是一组捆绑在一起的功能，这些功能捆绑在一个组件中。 数据项是项的子类型，允许使用 OneLake 将数据存储在其中。 项目从工作区角色继承权限，但也可以拥有附加的权限。 项中的文件夹用于存储和管理数据，例如Tables/或Files/。

  • 确定如何验证用户的标识。

  • 选择网络安全技术来保护网络和数据的完整性、机密性和访问权限。

  • 选择用于检测和通知威胁的工具。

  • 确定如何在 Fabric OneLake 上保护数据。

    • 帮助保护Fabric 上的数据，使用 Microsoft Purview 信息保护中的敏感度标签。 常规、机密和高度机密等标签在Microsoft Office 应用（如 Word、PowerPoint 和 Excel）中广泛使用，以保护敏感信息。 数据在流经 Fabric 的过程中从数据源到业务用户，系统能自动跟踪数据的每个步骤。

成本优化

成本优化侧重于减少不必要的开支和提高运营效率的方法。 有关详细信息，请参阅成本优化设计评审核对清单。

本部分概述了解决方案中使用的各种服务的定价详细信息，并说明了使用示例数据集为此方案做出的决策。 使用 Azure 定价计算器 中的起始配置，并调整它以适应你的方案。 有关 Fabric SKU 的详细信息，请参阅 Fabric 定价概述。 有关如何估算 Fabric 总体消耗的详细信息，请参阅 Fabric 容量估算器。

可扩展架构

Fabric 是大多数工作负载的无服务器体系结构，可用于独立缩放计算和存储级别。 计算资源根据使用情况产生成本。 可以按需缩放或暂停这些资源。 存储资源会产生每 GB 的成本，因此引入数据时成本会增加。

织物工厂管道

三个主要组件影响管道的价格：

  • 编排的数据管道活动： 若要优化成本，请通过实现并行流来减少编排的总时间。

  • 用于计算的数据流 Gen2： 若要优化成本，请通过筛选不必要的数据和处理增量提取来简化 ETL 管道。

  • 复制作业或复制活动的数据移动： 若要优化成本，请使用增量提取配置复制作业，并调整复制活动的吞吐量。

有关详细信息，请参阅数据工厂定价上的“数据工厂定价计量”选项卡。

价格因组件或活动、频率以及与编排关联的整体计算而异。 管道活动或复制作业产生的任何数据移动都会产生成本。 但是，通过 Fabric 镜像 与数据移动相关的计算是免费的，镜像数据的存储成本在容量大小内是免费的。 例如，如果购买 F64 容量，则会收到 64 TB 的免费存储空间，专用于镜像。 如果超出免费镜像存储限制或容量暂停，则会对 OneLake 存储进行计费。

架构负载决策指南

使用此 决策指南 为 Fabric 工作负载选择数据存储。 所有选项在 OneLake 中的统一存储中可用。

Fabric Lakehouse 或 Fabric Warehouse 的 SQL 终结点提供了运行临时查询进行分析的功能。 它还允许 Power BI 语义模型导入或直接查询数据。 与湖仓或仓库关联的成本相当于针对 SQL 终结点的 SQL 查询的 CUs 消耗量。 若要优化成本，在 Fabric Lakehouse 中实现 Z 排序和 V 排序 以提高查询性能。 对于数据仓库，请优化查询以读取较小的数据批次。

OneLake 存储

OneLake 存储按照使用的数据量以即用即付的费率计费，并且不会消耗 Fabric 容量单位（CUs）。 湖屋和仓库等 Fabric 项使用 OneLake 存储。 有关详细信息，请参阅 Fabric 定价。

为了优化 OneLake 成本，您可通过定期删除未使用的数据（包括 软删除 存储中的数据）和优化读/写操作来有效管理存储容量。 OneLake 存储与计算分开计费，因此请务必使用 Fabric 容量指标应用监视使用情况。 若要降低存储成本（根据当月的平均每日使用情况计算），请考虑尽量减少存储的数据量。

Power BI

此方案使用具有内置性能增强功能的 Power BI 工作区 来满足苛刻的分析需求。 为优化成本，在导入模式提取中实施增量刷新。 实现 Direct Lake 模式，以便在可能的情况下报告较大的数据集，以减少 Fabric 容量的总体负载。

有关详细信息，请参阅 Power BI 定价。

卓越运营

卓越运营涵盖了部署应用程序并使其在生产环境中保持运行的运营流程。 有关详细信息，请参阅设计卓越运营的审查清单。

  • 使用 Azure DevOps 发布管道和 GitHub Actions 自动跨多个环境部署 Fabric 工作区项目。 有关详细信息，请参阅 Fabric 工作区的持续集成和持续交付。

  • 将每个工作负荷放在单独的部署模板中，并将资源存储在源代码管理系统中。 可以将模板一起或单独部署为持续集成和持续交付（CI/CD）过程的一部分。 此方法简化了自动化过程。 此体系结构有四个主要工作负载：

    • 数据仓库和相关资源
    • 数据工厂的管道
    • Power BI 资产，包括仪表板、应用和数据集
    • 本地到云模拟方案

  • 在可行的情况下，请考虑将你的工作负载进行分阶段部署。 将工作负荷部署到各个阶段。 在移动到下一阶段之前，在每个阶段运行验证检查。 此方法以受控方式将更新推送到生产环境，并最大程度地减少意外的部署问题。 使用 蓝绿部署 和 canary 发布 策略来更新实时生产环境。

  • 使用回滚策略来处理失败的部署。 例如，可以自动重新部署部署历史记录中先前成功的部署。 在 Azure CLI 中使用 --rollback-on-error 标志。

  • 使用 Fabric 容量指标应用 全面监视 Fabric 容量消耗。 使用 工作区监视 来详细监视 Fabric 工作区遥测日志。

  • 使用 Fabric 容量估算器 来估算 Fabric 容量需求。

性能效率

性能效率是指工作负荷能够高效地缩放以满足用户需求。 有关详细信息，请参阅性能效率设计评审核对清单。

本文使用 Fabric F64 容量 演示 BI 功能。 Fabric 中的专用 Power BI 容量范围从 F64 到最大 SKU 大小。 要了解更多信息，请参阅 Fabric 定价。

若要确定所需的容量，请执行以下作：

供稿人

Microsoft维护本文。 以下参与者撰写了本文。

主要作者：

其他参与者：

若要查看非公开的LinkedIn个人资料，请登录LinkedIn。

后续步骤