azure - 统计信息是否像 Azure 数据仓库中的哈希那样对 JOINS 上的字段有帮助？

Question

在 Azure 数据仓库中，建议对计划加入甚至可能聚合的字段上的分布式表使用 HASH。还建议您对计划使用的字段创建统计信息。

假设您有两个具有相同数量记录和字段的表。一个表根据一个非常唯一的键进行哈希处理，另一个表为 ROUND_ROBIN，其中数据随机均匀地分布在 60 个数据库中。

-- CustomerID is alphanumeric
SELECT
   [ProductID]
  ,COUNT(DISTINCT [CustomerID]) AS [Unique Records]
FROM [dbo].[FactTable]
GROUP BY
   [Product]

在哈希表上，如果您对哈希键进行聚合，您可以看到它在 0.05 秒内返回结果。在循环表上，具有相同的聚合，为 0.51 秒。

CREATE STATISTICS [ProductID] ON [dbo].[FactTable] ([ProductID]);
CREATE STATISTICS [CustomerID] ON [dbo].[FactTable] ([CustomerID]);

当您对正在聚合的字段应用统计信息时，哈希表仍会在 0.05 秒内返回。不用找了。当您对循环表执行相同操作时，结果会在 0.05 秒内返回与哈希值相同的结果。

注意:2000 DWU 在 xlarge 资源中运行查询(最大内存分配)

在检查散列键的分布时，我发现 60 个数据库的一个分布中存储了 1.4 亿条记录。 5000 万条其他记录相当均匀地分布在其他 59 个数据库中。默认值使我的散列 key 不适合散列。

我的问题是，虽然带有统计信息的循环表在我与另一个表进行哈希处理的同一字段上表现良好，但当我在带有该键的 JOINS 上使用循环法时，相同的性能会保持不变吗？我还没有完全测试它，但正在寻找最好的方法。

统计数据对连接有帮助吗？我读过的一些文章说确实如此，但是在考虑分配 key 上的循环时，看看其他人是否对该方法有更可靠的答案。我确实没有任何好的候选者不会导致数据偏差，就像我上面的 1.4 亿个示例一样。

Answer 1

首先，在当前版本的 Azure SQL 数据仓库中，您应该始终为将在联接、GROUP BY 等中使用的列创建统计信息。忽略您在没有统计数据的情况下获得的时间，因为它们无关紧要。

良好哈希 key 的标准之一是 distributes the data evenly 。如果您没有好的候选人，那么 ROUND_ROBIN 是替代方案。关于 ROUND_ROBIN 需要记住的一点是，您总是会发生数据移动，但有时这很好。这实际上取决于您的关键查询是什么。我的建议是针对它们进行优化。

对于您给出的示例，性能非常快，因此确实不值得花费太多时间。您有一些更现实的疑问吗？

Azure SQL 数据仓库会进行缓存，与 SQL Server 类似，如所述 here .

当您从门户配置仓库时，我使用 AdventureWorksDW 示例模拟了一个测试设备，并发现对于这些示例查询，哈希表的性能明显更好(尽管偏差很大)，但您的里程可能会有所不同 (YMMV):

-- 603,980,000 rows
CREATE TABLE dbo.FactTable_rr
WITH ( 
    DISTRIBUTION = ROUND_ROBIN, 
    CLUSTERED COLUMNSTORE INDEX
)
AS
SELECT a.ProductKey AS [ProductID], a.CustomerKey AS [CustomerID]
FROM [dbo].[FactInternetSales] a
    CROSS JOIN ( SELECT TOP 1000 1 FROM [dbo].[FactInternetSales] ) b(c)
    CROSS JOIN ( SELECT TOP 10 1 FROM [dbo].[FactInternetSales] ) c(c)
GO


CREATE STATISTICS st_dbo_FactTable_rr_ProductID ON dbo.FactTable_rr ( ProductID ) WITH FULLSCAN;
CREATE STATISTICS st_dbo_FactTable_rr_CustomerID ON dbo.FactTable_rr ( CustomerID ) WITH FULLSCAN;
GO


CREATE TABLE dbo.FactTable_hh
WITH ( 
    DISTRIBUTION = HASH( [ProductID] ),
    CLUSTERED COLUMNSTORE INDEX
)
AS
SELECT *
FROM FactTable_rr
GO

CREATE STATISTICS st_dbo_FactTable_hh_ProductID ON dbo.FactTable_hh ( ProductID ) WITH FULLSCAN;
CREATE STATISTICS st_dbo_FactTable_hh_CustomerID ON dbo.FactTable_hh ( CustomerID ) WITH FULLSCAN;
GO



-- Find data skew for a distributed table
DBCC PDW_SHOWSPACEUSED('dbo.FactTable_rr');
DBCC PDW_SHOWSPACEUSED('dbo.FactTable_hh');
GO


--EXPLAIN
SELECT
   [ProductID],
   COUNT(DISTINCT [CustomerID]) AS [Unique Records]
FROM [dbo].[FactTable_rr]
GROUP BY [ProductID]
OPTION ( LABEL = 'rr' );


--EXPLAIN
SELECT
   [ProductID],
   COUNT(DISTINCT [CustomerID]) AS [Unique Records]
FROM [dbo].[FactTable_hh]
GROUP BY [ProductID]
OPTION ( LABEL = 'hh' );


-- Summary
SELECT [label], COUNT(*) records, CAST( AVG(total_elapsed_time) / 1000. AS DECIMAL(10,2) ) total_elapsed_time_s
FROM sys.dm_pdw_exec_requests 
WHERE [label] IS NOT NULL
  AND command Like 'select%'
GROUP BY [label];

我的结果，包含 6 亿行的表:

如果我查看两个查询的两个 EXPLAIN 计划( rr 、 hh )，我会看到一个更简单的哈希表计划，没有数据移动。 “rr”计划包含一个 SHUFFLE_MOVE 运算符，用于重新分配分布式表。