DAX: SUMMARIZECOLUMNS 性能优势分析

21 篇文章 5 订阅

本文将会拿SUMMARIZECOLUMNS函数与SUMMARIZE做个对比,分析SUMMARIZECOLUMNS的性能优势

前述

MarcoRusso在此前的文章中,首先讲到SUMMARIZE函数在有度量值时的执行效率问题,并在其后提出了其与ADDCOLUMNS函数组合的替代方案,SUMMARIZECOLUMNS发布后,又建议我们使用其来代替SUMMARIZE与ADDCOLUMNS的组合,但对于深层原因,Marco也只是点到为止,下文讲结合示例数据集对此展开,分析原因。

当公式中不含度量值时,两个函数在性能上无区别,本文省略此部分

案例

还是上文使用的数据集:
在这里插入图片描述
现在我们需要生成一个销量表,聚合到产品类别和月份。如果我们使用SUMMARIZE生成,它应该是这样的:

SUMMARIZE = 
SUMMARIZE (
    'FactSales',
    'DimProductCategory'[ProductCategoryName],
    'DimDate'[FiscalMonth],
    "SALES", SUM ( 'FactSales'[SalesQuantity] )
)

结果如下:

在这里插入图片描述

对于SUMMARIZE加ADDCOLUMNS组合方案,现已基本被SUMMARIZECOLUMNS方案取代,这是由于前者相对复杂的写法,以及在某些情况下的低效率(详情参考此文)。

SUMMARIZECOLUMNS则语句简洁一些:

SUMMARIZECOL = 
SUMMARIZECOLUMNS (
    'DimProductCategory'[ProductCategoryName],
    'DimDate'[FiscalMonth],
    "SALES", SUM ( 'FactSales'[SalesQuantity] )
)

他们都返回完全相同的结果,但如果我们使用DAX Studio进行分析,就可以看出他们的区别。

对于SUMMARIZE方案,存储引擎需要执行两次,耗时39ms:

在这里插入图片描述
第一次,是直接GroupBy并返回聚合结果,SQL参考如下:

SELECT
'DimDate'[FiscalMonth], 'DimProductCategory'[ProductCategoryName],
SUM ( 'FactSales'[SalesQuantity] )
FROM 'FactSales'
	LEFT OUTER JOIN 'DimDate' ON 'FactSales'[DateKey]='DimDate'[Datekey]
	LEFT OUTER JOIN 'DimProduct' ON 'FactSales'[ProductKey]='DimProduct'[ProductKey]
	LEFT OUTER JOIN 'DimProductSubcategory' ON 'DimProduct'[ProductSubcategoryKey]='DimProductSubcategory'[ProductSubcategoryKey]
	LEFT OUTER JOIN 'DimProductCategory' ON 'DimProductSubcategory'[ProductCategoryKey]='DimProductCategory'[ProductCategoryKey];

然后,引擎执行如下查询,为每行生成行上下文:

SELECT
'DimDate'[FiscalMonth], 'DimProductCategory'[ProductCategoryName]
FROM 'FactSales'
	LEFT OUTER JOIN 'DimDate' ON 'FactSales'[DateKey]='DimDate'[Datekey]
	LEFT OUTER JOIN 'DimProduct' ON 'FactSales'[ProductKey]='DimProduct'[ProductKey]
	LEFT OUTER JOIN 'DimProductSubcategory' ON 'DimProduct'[ProductSubcategoryKey]='DimProductSubcategory'[ProductSubcategoryKey]
	LEFT OUTER JOIN 'DimProductCategory' ON 'DimProductSubcategory'[ProductCategoryKey]='DimProductCategory'[ProductCategoryKey];

对于SUMMARIZECOLUMNS方案,存储引擎仅执行了一次,性能更优:

在这里插入图片描述
后台的SQL查询为:

SELECT
'DimDate'[FiscalMonth], 'DimProductCategory'[ProductCategoryName],
SUM ( 'FactSales'[SalesQuantity] )
FROM 'FactSales'
	LEFT OUTER JOIN 'DimDate' ON 'FactSales'[DateKey]='DimDate'[Datekey]
	LEFT OUTER JOIN 'DimProduct' ON 'FactSales'[ProductKey]='DimProduct'[ProductKey]
	LEFT OUTER JOIN 'DimProductSubcategory' ON 'DimProduct'[ProductSubcategoryKey]='DimProductSubcategory'[ProductSubcategoryKey]
	LEFT OUTER JOIN 'DimProductCategory' ON 'DimProductSubcategory'[ProductCategoryKey]='DimProductCategory'[ProductCategoryKey];

可以发现,SUMMARIZECOLUMNS方案的查询与SUMMARIZE方案的第一次查询是完全一样的,只不过后者多进行了一次查询,用于行上下文。这就不仅能解释为何在公式有度量值时,SUMMARIZECOLUMNS比SUMMARIZE性能更优,也可以解释为何SUMMARIZECOLUMNS只有筛选上下文,而无行上下文。

小结

当你的表里不包含任何度量值时,使用SUMMARIZE,有度量值时,则使用SUMMARIZECOLUMNS来代替SUMMARIZE以及SUMMARIZE加ADDCOLUMNS。

  • 2
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

DAVIS-BI

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值