Synapse POC playbook：Azure Synapse Analytics 中使用专用 SQL 池的数据仓库
本文介绍了为专用 SQL 池准备和运行有效 Azure Synapse Analytics 概念证明 (POC) 项目的概要方法。
注意
本文是“Azure Synapse 概念证明 playbook”系列文章的一部分。 有关该系列的概述，请参阅 Azure Synapse 概念证明 playbook。
提示
如果你不熟悉专用 SQL 池，建议完成通过 Azure Synapse Analytics 使用数据仓库学习路径。
准备 POC
在确定 Azure Synapse POC 目标之前，建议先阅读 Azure Synapse SQL 体系结构一文，熟悉专用 SQL 池如何分隔计算和存储，以提供行业领先的性能。
识别赞助商和潜在的阻碍因素
熟悉 Azure Synapse 后，应确保 POC 有必要的支持，并且不会遇到任何障碍。 你应该：
- 确定组织在将数据迁移到云以及在云中存储数据方面的任何限制或策略。
- 确定基于云的数据仓库项目的管理人员和业务赞助。
- 验证工作负荷是否适合 Azure Synapse。 有关详细信息，请参阅 Azure Synapse Analytics 中的专用 SQL 池体系结构。
设置时间线
POC 是一个已设定范围、有时间限制的活动，有具体的、可衡量的目标和指标来定义成功。 理想情况下，它应该有一些商业现实的基础，这样结果才有意义。
为 POC 设定了时间框时，它的结果是最好的。 时间框为一项活动分配一个固定的、最大的时间单位。 在我们的经验中，两周的时间足以完成工作，不会有过多用例或复杂的测试矩阵的负担。 在此固定时间段内工作时，建议遵循以下时间线：
- 数据加载：不超过三天
- 查询：不超过五天
- 增值测试：不超过两天
下面是一些提示：
- 对完成计划中的任务所需的时间进行现实的估计。
- 认识到完成 POC 的时间将与数据集大小、数据库对象（表、视图和存储过程）数量、数据库对象的复杂性以及要测试的接口数量相关。
- 如果你估计 POC 的运行时间将超过四周，请考虑缩小范围，只关注最重要的目标。
- 在开始 POC 之前，请从所有潜在顾客资源和赞助商那里获得对时间线的支持。
当你确定没有任何直接障碍，并且设定了时间线后，就可以确定一个概要体系结构的范围了。
创建限定范围的概要体系结构
一个概要的未来体系结构可能包含许多数据源和数据使用者、大数据组件，可能还包括机器学习和 AI 数据使用者。 为了保持 POC 目标的可实现性（并且在你设定的时间线范围内），需要决定哪些组件将是 POC 的构成部分，哪些组件将被排除在外。
此外，如果你已经在使用 Azure，请确定以下内容：
- 可在 POC 期间使用的任何现有 Azure 资源。 例如，资源可以包括 Microsoft Entra ID 或 Azure ExpressRoute。
- 你的组织首选的 Azure 区域。
- 可用于非生产 POC 工作的订阅。
- 到 Azure 的网络连接的吞吐量。
重要
请务必检查 POC 是否可以消耗一些吞吐量，而不会对生产解决方案产生不利影响。
应用迁移选项
如果要从旧数据仓库系统迁移到 Azure Synapse，请考虑以下问题：
- 是否正在进行迁移，并希望对现有的提取、转换和加载 (ETL) 流程以及数据仓库的消耗进行尽可能少的更改？
- 是否正在进行迁移，但希望在此过程中进行一些广泛的改进？
- 是否在构建全新的数据分析环境（有时称为绿地项目）？
接下来，你需要考虑一些痛点。
识别目前的痛点
POC 应包含用例，以证明潜在解决方案可以解决目前的痛点。 下面是一些需要考虑的问题：
- 你期望 Azure Synapse 填补当前实现中的哪些差距？
- 你需要支持哪些新的业务需求？
- 需要满足哪些服务级别协议 (SLA)？
- 工作负荷是什么（例如，ETL、批处理查询、分析、报告查询或交互式查询）？
接下来，需要设置 POC 成功条件。
设置 POC 成功条件
明确你要执行 POC 的原因，并确保设立明确的目标。 同样重要的是了解你所需的 POC 输出，以及计划用它们做什么。
请记住，POC 应该是一项简短而集中的工作，用来快速证明或测试一组有限的概念。 如果你有一长串要证明的项目，你可能想要将它们深入到多个 POC 中。 各个 POC 之间是可以有门的，因此你可以确定是否继续进行下一个 POC。
下面是一些 POC 目标的示例：
- 需要知道大型复杂报告查询的查询性能将满足我们新的 SLA。
- 需要知道交互式用户的查询性能。
- 需要知道现有 ETL 流程是否适合，以及哪方面需要改进。
- 需要知道是否可以缩短 ETL 运行时，以及缩短多少。
- 需要知道 Synapse Analytics 有足够的安全功能来充分保障数据安全。
接下来要创建测试计划。
创建测试计划
使用目标，确定要运行的具体测试，以支持这些目标并提供已确定的输出。 务必要确保对每个目标和预期输出至少有一个测试。 确定要运行的具体查询、报表、ETL 和其他流程，以提供可量化的结果。
通过添加多个测试场景来完善测试，以明确出现的任何表结构问题。
良好的计划通常决定了有效的 POC 执行。 确保所有利益干系人都同意一个书面测试计划，该计划将每个 POC 目标与一组清晰陈述的测试用例和成功的度量联系起来。
大多数测试计划都围绕性能和预期的用户体验展开。 下面是一个测试计划的示例。 务必要自定义测试计划以满足业务需求。 明确定义要测试的内容，在这个过程后期会有收获。
| 目标 | 测试 | 预期结果 |
|---|---|---|
| 需要知道大型复杂报告查询的查询性能将满足我们新的 SLA | - 复杂查询的顺序测试 - 根据规定的 SLA 对复杂查询进行并发测试 |
- 查询 A、B 和 C 分别在 10 秒、13 秒和 21 秒内完成 - 对于 10 个并发用户、查询 A、B 和 C 平均在 11 秒、15 秒和 23 秒内完成 |
| 需要知道交互式用户的查询性能 | - 在预期并发级别为 50 个用户的情况下，对所选查询进行并发测试。 - 运行前面的带有结果集缓存的查询 |
- 在 50 个并发用户的情况下，预计平均执行时间将低于 10 秒，并且没有结果集缓存 - 在 50 个并发用户的情况下，预计平均执行时间将低于 5 秒，并且有结果集缓存 |
| 需要知道现有 ETL 流程是否可以在 SLA 中运行 | - 运行一两个 ETL 流程来模拟生产负荷 | - 以增量方式加载到核心事实数据表必须在 20 分钟内完成（包括暂存和数据清理） - 维度处理需要少于 5 分钟 |
| 需要知道数据仓库有足够的安全功能来保障数据安全 | - 检查并启用网络安全（VNet 和专用终结点）、访问控制（行级别安全性、动态数据掩码） | - 证明数据从未离开我们的租户。 - 确保客户内容易于保护 |
接下来，需要标识和验证 POC 数据集。
标识并验证 POC 数据集
使用限定范围的测试，现在可以确定在 Azure Synapse 中执行这些测试所需的数据集。 要查看数据集，请考虑以下几点：
- 验证数据集在内容、复杂性和规模方面是否充分代表了你的生产数据集。
- 不要使用太小（小于 1TB）的数据集，因为可能无法实现具有代表性的性能。
- 不要使用太大的数据集，因为 POC 并不是为了完成一个完整的数据迁移。
- 确定每个表的分布模式、索引选项和分区。 如果对分布、索引或分区有任何疑问，请在 POC 中添加测试以解答问题。 请记住，你可能要为一些表测试多个分布选项或索引选项。
- 向业务所有者了解将 POC 数据集迁移到云的任何阻碍因素。
- 确定任何安全或隐私问题。
重要
在将任何数据迁移到云之前，请确保与业务所有者核实是否有任何阻碍因素。 在将数据迁移到云之前，确定应处理的任何安全或隐私问题或任何数据混淆需求。
接下来，需要组建专家团队。
组建团队
确定团队成员及其支持 POC 的承诺。 团队成员应包括：
- 一位项目经理，负责开展 POC 项目。
- 一位业务代表，负责监督需求和结果。
- 一位应用程序数据专家，负责为 POC 数据集提供数据来源。
- 一位 Azure Synapse 专家。
- 一位专家顾问，负责优化 POC 测试。
- 任何需要完成具体 POC 项目任务但不需要在整个项目期间工作的人员。 这些支持资源可以包括网络管理员、Azure 管理员或 Microsoft Entra 管理员。
提示
建议聘请专家顾问来协助完成 POC。 Microsoft 合作伙伴社区拥有在全球各地提供支持的专家顾问，可帮助你评估、衡量或实施 Azure Synapse。
你已经做好了充分的准备，现在可以将 POC 付诸实践了。
将 POC 付诸实施
谨记以下几点：
- 遵循任何生产项目的纪律和严格性来实施 POC 项目。
- 根据计划运行 POC。
- 制定好更改请求流程，防止 POC 范围扩大或改变。
在测试开始之前，你需要设置测试环境。 它涉及四个阶段：
- 设置
- 数据加载
- 查询
- 增值测试
安装
可以按照以下步骤在 Azure Synapse 上设置 POC：
- 使用本快速入门预配 Synapse 工作区，并根据 POC 测试计划设置存储和权限。
- 使用本快速入门将专用 SQL 池添加到 Synapse 工作区。
- 根据要求设置网络和安全性。
- 向 POC 团队成员授予适当的访问权限。 请参阅本文，了解用于访问专用 SQL 池的身份验证和授权。
提示
建议使用 DW500c 服务级别（或更低级别）开发代码和单元测试。 建议使用 DW1000c 服务级别（或更高级别）运行负载和性能测试。 可以随时暂停专用 SQL 池的计算，以停止计算计费，这可以节省成本。
数据加载
设置专用 SQL 池后，可以按照以下步骤加载数据：
- 将数据加载到 Azure Blob 存储中。 对于 POC，建议将常规用途 V2 存储帐户与本地冗余存储 (LRS) 配合使用。 虽然可以使用一些工具将数据迁移到 Azure Blob 存储，但最简单的方法是使用 Azure 存储资源管理器，它可以将文件复制到存储容器中。
- 将数据加载到专用 SQL 池中。 Azure Synapse 支持两种 T-SQL 加载方法：PolyBase 和 COPY 语句。 你可以使用 SSMS 连接到专用 SQL 池以使用任一方法。
当你第一次将数据加载到专用 SQL 池时，需考虑要使用的分发模式和索引选项。 虽然专用 SQL 池支持这两者的多种方法，但最佳做法是依赖默认设置。 默认设置使用轮循机制分布和聚集列存储索引。 如有必要，可以稍后调整这些设置，本文稍后将对此进行介绍。
下面的示例演示了 COPY 加载方法：
--Note when specifying the column list, input field numbers start from 1
COPY INTO
test_1 (Col_1 default 'myStringDefault' 1, Col_2 default 1 3)
FROM
'https://myaccount.blob.core.chinacloudapi.cn/myblobcontainer/folder1/'
WITH (
FILE_TYPE = 'CSV',
CREDENTIAL = (IDENTITY = 'Storage Account Key' SECRET = '<Your_Account_Key>'),
FIELDQUOTE = '"',
FIELDTERMINATOR = ',',
ROWTERMINATOR = '0x0A',
ENCODING = 'UTF8',
FIRSTROW = 2
);
查询
数据仓库的主要用途是执行分析，这需要查询数据仓库。 大多数 POC 首先针对数据仓库运行少量具有代表性的查询，先按顺序运行，然后是并发运行。 应在测试计划中定义这两种方法。
顺序查询测试
在 SSMS 中运行顺序查询测试是很容易的。 重要的是，使用具有足够大的资源类的用户运行这些测试。 资源类是专用 SQL 池中预先确定的资源限制，用于管理查询执行的计算资源和并发性。 对于简单的查询，建议使用预定义的 staticrc20 资源类。 对于更复杂的查询，建议使用预定义的 staticrc40 资源类。
请注意，以下第一个查询使用了查询标签来提供跟踪查询的机制。 第二个查询使用了 sys.dm_pdw_exec_requests 动态管理视图按标签进行搜索。
/* Use the OPTION(LABEL = '') Syntax to add a query label to track the query in DMVs */
SELECT TOP (1000)
*
FROM
[dbo].[Date]
OPTION (LABEL = 'Test1');
/* Use sys.dm_pdw_exec_requests to determine query execution duration (ms) */
SELECT
Total_elapsed_time AS [Elapsed_Time_ms],
[label]
FROM
sys.dm_pdw_exec_requests
WHERE
[label] = 'Test1';
并发查询测试
记录顺序查询性能后，可以同时运行多个查询。 这样，就可以模拟针对专用 SQL 池运行的商业智能工作负荷了。 运行此测试的最简单方法是下载压力测试工具。 最常使用的工具是 Apache JMeter，它是一个第三方开源工具。
该工具报告给定并发级别的最小、最大和中值查询持续时间。 例如，假设你要模拟一个可生成 100 个并发查询的商业智能工作负荷。 可以设置 JMeter 以在循环中运行这 100 个并发查询，然后查看稳定状态执行。 可以在打开或关闭结果集缓存的情况下执行，评估该功能的适用性。
请务必记录结果。 下面是一些结果示例：
| 并发 | 查询运行数量 | DWU | 最小持续时间（秒） | 最大持续时间（秒） | 中值持续时间（秒） |
|---|---|---|---|---|---|
| 100 | 1,000 | 5,000 | 3 | 10 | 5 |
| 50 | 5,000 | 5,000 | 3 | 6 | 4 |
混合工作负荷测试
混合工作负荷测试是并发查询测试的一个扩展。 通过将数据加载过程添加到工作负荷组合中，工作负荷将能够更好地模拟实际生产工作负荷。
优化数据
根据 Azure Synapse 上运行的查询工作负载，可能需要优化数据仓库的分布和索引并重新运行测试。
设置过程中最常见的错误包括：
- 使用过低的资源类运行大型查询。
- 专用 SQL 池服务级别 DWU 对于工作负荷而言太低。
- 大型表需要哈希分布。
为提高查询性能，可以执行以下操作：
增值测试
查询性能测试完成后，就可以测试具体功能了，验证它们是否符合预期用例。 这些功能包括：
最后，需要解释 POC 结果。
解释 POC 结果
在获得数据仓库的测试结果后，务必要解释该数据。 一种常见的方法是在价格/性能方面比较运行。 简单地说，价格/性能消除了每个 DWU 或服务硬件的价格差异，并为每个性能测试提供了单一的可比较数字。
下面是一个示例：
| 测试 | 测试持续时间 | DWU | DWU 的每小时价格（美元） | 测试成本 |
|---|---|---|---|---|
| 测试 1 | 10 分钟 | 1000 | �80.5/小时 | �13.416 |
| 测试 2 | 30 分钟 | 500 | �40.25/小时 | �20.125 |
从此示例不难看出，DWU 为 1000 的测试 1 的每次测试运行成本为 13.416 美元，比每次测试运行成本为 20.125 美元的测试 2 更具成本效益。
注意
还可以使用此方法来比较 POC 中不同供应商的结果。
总之，完成所有 POC 测试后，就可以评估结果了。 首先评估是否符合 POC 目标，是否收集了所需的输出。 记下哪些地方需要进行额外的测试，以及提出的其他问题。