扩展 Azure 流分析作业规模以提高吞吐量

本文介绍如何优化Azure 流分析查询以提高吞吐量。 使用这些缩放模式通过更多带宽、CPU 和内存资源来处理更高的负载。

Azure 流分析度量流单元（SU）中的计算容量。 每个 SU V2 表示单个计算节点的完整容量。 所谓极易并行化的查询，是指每个输入分区均可独立处理，且分区之间不共享数据。

先决条件

在开始之前，请查看以下文章：

• 理解并调整流单元
• 创建可并行化作业

扩展可完全并行化的查询

如果您的查询在输入分区之间极易并行化，请按照以下步骤操作：

1. 编写查询以使用 PARTITION BY 关键字。 有关详细信息，请参阅 在 Azure 流分析中使用查询并行化。

2. 根据查询中使用的输出类型，某些输出可以是不可并行的，或者需要进一步的配置来使并行。 例如，配置输出以支持并行化。 并非所有输出类型都支持并行写入：

   输出类型	并行化支持
   Azure Blob 存储、Azure 表存储、Azure Data Lake Storage、Azure 服务总线、Azure Functions	自动
   Azure SQL 数据库，Azure Synapse Analytics	Optional. 需要配置
   Azure 事件中心	PartitionKey需要设置为与PARTITION BY字段匹配（通常为PartitionId）。 匹配输入和输出分区计数以避免交叉。
   Power BI	不可并行化。 输出在发送到接收器之前始终会先合并

3. 使用 1 SU V2 （这是单个计算节点的完整容量）运行查询，以测量可实现的最大吞吐量。 如果使用 GROUP BY，请评估该作业可处理的分组数量（基数）。

4. 检查系统资源限制。 出现以下症状表明，Azure 流分析 作业已触及资源限制：

   症状	可能的原因	Action
   SU 利用率指标超过 80%	内存使用率高。 请参阅 “了解和调整流式处理单元”。	添加更多 SU V2。
   输出时间戳滞后于挂钟时间	根据查询逻辑，输出时间戳可能会与墙上的时钟时间产生逻辑偏移。 但是，它们的速度应该大致相同。 如果输出时间戳进一步下降，则表示系统过度工作。 它可能是下游输出汇聚点的限流或 CPU 占用率过高的结果。 流分析目前不提供 CPU 利用率指标，因此很难区分这两个指标。	如果问题是由于接收端限流引起的，请增加输出分区（并增加输入分区以保持并行性），或者增加接收端资源（例如，Azure Cosmos DB 的请求单位）。
   每个分区的积压事件指标持续增加（可在作业图中看到）	输出端节流或 CPU 使用率过高	同上。

5. 线性推断容量。 确定 1 SU V2 可以处理的内容后，假设分区之间没有数据倾斜，则按比例添加更多 SU。

扩展非并行查询

如果查询不易并行，请执行以下步骤：

1. 在不使用 PARTITION BY 的情况下启动以避免复杂性。 使用 1 SU V2 运行查询以测量最大吞吐量。 检查上一部分所述的相同 资源限制症状 （SU 利用率超过 80%、输出时间戳滞后、积压工作增加）。

2. 如果达到目标吞吐量，则已完成。 （可选）使用 2/3 SU V2 和 1/3 SU V2 进行测试，以找出适用于您的场景的最少 SU V2 数量。

3. 如果无法达到所需的吞吐量，可将查询分解为多个步骤。 为每个步骤最多可分配 1 个 SU V2。 例如，一个三步查询需要 3 个 SU V2。 Azure 流分析将每个步骤放在其自己的专用节点上。

4. 如果仍未达到吞吐量目标，请在更靠近输入端的步骤中添加 PARTITION BY。 对于不可自然分区的 GROUP BY 操作，请使用本地/全局聚合模式：首先执行分区 的 GROUP BY，然后执行非分区 的 GROUP BY。 例如，当流量超过 1 SU V2 的处理能力时，可每 3 分钟统计一次通过各收费站的车辆数：

   WITH Step1 AS (
   SELECT COUNT(*) AS Count, TollBoothId, PartitionId
   FROM Input1 Partition By PartitionId
   GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId
   )
   SELECT SUM(Count) AS Count, TollBoothId
   FROM Step1
   GROUP BY TumblingWindow(minute, 3), TollBoothId
   

   此查询在步骤 1 中按分区、按收费站统计汽车数量，然后在最后一步对各分区的计数结果进行聚合。

   对查询进行分区后，为每个步骤的每个分区分配 1 个 SU V2，以便每个分区在其自己的处理节点上运行。

   注释

   如果无法对查询进行分区，在多步骤查询中添加更多 SU V2 可能无法提高吞吐量。 若要提高性能，请使用步骤 4 所示的本地/全局聚合模式，以减少初始几个步骤中的数据量。

在单个作业中扩展多个独立查询

对于多租户独立软件供应商（ISV）方案，在单个Azure 流分析作业中处理来自多个租户的数据（每个租户都有单独的输入和输出），每个子查询的负载通常很小。 执行以下步骤：

1. 不要在查询中使用 PARTITION BY 。

2. 如果使用Azure 事件中心，请将输入分区计数减少到最小值 2。

3. 使用 1 SU V2 运行查询。 在作业达到资源限制之前添加子查询。 症状与 完全并行的查询相同：SU 利用率超过 80%、输出时间戳延迟或增加积压工作。

4. 达到子查询限制后，将新的子查询添加到单独的作业。 作业数量随独立查询数量呈线性增长（假设不存在负载倾斜）。 然后，您可以预测需要运行多少 SU V2 作业，以满足您想要服务的租户数量。

5. 对于引用数据联接，请在与引用数据联接之前联合所有输入，然后拆分事件。 否则，每个引用数据联接都会在内存中保留一个单独的引用数据副本，这可能会导致不必要的内存使用。

获取帮助

如需进一步的帮助，请尝试 Azure 流分析的Microsoft问答页面。

相关内容

• Azure 流分析 简介
• 开始使用 Azure 流分析
• Azure 流分析查询语言参考
• Azure 流分析管理 REST API 参考