长时间运行的操作的最佳做法

在 Azure Analysis Services 中,节点 表示运行服务器资源的主机虚拟机。 如果服务器资源移至其他节点,某些操作(例如长时间运行的查询、刷新操作、查询横向扩展同步)可能会失败。 此场景中的常见错误消息包括:

  • “尝试查找长时间运行的 XMLA 请求时出错。 该请求可能已被服务升级或服务器重启中断。”
  • 由于服务错误(不活动),针对模型 <database> 的 ID 为 <> 的作业已取消,并出现消息“正在取消刷新请求,因为它已停滞,无任何更新”。 这是一个内部服务问题。 如果此问题重复发生,请重新提交作业或提交票证以获取帮助。”

有很多原因会导致长时间运行的操作被中断。 例如,Azure 中的下述更新:

  • 操作系统修补
  • 安全更新
  • Azure Analysis Services 服务更新
  • Service Fabric 更新 Service Fabric 是由许多 Microsoft 云服务(包括 Azure Analysis Services)使用的平台组件。

除了服务中发生的更新外,由于需要进行负载均衡,服务还会在各个节点之间自然移动。 云服务需要进行节点移动。 Azure Analysis Services 会尝试最大程度地降低节点移动影响,但无法完全消除它们。

除了节点移动以外,还可能发生其他故障。 例如,数据源数据库系统可能处于脱机状态或网络连接断开。 在刷新过程中,如果某个分区包含 1000 万行,而在第 900 万行出现故障,则无法在故障点重启刷新。 必须从头开始重新启动该服务。

刷新 REST API

对于长时间运行的操作(例如数据刷新),服务中断可能是一个非常棘手的问题。 Azure Analysis Services 包含的 REST API 有助于缓解服务中断造成的负面影响。 若要了解详细信息,请参阅使用 REST API 执行异步刷新

除了 REST API 之外,还可以使用其他方法,尽量减少长时间运行的刷新操作过程中可能出现的问题。 目标是避免从头开始重启刷新操作,而是改为以较小的批执行刷新,这些批次可以分阶段提交。

REST API 能实现这样的重启,但不能灵活实现部分创建和删除。 如果某个方案需要复杂的数据管理操作,则解决方案应在其逻辑中包含某种形式的批处理。 例如,通过使用事务在多个单独的批次中处理数据,失败时将不需要从头开始重启,只需从某个中间检查点重启。

横向扩展查询副本

无论是使用 REST 还是使用自定义逻辑,在处理各个批次时,客户端应用程序查询仍然可能会返回不一致的结果或中间结果。 如果在处理过程中要求客户端应用程序查询返回一致的数据,并且模型数据处于中间状态,请使用只读查询副本进行横向扩展

通过使用只读查询副本,在分批执行刷新时,客户端应用程序用户可以继续在只读副本上查询数据的旧快照。 完成刷新后,可以执行同步操作,使只读副本保持最新。

后续步骤

使用 REST API 执行异步刷新
Azure Analysis Services 横向扩展
Analysis Services 高可用性
Azure 服务的重试指南