Azure SQL数据仓库的简单性能测试

Question

我们正在努力将现有应用程序移植到Azure SQL数据仓库。为了更好地理解Azure SQL数据仓库的性能/工作负载管理特性/功能，我设置了我认为是非常简单的测试。

我加载了一个包含大约20k行（即对于并行数据仓库非常小）的静态表，即我们的业务日历。

SELECT current_timestamp,COUNT(1) FROM 
    (SELECT C1, ..., Cn , COUNT(1) AS _A_ROW_COUNT 
FROM schema.view_to_table GROUP BY C1, ..., Cn) DER 

吉文斯：然后我使用图案等生成该单个表的所有可能的查询

• DWU设置为1000推出
• 35个并发线程。
• 在small_rc中运行的所有线程。 （即，每个查询使用1个插槽）
• 对初始连接使用sqlcmd，然后在每次SELECT后执行
• 在通过Express路由连接的非Azure VM上运行。选择外部SELECT COUNT（）结构以确保网络流量最小。
• 堆表的使用提供了比默认列存储更好的结果（如预期的那样）。 （需要使用聚簇索引进行测试。）
• 表由主键列分配。

背景/偏差 - 我曾与许多其他MPP数据库。

结果

• 查询在10-20秒，这是更长的时间比我预计这种简单的工作运行。
• 当我提交每个线程时，我睡在每个新线程之间。最初的查询运行得更快，并且随着线程数量增加到35，平均运行时间显着恶化。

我如何理解存在哪些瓶颈？

当然我会在其他DWU设置下重新运行测试，看看它是否会影响完全small_rc的工作负载。

附录 - 示例查询计划

<?xml version="1.0" encoding="utf-8"?> 
<dsql_query number_nodes="10" number_distributions="60" number_distributions_per_node="6"> 
    <sql>SELECT current_timestamp,COUNT(1) FROM (SELECT GREGORIAN_DATE, WM_MONTH, MON_MULT, FRI_MULT , COUNT(1) AS _A_ROW_COUNT FROM AR_WM_VM.CALENDAR_DAY GROUP BY GREGORIAN_DATE, WM_MONTH, MON_MULT, FRI_MULT) DER</sql> 
    <dsql_operations total_cost="0.260568" total_number_operations="8"> 
    <dsql_operation operation_type="RND_ID"> 
     <identifier>TEMP_ID_21523</identifier> 
    </dsql_operation> 
    <dsql_operation operation_type="ON"> 
     <location permanent="false" distribution="AllDistributions" /> 
     <sql_operations> 
     <sql_operation type="statement">CREATE TABLE [tempdb].[dbo].[TEMP_ID_21523] ([col] DATE) WITH(DATA_COMPRESSION=PAGE);</sql_operation> 
     </sql_operations> 
    </dsql_operation> 
    <dsql_operation operation_type="SHUFFLE_MOVE"> 
     <operation_cost cost="0.258648" accumulative_cost="0.258648" average_rowsize="3" output_rows="2155.4" GroupNumber="76" /> 
     <source_statement>SELECT [T1_1].[col] AS [col] 
FROM (SELECT dateadd(dd, CAST ((364) AS INT), [T2_1].[calendar_date]) AS [col] 
     FROM [db_ARdev1].[AR_CORE_DIM_TABLES].[calendar_dim] AS T2_1) AS T1_1</source_statement> 
     <destination_table>[TEMP_ID_21523]</destination_table> 
     <shuffle_columns>col;</shuffle_columns> 
    </dsql_operation> 
    <dsql_operation operation_type="ON"> 
     <location permanent="false" distribution="Control" /> 
     <sql_operations> 
     <sql_operation type="statement">CREATE TABLE [tempdb].[QTables].[QTable_3ff26b5253004eec9d9ca50492bab1e2] ([col] BIGINT) WITH(DATA_COMPRESSION=PAGE);</sql_operation> 
     </sql_operations> 
    </dsql_operation> 
    <dsql_operation operation_type="PARTITION_MOVE"> 
     <operation_cost cost="0.00192" accumulative_cost="0.260568" average_rowsize="8" output_rows="1" GroupNumber="93" /> 
     <location distribution="AllDistributions" /> 
     <source_statement>SELECT [T1_1].[col] AS [col] 
FROM (SELECT COUNT_BIG(CAST ((1) AS INT)) AS [col] 
     FROM  (SELECT 0 AS [col] 
        FROM  [tempdb].[dbo].[TEMP_ID_21523] AS T3_1 
          INNER JOIN 
          (SELECT CASE 
            WHEN ([T4_1].[wm_week_day_nbr] = CAST ((3) AS SMALLINT)) THEN CAST ((1) AS INT) 
            ELSE CAST ((0) AS INT) 
            END AS [col], 
            CASE 
            WHEN ([T4_1].[wm_week_day_nbr] = CAST ((7) AS SMALLINT)) THEN CAST ((1) AS INT) 
            ELSE CAST ((0) AS INT) 
            END AS [col1], 
            [T4_1].[calendar_date] AS [calendar_date], 
            [T4_1].[fiscal_month_nbr] AS [fiscal_month_nbr] 
          FROM [db_ARdev1].[AR_CORE_DIM_TABLES].[calendar_dim] AS T4_1) AS T3_2 
          ON ([T3_2].[calendar_date] = [T3_1].[col]) 
        GROUP BY [T3_2].[calendar_date], [T3_2].[fiscal_month_nbr], [T3_2].[col], [T3_2].[col1]) AS T2_1 
     GROUP BY [T2_1].[col]) AS T1_1</source_statement> 
     <destination>Control</destination> 
     <destination_table>[QTable_3ff26b5253004eec9d9ca50492bab1e2]</destination_table> 
    </dsql_operation> 
    <dsql_operation operation_type="ON"> 
     <location permanent="false" distribution="AllDistributions" /> 
     <sql_operations> 
     <sql_operation type="statement">DROP TABLE [tempdb].[dbo].[TEMP_ID_21523]</sql_operation> 
     </sql_operations> 
    </dsql_operation> 
    <dsql_operation operation_type="RETURN"> 
     <location distribution="Control" /> 
     <select>SELECT [T1_1].[col1] AS [col], 
     [T1_1].[col] AS [col1] 
FROM (SELECT CONVERT (INT, [T2_1].[col], 0) AS [col], 
       isnull(CONVERT (DATETIME, N'2016-10-03 13:04:34.203', 0), CONVERT (DATETIME, N'2016-10-03 13:04:34.203', 0)) AS [col1] 
     FROM (SELECT ISNULL([T3_1].[col], CONVERT (BIGINT, 0, 0)) AS [col] 
       FROM (SELECT SUM([T4_1].[col]) AS [col] 
         FROM [tempdb].[QTables].[QTable_3ff26b5253004eec9d9ca50492bab1e2] AS T4_1) AS T3_1) AS T2_1) AS T1_1</select> 
    </dsql_operation> 
    <dsql_operation operation_type="ON"> 
     <location permanent="false" distribution="Control" /> 
     <sql_operations> 
     <sql_operation type="statement">DROP TABLE [tempdb].[QTables].[QTable_3ff26b5253004eec9d9ca50492bab1e2]</sql_operation> 
     </sql_operations> 
    </dsql_operation> 
    </dsql_operations> 
</dsql_query> 

Answer 1

在DWU 1000你，最多32个并发查询和并发40个插槽，让你的一些查询将不得不排队。

你做了什么索引和分配选择？这个表很小，所以它听起来像是聚簇索引而不是群集列存储（默认）的更好选择。还要确保你已经创建了你的统计数据。

你从哪里调用sqlcmd，例如Azure虚拟机，以便它离DW较近，或者从笔记本电脑上调用，这种情况下，您可能正在等待网络往返。

审查并发DMV：sys.dm_pdw_exec_requests 审查的等待动态管理视图：sys.dm_pdw_waits

这recent answer看起来有用的。

我已经完成了您的示例EXPLAIN计划的注释。打开SSMS中的行号或查看类似Sublime文字的最佳效果：

• 第3行是要分析的查询。
• 第4行将计划中操作或步骤的总数列为8.每个操作都保存在XML中的dsql_operation元素中。
• 第5行开始操作1，RND_ID或RandomIdOperation。此操作仅为查询计划中使用的临时对象创建唯一的名称。标识符是TEMP_ID_21523。
• 第8行开始操作2，ON或OnOperation。这将对数据库或对象执行操作。此特定步骤在第9行中指定的所有节点上创建临时表[TEMP_ID_21523]。在所有节点上创建临时表的DDL位于第11行。此临时表只有一列，称为数据类型DATE的'col'。
• 第14行是操作3，称为SHUFFLE_MOVE的数据移动服务（DMS）操作或ShuffleMoveOperation。 SHUFFLE_MOVE重新分配分布式表。
• 第16行给出SHUFFLE_MOVE中使用的语句。它将计算列中的数据从[AR_CORE_DIM_TABLES]。[calendar_dim]中的数据移动到我们知道存在于所有节点上的临时表[TEMP_ID_21523]中。
• 第22行开始下一个操作4，另一个ON或OnOperation。此操作在控制节点上创建另一个临时表，并带有一个BIGINT列。该表的DDL在行25上提供。
• 行28开始操作5，a PARTITION_MOVE或PartitionMoveOperation。此DMS操作将数据从分布式表移动到控制节点上的单个表。此操作用于控制节点上的聚合操作。该特定步骤将数据从存在于所有节点上的临时表[TEMP_ID_21523]移动到控制节点上的目标临时表[QTable_3ff2 ...]。
• 第31至49行列出了用于执行此操作的SQL。
• 53行开始操作6，另一个ON或OnOperation。此步骤将删除所有节点上存在的临时表[TEMP_ID_21523]。
• 59行开始操作7 of 8，a RETURN或ReturnOperation。此操作发生在控制节点上，将查询结果从控制节点发送给提交查询的用户。返回的SQL显示在第61-67行中。
• 69行开始8的最后一个操作8，另一个ON或OnOperation。这个特定的步骤将删除存在于控制节点上的临时表[QTable_3ff2 ...]。

为了您的查询中，PARTITION_MOVE或SHUFFLE_MOVE步是性能问题的最可能的原因和提高性能将涉及消除或改善他们。

为了更进一步，我需要知道表[AR_CORE_DIM_TABLES]。[calendar_dim]和视图[AR_WM_VM]。[CALENDAR_DAY GROUP]的DDL，以便我可以计算出分配，并且如果计算出的任何列正在用过的。

此注释基于EXPLAIN计划的APS帮助文件部分中的类似文字和Understanding Query Plans中的某些文本从中复制而来。我已经根据你的计划进行了调整。