Azure 流分析输出的故障排除

本文介绍Azure 流分析输出连接的常见问题以及如何对其进行故障排除。 涉及的问题包括不生成输出的作业、延迟的第一个输出、落后的输出、Azure SQL 数据库密钥冲突和 SQL 重试行为。 许多故障排除步骤都需要为流分析作业启用资源日志和其他诊断日志。 如果没有启用资源日志，请参阅使用资源日志对 Azure 流分析进行故障排除。

作业不生成输出

  1. 使用每项输出对应的“测试连接”按钮来验证与输出的连接。

  2. 在“监视”选项卡上查看使用 Azure 门户监视流分析作业。由于这些值是聚合的，因此这些指标会延迟几分钟显示。

    • 如果“输入事件”的值大于零，则作业可以读取输入数据。 如果 Input Events 的值不大于零，则说明作业的输入有问题。 有关详细信息，请参阅对输入连接进行故障排除。 如果作业具有参考数据输入，请在查看Input Events指标时按逻辑名称进行拆分。 如果仅从参考数据中看不到任何输入事件，则很可能意味着此输入源未正确配置，无法获取正确的参考数据集。
    • 如果“数据转换错误”的值大于零并不断增大，请参阅 Azure 流分析数据错误，详细了解数据转换错误。
    • 如果“运行时错误”的值大于零，表示作业可以接收数据，但在处理查询时生成错误。 若要查找错误，请转到审核日志，然后筛选“失败”状态。
    • 如果“输入事件”的值大于零，而“输出事件”的值等于零，则下列陈述之一是正确的：
      • 查询处理导致了输出事件为零。
      • 事件或字段的格式可能不正确，导致在执行查询处理后的输出为零。
      • 由于连接或身份验证原因，作业无法将数据推送到输出接收器。

    操作日志消息解释了其他详细信息（包括具体发生了什么），但查询逻辑筛选掉所有事件的情况除外。 如果对多个事件的处理生成错误，则错误每 10 分钟聚合一次。

第一个输出被延迟

当流分析作业启动时，就会读取输入事件。 不过，在某些情况下，输出可能会有延迟。

在时态查询元素中使用较大的时间值可能会导致输出延迟。 为了在较大的时间窗口内生成正确的输出，流式作业会从尽可能晚的时间点开始读取数据，以补齐该时间窗口所需的数据。 数据最多可能延迟七天。 在读取未完成的输入事件之前，不会生成任何输出。 当系统升级流式处理作业时，可能会出现此问题。 当升级发生时，作业重启。 此类升级通常每隔几个月发生一次。

在设计流分析查询时，请保持审慎。 如果对作业查询语法中的时态元素使用长时间段，可能会导致首个输出在作业启动或重启时延迟。 超过几个小时（最长 7 天）就被视为长时间段。

缓解这种首个输出延迟的问题的一种方法是，使用查询并行化技术（如对数据进行分区）。 或者，可以添加更多流式处理单元来提高吞吐量，直到作业赶上进度。 有关详细信息，请参阅创建流分析作业时的注意事项。

下面这些因素会影响首个输出的及时性：

  • 使用窗口聚合，例如对翻转窗口、跳跃窗口和滑动窗口使用 GROUP BY 子句：

    • 对于翻转窗口或跳跃窗口聚合，结果在窗口时间范围结束时生成。
    • 对于滑动窗口，结果在事件进入或退出滑动窗口时生成。
    • 如果计划使用大的窗口大小（如超过一小时），最好选择跳跃窗口或滑动窗口。 使用这些类型的窗口，可以更频繁地看到输出。

  • 使用时态联接（如包含 DATEDIFF 的 JOIN）：

    • 一旦匹配事件的双方都到达，就会立即生成匹配结果。
    • 缺少匹配的数据（如 LEFT OUTER JOIN）在左侧每个事件的 DATEDIFF 窗口结束时生成。

  • 时态分析函数的使用，例如 ISFIRST、LAST，以及带有 LIMIT DURATION 的 LAG：

    • 对于分析函数，输出是针对每个事件生成的。 没有延迟。

输出因延迟增加而落后

在作业的正常操作期间，输出的延迟时间可能会越来越长。 如果输出像这样落后于进度，可以通过检查以下因素来确定根本原因：

  • 下游接收端是否被限流
  • 上游源是否被限流
  • 查询中的处理逻辑是否是计算密集型的

若要查看输出详细信息，请在 Azure 门户中选择流式处理作业，然后选择作业图。 对于每个输入，每个分区都有一个积压工作 (backlog) 事件指标。 如果指标持续增长，则表明系统资源受到约束。 这一增长可能是由于输出接收端限流或 CPU 使用率过高导致的。

Azure SQL 数据库输出中的键冲突警告

如果你将 Azure SQL 数据库配置为流分析作业的输出，它会将记录批量插入到目标表中。 一般来说，Azure 流分析保证至少一次传递到输出接收器。 当 SQL 表定义了唯一约束时，你仍然可以向 SQL 输出实现精确一次传递。

如果你在 SQL 表上设置唯一键约束，Azure 流分析会删除重复记录。 它将数据拆分为几个批，并以递归方式插入这些批，直到找到一个重复的记录。 拆分和插入过程会逐个忽略重复项。 对于包含多个重复行的流式处理作业，此过程效率低下且非常耗时。 如果你在前一个小时的活动日志中看到多个键冲突警告消息，则很可能是 SQL 输出拖慢了整个作业的速度。

若要解决此问题，请通过启用 IGNORE_DUP_KEY 选项来配置导致键冲突的索引。 使用此选项，SQL 可以在大容量插入期间忽略重复值。 Azure SQL 数据库只是生成警告消息，而不是错误。 因此，Azure 流分析不再生成主键冲突错误。

为多种类型的索引配置 IGNORE_DUP_KEY 时，应注意以下几点：

  • 无法对主键或使用 ALTER INDEX 的唯一约束设置 IGNORE_DUP_KEY。 必须删除该索引并重新创建它。
  • 可以使用 ALTER INDEX 为唯一索引设置 IGNORE_DUP_KEY。 此实例与 PRIMARY KEY/UNIQUE 约束不同，它是使用 CREATE INDEX 或 INDEX 定义创建的。
  • IGNORE_DUP_KEY 选项不应用于列存储索引，因为无法对此类索引强制实现唯一性。

Azure SQL 数据库 输出重试逻辑

当带有 SQL 输出的流分析作业收到第一批事件时，将执行以下步骤：

  1. 作业尝试连接到 SQL 数据库。
  2. 该作业获取目标表的结构。
  3. 作业针对目标表架构验证列名称和类型。
  4. 该作业根据批处理中的输出记录生成一个内存数据表。
  5. 作业使用 BulkCopy API 将数据表写入 SQL。

在这些步骤中，SQL 输出可能会遇到以下类型的错误：

  • 使用指数退避重试策略进行重试的瞬时错误。 最小重试间隔取决于各个错误代码，但是间隔通常小于 60 秒。 上限最多可为五分钟。

    登录失败和防火墙问题会在上次尝试后至少 5 分钟重试一次，直到成功为止。

  • 数据错误（如强制转换错误和架构约束冲突）将通过输出错误策略进行处理。 通过重试二进制拆分批处理来处理这些错误，直到导致错误的单个记录通过跳过或重试得到处理。 违反主唯一键约束始终会被处理。

  • 存在 SQL 服务问题或内部代码缺陷时，可能会出现非暂时性错误。 例如，当弹性池（代码 1132）等错误达到其存储限制时，重试无法解决此错误。 在这些情况下，流分析作业将遭遇降级。

  • 在步骤 5 的 BulkCopy 期间，可能发生 BulkCopy 超时。 BulkCopy 偶尔会发生操作超时。 默认配置的最小超时为五分钟，当连续达到此值时，它将增加一倍。 一旦超时超过 15 分钟，BulkCopy 的最大批处理大小提示将减少到一半，直到每批剩下 100 个事件为止。

Azure 流分析 (1.0) 中的列名称是小写的

如果使用的是原始兼容性级别 (1.0)，Azure 流分析会将列名称更改为小写。 此问题已在后续的兼容性级别中得到修复。 若要保留大小写形式，请迁移到兼容性级别 1.1 或更高。 有关详细信息，请参阅流分析作业的兼容性级别。

获取帮助

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

后续步骤

  • Last updated on