自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(11)
  • 收藏
  • 关注

原创 SUMMARIZECOLUMNS 的疑似 bug(5)最终结论

上一篇找到了触发 `SUMMARIZECOLUMNS`​ 计算的结果不符合 DAX 理论的充分条件,这一篇尝试探讨修正理论对其进行解释,在这一篇中,我以为找到了一个合理的理论假设,但随后一个新的发现给了我当头一棒,这一篇应该是本系列的最后一篇,我必须直面现实了。

2024-06-09 20:54:03 1178 2

原创 DAX 底层计算过程演示——ADDCOLUMNS + 复杂上下文环境

关于 DAX 理论的资料很多,DAX 理论帮助我们理解和预测 DAX 的计算结果,但 DAX 在底层实际是怎么计算的却少有人谈及。本篇以一段在复杂上下文环境中通过 ADDCOLUMNS 进行计算的 DAX 查询代码为观察对象,使用 DAX Stuido 查看查询计划,展示其在存储引擎中执行了哪些数据查询,揭示公式引擎如何组装这些数据最终得出计算结果。

2024-05-28 00:24:48 1350

原创 SUMMARIZECOLUMNS 的疑似 bug(4)验证触发条件

上一篇发现总计行并不是关键点,并根据观察到的现象猜测了3个关键点,本篇通过单变量控制实验逐一对其进行验证,判断哪些条件会触发计算结果与 DAX 理论不符的情况,并最终确认了这些条件。

2024-05-27 21:40:15 636

原创 SUMMARIZECOLUMNS 的疑似 bug(3)总计行是否关键点

上一篇介绍了在总计行中出现与理论预期不符的结果,通过物理查询计划了解其底层计算过程,猜想是否 `SUMMARIZECOLUMNS`​函数对总计行的计算存在什么特殊算法,本篇验证在非总计行中进行计算的情况,以帮助判断总计行是否是关键点。

2024-05-25 18:33:35 913

原创 SUMMARIZECOLUMNS 的疑似 bug(2)SUMX 在总计行

上一篇介绍了 SUMMARIZECOLUMNS 在特定情况下计算出的结果不符合 DAX 理论预测,这一篇我们开开始探究 DAX 在底层究竟是如何计算出这些结果的,主要的方法是用 DAX 查询复现该现象,通过观察物理查询计划了解底层计算步骤,试图从中定位到问题所在。

2024-05-24 19:42:41 490 5

原创 SUMMARIZECOLUMNS 的疑似 bug(1)引言

与 Excel 通过 MDX 创建报表的方式不同,PowerBI 在代码层面主要是通过 SUMMARIZECOLUMNS​ 函数计算报表中各个视觉对象,它实现了 MDX 中的 auto-exist 功能并具有诸多特性,能够在许多场景中代替ADDCOLUMNS​+ SUMMARIZE​的应用。在特定情况下,SUMMARIZECOLUMNS ​的计算结果似乎并不符合 DAX 理论,本篇介绍这些疑似存在 BUG 的现象。

2024-05-23 22:58:58 1076 2

原创 研究《DAX查询计划 白皮书》中的案例(五)优化方案3

这是本系列的最后一个优化方案,这一篇的优化方案3是所有方案中最优秀的,它解决了优化方案2中产生的[RowNumber] 问题,使整个底层计算过程中全部步骤都没有出现数据量超过万行的情况,使性能获得了极大的提升!

2024-05-19 21:15:21 1195 1

原创 研究《DAX查询计划 白皮书》中的案例(四)优化方案2

优化方案1将原始方案的计算效率提高了 90% 以上,而白皮书认为这还不是最好的方案,原作者给出了另外两个更好的方案,这两个算法都不再基于对计算要求的直接理解,更换了 DAX 写法。本篇分析白皮书提供的优化方案2,并与优化方案1和优化方案(番外)进行比较,进一步认识性能优劣的底层原因。

2024-05-17 00:05:18 1202

原创 研究《DAX查询计划 白皮书》中的案例(三)优化方案(番外)

‍上一篇给出的优化方案中使用了两个 FILTER 函数,而如果将两个 FILTER 函数合并成一个,可以使计算性能进一步提升,但是白皮书中并没有记录该方案。为了查明原因,比较优劣,本篇先将白皮书的其他优化方案抛开,先研究一下这个番外优化方案的秘诀。

2024-05-13 23:55:27 839

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

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

2024-05-12 21:18:48 348

原创 研究《DAX查询计划 白皮书》的案例(一)初始方案

SQLBI 网站上提供的[《White paper: Understarnding DAX Query Plans》,发布于2023年7月17日,距今已超过10年,随着DAX 版本不断更新优化,原文中关于查询计划的描述已不再符合当前实际情况。为充分理解、运用该文阐述的分析方法,以当前 DAX 版本运行文中案例,尝试理解查询计划及优化思路。

2024-05-10 22:34:45 822

《dax 查询计划 白皮书》 优化方案3 计算过程模拟演示

本系列的最后一个优化方案,这一篇的优化方案3是所有方案中最优秀的,它解决了优化方案2中产生的[RowNumber] 问题,使整个底层计算过程中全部步骤都没有出现数据量超过万行的情况,使性能获得了极大的提升! https://blog.csdn.net/Randvalue/article/details/139048417

2024-05-28

SUMMARIZECOLUMNS 的疑似 bug(1)引言案例文件

文章《SUMMARIZECOLUMNS 的疑似 bug(1)引言》中描述的案例,展示SUMMARIZECOLUMNS 疑似 BUG https://blog.csdn.net/Randvalue/article/details/139159515

2024-05-28

《DAX 底层计算过程演示-ADDCOLUMNS + 复杂上下文环境》配套数据文件

《DAX 底层计算过程演示——ADDCOLUMNS + 复杂上下文环境》配套的案例数据文件 https://blog.csdn.net/Randvalue/article/details/139251092

2024-05-28

《dax 查询计划 白皮书》 优化方案2 计算过程模拟演示

通过图示和动态计算,在 Excel 中演示优化方案2的底层计算过程。 详细解析见文章 《研究〈白皮书-理解DAX查询计划〉中的案例(四)优化方案2》 https://blog.csdn.net/Randvalue/article/details/138979537

2024-05-18

研究《白皮书-理解DAX查询计划中》的案例所用数据

系列文章【研究《白皮书-理解DAX查询计划中》的案例】所用数据,二进制 Excel 文档,包含 Sales 表一张,详情见文章链接 https://blog.csdn.net/Randvalue/article/details/138683483

2024-05-10

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除