Azure 流分析查询的故障排除

本文介绍了编写 Azure 流分析查询时遇到的常见问题，以及如何排查和更正查询问题。 许多故障排除步骤要求为流分析作业启用资源日志。 如果没有启用资源日志，请参阅使用资源日志对 Azure 流分析进行故障排除。

查询没有产生预期输出

1. 通过本地测试检查错误：

   • 在 Azure 门户的查询标签页中，选择测试。 使用下载的示例数据测试查询。 检查并尝试修正所有错误。
   • 你也可以使用Visual Studio或Visual Studio Code的Azure 流分析工具在本地测试查询。

2. 在适用于 Visual Studio Code 的 Azure 流分析工具中，使用作业关系图对查询进行本地分步调试。 作业图展示了数据如何从输入源（例如 Azure 事件中心 和 Azure IoT 中心）经过多个查询步骤，最终流向输出汇。 脚本将每个查询步骤映射到你用WITH语句定义的临时结果集。 查看每个中间结果集的数据和指标，以找出问题根源。

   

3. 如果使用了 Timestamp By，请验证事件的时间戳是否大于作业开始时间。

4. 避免常犯的错误，例如：

   • 查询中的 WHERE 子句过滤掉了所有事件，因此查询不产生输出。
   • CAST 函数失败，导致作业失败。 为了避免类型强制转换失败，请改用 TRY_CAST。
   • 使用窗口函数时，请等待整个窗口持续时间完成，以查看查询中的输出。
   • 事件的时间戳早于作业开始时间，因此该作业会丢弃这些事件。
   • JOIN 条件不匹配。 如果没有匹配，查询就不产生输出。

5. 确保你按照预期配置事件排序策略。 转到“设置”，选择“事件排序” 。 Test 按钮在测试查询时不会应用该策略。 这一结果是浏览器内测试与生产环境中运行作业的一个区别。

6. 使用活动和资源日志进行调试：

   • 使用活动日志，并通过筛选来识别和调试错误。
   • 使用作业资源日志来发现和调试错误。

逐步调试查询

在实时数据处理中，了解查询中数据的样子很有帮助。 要查看中间数据，请使用Visual Studio中的作业图。 如果你没有 Visual Studio，可以采取额外步骤来输出中间数据。

因为 Azure 流分析 可以多次读取作业的输入或步骤，你可以写额外的SELECT INTO语句。 这样做会把中间数据输出到存储中，并让你检查数据的正确性，就像调试程序时 的watch变量 一样。

下列 Azure 流分析作业中的示例查询具有一个流输入、两个引用数据输入和一个向 Azure 表存储的输出。 该查询联接来自事件中心和两个参考 Blob 的数据，以获取名称和类别信息：

作业正在运行，但输出中没有产生任何事件。 在此处显示的 监控 图块上，你可以看到输入正在产生数据，但你不知道 JOIN 的哪个步骤丢失了所有事件。

在这种情况下，你可以添加几个额外的 SELECT INTO 语句来“记录” JOIN 中间结果和从输入读取的数据。

在这个例子中，我们新增了两个“临时输出”。它们可以是你喜欢的任何水槽。 此处使用 Azure 存储作为示例：

然后，可以重写查询，如下所示：

现在再次启动该作业，让它运行几分钟。 然后查询temp1并temp2用 Visual Studio 云资源管理器生成以下表格：

temp1 表

temp2 表

如你所见，temp1和temp2都包含数据，并且在temp2中，name列已正确填充。 然而，由于输出仍然没有数据，说明某处出了问题：

通过对数据进行抽样，你几乎可以确定问题出在第二个 JOIN。 可以从 Blob 下载并查看引用数据：

如你所见，该参考数据中的 GUID 格式与 [from] 中 temp2 列的格式不同。 这就是为什么数据没有如预期般到达 output1 。

修正数据格式，上传到参考 blob，然后再试一次：

此时，输出中的数据按预期格式化和填充。

资源利用率高

确保利用 Azure 流分析中的并行化。 了解如何通过配置输入分区并优化分析查询定义，借助流分析作业的查询并行化实现扩展。

如果资源利用率始终超过 80%，水印延迟持续上升，且积压事件数量持续增加，请考虑增加流单元数。 高利用率指示作业使用的资源数接近分配的最大资源数。

获取帮助

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

相关内容

• Azure 流分析 简介
• 开始使用 Azure 流分析
• 扩展 Azure 流分析作业的规模
• Azure 流分析查询语言参考
• Azure 流分析管理 REST API 参考