你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

扩展 Azure 流分析作业以增加吞吐量

本文介绍如何优化流分析查询,增加流分析作业的吞吐量。 可以使用以下指南来扩展作业,以便处理较高负载并充分利用更多的系统资源(如更多带宽、更多 CPU 资源、更多内存)。

作为先决条件,请阅读以下文章:

案例 1 – 在各个输入分区中,查询本质上是完全可并行的

如果在各个输入分区中,查询本质上是完全可并行的,则可以按照以下步骤操作:

  • 通过使用 PARTITION BY 关键字来创作查询使之易并行。 有关详细信息,请参阅利用 Azure 流分析中的查询并行化
  • 根据查询中使用的输出类型,某些输出可能是不可并行的,或者需要进一步配置来实现易并行。 例如,Power BI 输出不可并行化。 请始终先合并输出,然后再将其发送到输出接收器。 Blob、表、Azure Data Lake Storage、服务总线和 Azure Function 会自动并行化。 SQL 和 Azure Synapse Analytics 输出具有并行化选项。 事件中心需要将 PartitionKey 配置设置为与 PARTITION BY 字段(通常是 PartitionId)匹配。 对于事件中心,还要格外注意匹配所有输入和所有输出的分区数量,以避免分区之间的交叉。
  • 使用 1 个 流单元 (SU) V2(即单个计算节点的全部容量)运行查询,来测量可实现的最大吞吐量;如果你使用的是 GROUP BY,则测量作业能处理的组数(基数)。 达到系统资源限制的作业,一般症状将如下所示。
    • 流单元 (SU) 利用率指标超过 80%。 它指示内存使用率较高。 了解和调整流分析流单元中介绍了导致此指标上升的因素。
    • 输出时间戳滞后于时钟时间。 根据查询逻辑,输出时间戳可能与时钟时间之间存在一个逻辑偏差。 但是,它们应该以大致相同的速度增进。 如果输出时间戳进一步滞后,则指示系统工作时间过长。 它可能是由于下游输出接收器限制,或高 CPU 利用率所致。 我们目前没有提供 CPU 利用率指标,因此很难区分两者。
      • 如果该问题是由接收器限制导致,则需要增加输出分区数(还要增加输入分区数,以使作业保持完全可并行化),或者增加接收器的资源量(例如,Cosmos DB 的请求单位数)。
    • 在作业关系图中,每个输出都有一个分区积压工作事件指标。 如果积压工作事件指标持续增加,则同样表示系统资源受到约束(由于输出接收器限制或高 CPU)。
  • 在确定 1 SU V2 作业可达到的上限后,可在添加更多 SU 时线性推断出作业的处理容量,前提是你没有任何导致某些分区“紧迫”的数据倾斜。

注意

选择适当数量的流单元:由于流分析为所添加的每个 1 SU V2 都创建一个处理节点,因此最好将节点数作为输入分区数的除数,以便分区可均匀分布在各节点上。 例如,你已经测量出 1 SU V2 作业可实现 4 MB/秒的处理速率,并且输入分区计数为 4。 你可选择使用 2 个 SU V2 来运行作业来实现大约 8 MB/秒的处理速率,或者使用 4 SU V2 来实现 16 MB/秒的处理速率。 然后,你可以决定何时增加作业的 SU 数量以及增加至多少,以作为输入速率的一个函数。

案例 2 - 如果查询不易并行。

如果查询不易并行,可执行以下步骤。

  • 首先使用不带 PARTITION BY 的查询来避免分区复杂性,然后使用 1 个 SU V2 运行查询来测量最大负载,如案例 1 中所示。
  • 如果能在吞吐量方面达到预期负载,则目标达成。 或者,你可选择测量使用小数节点(2/3 个 SU V2 和 1/3 个 SU V2)运行的相同作业,找到适合你的场景的流单元最小数目。
  • 如果无法实现所需的吞吐量,请尝试将查询分解为多个步骤(如果尚没有多个步骤),并为查询中的每个步骤分配最多 1 个 SU V2。 例如,如果有 3 个步骤,则在“规模”选项中分配 3 个 SU V2。
  • 为了运行这类作业,流分析会将每个步骤置于其自己包含专用的 1 个 SU V2 资源的节点上。
  • 如果仍未实现负载目标,可以尝试使用 PARTITION BY,从更接近输入的步骤开始。 对于不自然分区的 GROUP BY 运算符,可以使用本地/全局聚合模式来执行分区的 GROUP BY,然后执行非分区 GROUP BY。 例如,如果你想要计算每 3 分钟通过每个收费站的车辆数量,并且数据量超出了 1 个 SU V2 可处理的量。

查询:

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 个 SU V2,这样每个分区都可置于其自己的处理节点上。

注意

如果无法对查询进行分区,则在多步骤查询中添加额外的 SU 可能无法始终有效地提高吞吐量。 获得性能的一种方法是,使用本地/全局聚合模式来减少初始步骤的数量,如步骤 5 中所述。

案例 3 - 在作业中运行大量独立查询。

对于某些 ISV 用例,如果在单个作业中处理来自多个租户的数据更具经济效益,则可为每个租户使用单独的输入和输出,你最终会在单个作业中运行相当多的(例如 20 个)独立查询。 假设条件是每个此类子查询的负载都相对较小。

在这种情况下,可以按照以下步骤操作。

  • 在这种情况下,请勿在查询中使用 PARTITION BY
  • 如果使用事件中心,则将输入分区计数减少到可能的最低值 2。
  • 使用 1 个 SU V2 运行查询。 通过每个子查询的预期负载,尽可能多地添加此类子查询,直到作业达到系统资源上限。 有关发生这种情况时的症状,请参阅案例 1
  • 一旦达到测出的子查询上限,就可开始向新作业添加子查询。 作为独立查询数量的函数运行的作业数应是标准线性的,前提是你没有任何负载偏移。 然后,可根据你需要处理的租户数预测需要运行多少个 SU V2 作业。
  • 将引用数据联接与此类查询结合使用时,应在使用相同引用数据进行联接之前将输入合并在一起。 然后再根据需要拆分事件。 否则,每个引用数据联接会在内存中保留一份引用数据,可能导致不必要的内存使用。

注意

每个作业中要放置多少租户? 此查询模式通常具有大量子查询,并导致非常大且复杂的拓扑。 作业控制器可能无法处理此类大型拓扑。 一般来说,1/3 SU V2 作业保持在 40 个租户以下,2/3 SU V2 作业和 1 SU V2 作业则为 60 个租户。 当超出控制器的容量时,作业将无法成功启动。

获取帮助

如需获取进一步的帮助,可前往 Azure 流分析的 Microsoft 问答页面

后续步骤