本文介绍如何将数据从本地数据仓库传输到云环境，然后使用商业智能（BI）模型为数据提供服务。 可以使用此方法作为最终目标，或者使用基于云的组件实现全面现代化的第一步。
本指南基于 Azure Synapse Analytics 端到端方案。 此过程使用 Azure Synapse Analytics 管道将数据从 SQL 数据库引入 SQL 池。 然后，它会执行数据转换进行分析。 本文重点介绍 Azure Synapse Analytics 管道，但也可以使用 Azure 数据工厂管道或 Fabric 数据工厂管道来执行这些任务。
何时使用此体系结构
可以使用各种方法来满足企业 BI 的业务要求。 各方面都定义了业务要求，例如当前的技术投资、人类技能、现代化时间线、未来目标，以及你是否倾向于平台即服务（PaaS）或软件即服务（SaaS）。
请考虑以下设计方法：
Microsoft Fabric 中的 a lakehouse
Fabric 和 Azure Databricks，这些客户对 Azure Databricks 和 Power BI 有现有投资，并希望使用 Fabric 实现现代化
适用于使用 Azure SQL 生态系统和 Fabric 的中小企业的企业 BI
面向首选 SaaS 的客户完全在 Fabric 上实现数据仓库
本文中的体系结构假定使用 Azure Synapse Analytics 数据仓库作为企业语义模型的持久层，并使用 Power BI 实现商业智能。 此 PaaS 方法可以灵活地适应各种业务要求和偏好。
体系结构
使用 Azure Synapse Analytics 显示企业 BI 体系结构的 
下载此体系结构的 Visio 文件。
工作流
数据源
- Azure 中的 SQL Server 数据库包含源数据。 若要模拟本地环境，此方案的部署脚本将配置 Azure SQL 数据库。 AdventureWorks 示例数据库用作源数据架构和示例数据。 有关详细信息，请参阅 从 SQL Server复制和转换数据。
引入和数据存储
Azure Data Lake Storage 是数据引入过程中的临时暂存区域。 可以使用 PolyBase 将数据复制到 Azure Synapse Analytics 专用 SQL 池。
Azure Synapse Analytics 是一种分布式系统，用于对大数据执行分析。 它支持大规模并行处理，因此可以运行高性能分析。 Azure Synapse Analytics 专用 SQL 池是从本地环境持续引入的目标。 SQL 池可以通过 DirectQuery 提供数据来 Power BI，并执行进一步处理。
Azure Synapse Analytics 管道 协调 Azure Synapse Analytics 工作区中的数据引入和转换。
分析和报告
- 此方案中的数据建模方法结合了 企业模型 和 BI 语义模型。 Azure Synapse Analytics 专用 SQL 池 包含企业模型。 Power BI Premium 容量 F64 包含 BI 语义模型。 Power BI 通过 DirectQuery 访问数据。
组件
此方案使用以下组件：
Azure SQL 数据库 是 Azure 托管的 PaaS SQL 服务器。 此体系结构使用 SQL 数据库来演示迁移方案的数据流。
Data Lake Storage 为用于保存中间迁移结果的非结构化数据提供灵活的云存储。
Azure Synapse Analytics 是用于数据仓库和大数据系统的企业分析服务。 Azure Synapse Analytics 充当企业语义建模和服务中的主要计算和持久性存储。
Power BI Premium 是一种 BI 工具，用于呈现和可视化此方案中的数据。
Microsoft Entra ID 是支持身份验证和授权流的多云标识和网络解决方案套件。
简化的体系结构
显示企业 BI 简化体系结构的 
方案详细信息
在此方案中，组织有一个包含大型本地数据仓库的 SQL 数据库。 组织希望使用 Azure Synapse Analytics 执行分析，然后通过 Power BI 将这些见解提供给用户和分析。
身份验证
Microsoft Entra ID 对连接到 Power BI 仪表板和应用的用户进行身份验证。 单一登录将用户连接到 Azure Synapse Analytics 预配池中的数据源。 授权发生在源上。
增量加载
运行自动提取、转换、加载、加载（ETL）或提取、加载、转换（ELT）过程时，应仅加载自上一次运行以来已更改的数据。 此过程称为 增量加载。 相反，完全加载将加载所有数据。 若要执行增量加载，请确定如何标识已更改的数据。 可以使用 高水印 值方法，该方法跟踪日期时间列的最新值或源表中的唯一整数列。
可以在 SQL Server 中使用 临时表。 临时表是存储数据更改历史记录的系统版本控制表。 数据库引擎会在单独的历史记录表中自动记录每项更改的历史记录。 若要查询历史数据，可以将 FOR SYSTEM_TIME 子句添加到查询。 在内部，数据库引擎会查询历史记录表，但此操作对于应用程序而言是透明的。
临时表支持维度数据，这些数据可能会随时间而变化。 事实数据表通常代表不可变的事务（例如销量），在这种情况下，保留系统版本历史记录没有意义。 相反，事务通常具有表示事务日期的列。 该列可用作水印值。 例如，在 AdventureWorks 数据仓库中，SalesLT.* 表具有 LastModified 字段。
下面是 ELT 管道的常规流：
针对源数据库中的每个表，跟踪最后一个 ELT 作业的运行截止时间。 将此信息存储在数据仓库中。 在初始设置时，所有时间都设置为
1-1-1900。在执行数据导出步骤期间，截止时间作为参数传递给源数据库中的一组存储过程。 这些存储过程查询在截止时间后更改或创建的任何记录。 对于示例中的所有表，你可以使用
ModifiedDate列。完成数据迁移后，更新存储截止时间的表。
数据管道
此方案使用 AdventureWorks 示例数据库作为数据源。 增量数据加载模式可确保仅加载最近管道运行后修改或添加的数据。
元数据驱动的复制工具
Azure Synapse Analytics 管道中的内置 元数据驱动复制工具 增量加载关系数据库中包含的所有表。
使用向导接口将复制数据工具连接到源数据库。
连接后，为每个表配置增量加载或完全加载。
复制数据工具创建生成控制表所需的管道和 SQL 脚本。 此表存储用于增量加载过程的数据，例如每个表的高水印值或列。
运行这些脚本后，管道会将所有源数据仓库表加载到 Azure Synapse Analytics 专用池中。
在工具加载数据之前，它会创建三个管道来循环访问数据库中的表。
管道执行以下任务：
计算管道运行中要复制的对象（例如表）的数量。
循环访问要加载或复制的每个对象。
管道循环访问每个对象后，它会执行以下任务：
检查增量负载是否是必需的。 否则，管道将完成正常的完全加载。
从控制表中检索高水印值。
将数据从源表复制到 Data Lake Storage 中的临时帐户。
通过所选复制方法将数据加载到专用 SQL 池中，例如 PolyBase 或 Copy 命令。
更新控制表中的高水印值。
将数据加载到 Azure Synapse Analytics SQL 池
复制活动 将数据从 SQL 数据库复制到 Azure Synapse Analytics SQL 池。 此示例的 SQL 数据库位于 Azure 中，因此它使用 Azure 集成运行时从 SQL 数据库读取数据，并将数据写入指定的暂存环境。
然后，复制语句将数据从过渡环境加载到 Azure Synapse Analytics 专用池中。
使用 Azure Synapse Analytics 管道
Azure Synapse Analytics 中的管道定义一组有序的活动，以完成增量加载模式。 手动或自动触发器启动管道。
转换数据
此参考体系结构中的示例数据库很小，因此不会创建没有分区的复制表。 对于生产工作负荷，分布式表可以提高查询性能。 有关详细信息，请参阅有关在 Azure Synapse Analytics 中设计分布式表的指南。 示例脚本通过静态 资源类运行查询。
在生产环境中，请考虑创建具有轮循机制分布的临时表。 然后转换数据并将其移动到具有聚集列存储索引的生产表中，从而提供最佳的整体查询性能。 列存储索引已针对扫描大量记录的查询进行优化。
列存储索引不会针对单一实例查找或查找单行以最佳方式执行。 如果需要执行频繁的单一实例查找，可以将非聚集索引添加到表，从而提高速度。 但是，在数据仓库方案中，单一实例查找通常不太常见，而不是联机事务处理工作负荷。 有关详细信息，请参阅 Azure Synapse Analytics 中的索引表。
注意
聚集列存储表不支持 varchar(max)、nvarchar(max) 或 varbinary(max) 数据类型。 如果使用这些数据类型，请考虑使用堆或聚集索引。 还可以考虑将这些列放入单独的表中。
使用 Power BI Premium 对数据进行访问、建模和可视化
Power BI Premium 支持多个选项连接到 Azure 上的数据源。 可以使用 Azure Synapse Analytics 预配池执行以下任务：
- 导入：将数据导入 Power BI 模型。
- DirectQuery：直接从关系存储拉取数据。
- 复合模型：为某些表使用导入，为其他表使用 DirectQuery。
此方案使用 DirectQuery 仪表板，因为它具有少量数据和低模型复杂性。 DirectQuery 将查询委托给下面功能强大的计算引擎，并在源上使用广泛的安全功能。 DirectQuery 可确保结果始终与最新的源数据保持一致。
导入模式提供最快的查询响应时间。 如果：
- 该模型完全适合 Power BI 的内存。
- 刷新之间的数据延迟是可以接受的。
- 需要源系统与最终模型之间的复杂转换。
在这种情况下，最终用户希望完全访问最新数据，且 Power BI 刷新时没有延迟，并且他们希望所有历史数据超过 Power BI 数据集容量。 Power BI 数据集可以处理 25-400 GB，具体取决于容量大小。 专用 SQL 池中的数据模型已在星型架构中，不需要转换，因此 DirectQuery 是一个合适的选择。
使用 Power BI Premium 管理大型模型、分页报表和部署管道。 利用内置的 Azure Analysis Services 终结点。 你还可以拥有具有独特价值主张的专用容量。
当 BI 模型增长或仪表板复杂性增加时，可以通过 混合表和导入预聚合数据切换到复合模型并导入查找表的各个部分。 可以在 Power BI 中为导入的数据集启用 查询缓存，并将 双表 用于存储模式属性。
在复合模型中，数据集充当虚拟直通层。 当用户与可视化效果交互时，Power BI 会向 Azure Synapse Analytics SQL 池生成 SQL 查询。 Power BI 根据效率确定是使用内存中存储还是 DirectQuery 存储。 引擎决定何时从内存中切换到 DirectQuery，并将逻辑推送到 Azure Synapse Analytics SQL 池。 根据查询表的上下文，它们可以充当缓存的（导入）或非缓存复合模型。 可以选择要缓存到内存中的表、合并一个或多个 DirectQuery 源中的数据，或合并 DirectQuery 源数据和导入的数据。
将 DirectQuery 与 Azure Synapse Analytics 预配池配合使用时：
使用 Azure Synapse Analytics 结果集缓存 来缓存用户数据库中的查询结果以供重复使用。 此方法将查询性能提高到毫秒，并减少计算资源使用率。 使用缓存结果集的查询不会在 Azure Synapse Analytics 中使用任何并发槽，因此它们不会计入现有的并发限制。
使用 Azure Synapse Analytics 具体化视图 来预计算、存储和维护表等数据。 在具体化视图中使用所有数据或部分数据的查询可以实现更快的性能，而无需直接引用定义的具体化视图来使用它。
注意事项
这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改进工作负荷质量的指导原则。 有关详细信息，请参阅 Well-Architected Framework。
安全性
安全性提供针对故意攻击和滥用宝贵数据和系统的保证。 有关详细信息，请参阅 安全的设计评审清单。
云现代化引入了安全问题，例如数据泄露、恶意软件感染和恶意代码注入。 你需要一个云提供商或服务解决方案来解决你的问题，因为安全措施不足可能会造成重大问题。
此方案通过使用分层安全控制的组合来解决最苛刻的安全问题：网络、标识、隐私和授权控制。 Azure Synapse Analytics 预配池存储大部分数据。 Power BI 通过单一登录通过 DirectQuery 访问数据。 可以使用 Microsoft Entra ID 进行身份验证。 预配池中的数据授权也有广泛的安全控制。
一些常见的安全问题包括：
定义谁可以查看哪些数据。
- 确保数据符合联邦、本地和公司指南，以缓解数据泄露风险。 Azure Synapse Analytics 提供多个 数据保护功能， 实现合规性。
确定如何验证用户的标识。
选择网络安全技术来保护网络和数据的完整性、机密性和访问权限。
- 使用 网络安全 选项帮助保护 Azure Synapse Analytics。
选择用于检测和通知威胁的工具。
- 使用 Azure Synapse Analytics 威胁检测 功能，例如 SQL 审核、SQL 威胁检测和漏洞评估来审核、保护和监视数据库。
确定如何保护存储帐户中的数据。
- 将 Azure 存储帐户用于需要快速且一致的响应时间的工作负荷，或者每秒具有大量输入/输出作（IOP）。 存储帐户可以存储所有数据对象，并具有多个 存储帐户安全选项。
成本优化
成本优化侧重于减少不必要的开支和提高运营效率的方法。 有关详细信息，请参阅成本优化设计评审核对清单。
本部分提供有关此解决方案中涉及的不同服务的定价的信息，并提到使用示例数据集为此方案做出的决策。 在 Azure 定价计算器中使用此启动配置，并调整它以适应你的方案。
Azure Synapse Analytics
Azure Synapse Analytics 是一种无服务器体系结构，可用于独立缩放计算和存储级别。 计算资源根据使用情况产生成本。 可以按需缩放或暂停这些资源。 存储资源会产生每 TB 的成本，因此引入数据时成本会增加。
Azure Synapse Analytics 管道
三个主要组件影响管道的价格：
- 数据管道活动和集成运行时小时数
- 数据流群集大小和实现
- 操作费用
有关定价详细信息，请参阅 Azure Synapse Analytics 定价上的 数据集成 选项卡。
价格因组件或活动、频率和集成运行时单位数而异。
对于使用标准 Azure 托管集成运行时的示例数据集，复制数据活动 充当管道的核心。 它按每日计划对源数据库中的所有实体（表）运行。 此方案不包含数据流。 由于管道每月运行不到 100 万个作，因此不会产生运营成本。
Azure Synapse Analytics 专用池和存储
对于示例数据集，可以预配 500 个数据仓库单位（DWU），以便为分析负载提供流畅的体验。 可以在工作时间维护计算，以便进行报告。 如果解决方案迁移到生产环境，请使用保留数据仓库容量作为经济高效的策略。 使用各种技术最大程度地提高成本和性能指标。
有关 Azure Synapse Analytics 专用池的定价详细信息，请参阅 azure Synapse Analytics 定价 “数据仓库” 选项卡。 在专用消耗模型中，客户对每个预配的 DWU 产生成本（每小时运行时间）。 另请考虑数据存储成本，包括静态数据的大小、快照和异地冗余。
Blob 存储
请考虑使用 Azure 存储预留容量来降低存储成本。 使用此模型时，如果你预留一年或三年的固定存储容量，则可获得折扣。 有关详细信息，请参阅 使用预留容量优化 blob 存储的成本。 此方案不使用永久性存储。
Power BI Premium
此方案使用 Power BI Premium 工作区 内置性能增强，以满足需求苛刻的分析需求。
有关详细信息，请参阅 Power BI 定价。
卓越运营
卓越运营涵盖部署应用程序并使其在生产环境中运行的运营流程。 有关详细信息，请参阅 卓越运营的设计评审清单。
使用 Azure DevOps 发布管道和 GitHub Actions 自动跨多个环境部署 Azure Synapse Analytics 工作区。 有关详细信息，请参阅 Azure Synapse Analytics 工作区的持续集成和持续交付。
将每个工作负荷放在单独的部署模板中，并将资源存储在源代码管理系统中。 可以将模板一起或单独部署为持续集成和持续交付（CI/CD）过程的一部分。 此方法简化了自动化过程。 此体系结构有四个主要工作负载：
- 数据仓库服务器和相关资源
- Azure Synapse Analytics 管道
- Power BI 资产，包括仪表板、应用和数据集
- 本地到云模拟方案
在可行的情况下，请考虑将你的工作负载进行分阶段部署。 将工作负荷部署到各个阶段。 在移动到下一阶段之前，在每个阶段运行验证检查。 此方法以受控方式将更新推送到生产环境，并最大程度地减少意外的部署问题。 使用 蓝绿部署 和 canary 发布 策略来更新实时生产环境。
使用回滚策略来处理失败的部署。 例如，可以自动重新部署部署历史记录中先前成功的部署。 在 Azure CLI 中使用
--rollback-on-error标志。使用 Azure Monitor 分析数据仓库的性能和整个 Azure 分析平台，以获取集成的监视体验。 Azure Synapse Analytics 在 Azure 门户中提供监视体验，以显示有关数据仓库工作负载的见解。 使用 Azure 门户监视数据仓库。 它提供可配置的保留期、警报、建议以及指标和日志的可自定义图表和仪表板。
有关详细信息，请参阅以下资源：
- 教程：Azure Synapse Analytics 入门
- 使用 Azure CLI 创建 Azure Synapse Analytics 工作区
性能效率
性能效率是指工作负荷能够高效地缩放以满足用户需求。 有关详细信息，请参阅性能效率设计评审核对清单。
本部分提供有关调整大小决策以适应此数据集的详细信息。
Azure Synapse Analytics 预配池
可以使用各种 数据仓库配置。
| DWU | 计算节点数 | 每个节点的分布数 |
|---|---|---|
| DW100c | 1 | 60 |
-- TO -- |
||
| DW30000c | 60 | 1 |
若要查看横向扩展的性能优势，尤其是对于较大的 DWU，请使用至少 1 TB 的数据集。 若要查找专用 SQL 池的最佳 DWU 数，请尝试纵向扩展和缩减。 运行加载数据后具有不同数量的 DWU 的查询。 缩放速度很快，因此可以轻松试验各种性能级别。
查找最佳 DWU 数
对于开发中的专用 SQL 池，请选择少量 DWU 作为起点，例如 DW400c 或 DW200c。 监视应用程序性能，了解每个数量的 DWU。 假设线性刻度，并确定需要增加或减少 DWU 的量。 继续进行调整，直到达到业务要求的最佳性能级别。
缩放 Azure Synapse Analytics SQL 池
有关 Azure Synapse Analytics 中的管道的可伸缩性和性能优化功能以及使用的复制活动，请参阅 复制活动性能和可伸缩性指南。
有关详细信息，请参阅以下资源：
- 使用 Azure 门户 缩放 Azure Synapse Analytics SQL 池的计算
- 使用 Azure PowerShell 缩放专用 SQL 池的计算
- 使用 T-SQL 在 Azure Synapse Analytics 中缩放专用 SQL 池的计算
- 管理专用 SQL 池 的计算
Power BI Premium 和 Fabric
本文使用 Power BI Premium F64 容量 来演示 BI 功能。 Fabric 中的专用 Power BI 容量范围从 F64（8 个 vCore）到 F1024（128 个 vCore）。
若要确定需要多少容量，请：
- 评估容量上的负载。
- 安装 Fabric 容量指标应用 进行持续监视。
- 请考虑 使用与工作负荷相关的容量优化技术。
作者
Microsoft维护本文。 以下参与者撰写了本文。
主要作者：
- Galina Polyakova | 高级云解决方案架构师
- Noah Costar | 云解决方案架构师
- George Stevens | 云解决方案架构师
其他参与者：
- Jim McLeod | 云解决方案架构师
- Miguel Myers | 高级项目经理
若要查看非公开的LinkedIn个人资料，请登录LinkedIn。
后续步骤
- 什么是 Power BI Premium？
- 什么是 Microsoft Entra ID？
- 使用 Azure Databricks 访问 Data Lake Storage 和 Azure Blob 存储
- 什么是 Azure Synapse Analytics？
- Azure 数据工厂和 Azure Synapse Analytics 中的管道和活动
- 什么是 Azure SQL？