Azure 流分析 在每次作业运行时内部维护状态信息，并定期将该状态保存到检查点。 如果作业失败或进行了升级，Stream Analytics 可以利用最新的检查点进行恢复。 当作业无法使用检查点时，它会执行重放，重新处理最近的输入事件以重建状态。
本文解释了检查点和重播在 Azure 流分析 中的工作原理，以及它们如何影响作业恢复所需的时间。
时态元素中的有状态查询逻辑
Azure 流分析 作业的一个独特功能是执行有状态处理，如窗口聚合、时间连接和时间分析函数。 运行作业时，每个运算符都会保持状态信息。 这些查询元素的最大窗口大小为 7 天。
多个流分析查询元素中都出现了时态窗口的概念：
- 窗口聚合（滚动、跳动和滑动窗口的 GROUP BY）
- 临时联接 （JOIN with DATEDIFF）
- 临时分析函数（ISFIRST、LAST 和 LAG，限制持续时间）
从节点故障中恢复作业，包括操作系统升级
每次 Stream Analytics 作业运行时，服务都会在内部将其横向扩展到多个工作器节点上执行处理。 服务每隔几分钟检查每个工作节点的状态，这有助于在发生故障时恢复。
有时，某个工作节点可能会失败，或者该工作节点可能发生操作系统升级。 为了自动恢复，Stream Analytics 会获取一个新的健康节点，并从最新的可用检查点恢复前一个工作节点的状态。 为了恢复工作，作业会重放少量数据，以恢复上次检查点的状态。 通常，还原差距仅为几分钟。 当你为该作业选择了足够多的流式处理单元时，重放就会很快完成。
在完全并行的查询中，工作器节点故障后追赶所需的时间与以下成正比：
[输入事件速率] x [间隙长度] / [处理分区数]
如果你发现节点故障和操作系统升级导致处理延迟显著，考虑将查询设置为完全并行，并扩展作业以分配更多流媒体单元。 有关详细信息，请参阅缩放Azure 流分析作业以提高吞吐量。
Stream Analytics 目前不会显示此类恢复过程的报告。
由于服务升级导致的作业恢复
Microsoft偶尔会升级在 Azure 服务中运行流分析作业的二进制文件。 此时，Microsoft会将正在运行的作业升级到更新版本，作业会自动重启。
在可能的情况下，Azure 流分析 使用检查点从最后一个检查点状态还原数据。 当 Stream Analytics 无法使用内部检查点时，重放技术会恢复流式查询的整个状态。 要让Stream Analytics作业重放完全相同的输入，请将源数据的保留策略设置为至少与查询窗口大小相同。 如果不这样做，在服务升级期间可能会导致错误或不完整的结果，因为 Stream Analytics 可能无法将源数据保留足够长的时间，从而无法覆盖完整的窗口时长。
一般情况下，所需的重播量与窗口大小成比例乘以平均事件速率。 例如，对于输入速率为每秒 1,000 个事件的作业，当窗口大小超过一小时时，回放量会很大。 服务可能需要重新处理多达一小时的数据以初始化状态，以便产生完整且正确的结果，这可能导致输出延迟（无输出）一段时间。 没有窗口或其他时间操作符的查询，比如 JOIN 或 LAG，则没有重放。
估算重播追赶时间
要估算因服务升级引起的延迟时间，请遵循以下技术：
- 向输入事件中心加载足够的数据，以涵盖查询中的最大窗口大小，并保持预期的事件速率。 在这段时间内，事件的时间戳应始终接近实际时钟时间，就像是实时输入流一样。 例如，如果查询中的时间窗口为三天，请将事件持续三天发送到事件中心，并在此之后继续发送事件。
- 开始工作时，先用 “现在 ”作为开始时间。
- 测量从开始时间到作业产生第一个输出之间的时间。 这段时间大致相当于服务升级过程中作业产生的延迟。
- 如果延迟太长，试着分区你的作业，增加流式单元数量，让负载分散到更多节点。 或者，可以考虑减小查询中的窗口大小，并对 Stream Analytics 作业在下游接收器中生成的输出执行进一步聚合或其他有状态处理（例如，通过使用 Azure SQL 数据库）。
在任务关键作业升级期间考虑整体服务的稳定性问题时，请考虑在配对的 Azure 区域中运行重复作业。 有关详细信息，请参阅 保证服务更新期间的流分析作业可靠性。
从用户主动执行的停止和启动操作中进行作业恢复
要编辑流式作业的查询语法，或调整输入输出，你需要暂停作业来进行修改并升级作业设计。 在这种情况下，当你停止流式传输工作再重新开始时，恢复场景类似于服务升级。
用户发起的作业重启不能使用检查点数据。 要估算此类重启期间的输出延迟，使用前节描述的相同程序，若延迟过长则采取类似缓解措施。
相关内容
有关可靠性和可伸缩性的详细信息，请参阅以下文章：