Azure Synapse Analytics 查询超时

Question

我们最近在生产中遇到了问题。 Azure 突触分析（以前称为 DWH）有一个 DW2500c 实例。一切都运行良好，直到最近一个团队部署了一个 web 应用程序供企业访问数据。数据是从 DWH 中提取的。我们注意到，查询和会话突然激增，导致并发紧缩。我附上了统计数据 DWH stats 从文档中，我可以看到允许的最大会话数为 1024。这表明问题不是会话数，而是并发查询数（300+），并且查询可能进入内部队列等待资源被释放。 我正在对工作负载管理进行一些研究，并认为我们可以尝试一下。我们仍然需要检查工作负载组的当前分配情况，看看我们是否需要增加并发或增加内存。我们尝试将等级从 2000 增加到 2500，但这没有帮助。 但我想得到一个普遍的看法，避免这种情况的最佳方法是什么？

Answer 1

您应该仔细查看 webapp 访问数据库时使用的 resource class。即它是像staticrc80 这样的静态类，它分配相同数量的内存而不管当前的DWU，还是像largerc 这样的动态资源类，它根据DWU 分配动态的内存量。如果 webapp 开发人员没有明确指定任何资源类，那么它很可能在 smallrc 运行。

也许 webapp 的设计者认为他们的应用比其他任何东西都重要，并且给自己分配了一个贪婪的资源类。无论哪种方式，这将是有益的。然后，您需要与负责 web 应用程序的架构师、Synapse 和负责管理 Synapse 的 DBA 就容量规划进行讨论。

这个问题在负载测试中也应该很明显。现在很容易使用 webapps 测试多个用户，例如Azure DevOps load testing、Selenium 等。请向 webapp 开发人员询问他们的负载测试结果。

作为替代方案，您可以做一些事情：

• 尝试 Synapse 中的新 result set caching 功能，该功能在启用时会缓存查询结果。针对缓存运行的查询不计入您的并发限制。然而，这种方法依赖于运行大量类似的查询，但此功能可能会减少您的问题并提高性能。
• 由于 SQL 数据仓库和现在的 Synapse 并不以大规模并发而闻名，因此可以使用替代模式，例如中心辐射型，您可以将某些表转储到普通 Azure SQL 数据库中（它们没有相同的并发问题）和甚至可能暂停您的 Synapse（您的集线器）。让您的 webapp 用户连接到 SQL DB（辐条）。
• Synapse 的另一个有趣的新功能是SQL on-demand。这将允许使用集线器和辐条的变体，您可以使用CREATE EXTERNAL TABLE 将表转储到 Azure Data Lake，然后让您的 Web 应用程序用户连接到 SQL 按需端点而不是 Synapse 端点。从理论上讲，这对他们来说只是一个连接字符串的更改，并且可以解决您的并发问题。您无法真正优化查询，并且 SQL 按需 T-SQL 覆盖范围更有限，但它肯定是一个有趣的模式，我现在正在研究它。
• 另一种经过尝试和测试的替代方法是将 Azure 分析服务 (AAS) 或 Power BI 放在 Synapse 数据库前面以卸载工作。

HTH