研究《DAX查询计划 白皮书》中的案例(二)优化方案1

原创 已于 2024-05-19 21:28:42 修改 · 511 阅读 · 6 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#powerbi

于 2024-05-12 21:18:48 首次发布

上一篇文章中介绍了初始方案的查询计划，找到了性能瓶颈来自 FILTER 的一参使用 Sales 整表，在底层执行时需要计算数据量巨大的交叉表，导致公式引擎部分耗费大量时间，确定了改进方向是想法提高 FILTER 的性能，减少迭代对象的势。不过白皮书给出的第一个方案并没有直接从减少 FILTER 迭代对象的势入手，而是采取了 CALCULATE+FILTER 的写法，这也是许多初学者可能采取的方案。那么本篇文章将继续通过理解查询计划，了解其底层执行过程，分析其优劣势。

运行环境、模拟数据、计算要求与上一篇相同。

研究《DAX查询计划 白皮书》中的案例(一)初始方案
研究《DAX查询计划 白皮书》中的案例(二)优化方案1
研究《DAX查询计划 白皮书》中的案例(三)优化方案(番外)
研究《DAX查询计划 白皮书》中的案例(四)优化方案2
研究《DAX查询计划 白皮书》中的案例(四)优化方案3

优化方案1

DAX 查询

// 优化方案1
EVALUATE
ADDCOLUMNS (
    VALUES ( 'Calendar'[Date] ),
    "OpenOrders",
        CALCULATE (
            COUNTROWS ( Sales ),
            FILTER ( sales, sales[OrderDate] < 'Calendar'[Date] ), 
            FILTER ( sales, sales[ShipDate] > 'Calendar'[Date] )
        ) // 白皮书这里给的方案就是两个 FILTER
)

运行效率

以连续5次冷启动的结果进行统计：

  • 环境1

平均总耗时 290.4 毫秒，标准差 26.07 毫秒

其中 SE（存储引擎）平均耗时 4.80 毫秒，标准差 1.48 毫秒

SE/总耗时 = 1.653%

  • 环境2

平均总耗时 300 毫秒，标准差 2.88 毫秒

其中 SE（存储引擎）平均耗时 5.80 毫秒，标准差 3.19 毫秒

SE/总耗时 = 1.929%

与之前的原始方案做比较：

环境参数初始方案优化方案1提升幅度
环境1平均总耗时4389.4290.493.38%
SE耗时14.44.866.67%
SE占比0.328%1.653%403.83%
环境2平均总耗时4017.0300.6092.52%
SE耗时17.25.866.28%
SE占比0.428%1.929%350.62%

与初始方案对比，优化方案1带来的性能提升非常明显，平均总耗时从 4389.4 毫秒缩减到 290.4 毫秒，计算效率提升约 90% 以上, SE 耗时占比也大幅提高。

从 DAX 代码来看，FILTER 仍然使用整个 Sales 表作为迭代对象，与初始方案的区别并不大，究竟是哪个部分使其获得了性能提升，它是如何解决超大交叉表的性能瓶颈的，本篇继续通过查看查询计划来一探究竟。

存储引擎部分

存储引擎这次执行了 4 个 xmSQL 查询，分别是：

1、VQ1：从 Sales 表中以 [OrderDate] 分组，返回 [OrderDate] 列的不重复值，该查询返回 1081 行数据

// VQ1
SELECT
    'Sales'[OrderDate]
FROM 'Sales';

2、VQ2：从 Calendar 表中以 [Date] 分组，返回 [Date] 列的不重复值，该查询返回 1081 行数据

// VQ2
SELECT
    'Calendar'[Date]
FROM 'Calendar';

3、VQ3：从 Sales 表中以 [ShipDate] 分组，返回 [ShipDate] 列的不重复值，该查询返回 1075 行数据

// VQ3
SELECT
    'Sales'[ShipDate]
FROM 'Sales';

4、VQ4：该 xmSQL 与之前的有些区别，先看看代码

// VQ4
SELECT
    'Sales'[OrderDate],
    'Sales'[ShipDate],
    COUNT ( )
FROM 'Sales'
WHERE
    'Sales'[OrderDate] IN ( 43768.000000, 43809.000000, 43850.000000, 43893.000000, 43934.000000, 43975.000000, 43014.000000, 43426.000000, 43468.000000, 43513.000000..[1,080 total values, not all displayed] ) VAND
    'Sales'[ShipDate] IN ( 43775.000000, 43816.000000, 43857.000000, 43900.000000, 43941.000000, 43982.000000, 43028.000000, 43433.000000, 43475.000000, 43520.000000..[1,074 total values, not all displayed] ) ;

该 xmSQL 查询的 WHERE 子句中有许多字符，限定了 Sales[OrderDate] 和 Sales[ShipDate] 的值范围，

‘Sales’[OrderDate] IN ( 43768.000000, 43809.000000, 43850.000000, 43893.000000, 43934.000000, 43975.000000, 43014.000000, 43426.000000, 43468.000000, 43513.000000…[1,080 total values, not all displayed] ) VAND
‘Sales’[ShipDate] IN ( 43775.000000, 43816.000000, 43857.000000, 43900.000000, 43941.000000, 43982.000000, 43028.000000, 43433.000000, 43475.000000, 43520.000000…[1,074 total values, not all displayed] )

WHERE 子句将 Sales[Order] 限定在 1080 个值的列表中，Sales[ShipDate] 限定在 1074 个值的列表中。这些列表怎么来的，后面的物理查询计划会给出答案。

整个 xmSQL 查询以 Sales[OrderDate]、Sales[ShipDate]为分组依据，从符合 WHERE 子句条件的 Sales 表数据中返回 {[OrderDate]、[ShipDate]} 的非重复值对，并计算每组值对出现的次数，共 1079 行，包括3列：

Sales[OrderDate], Sales[ShipDate], [COUNT]

可以借用这段 DAX 查询，来理解该 xmSQL 查询的结果：

// DAX
DEFINE
    VAR OrderDateList = ...
    VAR ShipDateList = ...

EVALUATE
CALCULATETABLE (
    ADDCOLUMNS (
        SUMMARIZE ( Sales, Sales[OrderDate], sales[ShipDate] ),
        "COUNT", CALCULATE ( COUNTROWS ( Sales ) )
    ),
    orderDatelist,
    shipdatelist
)

公式引擎部分

逻辑查询计划

逻辑查询计划的代码和流程图如下：

AddColumns: RelLogOp DependOnCols()() 0-1 RequiredCols(0, 1)('Calendar'[Date], ''[OpenOrders])
├── Scan_Vertipaq: RelLogOp DependOnCols()() 0-0 RequiredCols(0)('Calendar'[Date])
└── Calculate: ScaLogOp DependOnCols(0)('Calendar'[Date]) Integer DominantValue=BLANK
    ├── Count_Vertipaq: ScaLogOp DependOnCols(0)('Calendar'[Date]) Integer DominantValue=BLANK
    │   └── Scan_Vertipaq: RelLogOp DependOnCols(0)('Calendar'[Date]) 31-45 RequiredCols(0)('Calendar'[Date])
    ├── Filter: RelLogOp DependOnCols(0)('Calendar'[Date]) 1-15 RequiredCols(0, 6)('Calendar'[Date], 'Sales'[OrderDate])
    │   ├── Scan_Vertipaq: RelLogOp DependOnCols()() 1-15 RequiredCols(6)('Sales'[OrderDate])
    │   └── LessThan: ScaLogOp DependOnCols(0, 6)('Calendar'[Date], 'Sales'[OrderDate]) Boolean DominantValue=NONE
    │       ├── 'Sales'[OrderDate]: ScaLogOp DependOnCols(6)('Sales'[OrderDate]) DateTime DominantValue=NONE
    │       └── 'Calendar'[Date]: ScaLogOp DependOnCols(0)('Calendar'[Date]) DateTime DominantValue=NONE
    └── Filter: RelLogOp DependOnCols(0)('Calendar'[Date]) 16-30 RequiredCols(0, 22)('Calendar'[Date], 'Sales'[ShipDate])
        ├── Scan_Vertipaq: RelLogOp DependOnCols()() 16-30 RequiredCols(22)('Sales'[ShipDate])
        └── GreaterThan: ScaLogOp DependOnCols(0, 22)('Calendar'[Date], 'Sales'[ShipDate]) Boolean DominantValue=NONE
            ├── 'Sales'[ShipDate]: ScaLogOp DependOnCols(22)('Sales'[ShipDate]) DateTime DominantValue=NONE
            └── 'Calendar'[Date]: ScaLogOp DependOnCols(0)('Calendar'[Date]) DateTime DominantValue=NONE

图示结构图：
1:AddColumns
2:Scan_Vertipaq
Calendar[Date]
3:Calculate
4:Count_Vertipaq
5:Scan_Vertipaq
Calendar[Date]
6:Filter
7:Scan_Vertipaq
Sales[OrderDate]
8:LessThan
9:'Sales'[OrderDate]
10:'Calendar'[Date]
11:Filter
12:Scan_Vertipaq
Sales[ShipDate]
13:GreaterThan
14:'Sales'[ShipDate]
15:'Calendar'[Date]

上一篇已经讲过，逻辑查询计划通常与原始 DAX 代码相似，本篇也没有出现例外，与 DAX 查询代码几乎完全一致，并没有提供足够有用的信息，继续往下查看物理查询计划。

物理查询计划

优化方案1的物理查询计划相对上一篇长了不少，截图如下
​物理查询计划截图
​
为了便于展示结构，删除 Lines 和 Records，加上层级结构线如下：

AddColumns: IterPhyOp LogOp=AddColumns IterCols(0, 1)('Calendar'[Date], ''[OpenOrders])
├── Spool_Iterator<SpoolIterator>: IterPhyOp LogOp=Scan_Vertipaq IterCols(0)('Calendar'[Date]) #Records=1081 #KeyCols=26 #ValueCols=0
│   └── ProjectionSpool<ProjectFusion<>>: SpoolPhyOp #Records=1081
│       └── Cache: IterPhyOp #FieldCols=1 #ValueCols=0
└── SpoolLookup: LookupPhyOp LogOp=Count_Vertipaq LookupCols(0)('Calendar'[Date]) Integer #Records=1079 #KeyCols=1 #ValueCols=1 DominantValue=BLANK
    └── AggregationSpool<AggFusion<Sum>>: SpoolPhyOp #Records=1079
        └── CrossApply: IterPhyOp LogOp=Count_Vertipaq IterCols(0)('Calendar'[Date])
            ├── Spool_UniqueHashLookup: IterPhyOp LogOp=Filter LookupCols(0, 22)('Calendar'[Date], 'Sales'[ShipDate]) #Records=583719 #KeyCols=2 #ValueCols=0
            │   └── AggregationSpool<GroupBy>: SpoolPhyOp #Records=583719
            │       └── Filter: IterPhyOp LogOp=Filter IterCols(0, 22)('Calendar'[Date], 'Sales'[ShipDate])
            │           └── Extend_Lookup: IterPhyOp LogOp=GreaterThan IterCols(0, 22)('Calendar'[Date], 'Sales'[ShipDate])
            │               ├── CrossApply: IterPhyOp LogOp=GreaterThan IterCols(0, 22)('Calendar'[Date], 'Sales'[ShipDate])
            │               │   ├── Spool_Iterator<SpoolIterator>: IterPhyOp LogOp=Scan_Vertipaq IterCols(0)('Calendar'[Date]) #Records=1081 #KeyCols=26 #ValueCols=0
            │               │   │   └── ProjectionSpool<ProjectFusion<>>: SpoolPhyOp #Records=1081
            │               │   │       └── Cache: IterPhyOp #FieldCols=1 #ValueCols=0
            │               │   └── Spool_Iterator<SpoolIterator>: IterPhyOp LogOp=Scan_Vertipaq IterCols(22)('Sales'[ShipDate]) #Records=1075 #KeyCols=26 #ValueCols=0
            │               │       └── ProjectionSpool<ProjectFusion<>>: SpoolPhyOp #Records=1075
            │               │           └── Cache: IterPhyOp #FieldCols=1 #ValueCols=0
            │               └── GreaterThan: LookupPhyOp LogOp=GreaterThan LookupCols(0, 22)('Calendar'[Date], 'Sales'[ShipDate]) Boolean
            │                   ├── ColValue<'Sales'[ShipDate]>: LookupPhyOp LogOp=ColValue<'Sales'[ShipDate]>'Sales'[ShipDate] LookupCols(22)('Sales'[ShipDate]) DateTime
            │                   └── ColValue<'Calendar'[Date]>: LookupPhyOp LogOp=ColValue<'Calendar'[Date]>'Calendar'[Date] LookupCols(0)('Calendar'[Date]) DateTime
            ├── Spool_MultiValuedHashLookup: IterPhyOp LogOp=Filter LookupCols(6)('Sales'[OrderDate]) IterCols(0)('Calendar'[Date]) #Records=583740 #KeyCols=2 #ValueCols=0
            │   └── AggregationSpool<GroupBy>: SpoolPhyOp #Records=583740
            │       └── Filter: IterPhyOp LogOp=Filter IterCols(0, 6)('Calendar'[Date], 'Sales'[OrderDate])
            │           └── Extend_Lookup: IterPhyOp LogOp=LessThan IterCols(0, 6)('Calendar'[Date], 'Sales'[OrderDate])
            │               ├── CrossApply: IterPhyOp LogOp=LessThan IterCols(0, 6)('Calendar'[Date], 'Sales'[OrderDate])
            │               │   ├── Spool_Iterator<SpoolIterator>: IterPhyOp LogOp=Scan_Vertipaq IterCols(0)('Calendar'[Date]) #Records=1081 #KeyCols=26 #ValueCols=0
            │               │   │   └── ProjectionSpool<ProjectFusion<>>: SpoolPhyOp #Records=1081
            │               │   │       └── Cache: IterPhyOp #FieldCols=1 #ValueCols=0
            │               │   └── Spool_Iterator<SpoolIterator>: IterPhyOp LogOp=Scan_Vertipaq IterCols(6)('Sales'[OrderDate]) #Records=1081 #KeyCols=26 #ValueCols=0
            │               │       └── ProjectionSpool<ProjectFusion<>>: SpoolPhyOp #Records=1081
            │               │           └── Cache: IterPhyOp #FieldCols=1 #ValueCols=0
            │               └── LessThan: LookupPhyOp LogOp=LessThan LookupCols(0, 6)('Calendar'[Date], 'Sales'[OrderDate]) Boolean
            │                   ├── ColValue<'Sales'[OrderDate]>: LookupPhyOp LogOp=ColValue<'Sales'[OrderDate]>'Sales'[OrderDate] LookupCols(6)('Sales'[OrderDate]) DateTime
            │                   └── ColValue<'Calendar'[Date]>: LookupPhyOp LogOp=ColValue<'Calendar'[Date]>'Calendar'[Date] LookupCols(0)('Calendar'[Date]) DateTime
            └── Cache: IterPhyOp #FieldCols=2 #ValueCols=1
                ├── Spool_Iterator<SpoolIterator>: IterPhyOp LogOp=Filter IterCols(0, 6)('Calendar'[Date], 'Sales'[OrderDate]) #Records=583740 #KeyCols=2 #ValueCols=0
                │   └── AggregationSpool<GroupBy>: SpoolPhyOp #Records=583740
                │       └── Filter: IterPhyOp LogOp=Filter IterCols(0, 6)('Calendar'[Date], 'Sales'[OrderDate])
                │           └── Extend_Lookup: IterPhyOp LogOp=LessThan IterCols(0, 6)('Calendar'[Date], 'Sales'[OrderDate])
                │               ├── CrossApply: IterPhyOp LogOp=LessThan IterCols(0, 6)('Calendar'[Date], 'Sales'[OrderDate])
                │               │   ├── Spool_Iterator<SpoolIterator>: IterPhyOp LogOp=Scan_Vertipaq IterCols(0)('Calendar'[Date]) #Records=1081 #KeyCols=26 #ValueCols=0
                │               │   │   └── ProjectionSpool<ProjectFusion<>>: SpoolPhyOp #Records=1081
                │               │   │       └── Cache: IterPhyOp #FieldCols=1 #ValueCols=0
                │               │   └── Spool_Iterator<SpoolIterator>: IterPhyOp LogOp=Scan_Vertipaq IterCols(6)('Sales'[OrderDate]) #Records=1081 #KeyCols=26 #ValueCols=0
                │               │       └── ProjectionSpool<ProjectFusion<>>: SpoolPhyOp #Records=1081
                │               │           └── Cache: IterPhyOp #FieldCols=1 #ValueCols=0
                │               └── LessThan: LookupPhyOp LogOp=LessThan LookupCols(0, 6)('Calendar'[Date], 'Sales'[OrderDate]) Boolean
                │                   ├── ColValue<'Sales'[OrderDate]>: LookupPhyOp LogOp=ColValue<'Sales'[OrderDate]>'Sales'[OrderDate] LookupCols(6)('Sales'[OrderDate]) DateTime
                │                   └── ColValue<'Calendar'[Date]>: LookupPhyOp LogOp=ColValue<'Calendar'[Date]>'Calendar'[Date] LookupCols(0)('Calendar'[Date]) DateTime
                └── Spool_Iterator<SpoolIterator>: IterPhyOp LogOp=Filter IterCols(0, 22)('Calendar'[Date], 'Sales'[ShipDate]) #Records=583719 #KeyCols=2 #ValueCols=0
                    └── AggregationSpool<GroupBy>: SpoolPhyOp #Records=583719
                        └── Filter: IterPhyOp LogOp=Filter IterCols(0, 22)('Calendar'[Date], 'Sales'[ShipDate])
                            └── Extend_Lookup: IterPhyOp LogOp=GreaterThan IterCols(0, 22)('Calendar'[Date], 'Sales'[ShipDate])
                                ├── CrossApply: IterPhyOp LogOp=GreaterThan IterCols(0, 22)('Calendar'[Date], 'Sales'[ShipDate])
                                │   ├── Spool_Iterator<SpoolIterator>: IterPhyOp LogOp=Scan_Vertipaq IterCols(0)('Calendar'[Date]) #Records=1081 #KeyCols=26 #ValueCols=0
                                │   │   └── ProjectionSpool<ProjectFusion<>>: SpoolPhyOp #Records=1081
                                │   │       └── Cache: IterPhyOp #FieldCols=1 #ValueCols=0
                                │   └── Spool_Iterator<SpoolIterator>: IterPhyOp LogOp=Scan_Vertipaq IterCols(22)('Sales'[ShipDate]) #Records=1075 #KeyCols=26 #ValueCols=0
                                │       └── ProjectionSpool<ProjectFusion<>>: SpoolPhyOp #Records=1075
                                │           └── Cache: IterPhyOp #FieldCols=1 #ValueCols=0
                                └── GreaterThan: LookupPhyOp LogOp=GreaterThan LookupCols(0, 22)('Calendar'[Date], 'Sales'[ShipDate]) Boolean
                                    ├── ColValue<'Sales'[ShipDate]>: LookupPhyOp LogOp=ColValue<'Sales'[ShipDate]>'Sales'[ShipDate] LookupCols(22)('Sales'[ShipDate]) DateTime
                                    └── ColValue<'Calendar'[Date]>: LookupPhyOp LogOp=ColValue<'Calendar'[Date]>'Calendar'[Date] LookupCols(0)('Calendar'[Date]) DateTime

用流程图来说明层级结构（注意一下 7:CrossApply​的子级，按先后顺序应该是 8:Spool_UniqueHashLookup​、22:Spool_MultiValuedHashLookup​、36:Cache(VQ4)​，但是用 Mermaid 画出来22:Spool_MultiValuedHashLookup​ 跑到最左边去了，如果有谁知道在 Mermaid 中怎么控制这些块的排布顺序，将8:Spool_UniqueHashLookup​调到最左侧，请指导一下，谢谢）
T1:Sales[ShipDate] > Calendar[Date]
55:CrossApply
53:Filter
62:Sales[ShipDate] >
Calendar[Date]
58:Cache(VQ2)
Calendar[Date]
61:Cache(VQ3)
Ship[ShipDate]
T2:Sales[OrderDate] < Calendar[Date]
41:CrossApply
39:Filter
48:Sales[OrderDate] <
Calendar[Date]
44:Cache(VQ2)
Calendar[Date]
47:Cache(VQ1)
Sales[OrderDate]
T2:Sales[OrderDate]<Calendar[Date]
26:CrossApply
24:Filter
33:Sales[OrderDate] <
Calendar[Date]
29:Cache(VQ2)
Calendar[Date]
32:Cache(VQ1)
Sales[OrderDate]
T1:Sales[ShipDate] > Calendar[Date]
12:CrossApply
10:Filter
19:Sales[ShipDate] >
Calendar[Date]
15:Cache(VQ2)
Calendar[Date]
18:Cache(VQ3)
Sales[ShipDate]
1:AddColumns
2:Spool_Iterator
4:Cache(VQ2)
Calendar[Date]
5:SpoolLookup
6:Sum
7:CrossApply
8:Spool_UniqueHashLookup
22:Spool_MultiValuedHashLookup
36:Cache(VQ4)
Sales[OrderDate],Sales[ShipDate],[COUNT]
37:Spool_Iterator
51:Spool_Iterator

在这次的物理查询计划中，有部分行内容是重复的，上图中用 T1​ 和 T2​ 和方框做了标记，各部分作用如下：

  • T1：将 VQ2（Calendar[Date]）（1081行） 与 VQ3（Sales[ShipDate]）（1075行） 求交叉表（1081×1075=1162075行），从中筛选出 Sales[ShipDate] > Calendar[Date] 的数据，共 583719 行，有两列，Sales[ShipDate] 和 Calendar[Date]，后文用 T1(Sales[ShipDate],Calendar[Date])​表示T1​的结果

  • T2：将 VQ2 （Calendar[Date]）（1081行）与 VQ1（Sales[OrderDate]) （1081行） 求交叉表（1081×1081=1168561行），从中筛选出 Sales[OrderDate] < Calednar[Date] 的数据，共 583740 行，有两列，Sales[OrderDate] 和 Calendar[Date]，后文用 T2(Sales[OrderDate],Calendar[Date])​表示T2​的结果

这种通过求交叉表再进行筛选的操作，在上一篇初始方案的查询计划中已经见到过了，在 DAX 底层这是一种常见操作。

将重复的步骤合并后，把流程图简化一下：

‍
T2:Sales[OrderDate]<Calendar[Date]
CrossApply
Filter
Sales[OrderDate] <
Calendar[Date]
Cache(VQ2)
Calendar[Date]
Cache(VQ1)
Sales[OrderDate]
T1:Sales[ShipDate] > Calendar[Date]
CrossApply
Filter
Sales[ShipDate] >
Calendar[Date]
Cache(VQ2)
Calendar[Date]
Cache(VQ3)
Sales[ShipDate]
1:AddColumns
2:Spool_Iterator
4:Cache(VQ2)
Calendar[Date]
5:SpoolLookup
6:Sum
7:CrossApply
8:Spool_UniqueHashLookup
22:Spool_MultiValuedHashLookup
36:Cache(VQ4)
Sales[OrderDate],Sales[ShipDate],[COUNT]

现在来回答前面 VQ4 xmSQL 中 WHERE 子句中的值列表怎么来的，VQ4 的代码再贴一下

// VQ4
SELECT
    'Sales'[OrderDate],
    'Sales'[ShipDate],
    COUNT ( )
FROM 'Sales'
WHERE
    'Sales'[OrderDate] IN ( 43768.000000, 43809.000000, 43850.000000, 43893.000000, 43934.000000, 43975.000000, 43014.000000, 43426.000000, 43468.000000, 43513.000000..[1,080 total values, not all displayed] ) VAND
    'Sales'[ShipDate] IN ( 43775.000000, 43816.000000, 43857.000000, 43900.000000, 43941.000000, 43982.000000, 43028.000000, 43433.000000, 43475.000000, 43520.000000..[1,074 total values, not all displayed] ) ;

从上面物理查询计划的流程图可知，36:Cache(VQ4)​ 使用了 T1​ 和 T2​，这便是 VQ4 的 xmSQL 中 WHERE 子句部分的来源：

  • WHERE 子句将 Sales[OrderDate] 限定在 1080 个值列表中，这 1080 个值来自 T2 结果中 [ShipDate] 的不重复值。

  • WHERE 子句将 Sales[ShipDate] 限定在 1074 个值列表中， 这 1074 个值来自 T1 结果中 [ShipDate] 的不重复值。

在 DAX Studio 中可以验证一下 1074 这个数值。
​​在这里插入图片描述

据此可知，VQ4 分别限定了 Sales[OrderDate] 和 Sales[ShipDate] 的值范围，使其满足 Sales[OrderDate] < Calednar[Date] 和 Sales[ShipDate] > Calendar[Date] 两个条件，对 Sales 表进行筛选，并将符合的数据行以 Sales[OrderDate] 和 Sales[ShipDate] 分组，计算出每个分组的行数 [Count]。后文以 VQ4(Sales[OrderDate], Sales[ShipDate], [COUNT])​表示 VQ4 的结果

底层计算过程

由于没有找到关于操作符 Spool_UniqueHashLookup​ 和 Spool_MultiValuedHashLookup​的说明，根据最终结果、结合实践做一些方案推理，目前我找到一个可能的理解，暂未遇到能够推翻该理解的反例，姑且认为是正确，那么现在可以把优化方案1的底层计算过程梳理出来了：

1、SE 执行 xmlSQL 查询： VQ2 和 VQ1，操作符CrossApply​ 对VQ2 和 VQ1求交叉表即 Calendar[Date] 和 Sales[OrderDate] 的交叉表，操作符FILTER​从该交叉表中筛选出 Sales[OrderDate]<Calendar[Date] 的数据，得到 T1(Sales[ShipDate],Calendar[Date])​

2、SE 执行 xmlSQL 查询： VQ2 和 VQ3，操作符CrossApply​ 对VQ2 和 VQ3 求交叉表 即 Calendar[Date] 和 Sales[ShipDate] 的交叉表，操作符FILTER​从该交叉表中筛选出 Sales[ShipDate]> Calendar[Date] 的数据，得到 T2(Sales[OrderDate],Calendar[Date])​

3、 T1​ 和 T2​ 中的 Sales[ShipDate] 和 Sales[OrderDate] 去重后构成 VQ4 WHERE 子句中的值列表，SE 执行 VQ4，得到VQ4(Sales[OrderDate], Sales[ShipDate], [COUNT])​

4、22:Spool_MultiValuedHashLookup​将VQ4(Sales[OrderDate], Sales[ShipDate], [COUNT])​与T2(Sales[OrderDate],Calendar[Date])​ 以共有的 Sales[OrderDate] 作为匹配列进行连接（类似 PowerQuery 里的合并查询），得到含有4列（Sales[OrderDate], Sales[ShipDate], [Count], Calendar[Date]）的表，该表中的数据仅满足计算要求中的单个条件： Sales[OrderDate] < Calendar[Date] 这一个条件。

5、8:Spool_UniqueHashLookup​将 4# 的结果与T1(Sales[ShipDate],Calendar[Date])​ 以 Calendar[Date] 和 Sales[ShipDate] 作为匹配列进行内连接，包含4列（Sales[OrderDate], Sales[ShipDate], [Count], Calendar[Date]）。该结果中的数据满足了计算要求中的两个条件：Sales[OrderDate] < Calendar[Date] 和 Sales[ShipDate] > Calendar[Date]

6、6:SUM​将 5# 的结果以 Calendar[Date] 分组并将 [Count] 进行累加，得到一张仅有2列（Calendar[Date], [SUM]）的表，其中 [SUM] 的值便是当日包含的 OpenOrders 数量

7、1:AddColumns​以 4:Cache(VQ2)​中的 Calendar[Date] 列为基准，从 6# 的结果中查询对应的 [SUM] 值，作为新添加的 [OpenOrders] 列的值，得到最终结果

性能瓶颈分析比较

优势

既然优化方案1相较原始方案将性能提升了 9 成，那么一定部分克服了上一篇中分析的性能瓶颈，回顾一下上一篇中原始方案的瓶颈：

SE 执行了 2 个查询，且都是初级数据，FE 执行大量运算来转换成最终结果。

FE 执行过程中，需要将 VQ1（101253行） 和 VQ2（1081）行做交叉表，得到数量非常庞大的数据表（109,454,493行），这需要耗费大量内存。后续又对该数据表进行两次 FILTER 操作，耗费了大量时间。

上一篇的分析中， VQ1（101253行） 和 VQ2（1081）交叉表数据量非常庞大，原因是原始方案中 VQ1 存在一个特殊列 Sales[RowNumber] 使得该查询返回了 Sales 表中全部 101253 行中的 [OrderDate] 和 [ShipDate]

// 原始方案中的 VQ1
SELECT
    'Sales'[RowNumber],  //注意此处
    'Sales'[OrderDate],
    'Sales'[ShipDate]
FROM 'Sales';

xmSQL 与标准 SQL 有一个重大的区别：xmSQL 始终对 SELECT 子句中的列进行分组运算，而标准 SQL 必须使用 GROUP BY 来设置分组。下面两段代码是等价的：

// xmSQL
SELECT Product[Color]
FROM Product  

// 标准 ANSI SQL
SELECT Color
FROM Product   
GROUP BY Color

[RowNumber] 是引擎在底层自动给表添加的唯一标识列，当 xmSQL 需要获取表中每一行的数据时，就会将 [RowNumber] 添加到 SELECT 子句中，由于 [RowNumber] 每一行都有不同的值，对其进行分组的实际效果等价于不分组。因此，原始方案中的 VQ1 返回了 101253 行数据。

而本篇的优化方案1，存储引擎执行的与 Sales 有关的 3 个 xmSQL 查询中， SELECT 子句中都没有出现 [RowNumber]，分别如下：

// VQ1
SELECT
    'Sales'[OrderDate] 
FROM 'Sales';

// VQ3
SELECT
    'Sales'[ShipDate]
FROM 'Sales';

// VQ4
SELECT
    'Sales'[OrderDate],
    'Sales'[ShipDate],
    COUNT ( )
FROM 'Sales'
WHERE
    'Sales'[OrderDate] IN ( 43768.000000, 43809.000000, 43850.000000, 43893.000000, 43934.000000, 43975.000000, 43014.000000, 43426.000000, 43468.000000, 43513.000000..[1,080 total values, not all displayed] ) VAND
    'Sales'[ShipDate] IN ( 43775.000000, 43816.000000, 43857.000000, 43900.000000, 43941.000000, 43982.000000, 43028.000000, 43433.000000, 43475.000000, 43520.000000..[1,074 total values, not all displayed] ) ;

VQ1 等价于标准 SQL：

// ANSI SQL
SELECT OrderDate
FROM Sales
GROUP BY OrderDate

VQ4 等价于标准 SQL

// ANSI SQL
SELECT OrderDate, ShipDate, COUNT (*)
FROM Sales
WHERE OrderDate IN ... AND ShipDate IN ...
GROUP BY OrderDate, ShipDate

Sales 表中[OrderDate] 和 [ShipDate] 列都存在大量重复值，进行分组后，实际返回的数据量并不包含重复值，使得数据量大幅减少。

DAX 引擎在底层执行 FILTER 的判断条件时会先计算交叉表，比较两个方案的情况：

原始方案：

  1. 将 Sales 所有行（101253行）与 Calendar[Date]（1081行） 做交叉表（109,454,493行）

优化方案1：

  1. 将去重后的 Sales[OrderDate]（1081行）与 Calendar[Date]（1081行）做交叉表（1,168,561行）
  2. 将去重后的 Sales[ShipDate]（1075行）与 Calendar[Date]（1081行）做交叉表（1,162,075行）

优化方案1 将交叉表的势，从亿级(108 )降到了百万级(106)，减少了2个数量级，因此获得了相应的性能提升。

劣势

白皮书提供了3个优化方案，本篇的优化方案1是性能提升最小的一个。

单从本篇分析的底层执行过程来看，不容易找到哪里存在劣势。待研究完其他方案后，再通过比较来发现优化方案1的劣势吧。

思考总结

一

本篇介绍的优化方案1所采用的算法，本质上仍然是基于对计算要求的直接理解，并没有刻意使用任何能够减少迭代对象的势从而减少计算量的方法，计算效率得到提升，源自 DAX 底层对 CALCULATE + FILTER 进行过优化。

二

DAX 使用者从中能获取的实践经验，表面上看，有以下几点

  • 在 DAX 引擎底层，CALCULATE 中的筛选器会被作为 WHERE 子句放到 xmSQL 中，而直接使用 FILTER 则不会，尤其在 FILTER 的一参中使用整表作为迭代对象时，还会在 xmSQL 中使用 [RowNumber]，使查询结果的势等于整张表的总行数

  • 即便在 FILTER 的一参中使用整表作为迭代对象，存储引擎执行的相关 xmSQL 时只会包含跟条件有关的列，并不会将一参中所有列都列进来。比如原始方案虽然写了FLTER(Sales,...)​，从 DAX 理论来看，FILTER 会遍历 Sales 所有行上的行上下文，包括全部 14 列，但实际执行的 xmSQL，VQ1 中 SELECT 子句中只有’Sales’[RowNumber], ‘Sales’[OrderDate], ‘Sales’[ShipDate] 3列，并没有包含其他列，这也是 DAX 底层进行优化的结果

  • 在某些数据模型中， 将 COUNTROWS( FILTER( Sales, …)) 的写法改成 CALCULATE + FILTER 的组合可能会计算得更快

说这是表面的经验，是因为 DAX 优化并不是只需要考虑代码如何写，而是需要先了解数据模型中的各列的势、列上的数据分布、数据类型等等因素，并不存在套用在任何数据模型中都能取得性能提升的通用经验写法。比如笔者看到过在某些数据模型中使用 CALCULATE 的写法导致产生数量庞大的 xmSQL 查询（比如生成99个 xmSQL 查询），反而拖慢计算速度。

DAX 使用者不应该追求找到某种通用的经验代码，而是应该先了解影响计算效率的因素，掌握分析方法，分析出性能瓶颈原因后，再结合数据模型改进写法，并通过测试判断是否实现了计算效率提升。

三

我不太明白为什么优化案例1中 CALCULATE 的参数中要写 2 个 FILTER，很显然它们可以合并成一个 FILTER，我测试了将 2 个 FILTER 合并的写法，计算速度会更快一些。

由于白皮书后面给出的另外两个优化方案不再是基于对计算要求的直接理解，改用了不同的算法，完全没有探讨将 FILTER 分开和合并的区别，我打算在继续写白皮书给的其他优化方案之前，先分析研究下 FILTER 合并后性能提升的原因。

云数据库索引设计：提升查询性能的黄金法则
AI天才研究院
07-03 1005
本文系统解析云数据库索引设计的核心逻辑，覆盖从理论原理到工程实践的全生命周期。通过第一性原理推导揭示索引优化的本质规律，结合云原生特性（弹性扩展、多租户、分布式架构）分析传统索引结构的演进与创新。内容包含多层次知识体系：面向专家的理论模型与分布式挑战、面向中级开发者的架构设计与实现技巧、面向入门者的类比教学与案例解析。最终提炼12条黄金法则，为云数据库索引设计提供可落地的技术指南。索引的本质是用存储与写入性能换取查询性能查询性能。
计算机设备管理器dax,《DAX权威指南：运用Power BI、SQL Server Analysis Services和Excel实现商业智能分》（意）MarcoRusso（马尔·科鲁索），Albe...
weixin_39930671的博客
07-07 954
章DAX是什么1理解数据模型1理解关系的方向3给Excel用户的DAX学习建议5单元格和智能表格5Excel函数和DAX：两种函数式语言7使用迭代器7DAX相关理论8给SQL开发人员的DAX学习建议8处理关系9DAX是函数式语言9DAX是一种编程语言和查询语言10DAX和SQL中的子查询与条件语句10给MDX开发者的DAX学习建议11多维模型和表格模型12DAX是一种编程语言和查询语言12层级结构...
DAX-查询计划
java开发指南博客 【转载】
06-09 245
DAX-查询计划，有四个： DAX VertiPaq Logical Plan DAX VertiPaq Physical Plan DAX DirectQuery Algebrizer Tree DAX DirectQuery Logical Plan 运算符类型： Plan Type Operator Type Description ...
DAX-查询计划续
java开发指南博客 【转载】
06-11 141
前文的查询,补两个图: A B 显然, 查询B要好于查询A. 因为后者, FE把SUM推给VERTIPAQ ENGINE.,而前者SUMX由FE执行.
DAX实战小例：对数据进行分组分析 1
Fluffy的百宝箱
03-27 7485
介绍使用DAX对数据按组分类计算的情况。
DAX中的自定义变量函数VAR（1）
热门推荐
Fluffy的百宝箱
06-01 1万+
DAX中的自定义变量函数VAR的基本概念和用法
研究《DAX查询计划 白皮书》中的案例(三)优化方案（番外）
一棵松的博客
05-13 979
‍上一篇给出的优化方案中使用了两个 FILTER 函数，而如果将两个 FILTER 函数合并成一个，可以使计算性能进一步提升，但是白皮书中并没有记录该方案。为了查明原因，比较优劣，本篇先将白皮书的其他优化方案抛开，先研究一下这个番外优化方案的秘诀。
研究《DAX查询计划 白皮书》中的案例(五)优化方案3
一棵松的博客
05-19 1309
这是本系列的最后一个优化方案，这一篇的优化方案3是所有方案中最优秀的，它解决了优化方案2中产生的[RowNumber] 问题，使整个底层计算过程中全部步骤都没有出现数据量超过万行的情况，使性能获得了极大的提升！
研究《DAX查询计划 白皮书》中的案例(四)优化方案2
一棵松的博客
05-17 1359
优化方案1将原始方案的计算效率提高了 90% 以上，而白皮书认为这还不是最好的方案，原作者给出了另外两个更好的方案，这两个算法都不再基于对计算要求的直接理解，更换了 DAX 写法。本篇分析白皮书提供的优化方案2，并与优化方案1和优化方案(番外)进行比较，进一步认识性能优劣的底层原因。
《dax 查询计划 白皮书》 优化方案2 计算过程模拟演示
05-18
通过图示和动态计算，在 Excel 中演示优化方案2的底层计算过程。...详细解析见文章 《研究〈白皮书-理解DAX查询计划〉中的案例(四)优化方案2》 https://blog.youkuaiyun.com/Randvalue/article/details/138979537
大数据与Power BI：开启数据分析新征程
Golang编程笔记的博客
09-30 606
随着企业数据量以年均40%的速度增长（IDC数据），传统数据分析工具已难以应对PB级数据的处理需求。Power BI作为微软推出的商业智能平台，凭借其强大的数据整合能力和可视化引擎，成为连接大数据技术与业务决策的核心枢纽。解析Power BI处理大数据的技术架构与核心原理演示从数据接入到交互式报表的全流程操作探讨复杂数据建模与性能优化策略提供零售、金融等行业的实战应用方案大数据与Power BI的核心概念及技术关联数据处理的核心算法与数学模型。
Windows操作系统的数据分析工具使用教程
操作系统内核探秘的博客
04-15 1007
本教程旨在为Windows用户提供一套完整的数据分析工具使用指南，覆盖从基础到进阶的数据处理技术。我们将重点介绍Microsoft生态系统中的数据分析工具，同时也会涉及开源解决方案在Windows环境下的集成使用。教程按照工具类型和技术难度组织，从简单的Excel分析开始，逐步过渡到专业的BI工具和编程解决方案。每个工具部分都包含安装配置、核心功能演示和实际应用案例。ETL：提取(Extract)、转换(Transform)、加载(Load)的数据处理流程。
【云原生进阶之容器】第五章容器运行时5.5--容器运行时之Kata Containers
junbaozi的专栏
04-04 897
Kata Containers是一个新的开源项目，它提供了与虚拟机工作负载隔离的Linux容器的速度和性能。它被设计为与OCI镜像兼容的体系结构，并与Kubernetes的容器运行时接口(CRI)兼容。Kata Containers托管在Apache 2许可下的Github上，并由OpenStack基金会管理。Kata Container项目是两个现有的开源项目合并——Intel Clear Containers和Hyper runV。
DAX中的自定义变量函数VAR（2）
Fluffy的百宝箱
06-04 3834
自定义变量函数VAR合并或者拆分的注意事项。
PowerBI常见报错故障
专注“目标检测”领域技术分享
11-30 136
因为日期没有和销售额所在的表建立联系建立关系以后。
lenz0a89.gsd Lenze E84AYCPM gsd
12-05
lenz0a89.gsd Lenze E84AYCPM gsd
【大厂+2025】500+真题考点合规备考双通！.zip
12-05
【大厂+2025】500+真题考点合规备考双通！.zip
【微服务架构】基于Spring Cloud Alibaba的秒杀系统设计：高并发场景下库存超卖与分布式事务解决方案
12-05
内容概要：本文详细介绍了“秒杀商城”微服务架构的设计与实战全过程，涵盖系统从需求分析、服务拆分、技术选型到核心功能开发、分布式事务处理、容器化部署及监控链路追踪的完整流程。重点解决了高并发场景下的超卖问题，采用Redis预减库存、消息队列削峰、数据库乐观锁等手段保障数据一致性，并通过Nacos实现服务注册发现与配置管理，利用Seata处理跨服务分布式事务，结合RabbitMQ实现异步下单，提升系统吞吐能力。同时，项目支持Docker Compose快速部署和Kubernetes生产级编排，集成Sleuth+Zipkin链路追踪与Prometheus+Grafana监控体系，构建可观测性强的微服务系统。; 适合人群：具备Java基础和Spring Boot开发经验，熟悉微服务基本概念的中高级研发人员，尤其是希望深入理解高并发系统设计、分布式事务、服务治理等核心技术的开发者；适合工作2-5年、有志于转型微服务或提升架构能力的工程师； 使用场景及目标：①学习如何基于Spring Cloud Alibaba构建完整的微服务项目；②掌握秒杀场景下高并发、超卖控制、异步化、削峰填谷等关键技术方案；③实践分布式事务（Seata）、服务熔断降级、链路追踪、统一配置中心等企业级中间件的应用；④完成从本地开发到容器化部署的全流程落地； 阅读建议：建议按照文档提供的七个阶段循序渐进地动手实践，重点关注秒杀流程设计、服务间通信机制、分布式事务实现和系统性能优化部分，结合代码调试与监控工具深入理解各组件协作原理，真正掌握高并发微服务系统的构建能力。
MATLAB基于3D FDTD的微带线馈矩形天线分析[用于模拟超宽带脉冲通过线馈矩形天线的传播，以计算微带结构的回波损耗参数]
最新发布
12-05
MATLAB基于3D FDTD的微带线馈矩形天线分析[用于模拟超宽带脉冲通过线馈矩形天线的传播，以计算微带结构的回波损耗参数]内容概要：本文介绍了基于3D FDTD（时域有限差分）方法在MATLAB平台上对微带线馈电的矩形天线进行分析的技术方案，旨在模拟超宽带脉冲通过该天线结构的传播过程，并重点计算微带结构的回波损耗参数。该方法通过数值仿真手段精确建模电磁波在天线中的传播特性，适用于高频电磁场仿真与天线性能评估，能够有效支持天线设计优化。文中可能涵盖FDTD算法的基本原理、网格划分、边界条件设置、激励源配置及结果后处理等关键环节。; 适合人群：具备电磁场与微波技术基础知识，熟悉MATLAB编程，从事天线设计、射频工程或相关领域研究的研究生、科研人员及工程技术人员。; 使用场景及目标：①开展超宽带天线的设计与性能仿真；②研究微带天线在脉冲激励下的瞬态响应特性；③计算和优化天线的回波损耗（S11参数），提升匹配性能；④教学与科研中用于电磁仿真方法的实践训练。; 阅读建议：建议读者结合FDTD理论基础与MATLAB编程实践，逐步实现仿真流程，重点关注时间步长、空间网格精度和边界条件对仿真结果的影响，并通过对比仿真与实测数据验证模型准确性。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值