Azure Synapse Analytics查询超时

问题描述

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

解决方法

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

也许Web应用程序设计人员认为他们的应用程序比其他任何应用程序都重要，并为自己分配了贪婪的资源类。无论哪种方式，这都是有益的。然后，您需要与负责webapp的架构师，Synapse和负责您的Synapse的DBA进行有关容量规划的讨论。

该问题在负载测试中也应该变得很明显。目前，使用webapp测试多个用户非常容易，例如Azure DevOps load testing，Selenium等。请向webapp开发人员查询其负载测试的结果。

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

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

HTH