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中的某些文本從中複製而來。我已經根據你的計劃進行了調整。