Synapse POC 演练手册：Azure Synapse Analytics 中使用专用 SQL 池的数据仓库

本文介绍了一种高级方法，用于为专用 SQL 池准备和运行有效的 Azure Synapse Analytics 概念证明 (POC) 项目。

在确定 Azure Synapse POC 目标之前，建议先阅读 Azure Synapse SQL 体系结构一文，熟悉专用 SQL 池如何分离计算和存储，以提供行业领先的性能。

熟悉 Azure Synapse 后，就需要确保 POC 获得必要的支持并且不会遇到任何障碍。 您应该：

• 确定组织在将数据迁移和存储到云方面的任何限制或策略。
• 确定基于云的数据仓库项目的行政和业务赞助。
• 验证你的工作负载是否适合 Azure Synapse。 有关详细信息，请参阅 Azure Synapse Analytics 中的专用 SQL 池体系结构。

POC 是一种有范围和时间限制的练习，具有特定的、可衡量的目标和指标来定义成功。 理想情况下，它应该有一些业务现实基础，这样的结果才是有意义的。

POC 在时间框中具有最佳结果。 时间框将为活动分配一个固定的最大时间单位。 根据我们的经验，只要两周就足以完成相关工作，而且无需担心有太多用例或复杂的测试矩阵。 在这个固定时间段内工作时，建议遵循以下时间线：

1. 数据加载：三天或更短时间
2. 查询：五天或更短时间
3. 增值测试：两天或更短时间

下面是一些提示：

一旦确定没有任何直接障碍并设置了时间线，就可以确定高级体系结构的范围。

未来的高级体系结构可能包含许多数据源和数据使用者、大数据组件，以及机器学习和 AI 数据使用者。 为了使你的 POC 目标可以实现（并在你设定的时间线范围内），请确定这些组件中的哪些将构成 POC 的一部分，哪些将被排除在外。

此外，如果你已经在使用 Azure，请确定以下内容：

• 可以在 POC 期间使用的任何现有 Azure 资源。 例如，资源可以包括 Microsoft Entra ID 或 Azure ExpressRoute。
• 组织首选的 Azure 区域。
• 可用于非生产 POC 工作的订阅。
• 与 Azure 的网络连接的吞吐量。

  Importante

  请务必检查你的 POC 是否可以使用部分吞吐量，而不会对生产解决方案产生不利影响。

如果要从旧数据仓库系统迁移到 Azure Synapse，请考虑以下问题：

• 你是否正在迁移，并希望对现有的提取、转换和加载 (ETL) 流程和数据仓库使用进行尽可能少的更改？
• 是否在迁移的同时希望进行一些广泛的改进？
• 你是否正在构建全新的数据分析环境（有时称为绿地项目）？

接下来，你需要考虑你所面临的一些难题。

你的 POC 应包含一些用例，以证明潜在解决方案可以解决你当下面临的难题。 下面是需要考虑的一些问题：

• 你希望 Azure Synapse 填补当前实施中的哪些空白？
• 你需要支持哪些新的业务需求？
• 你需要满足哪些服务级别协议 (SLA)？
• 工作负载是什么（例如，ETL、批处理查询、分析、报告查询或交互式查询）？

接下来，你需要设置 POC 成功标准。

确定你为什么要进行 POC，并确保定义明确的目标。 了解你想要从 POC 中获得的结果以及你打算用它们做什么也很重要。

请记住，POC 应该是一个简短而集中的工作，用于快速证明或测试一组有限的概念。 如果你有一长串需要证明的项，你可能希望将它们深入到多个 POC 中。 POC 之间可以设入口，这样你就可以确定是否继续进行下一个 POC。

下面是一些 POC 目标示例：

• 我们需要知道大型复杂报告查询的查询性能将满足新的 SLA。
• 我们需要知道交互式用户的查询性能。
• 我们需要知道现有的 ETL 流程是否合适，以及需要改进的地方。
• 我们需要知道是否可以缩短 ETL 的运行时间以及缩短多少。
• 我们需要知道 Synapse Analytics 具有足够的安全功能来充分保护我们的数据。

接下来，你需要创建一个测试计划。

根据目标确定要运行的具体测试，以支持这些目标并提供确定的结果。 务必确保至少有一个测试来支持每个目标和预期结果。 确定要运行的具体查询、报告、ETL 和其他流程，以提供可量化的结果。

通过添加多个测试方案来优化测试，以阐明出现的任何表结构问题。

良好的计划通常决定了有效的 POC 执行。 制定一个书面测试计划，将每个 POC 目标与一组明确表述的测试用例和成功衡量标准联系起来，并确保所有利益干系人都同意该计划。

大多数测试计划都围绕性能和预期的用户体验。 下面是一个测试计划示例。 自定义测试计划以满足业务需求很重要。 通过明确定义要测试的内容，可在此过程的后期获得回报。

接下来，需要确定和验证 POC 数据集。

使用范围测试，现在可以确定在 Azure Synapse 中执行这些测试所需的数据集。 通过考虑以下几点来审查数据集：

• 验证数据集在内容、复杂性和规模方面是否充分代表了你的生产数据集。
• 不要使用太小（小于 1TB）的数据集，因为你可能无法获得有代表性的性能。
• 不要使用太大的数据集，因为 POC 并非旨在完成完整的数据迁移。
• 确定每个表的分布模式、索引选项和分区。 如果有任何关于分布、索引或分区的问题，请在 POC 中添加测试来回答这些问题。 请记住，你可能需要为某些表测试多个分布选项或索引选项。
• 向业务所有者了解将 POC 数据集迁移到云的任何障碍。
• 确定任何安全或隐私问题。

接下来，你需要组建专家团队。

确定团队成员及其支持 POC 的承诺。 团队成员应包括：

• 运行 POC 项目的项目经理。
• 一名业务代表，负责监督要求和结果。
• 为 POC 数据集提供数据的应用程序数据专家。
• Azure Synapse 专家。
• 优化 POC 测试的专家顾问。
• 任何需要完成特定 POC 项目任务，但不需要参与整个项目的人。 这些支持资源可以包括网络管理员、Azure 管理员或 Microsoft Entra 管理员。

现在万事俱备，是时候将 POC 付诸实践了。

请务必记住以下几点：

• 按照任何生产项目的纪律和严格性来实施 POC 项目。
• 按计划运行 POC。
• 制定更改请求流程，以防止 POC 范围扩大或改变。

在开始测试之前，需要设置测试环境。 它包括四个阶段：

1. 设置
2. 数据加载
3. 查询
4. 增值测试

可以按照以下步骤在 Azure Synapse 上设置 POC：

1. 使用此快速入门来预配 Synapse 工作区，并根据 POC 测试计划设置存储和权限。
2. 使用此快速入门将专用 SQL 池添加到 Synapse 工作区。
3. 根据要求设置网络和安全性。
4. 向 POC 团队成员授予适当的访问权限。 有关用于访问专用 SQL 池的身份验证和授权，请参阅这篇文章。

设置专用 SQL 池后，可以按照以下步骤加载数据：

1. 将数据加载到 Azure Blob 存储。 对于 POC，建议使用具有本地冗余存储 (LRS) 的常规用途 V2 存储帐户。 虽然可以通过多种工具将数据迁移到 Azure Blob 存储，但最简单的方法是使用 Azure 存储资源管理器，它可以将文件复制到存储容器中。
2. 将数据加载到专用 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 个并发查询，然后查看稳态执行。 你可以在打开或关闭结果集缓存的情况下执行此操作，以评估该功能的适用性。

请务必记录你的结果。 下面是一些结果的示例：

混合工作负载测试是并发查询测试的延伸。 通过在工作负载组合中添加数据加载过程，工作负载将更好地模拟真实的生产工作负载。

根据 Azure Synapse 上运行的查询工作负荷，可能需要优化数据仓库的分布和索引并重新运行测试。

设置过程中出现的最常见错误包括：

• 大型查询使用过低的资源类运行。
• 专用 SQL 池服务级别 DWU 对工作负载而言过低。
• 大型表需要哈希分布。

若要提高查询性能，你可以：

• 创建具体化视图，这类视图可以加速涉及常见聚合的查询。
• 复制表，尤其是对于小型维度表。
• 哈希分布联接或聚合的大型事实数据表。

一旦完成查询性能测试，就是测试特定功能以验证它们是否满足预期用例的好时机。 这些功能包括：

• 行级安全
• 列级别安全性
• 动态数据屏蔽
• 通过工作负载隔离实现群集内缩放

最后，需要解释 POC 结果。

获得数据仓库的测试结果后，必须解释该数据。 你可以采用的一种常见方法是从性价比方面来比较运行。 简而言之，性价比消除了每个 DWU 或服务硬件的价格差异，并为每个性能测试提供了一个可比较的数字。

下面是一个示例：

通过此示例，可以轻松地看出 DWU1000 处的测试 1 每次测试运行成本为 �13.416，与每次测试运行成本 �20.125 相比更具成本效益。

总之，一旦完成所有 POC 测试，即可评估结果。 首先评估是否达到了 POC 目标，并收集了所需的结果。 记下需要额外测试的地方以及提出的其他问题。