azure-data-explorer - 如果异步运行，是否保证 Kusto 查询摄取 (.set-or-append)

Question

我无法从文档中找到答案。

如果我使用

.set-or-append async

结果能保证吗？

目前，我们正在运行所有没有async关键字的数据修饰操作。有时它们会阻塞我们的集群，但我们知道它们会失败并且可以从队列中恢复。

如果我们异步触发它们，那么我们无法控制它们是否失败并恢复。有什么推荐的方法来处理这个问题？

为了获得更多上下文细节，我们必须将 2 个非常大的表中的数据整理到其他 4 个带有聚合数据的表中。UpdatePolicy 并没有真正应用在这个用例中。我们只需要每周运行一次，因为它更像是每周或每月的聚合。不幸的是，当它们运行时，我们似乎很容易受到限制。

标签： azure-data-explorer

Answer 1

目前，我们正在运行所有这些数据修饰操作而不使用 async 关键字。有时它们会阻塞我们的集群，但我们知道它们会失败并且可以从队列中恢复。

这不准确 - 这些命令 [当前] 没有排队。如果由于某种原因（瞬时失败、由于达到摄取容量而导致的节流等）命令失败 - 它会失败，并且调用者有责任重试它（如果这样做有意义，则基于种类失败的原因）

为了获得更多上下文细节，我们必须将数据从 2 个非常大的表中整理到其他 4 个具有聚合数据的表中。UpdatePolicy 并没有真正应用在这个用例中。我们只需要每周运行一次，因为它更像是每周或每月的聚合。不幸的是，当它们运行时，我们似乎很容易受到限制。

经常受到限制的命令表明您的集群经常充分利用其摄取容量。由于摄取容量与集群中的核心数量呈线性关系，您可以选择横向扩展/向上扩展集群，以获得额外的摄取容量（您也可以临时按计划执行此操作，仅在预期额外的摄取负载时跑步）。

请注意，您可以（并且可能应该）使用async关键字监视您运行的命令的状态/状态 - 这可以使用.show operations命令（doc）来完成