解决方案构想
本文介绍了一种解决方案构想。 云架构师可以通过本指南来帮助可视化此体系结构的典型实现的主要组件。 以本文为起点，设计一个符合工作负荷特定要求的架构合理的解决方案。
此示例演示如何在提取、加载和转换 (ELT) 管道中执行增量加载。 它使用 Azure 数据工厂将 ELT 管道自动化。 该管道以增量方式将最新的 OLTP 数据从本地 SQL Server 数据库移入 Azure Synapse。 事务数据将转换为表格模型以供分析。
体系结构
下载此体系结构的 Visio 文件。
此体系结构构建在企业 BI 与 Azure Synapse 中所述的体系结构基础之上，但添加了一些对企业数据仓库方案而言非常重要的功能。
- 使用数据工厂将管道自动化。
- 增量加载。
- 集成多个数据源。
- 加载地理空间数据和图像等二进制数据。
工作流
该体系结构包括以下服务和组件。
数据源
本地 SQL Server。 源数据位于本地的 SQL Server 数据库中。 模拟本地环境。 Wide World Importers OLTP 示例数据库用作源数据库。
外部数据。 数据仓库的常见方案是集成多个数据源。 此参考体系结构加载一个包含不同年份的城市人口的外部数据集，并将它与 OLTP 数据库中的数据集成。 可以使用此数据获取如下所述的见解：“每个区域的销量增长率是否达到或超过人口增长率？”
引入和数据存储
Blob 存储。 Blob 存储用作临时区域，在将源数据载入 Azure Synapse 之前，会在此区域中存储这些数据。
Azure Synapse。 Azure Synapse 是一种分布式系统，设计用于对大型数据执行分析。 它支持大规模并行处理 (MPP)，因此很适合用于运行高性能分析。
Azure 数据工厂。 数据工厂是一项托管服务，用于协调和自动化数据的移动与转换。 在此体系结构中，数据工厂协调 ELT 过程的各个阶段。
分析和报告
Azure Analysis Services。 Analysis Services 是提供数据建模功能的完全托管服务。 语义模型将载入 Analysis Services。
Power BI。 Power BI 是一套商业分析工具，用于分析数据以获取商业见解。 在此体系结构中，Power BI 查询 Analysis Services 中存储的语义模型。
身份验证
Microsoft Entra ID 通过 Power BI 对连接到 Analysis Services 服务器的用户进行身份验证。
数据工厂还可以使用 Microsoft Entra ID 通过服务主体或托管服务标识 (MSI) 对 Azure Synapse 进行身份验证。
组件
- Azure Blob 存储
- Azure Synapse Analytics
- Azure 数据工厂
- Azure Analysis Services
- Power BI
- Microsoft Entra ID
方案详细信息
数据管道
在 Azure 数据工厂中，管道是用于协调某个任务的活动的逻辑分组 - 在本例中，该任务是将数据加载到 Azure Synapse 中并对其进行转换。
此参考体系结构定义一个运行一系列子管道的父管道。 每个子管道将数据载入一个或多个数据仓库表。
建议
增量加载
运行自动化的 ETL 或 ELT 过程时，最有效的做法是仅加载自上次运行以来已发生更改的数据。 这称为“增量加载”，不同于加载所有数据的“完全加载”。 若要执行增量加载，需要通过某种方式来识别哪些数据已更改。 最常用的方法是使用高水印值，即，跟踪源表中某个列的最新值：日期时间列，或唯一整数列。
从 SQL Server 2016 开始，可以使用时态表。 这些表的版本受系统控制，可保留数据更改的完整历史记录。 数据库引擎会在单独的历史记录表中自动记录每项更改的历史记录。 可以通过将 FOR SYSTEM_TIME 子句添加到查询，来查询历史数据。 在内部，数据库引擎会查询历史记录表，但此操作对于应用程序而言是透明的。
注意
对于早期版本的 SQL Server，可以使用变更数据捕获 (CDC)。 与时态表相比，此方法不够方便，因为必须查询单独的更改表，而更改是按日志序列号而不是时间戳跟踪的。
时态表适用于随时可能更改的维度数据。 事实数据表通常代表不可变的事务（例如销量），在这种情况下，保留系统版本历史记录没有意义。 相反，事务通常具有一个表示事务日期的列，该日期可用作水印值。 例如，在 Wide World Importers OLTP 数据库中，Sales.Invoices 和 Sales.InvoiceLines 表具有一个默认值为 sysdatetime() 的 LastEditedWhen 字段。
下面是 ELT 管道的常规流：
针对源数据库中的每个表，跟踪最后一个 ELT 作业的运行截止时间。 将此信息存储在数据仓库中。 （在初始设置时，所有时间设置为“1-1-1900”。）
在执行数据导出步骤期间，截止时间作为参数传递给源数据库中的一组存储过程。 这些存储过程会查询截止时间之后更改或创建的所有记录。 对于 Sales 事实数据表，使用
LastEditedWhen列。 对于维度数据，使用版本由系统控制的时态表。完成数据迁移后，更新存储截止时间的表。
该表也可用于记录每个 ELT 轮次的沿袭。 对于给定的记录，该沿袭会将该记录与生成数据的 ELT 轮次相关联。 对于每个 ETL 轮次，将为每个表创建新的沿袭记录，其中显示起始和结束加载时间。 每个记录的沿袭键存储在维度表和事实数据表中。
将一批新数据载入仓库后，刷新 Analysis Services 表格模型。 请参阅使用 REST API 执行异步刷新。
数据清理
数据清理应是 ELT 过程的一部分。 在此参考体系结构中，一个错误数据源是城市人口表，其中的某些城市人口为零，可能的原因是没有可用的数据。 在处理期间，ELT 管道会从城市人口表中删除这些城市。 针对临时表而不是外部表执行数据清理。
外部数据源
数据仓库通常合并多个源的数据。 例如，包含人口统计数据的外部数据源。 此数据集在 Azure Blob 存储中作为 WorldWideImportersDW 示例的一部分提供。
Azure 数据工厂可以使用 Blob 存储连接器直接从 Blob 存储复制。 但是，连接器需要连接字符串或共享访问签名，因此它无法用于复制具有公共读取访问权限的 Blob。 解决方法之一是使用 PolyBase 创建基于 Blob 存储的外部表，然后将外部表复制到 Azure Synapse 中。
处理大型二进制数据
例如，在源数据库中，City 表包含一个 Location 列，该列保存了 geography 空间数据类型。 Azure Synapse 原生并不支持 geography 类型，因此，在加载期间，此字段将转换为 varbinary 类型。 （请参阅适用于不支持的数据类型的解决方法。）
但是，PolyBase 支持的最大列大小为 varbinary(8000)，这意味着某些数据可能会截断。 此问题的解决方法之一是在导出期间将数据分解为多个区块，然后重新汇编区块，如下所示：
为 Location 列创建临时表。
对于每个城市，将位置数据拆分为 8000 字节的区块，使每个城市具有 1 - N 行。
若要重新汇编区块，请使用 T-SQL PIVOT 运算符将行转换为列，然后连接每个城市的列值。
难点在于，需要根据地理数据的大小，将每个城市拆分为不同数量的行。 若要正常使用 PIVOT 运算符，每个城市的行数必须相同。 为此，T-SQL 查询会通过一些技法在行中填充空值，以便在透视后，每个城市的列数相同。 生成的查询比每次循环访问一行要快得多。
可对图像数据使用相同的方法。
渐变维度
维度数据相对而言是静态的，但仍可能发生变化。 例如，某个产品可能会重新分配到不同的产品类别。 可通过多种方法来处理缓慢变化的维度。 常用的方法称为类型 2，即，每当维度发生变化，就添加一条新记录。
若要实现“类型 2”方法，维度表中需要包含附加的列，用于指定给定记录的有效日期范围。 此外，源数据库中的主键将会复制，因此，维度表必须包含一个人造主键。
例如，下图显示了 Dimension.City 表。 WWI City ID 列是源数据库中的主键。 City Key 列是在运行 ETL 管道期间生成的人造键。 另请注意，该表包含 Valid From 和 Valid To 列，这些列定义每个行的有效时间范围。 当前值包含等于“9999-12-31”的 Valid To。
此方法的优势在于，它会保留历史数据，而这些数据对于分析可能非常有用。 但是，这也意味着，同一个实体存在多个行。 例如，以下记录与 WWI City ID = 28561 相匹配：
对于每个销售事实，需要将该事实与 City 维度表中对应于发票日期的单个行相关联。
注意事项
这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改善工作负荷质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。
安全性
安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息，请参阅安全性支柱概述。
为了提高安全性，可以使用虚拟网络服务终结点来保护 Azure 服务资源：只允许在你的虚拟网络中访问这些资源。 这可以完全避免通过公共 Internet 访问这些资源，只允许来自该虚拟网络的流量。
如果使用此方法，请在 Azure 中创建 VNet，并为 Azure 服务创建专用服务终结点。 然后，将这些服务限制为来自该虚拟网络的流量。 也可以通过网关从本地网络访问这些资源。
注意以下限制：
如果为 Azure 存储启用了服务终结点，PolyBase 无法将数据从存储复制到 Azure Synapse。 此问题有一种缓解方法。 有关详细信息，请参阅将 VNet 服务终结点与 Azure 存储配合使用的影响。
若要将数据从本地移入 Azure 存储，需要允许本地或 ExpressRoute 中的公共 IP 地址。 有关详细信息，请参阅在虚拟网络中保护 Azure 服务。
若要允许 Analysis Services 从 Azure Synapse 读取数据，请将一个 Windows VM 部署到包含 Azure Synapse 服务终结点的虚拟网络。 在此 VM 上安装 Azure 本地数据网关。 然后将 Azure Analysis Services 连接到数据网关。
DevOps
为生产、开发和测试环境创建单独的资源组。 使用单独的资源组可以更方便地管理部署、删除测试部署，以及分配访问权限。
将每个工作负载放在单独的部署模板中，并将资源存储在源代码管理系统中。 可以在 CI/CD 过程中统一或者逐个部署这些模板，以简化自动化流程。
在此体系结构中，有三个主要工作负载：
- 数据仓库服务器、Analysis Services 和相关资源。
- Azure 数据工厂。
- 本地到云模拟方案。
每个工作负载都有其自身的部署模板。
数据仓库服务器是使用 Azure CLI 命令设置和配置的，这些命令遵循 IaC 实践的命令性方法。 考虑使用部署脚本并将其集成到自动化流程中。
请考虑暂存工作负载。 部署到各个阶段，并在每个阶段运行验证检查，然后再移动到下一阶段。 这样便能以高度受控的方式将更新推送到生产环境，并最大程度地减少意外的部署问题。 使用蓝绿部署和 Canary 版本策略来更新实时生产环境。
有一个良好的回滚策略用于处理失败的部署。 例如，可以自动重新部署部署历史记录中先前成功的部署。 请参阅 Azure CLI 中的 --rollback-on-error 标志参数。
建议选择Azure Monitor 来分析数据仓库和整个 Azure 分析平台的性能，以获得集成的监视体验。 Azure Synapse Analytics 在 Azure 门户中提供了监视体验，以展示对数据仓库工作负载的见解。 建议使用 Azure 门户来监视数据仓库，因为它提供可配置的保持期、警报、建议，并为指标和日志提供可自定义的图表与仪表板。
有关详细信息，请参阅 Microsoft Azure 架构良好的框架中的“DevOps”部分。
成本优化
成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息，请参阅成本优化支柱概述。
使用 Azure 定价计算器估算成本。 下面是此参考体系结构中使用的服务的一些注意事项。
Azure 数据工厂
Azure 数据工厂自动执行 ELT 管道。 该管道将数据从本地 SQL Server 数据库移入 Azure Synapse。 然后，数据转换为表格模型以供分析。 对于此方案，每月的活动运行起价为 $0.001，包括活动、触发器和调试运行。 该价格只是业务流程的基本费用。 你还需要为执行活动付费，例如复制数据、查找和外部活动。 每个活动单独定价。 如果管道在一个月内没有关联触发器或运行，也将向你收费。 所有活动按分钟计算，并向上舍入。
成本分析示例
假设有一个用例，其中有两个查找活动来自两个不同来源。 其中一个需要 1 分钟 2 秒（向上舍入为 2 分钟），另一个需要 1 分钟，因此总时间为 3 分钟。 一个数据复制活动需要 10 分钟。 一个存储过程活动需要 2 分钟。 活动运行总时长为 4 分钟。 成本的计算方式如下：
活动运行：4 * $ 0.001 = $0.004
查找：3 * ($0.005 / 60) = $0.00025
存储过程：2 * ($0.00025 / 60) = $0.000008
数据复制：10 * ($0.25 / 60) * 4 数据集成单元 (DIU) = $0.167
- 每个管道运行的总成本：$0.17。
- 每天运行一次，持续 30 天：$5.1/月。
- 每 100 个表每天运行一次，持续 30 天：$510
每个活动都有关联的成本。 了解定价模型，并使用 ADF 定价计算器来优化解决方案（不仅针对性能，还针对成本）。 通过启动、停止、暂停和缩放服务来管理成本。
Azure Synapse
Azure Synapse 非常适合具有更高查询性能和计算可伸缩性需求的密集型工作负载。 可以选择即用即付模型或使用一年（节省 37%）或 3 年（节省 65%）的预留计划。
数据存储单独收费。 灾难恢复和威胁检测等其他服务也单独收费。
有关详细信息，请参阅 Azure Synapse 定价。
Analysis Services
Azure Analysis Services 的定价取决于层级。 此体系结构的参考实现使用“开发人员”层，建议将该层级用于评估、开发和测试方案。 其他层级包括“基本”层和“标准”层，建议将前者用于小型生产环境，将后者用于任务关键型生产应用程序。 有关详细信息，请参阅符合需要的层级。
暂停实例时不收取任何费用。
有关详细信息，请参阅 Azure Analysis Services 定价。
Blob 存储
请考虑使用 Azure 存储预留容量功能来降低存储成本。 使用此模型时，如果可以承诺预留一年或三年的固定存储容量，则可获得折扣。 有关详细信息，请参阅借助预留容量优化 Blob 存储的成本。
有关详细信息，请参阅 Microsoft Azure 架构良好的框架中的“成本”部分。
后续步骤
相关资源
可以查看以下 Azure 示例方案，了解使用部分相同技术的具体解决方案：