为 Azure 流分析配置事件排序策略

本文介绍如何在Azure 流分析中设置和使用延迟到达和无序事件策略。 仅当在查询中使用 TIMESTAMP BY 子句时，才会应用这些策略，这些策略仅应用于云输入源。

事件时间和到达时间

流分析作业可以根据事件时间或抵达时间处理事件。 事件/应用程序时间 是事件有效负载中存在的时间戳（生成事件时）。 抵达时间是输入源（事件中心/IoT 中心/Blob 存储）收到事件时的时间戳。

默认情况下，Stream Analytics 按 到达时间 处理事件，但你可以通过在查询中使用 TIMESTAMP BY 子句，选择按 事件时间 处理事件。 仅当按事件时间处理事件时，延迟到达和乱序策略才适用。 配置这些设置时，请考虑方案的延迟和正确性要求。

什么是迟到政策？

有时，由于各种原因，事件会迟到。 例如，延期 40 秒抵达的事件的事件时间为 00:10:00，抵达时间为 00:10:40。 如果将延迟到达策略设置为 15 秒，则到达时间超过 15 秒的任何事件都将被删除（流分析未处理）或调整其事件时间。 在以上示例中，由于事件延期 40 秒抵达（超过了设置的策略），其事件时间将调整为延期抵达策略最大值，即 00:10:25（到达时间 - 延期抵达策略值）。 默认的延期抵达策略为 5 秒。

什么是失序策略？

事件也可能乱序到达。 根据延期抵达策略调整事件时间后，还可以选择自动丢弃或调整失序的事件。 如果将此策略设置为 8 秒，则任何乱序到达但在 8 秒窗口内的事件都会按事件时间重新排序。 延迟到达的事件将被丢弃，或调整为乱序策略允许的最大值。 默认乱序策略为 0 秒。

调整或删除延迟和无序事件

如果事件根据配置的策略延期抵达或失序抵达，你可以丢弃此类事件（不会由流分析处理），或者调整其事件时间。

以下示例演示了这些策略。

• 延迟到达策略： 15 秒
• 乱序策略： 5 秒

事件编号	事件时间	到达时间	System.Timestamp	说明
1	00:10:00	00:10:40	00:10:25	事件延迟到达且超出容差范围。 因此，事件时间会被调整为最大延迟到达容忍度。
2	00:10:30	00:10:41	00:10:30	事件到达较晚，但仍在容差范围内。 因此，事件时间不会被调整。
3	00:10:42	00:10:42	00:10:42	事件已按时到达。 无需调整。
4	00:10:38	00:10:43	00:10:38	事件到达顺序错乱，但仍在 5 秒容差范围内。 因此，事件时间不会被调整。 为了分析，此事件将被视为前面的事件编号 3（假设总共 5 个事件。实际顺序为：1、2、5、4、3）。
5	00:10:35	00:10:45	00:10:37	事件乱序到达，且超出 5 秒的容差范围。 因此，事件时间会被调整为乱序容忍度的最大值。

延迟到达和无序策略是否可以延迟作业输出？

是的。 默认情况下，失序策略设置为 0（00 分 00 秒）。 如果更改默认值，则作业的第一个输出将按此值延迟（或有更大的延迟）。

如果你的某个输入分区没有收到事件，则应预计输出会按延迟到达策略值所设定的时长延迟。 若要了解原因，请参阅InputPartitionNotProgressing 消息。

我在活动日志中看到 LateInputEvents 消息

显示这些消息是为了通知您，事件已延迟到达，并根据您的配置被丢弃或调整。 如果已正确配置延迟到达策略，则可以忽略这些消息。

下面是此消息的示例：

{"message Time":"2019-02-04 17:11:52Z","error":null,
"message":"First Occurred: 02/04/2019 17:11:48 | Resource Name: ASAjob | Message: Source 'ASAjob' had 24 data errors of kind 'LateInputEvent' between processing times '2019-02-04T17:10:49.7250696Z' and '2019-02-04T17:11:48.7563961Z'. Input event with application timestamp '2019-02-04T17:05:51.6050000' and arrival time '2019-02-04T17:10:44.3090000' was sent later than configured tolerance.","type":"DiagnosticMessage","correlation ID":"aaaa0000-bb11-2222-33cc-444444dddddd"}

我在我的活动日志中发现 InputPartitionNotProgressing

你的输入源（事件中心/IoT 中心）可能包含多个分区。 Azure 流分析 仅在所有要合并的分区的时间至少达到 t1 之后，才会生成时间戳为 t1 的输出。 例如，假设查询从包含两个分区的事件中心分区读取数据。 其中一个分区 P1 包含时间点 t1 之前的事件。 另一个分区 P2 包含时间点 t1 + x 之前的事件。 随后会持续生成输出，直到时间点 t1。 但是，如果显式指定了 Partition by PartitionId 子句，这两个分区会独立地继续运行。

如果将相同输入流中的多个分区组合在一起，则延期抵达容限就是每个分区等待新数据的最长时间。 如果事件中心只包含一个分区，或者 IoT 中心未收到输入，则在该分区达到延期抵达容限阈值之前，其时间线不会递进。 这会使您的输出延迟相当于延迟到达容差阈值的时间。 在这种情况下，你可能会看到以下消息：

{"message Time":"2/3/2019 8:54:16 PM UTC","message":"Input Partition [2] does not have additional data for more than [5] minute(s). Partition will not progress until either events arrive or late arrival threshold is met.","type":"InputPartitionNotProgressing","correlation ID":"0000000000-0000-0000-0000-00000000000000"}

此消息通知输入中至少有一个分区为空，并将延迟到达阈值延迟输出。 为了克服这一点，建议你：

• 确保事件中心/IoT 中心的所有分区都收到输入。
• 在查询中使用 Partition by PartitionID 子句。

为什么即使将延迟到达策略设置为 0 时，也会出现 5 秒的延迟？

如果有一个输入分区从未接收到任何输入，就会发生这种情况。 你可以按分区验证输入指标，以验证此行为。

当某个分区在超过已配置的延迟到达阈值的时间内没有任何数据时，流分析会按照“事件排序注意事项”部分中所述推进应用程序时间戳。 这需要预计的到达时间。 如果分区从未有任何数据，流分析将到达时间估计为 本地时间 - 5 秒。 出于此原因，从未有过任何数据的分区可能会显示 5 秒的水印延迟。

后续步骤

• 时间处理注意事项
• Azure 流分析作业指标
• Azure 流分析指标维度