编辑

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

企业商业智能

Power BI
Azure Synapse Analytics
Azure 数据工厂
Microsoft Entra ID
Azure Blob 存储

此示例方案展示了如何将数据从本地数据仓库引入到云环境中，然后使用商业智能 (BI) 模型为其提供服务。 此方法可能是一个最终目标，也可能是使用基于云的组件实现全面现代化的第一步。

以下步骤基于 Azure Synapse Analytics 端到端方案。 它使用 Azure Pipelines 将数据从 SQL 数据库引入到 Azure Synapse SQL 池中，然后转换数据以进行分析。

体系结构

Diagram of enterprise BI architecture with Azure Synapse.

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

工作流

数据源

引入和数据存储

  1. Azure Data Lake Gen2 在数据引入期间用作临时暂存区域。 然后，你可以使用 PolyBase 将数据复制到 Azure Synapse 专用 SQL 池。

  2. Azure Synapse Analytics 是一种分布式系统，用于对大型数据执行分析。 它支持大规模并行处理 (MPP)，因此很适合用于运行高性能分析。 Azure Synapse 专用 SQL 池是从本地持续引入的数据的目标位置。 它可用于进一步处理，以及通过 DirectQuery 为 Power BI 提供数据。

  3. Azure Pipelines 用于协调 Azure Synapse 工作区中的数据引入和转换。

分析和报告

组件

此方案使用以下组件：

简化的体系结构

Diagram of the enterprise BI simplified architecture.

方案详细信息

某个组织有一个存储在 SQL 数据库中的大型本地数据仓库。 该组织希望使用 Azure Synapse 执行分析，然后使用 Power BI 提供这些见解。

身份验证

Microsoft Entra 对连接到 Power BI 仪表板和应用的用户进行身份验证。 连接到 Azure Synapse 预配的池中的数据源时将使用单一登录。 授权在源上进行。

增量加载

运行自动化的“提取-转换-加载”(ETL) 或“提取-加载-转换”(ELT) 流程时，最有效的做法是仅加载自上次运行以来已发生更改的数据。 这称为“增量加载”，与加载所有数据的“完全加载”相对。 若要执行增量加载，需要通过某种方式来识别哪些数据已更改。 最常用的方法是使用高水印值，这将跟踪源表中某个列的最新值：日期时间列，或唯一整数列。

从 SQL Server 2016 开始，你可以使用临时表，这些表是带有系统版本的表，它们保留着完整的数据变更历史记录。 数据库引擎会在单独的历史记录表中自动记录每项更改的历史记录。 可以通过向查询中添加 FOR SYSTEM_TIME 子句来查询历史数据。 在内部，数据库引擎会查询历史记录表，但此操作对于应用程序而言是透明的。

注意

对于早期版本的 SQL Server，可以使用变更数据捕获 (CDC)。 与时态表相比，此方法不够方便，因为必须查询单独的更改表，而更改是按日志序列号而不是时间戳跟踪的。

时态表适用于随时可能更改的维度数据。 事实数据表通常代表不可变的事务（例如销量），在这种情况下，保留系统版本历史记录没有意义。 相反，事务通常具有一个表示事务日期的列，该日期可用作水印值。 例如，在 AdventureWorks 数据仓库中，SalesLT.* 表有一个 LastModified 字段。

下面是 ELT 管道的常规流：

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

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

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

数据管道

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

元数据驱动的复制工具

Azure Pipelines 中内置的元数据驱动复制工具以增量方式加载关系数据库中包含的所有表。 通过借助向导进行导航，你可以将该“复制数据”工具连接到源数据库，并为每个表配置增量加载或完全加载。 然后，该“复制数据”工具将创建管道和 SQL 脚本，以生成所需的控制表来存储增量加载流程的数据，例如，每个表的高水印值/列。 运行这些脚本后，管道就可以将源数据仓库中的所有表加载到 Synapse 专用池中。

Screenshot of metadata-driven copy data tool in Synapse Analytics.

该工具创建三个管道，用于在加载数据之前循环访问数据库中的所有表。

此工具生成的管道：

  • 计算管道运行中要复制的对象（例如表）的数量。
  • 循环访问要加载/复制的每个对象，然后：
    • 检查是否要求执行增量加载；如果不要求，则完成正常的完全加载。
    • 从控制表中检索高水印值。
    • 将数据从源表复制到 ADLS Gen2 中的暂存帐户。
    • 通过所选复制方法（例如 Polybase、Copy 命令）将数据加载到专用 SQL 池中。
    • 更新控制表中的高水印值。

将数据加载到 Azure Synapse SQL 池中

复制活动将数据从 SQL 数据库复制到 Azure Synapse SQL 池中。 在此示例中，因为我们的 SQL 数据库位于 Azure 中，所以我们使用 Azure 集成运行时从 SQL 数据库中读取数据，并将数据写入到指定的暂存环境。

然后，使用复制语句将数据从暂存环境加载到 Synapse 专用池中。

使用 Azure Pipelines

Azure Synapse 中的管道用于定义有序的活动集，以完成增量加载模式。 触发器用来启动管道，管道可以手动触发或在指定的时间触发。

转换数据

因为我们的参考体系结构中的示例数据库不大，所以我们创建了没有分区的复制表。 对于生产工作负荷，使用分布式表可能会提高查询性能。 请参阅在 Azure Synapse 中设计分布式表的指南。 示例脚本使用一个静态资源类来运行查询。

在生产环境中，请考虑创建采用轮循分布的暂存表。 然后，对数据进行转换并将其移动到具有聚集列存储索引的生产表中，这些索引可以提供最佳的整体查询性能。 列存储索引已针对扫描大量记录的查询进行优化。 列存储索引并不是很适合用于单一实例查找（即，查找单个行）。 如果需要执行频繁的单一实例查找，可以在表中添加非聚集索引。 使用非聚集索引时，单一实例查找的运行速度要快得多。 但是，与在 OLTP 工作负荷中相比，单一实例查找在数据仓库场景中通常不太常见。 有关详细信息，请参阅 Azure Synapse 中的索引表。

注意

聚集列存储表不支持 varchar(max)、nvarchar(max) 或 varbinary(max) 数据类型。 在这种情况下，请考虑堆或聚集索引。 可将这些列放入单独的表中。

使用 Power BI Premium 对数据进行访问、建模和可视化

Power BI Premium 支持多个用于连接到 Azure 上的数据源的选项，特别是在 Azure Synapse 预配的池中：

  • 导入：将数据导入 Power BI 模型。
  • DirectQuery：直接从关系存储拉取数据。
  • 复合模型：为某些表使用导入，为其他表使用 DirectQuery。

此方案是通过 DirectQuery 仪表板交付的，因为使用的数据量和模型复杂度不高，因此我们可以提供良好的用户体验。 DirectQuery 将查询委托给底层的功能强大的计算引擎，并利用源上的大量安全功能。 此外，使用 DirectQuery 可确保结果始终与最新源数据保持一致。

导入模式可以提供最快的查询响应时间，在下列情况下应当考虑使用此模式：如果模型可以完全容纳在 Power BI 的内存中，可以容忍刷新之间的数据延迟，并且源系统与最终模型之间可能存在一些复杂的转换。 在本例中，最终用户希望能够通过进行 Power BI 刷新无延迟地完全访问最新的数据，以及所有历史数据，这些数据大于 Power BI 数据集可以处理的大小（25-400 GB，具体取决于容量大小）。 由于专用 SQL 池中的数据模型已采用星型架构，无需转换，因此 DirectQuery 是一个合适的选择。

Screenshot of dashboard in Power BI.

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

当 BI 模型增长或仪表板复杂度增加时，你可以切换到复合模型，并开始导入一部分查找表（通过混合表）和一些预先聚合的数据。 在 Power BI 中为导入的数据集启用查询缓存是一个选项，还可以为存储模式属性利用双表。

在复合模型中，数据集充当一个虚拟的直通层。 当用户与可视化效果进行交互时，Power BI 会针对 Synapse SQL 池双存储生成 SQL 查询：内存中查询或直接查询，具体取决于哪种查询效率更高。 引擎决定何时从内存中查询切换到直接查询，并将逻辑推送到 Synapse SQL 池。 根据查询表的上下文，它们可以充当缓存的（导入的）或非缓存的复合模型。 选取并选择要缓存到内存中的表，合并来自一个或多个 DirectQuery 源的数据，并且/或者在混用了 DirectQuery 源和导入的数据时合并数据。

建议：通过 Azure Synapse Analytics 预配的池使用 DirectQuery 时：

  • 使用 Azure Synapse 结果集缓存来缓存用户数据库中的查询结果以供重复使用，将查询性能提升至毫秒级，并降低计算资源使用量。 使用缓存结果集的查询不会使用 Azure Synapse Analytics 中的任何并发槽，因此不会根据现有的并发限制进行计数。
  • 像使用表那样使用 Azure Synapse 具体化视图来预先计算、存储和维护数据。 使用具体化视图中的所有数据或部分数据的查询可以获得更快的性能，它们无需直接引用所定义的具体化视图便可使用它。

注意事项

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

安全性

安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息，请参阅安全性支柱概述。

频繁出现的数据泄露、恶意软件感染和恶意代码注入的头条新闻，是寻求云现代化的公司所关注的广泛安全问题之一。 企业客户需要可以解决这些问题的云提供商或服务解决方案，因为他们承担不起犯错的代价。

此方案使用分层安全控制措施的组合来解决最苛刻的安全顾虑：网络、标识、隐私和授权。 大部分数据存储在 Azure Synapse 预配的池中，Power BI 通过单点登录使用 DirectQuery。 可以使用 Microsoft Entra ID 进行身份验证。 此外，还针对预配的池的数据授权实施了大量的安全控制措施。

一些常见的安全问题包括：

  • 如何控制谁可以查看哪些数据？
    • 组织需要保护其数据以符合联邦、本地和公司准则，从而降低数据泄露的风险。 Azure Synapse 提供了多种数据保护功能来实现合规性。
  • 用于验证用户身份的选项有哪些？
    • Azure Synapse 支持使用广泛的功能通过访问控制和授权来控制谁可以访问数据以及可以访问哪些数据。
  • 可使用哪些网络安全技术来保护网络和数据的完整性、机密性和访问？
    • 若要确保 Azure Synapse 的安全，有一系列的网络安全选项可供选择。
  • 哪些工具可以检测威胁并发出通知？
    • Azure Synapse 提供了许多威胁检测功能（例如SQL 审核、SQL 威胁检测和漏洞评估）来审核、保护和监视数据库。
  • 如何保护我的存储帐户中的数据？
    • Azure 存储帐户非常适合于需要快速且一致的响应时间或每秒输入输出操作 (IOP) 量很高的那些工作负载。 存储帐户包含你的所有 Azure 存储数据对象，并且有许多用于存储帐户安全性的选项。

成本优化

成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息，请参阅成本优化支柱概述。

本部分提供了此解决方案中涉及的各种服务的定价信息，并提到了使用示例数据集时为此方案做出的决策。

Azure Synapse

Azure Synapse Analytics 无服务器体系结构允许独立缩放计算和存储级别。 计算资源按使用情况计费，可按需缩放或暂停这些资源。 存储资源按 TB 计费，因此，引入的数据越多，费用就越高。

Azure Pipelines

可以在 Azure Synapse 定价页的“数据集成”选项卡下找到 Azure Synapse 中管道的定价详细信息。 有三个主要组件会影响管道的价格：

  1. 数据管道活动和集成运行时小时数
  2. 数据流群集大小和执行
  3. 操作费用

价格因组件或活动、频率和集成运行时单位数而异。

对于示例数据集，标准的 Azure 托管集成运行时（管道核心的复制数据活动）按每日日程表针对源数据库中所有实体（表）触发。 此方案不包含数据流。 没有操作成本，因为每月使用管道的操作数少于 100 万。

Azure Synapse 专用池和存储

可以在 Azure Synapse 定价页的“数据仓库”选项卡下找到 Azure Synapse 专用池的定价详细信息。 在“专用”消耗模型下，将按照正常运行的小时数针对预配的 DWU 单位数向客户收费。 另一个影响因素是数据存储成本：静态数据的大小 + 快照 + 异地冗余（如果有）。

对于示例数据集，你可以预配 500DWU，这可以保证分析负载的良好体验。 你可以使计算功能在报告功能的工作期间内保持正常运行。 如果投入生产，则预留数据仓库容量对于成本管理来说是一个有吸引力的选择。 应使用各种技术来最大限度地提高成本/性能指标，这在前面的部分中进行了介绍。

Blob 存储

请考虑使用 Azure 存储预留容量功能来降低存储成本。 使用此模型时，如果您预留一年或三年的固定存储容量，则可获得折扣。 有关详细信息，请参阅借助预留容量优化 Blob 存储的成本。

此方案中没有持久性存储。

Power BI Premium

可以在 Power BI 定价页上找到 Power BI Premium 定价详细信息。

此方案使用了 Power BI Premium 工作区，这些工作区内置了一系列性能增强功能，以满足要求苛刻的分析需求。

卓越运营

卓越运营涵盖了部署应用程序并使其在生产环境中保持运行的运营流程。 有关详细信息，请参阅卓越运营支柱概述。

DevOps 建议

  • 为生产、开发和测试环境创建单独的资源组。 使用单独的资源组可以更方便地管理部署、删除测试部署，以及分配访问权限。

  • 将每个工作负载放在单独的部署模板中，并将资源存储在源代码管理系统中。 你可以在持续集成 (CI) 和持续交付 (CD) 流程中统一或者逐个部署这些模板，以简化自动化流程。 在此体系结构中，有四个主要工作负载：

    • 数据仓库服务器和相关资源
    • Azure Synapse 管道
    • Power BI 资产：仪表板、应用、数据集
    • 本地到云模拟方案

    请为每个工作负载使用单独的部署模板。

  • 在可行的情况下，请考虑将你的工作负载进行分阶段部署。 部署到各个阶段，并在每个阶段运行验证检查，然后再移动到下一阶段。 这样便能够以高度受控的方式将更新推送到生产环境，并最大程度地减少意外的部署问题。 使用蓝绿部署和 Canary 版本策略来更新实时生产环境。

  • 有一个良好的回滚策略用于处理失败的部署。 例如，可以自动重新部署部署历史记录中先前成功的部署。 请参阅 Azure CLI 中的 --rollback-on-error 标志。

  • 建议选择Azure Monitor 来分析数据仓库和整个 Azure 分析平台的性能，以获得集成的监视体验。 Azure Synapse Analytics 在 Azure 门户中提供监视体验，以显示有关数据仓库工作负载的见解。 建议使用 Azure 门户来监视数据仓库，因为它提供可配置的保持期、警报、建议，并为指标和日志提供可自定义的图表与仪表板。

快速入门

性能效率

性能效率是指工作负载能够以高效的方式扩展以满足用户对它的需求。 有关详细信息，请参阅性能效率要素概述。

本部分提供了有关调整大小以适应此数据集时所做决策的详细信息。

Azure Synapse 预配的池

有一系列数据仓库配置可供选择。

数据仓库单位数 计算节点数 每个节点的分布区数
DW100c 1 60
-- TO --
DW30000c 60 1

若要体验横向扩展带来的性能优势（尤其是对于较大的数据仓库单位），请至少使用 1 TB 的数据集。 若要确定专用 SQL 池的最佳数据仓库单位数目，请尝试纵向扩展和缩减。 加载数据后，使用不同数量的数据仓库单位运行几个查询。 由于缩放很快就能完成，可以在一个小时或更少时间内尝试一些不同级别的性能。

确定最佳的数据仓库单位数目

对于开发中的专用 SQL 池，可以从较小的数据仓库单位数目开始。 DW400c 或 DW200c 是一个不错的起点。 监视应用程序性能，将所选数据仓库单位数目与观测到的性能变化进行比较。 采用线性缩放，确定需要以多大的增量来增加或减少数据仓库单位。 继续进行调整，直到达到业务要求的最佳性能级别。

缩放 Synapse SQL 池

Azure Pipelines

有关 Azure Synapse 中的管道以及所用复制活动的可伸缩性和性能优化功能，请参阅复制活动性能和可伸缩性指南。

Power BI Premium

本文使用 Power BI Premium Gen 2 来演示 BI 功能。 目前，Power BI Premium 的容量 SKU 的范围为 P1（8 个 v 核心）到 P5（128 个 v 核心）。 选择所需容量的最佳方法是进行容量加载评估，安装第 2 代指标应用进行持续监视，并考虑使用 Power BI Premium 进行自动缩放。

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

主要作者：

其他参与者：

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

后续步骤