从 PowerBI DAX 计算最大连续复购天数到极致的性能优化

DAX 是 PowerBI 中的函数语言，并非通用类编程语言，对于很多问题，无法像编程语言一样设计解决思路，需要另辟蹊径。而使用 DAX 设计的算法是否可以达到性能最优也是一个问题。
本文达成两个预期：

• 编写一个解决复杂业务问题的DAX算法
• 对该算法进行性能优化
  并展示一个好玩的现象：
• 普通算法与优化算法的性能对比
• 10000行逻辑查询的性能是可能由于1000行查询逻辑的

这里的每个问题都十分惊艳，让我们一起来了解。

问题重述

在很多情况下，我们会遇到以下场景：

• 对于某员工，最近一个月，连续迟到的最大日数是多少？
• 对于某会员，最近12个月，连续每月购买的最大月数是多少？
• 对于某企业，最近10年中，每年发展都增长的最大连续年数是多少？

大家可以自行考虑或尝试实现以上问题的 PowerBI 中 DAX 实现。这并不是一个简单的问题。

问题抽象

为了更好地理解本问题，并为未来扩展留有机会，这里对上述问题进行抽象，如下：

可以看出对于上述问题，均可以描述成由核心两列完成计算的过程。因此，可以对该问题做进一步优化，得到：

对问题进行进一步加工抽象，可以得到：

• Index 列，与行号类似。
• Flag 列，指明该用户或产品在当期有效（真实环境中）。

于是问题转化成了从Index与Flag构成的表中寻找答案。

DAX 算法设计

本案例中描述的问题比较复杂，由于DAX中是没有循环结构，导致无法使用循环结构来处理问题。

在 PowerBI DAX 中，我们可以通过技巧来实现类似循环结构的效果，我们将这个效果用于本案例，首先来看下算法示意图：

大家可以思考本问题的本质是几层循环结构？

按照上图的算法思路，我们考虑如下：

• 对于[Index]的每一行
  • 建立从起始位置到当前[Index]位置 n 的结构
  • 对于该结构的每行 m
    • 建立从 m 到 n 的结构
    • 如果 m 到 n 全是 1 ，则该行为连续满足行
  • 获取连续满足行的最大值，则得到连续满足条件的最大值
• 再获取连续满足条件的最大值的最大值

因此，可以发现对于这里的业务问题涉及3层循环结构，在DAX中很可惜是不支持循环结构的。

DAX 算法实现

这里使用技巧来实现需求，直接上 DAX 算法如下：

Source 的示意结构以及计算完成的结构为：

通过对 Source 表加入一个 Value 列来计算每行的结果。

DAX 性能评估及优化

如果将下图的面积部分视作 DAX工作的负荷，则：

可以看出，凡是出现 1 的位置，都会做一个从头到当前位置的迭代，因此总的算法规模大致在：
n * ( 1 + n ) * n / 2 ，大致为 n 的三次方规模，其中 n 为行数。

通过增加行数来看看算法的可用性随着时间的变化：

也就是说，当迭代行数达到1000行时，所需时间规模在6分钟（原单位为毫秒，1秒=1000毫秒）。这是一个不可接受的性能。当然在实际的操作中，可能并不需要有大到1000规模的迭代。

算法的优化设计

对于上述的算法，其实已经做了少许优化，算法并不考察每一行，而是仅仅考察Flag=1的行，这样已经减小了计算规模，但远远不够。其实还可以在优化，我们仔细再研究该问题后，可以得到这样的算法思路：

对比之前的算法，从观察面积表示了算法的计算规模（消耗时间）可以看出优化的算法，可以大幅提升性能。其思路是：不从开始位置迭代，不然会产生大量无效迭代计算，优化的算法从1的位置开始迭代，因此可以大幅度缩减计算规模。

如果再进一步仔细观察，会发现如果数据中存在大量的独立点1，也就是说：几乎都是偶尔迟到1次，很少出现连续多次迟到，这是一种稀疏情形，那么还可以做更进一步的优化，将针对第一个 1 的迭代全部去除，以降低大量稀疏的 1 带来的运算量，这种运算也是意义不大的，算法进一步改进如下：

可以再次通过面积来直观对比，可以发现所需面积大幅度下降，也就是性能再次大幅提升。

如果原问题是带有大量的稀疏的 1 的，全部排出后的算法复杂度大致为：

k * ( 1 + k ) * k / 2 ，其中 k << n ，n 为行数，k 为最终的答案值， 且远远小于 n。

DAX 改进算法的实现

我们看看它的DAX表达式：

高亮圈选的内容就是优化的核心所在。

用 DAX Studio 观测性能优化效果

首先来比较一下优化前后，DAX引擎对DAX表达式的处理，也就是翻译成DAX引擎可以执行的逻辑，改良前的逻辑查询达1000行；而改良后的逻辑查询达10000行；问题来了：1000行的效率会比10000行更高吗？截图如下：

优化前：

优化后：

我们分别记录不同量级下的查询耗时来进行分析。

性能实际测试分析

如下所示：

这是在 100 行数据以内，两种算法效果的对比。这反应了在 60个元素以内，优化算法反而看不出优化。

随着数据量的增长，优化算法的优化被慢慢显现出来，如下所示：

可以看出随着时间的变化，优化算法可以保持很好的稳定性，但普通算法在 60 个元素以后就会大幅来到性能瓶颈。

优化算法可以处理5000元素在10秒以内完成。也就是说500个用户在过去12个月的最大连续购买月数。我们在DAX中运行可以看到非常明显的差异。

为何优化后的查询更复杂，而效率反而更高

大家可以留意到优化后的查询多达10000行；而优化前的查询大致是1000行。
由于查询复杂度增加了10倍，因此，表现出：

• 60以内的元素，普通算法胜出；
• 100以上元素，优化算法大幅胜出。

总结

本文通过实际案例讲述了：

• 复杂DAX的算法设计流程
• 算法优化流程
• 算法性能的评估

因此，本文内容在有着巨大的实际业务价值的同时还有着巨大的示范意义。