★ FEATURED ARTICLE 简介《DAX权威指南》第二版原版英文PDF是一份面向数据分析师、商业智能开发者及IT项目经理的权威技术资料聚焦DAX语言在微软Power BI、SQL Server Analysis Services和Excel等商业智能工具中的建模与计算应用。全书从DAX基础概念、表函数与筛选上下文入手逐步深入计算列与度量值、CALCULATE函数、SUMX等迭代器、上下文转换、多对多关系等核心机制并专门讨论查询性能优化、最佳实践及常见错误规避书中提供的多个贴近业务场景的案例研究能帮助读者将理论快速应用到实际数据分析任务中。这份资源为单个PDF文件压缩包整体约13.03MB内容为英文原版便于离线阅读与按章节检索也可作为团队内部分享的参考资料。目前已有826人学习下载适合希望系统掌握DAX语言、提升数据建模效率的中高级读者。1. DAX 权威指南第二版为什么它比函数速查手册更值得啃写 DAX 的人大多有这样的经历公式能从网上查来理解却基本靠猜。SUMX、CALCULATE 抄下来能跑可一旦筛选条件变了、图表交互多了该出的数字对不上还没法解释。这本《DAX 权威指南》第二版就是为这种状态准备的。它不教你背函数而是从评估上下文、CALCULATE 的运作机制、时间智能写法一路讲到 VertiPaq 存储引擎和查询计划——把 DAX 从“能写”带到“能判断为什么对、为什么错”。适合在 Power BI 和 Excel 里写度量值的数据分析师、要交付模型给业务方的 BI 开发者以及被报表性能问题反复折腾的优化人员。英文原版读起来慢一些但对术语的表达是最准确的。2. 一张目录背后的逻辑这本书到底在讲什么拿到这种大部头的第一反应通常是从哪读起其实它的目录本身就是一条完整的学习路径从语法、上下文、场景计算一路延伸到引擎级优化。理解这条主线比急着抄公式有用得多。2.1 前三章建立 DAX 的语法基线第 1 章先用几个小节把数据模型、关系方向和 DAX 与 Excel/SQL/MDX 的差异讲清楚。目录里“Cells versus tables”单元格与表这个标题特别点题——Excel 里你操作的是一个单元格DAX 里你操作的是整列、整表这个思维转换不过去后面读什么都别扭。第 2 章进入数据类型、运算符、条件语句重点对比计算列和度量值的定义方式还包含错误处理和 DAX 代码格式化规则。第 3 章开始接触表函数FILTER、ALL、ALLEXCEPT、VALUES、ALLSELECTED 都在这一章出现。如果你有 Excel 公式基础前两章可以快速扫过如果你是从 SQL 转过来第 1 章里关于关系方向的解释值得多看一遍。第 3 章的表函数不能快进它们是后面 CALCULATE 表达式的建筑材料。2.2 第 4—7 章评估上下文与 CALCULATE 是整个知识链的枢纽如果全书只允许你读透一个部分就是第 4 章到第 7 章。第 4 章讲评估上下文把“筛选上下文”和“行上下文”拆开讲这是 DAX 与 Excel 思维最根本的差异。第 5 章是很多人口中的“DAX 真正的入口”整章围绕 CALCULATE 和 CALCULATETABLE 展开包括筛选参数的行为、KEEPFILTERS、上下文转换。第 6 章用一整章讲变量不是因为 VAR 语法多复杂而是“变量是常量”这件事直接决定了公式在多个引用点上的执行行为。第 7 章把迭代器与 CALCULATE 放在一起SUMX、FILTERX、CONCATENATEX 这类逐行计算的函数在这里集体登场。这四个章节构成了一个完整闭环上下文决定公式的运行环境CALCULATE 修改这个环境变量控制表达式的取值时机迭代器控制计算的粒度。我见过不少人跳过这段直接读时间智能章节结果就是样例复现没问题换一个业务条件就不知道怎么组合。这四章值得慢慢读而不是追求速度。2.3 第 8—13 章从时间智能到查询实践第 8 章是时间智能计算业务报表的重头戏第 9 章讲计算组第二版把它单独成章说明它已经从前沿概念变成了可落地的工程手段。第 10 章回到筛选上下文这一章比第 4 章更深涉及 ALLSELECTED、KEEPFILTERS 的更多细节。第 11 章处理层级第 12 章讲表与表之间的操作第 13 章专门讲 DAX 查询的编写方式包括 EVALUATE 的语法规则。这个阶段有一个明显的节奏变化前几章在建立心智模型这里开始解决具体业务问题。时间智能需要日期表和连续日期计算组适合多指标复用的项目第 13 章的查询语法在调试问题时特别有用。如果你做的是固定报表交付第 8 章和第 9 章是必须拿下的如果你做的是临时分析和问题排查第 13 章的比重可以更高。2.4 第 14—16 章关系与高级计算的延展第 14 章涉及更抽象的 DAX 概念比如扩展表expanded table和更复杂的筛选语义。第 15 章是高级关系涉及多对多、双向筛选、USERELATIONSHIP 这类在复杂模型里才会用到的手段。第 16 章是一系列高级计算案例目录里没有列出具体小节但从标题推测它是把前面所有概念组合起来做综合计算练习。这三章不是给所有人准备的。如果你的模型是标准的星型结构关系都是一对多第 15 章可以暂时跳过如果你的项目里出现“同一张日期表对应多个事实表”“间接关系导致筛选方向混乱”这类问题再回来精读。2.5 第 17—20 章引擎层性能问题的真正根源第 17 章介绍 DAX 的两大引擎第 18 章深入 VertiPaq 存储引擎与压缩原理第 19 章讲解查询计划的分析方法第 20 章给出 DAX 优化的系统方法论。在 DAX 圈里性能调优经常被当作一门玄学——同一个度量值在另一份报表里慢了十倍谁都不好解释。这本书给的思路是去掉“猜”把公式拆到公式引擎与存储引擎两层看数据被压缩成什么形态、查询计划里哪一步开销最大。这种拆法不一定让每个优化都成功但至少让性能问题变成可以被分析的动作。需要提醒的是这部分对基础有要求。如果第 4 章和第 5 章的上下文概念还不稳直接读第 18 章会觉得很吃力建议读完第 4、5 章之后再回头啃这四章。3. 按角色挑章节数据分析师、BI 开发者、性能优化师的阅读路径这本书的 20 章按顺序读当然可以但大多数人是带着明确诉求来的要么想把报表做对要么想把模型交付出去要么想解决性能瓶颈。按角色规划路径效率会高很多。3.1 数据分析师前八章走到底数据分析师的核心任务是算出“对”的数字。第 1 章到第 7 章读完能回答“什么是上下文转换”“变量在度量值里起到什么作用”这类问题就不太容易写出不可复现的公式。第 8 章时间智能是业务报表的高频需求建议在这一章做完整练习月初至今、上年同期、移动平均每个模式都亲手写一遍。这一路径的目标不是掌握所有函数而是建立“公式为什么这么写”的判断力。遇到没见过的函数你能根据上下文规则推测它的大致行为而不是只能查示例。3.2 BI 开发者加上第 9、12、13 章BI 开发者交付的不只是度量值还有模型、表结构和查询性能。第 9 章计算组能大幅减少“同一指标做本月、上月、年初至今”这类重复劳动第 12 章讲表操作函数在需要生成参数表、做动态安全控制时非常有用第 13 章讲 DAX 查询编写调试复杂逻辑时可以在外部工具里独立验证一段计算不用反复改报表。建议这部分的阅读节奏放慢每读完一章回到自己维护的模型里找对应场景试一次。计算组尤其值得先搭一套最小示例跑通再考虑推广到项目里。3.3 性能优化者第 14—20 章是主战场如果你的核心痛点是报表越开越慢、刷新越来越久第 14 章到第 20 章就是主战场。但有一个前提读第 18 章之前至少要把第 4 章和第 5 章的上下文知识补牢。VertiPaq 的压缩行为、查询计划中存储引擎与公式引擎的分工都需要在理解上下文转换的基础上才能消化。这一路径的预期收获不是“把所有公式改成最优写法”而是拿到一套分析方法数据列的基数、关系方向、迭代器遍历范围、聚合是否可以被引擎下推这些因素各自如何影响性能你心里有数。3.4 阅读节奏建议表角色核心章节辅助章节预期收获数据分析师1—89能自解释每一个度量值的结果BI 开发者1—1314—15能交付稳定可维护的模型与计算逻辑性能优化者4、5、17—2014—16能定位查询性能瓶颈并给出优化方向实操层面我一般会把书里的示例数据换成自己熟悉的业务数据找一份销售明细表、一张日期表、一张产品表在 Power BI Desktop 里建好关系按章节的练习逐个验证。每读完一章把书里的例子做一次“变形”——书里用订单表换成自己手里的明细表看结果能不能复现书中结论。如果对不上通常不是书错了而是你对上下文的假设和书上的场景不一致。4. 提前建立概念框架把上下文、度量值与迭代器一次讲透本书的难度集中在几个核心概念上。提前搭好框架读原文时就不会第一次接触就被术语淹没。4.1 行上下文与筛选上下文两种不同的计算环境在 Excel 里写公式是孤立的结果只取决于单元格本身。DAX 中一个度量值的计算结果取决于外部施加的筛选上下文——它来自报表里的切片器、行标签、列标签也会由 CALCULATE 内部产生。行上下文则来自计算列和迭代函数表示“当前处理到哪一行”。看一个经常让人困惑的写法-- 计算列行上下文存在但没有筛选上下文 Orders[年度合计] SUM( Orders[SalesAmount] )这段代码在计算列里会让每一行都返回整张订单表的销售总额。原因是 SUM 扫描的是整列而计算列自带的行上下文不会自动变成筛选上下文。想按当前行去限定范围需要借助 CALCULATE 触发上下文转换。这正是第 4 章和第 5 章的核心内容。提示行上下文不等于筛选上下文。迭代器里的当前行不会自动成为聚合函数的筛选条件。4.2 计算列与度量值先想清楚放在哪一边两者的区别在于计算时机和存储方式。计算列在刷新时逐行计算并写入模型度量值在查询触发时动态计算。同一个逻辑优先写成度量值因为计算列会同时影响刷新速度和模型文件大小。Total Sales SUMX( Orders, Orders[Quantity] * Orders[UnitPrice] )这是一个迭代器求和逐行计算“数量 × 单价”再汇总。如果把它写成计算列每个订单行的乘积都会被存储而作为度量值只有查询时才计算。书里第 2 章的定义部分和第 18 章存储引擎部分分别解释了语义和物理两个层面的差异。4.3 变量它不是临时值而是常量第 6 章用整章讲变量绕不开一个核心规则VAR 定义之后就是常量RETURN 里多次引用同一个变量它也只按定义时的上下文计算一次。Sales Excluding Segment VAR CurrentSegment SELECTEDVALUE( Products[Segment] ) RETURN IF( CurrentSegment 旧品, [Total Sales], BLANK() )这里的 CurrentSegment 在定义时就确定了值后续公式不会改变它。新手最容易踩的误区是把变量当成普通编程语言里的可变变量想着中间给它重新赋值——DAX 不允许这样做也不需要这样做。理解“变量是常量且惰性求值”是读懂书里很多复杂示例的前提。4.4 迭代器SUMX 不是 SUM 的高级版当聚合不是简单求和而是需要逐行判断再累加时SUMX、FILTERX、CONCATENATEX 这类迭代器就有了不可替代的位置。它们遍历一张表对每一行计算表达式最后汇总结果。Brand Sales CALCULATE( [Total Sales], Products[Brand] 某品牌 )这个例子同时用到了 CALCULATE 和关系传播CALCULATE 把“品牌等于某品牌”变成一个筛选条件这个条件顺着产品和订单之间的关系传播到订单表再执行聚合。方法上它和“筛选一行再求和”不同DAX 是先构造筛选上下文再计算表达式。这个顺序就是第 5 章最想讲透的东西。4.5 表函数FILTER 与 ALL 的反直觉行为表函数是 DAX 区别于 Excel 公式的重要标志。FILTER 按条件返回一张表ALL 移除某个表的筛选上下文。最反直觉的是 ALL——它不是“清空数据”而是“解除筛选”。-- 全部品牌销售额不受当前品牌筛选影响 All Brand Sales CALCULATE( [Total Sales], ALL( Products[Brand] ) )把 ALL 放进 CALCULATE就是把上层对 Products[Brand] 的筛选全部拿掉得到一个不受品牌影响的“总计”。做占比计算时这个写法几乎是标准动作。如果哪天发现占比加起来不等于 100%大概率又是对 ALL 和筛选覆盖的理解出现了偏差。5. DAX 学习避坑指南五个最常见的翻车现场以下五条来自实际带项目时的血泪经验。按“现象 → 原因 → 解决”记录每条都对应书里的某一处章节遇到问题可以直接翻回去。5.1 跳过第 4 章直接刷函数样例能抄换条件全懵现象把书里或网上的公式抄到自己的模型里能出数但换一个筛选条件结果立刻不对而且拿不出解释。原因评估上下文是 DAX 公式的执行环境不懂上下文公式在你手里就是黑匣子。抄来的公式只是恰好匹配了原作者的上下文假设换个场景就失效。解决把第 4 章和第 5 章放在所有章节之前精读两遍。至少要能闭眼回答两个问题筛选上下文和行上下文有什么区别CALCULATE 在什么情况下触发上下文转换5.2 把 CALCULATE 的筛选参数当成“追加筛选”现象做产品销售占比报告里算出来的数字是有的但各分类占比加起来不等于 100%。原因CALCULATE 的筛选参数是修改现有筛选上下文而不是简单追加。位置放不对可能把原本的筛选条件覆盖掉或者保留了不该保留的筛选。解决需要保留原有筛选时使用 KEEPFILTERS。书中第 5 章和第 10 章都有讲解建议拿一小段数据反复验证“带 KEEPFILTERS”和“不带 KEEPFILTERS”的结果差异。5.3 所有指标都写成计算列模型越跑越重现象数据量不大但模型刷新越来越慢文件体积也在涨。原因计算列在刷新时物化存储度量值在查询时动态计算。大量计算列不仅占用空间还会干扰 VertiPaq 对列的压缩效果。解决能用度量值就不写计算列。遇到计算列导致的性能问题时去读第 18 章关于 VertiPaq 压缩与列存储的内容你会理解“少存储一次计算结果”为什么如此重要。5.4 忽视数据模型直接埋头写公式现象公式逻辑看着没问题但跨表取数时结果差了一截时对时不对。原因DAX 的计算沿关系传播。关系方向错了筛选传播就不完整后续的所有计算都建立在一个残缺的上下文之上。解决写任何度量值之前先核对表关系方向和基数。一对多关系中从“一”端筛选“多”端是自然的反过来则要仔细检查是否真的需要。第 1 章和第 15 章分别从入门和高级两个角度处理这个问题。5.5 把英文原版的术语直译成日常英语来理解现象读原版时每个单词都认识整句连起来不知道在说什么。原因DAX 术语有精确含义。“context transition”不是字面意义的“上下文变化”“expanded table”也不是“展开的表”。用日常英语去套理解会越来越偏。解决读前几章时先建立自己的术语对照表把 row context、filter context、context transition、expanded table 这些词的中文含义和一句话示例钉在一起。术语理顺之后原版会越读越快。6. 把书读成能力三个可验证的落地练习读技术书最怕的是“眼睛会了手不会”。下面三个练习分别对应性能、时间智能、计算组做完之后书里的结论就不再是纸面上的文字。6.1 用 DAX Studio 验证性能结论DAX Studio 是常用的 DAX 查询与分析工具。安装后连接你的 Power BI Desktop 模型打开查询计划和服务器计时面板运行一个简单的 SUM 和一个 SUMX 度量值观察两者在存储引擎和公式引擎上的耗时差异。对比第 17、19 章的内容你会直观看到“公式引擎与存储引擎”在真实查询中的分工。观察项对应章节要看什么SE/公式引擎事件第 17、19 章计算发生在哪一层是否大量逐行扫描缓存命中第 18 章同一查询两次执行第二次是否走缓存VertiPaq 扫描耗时第 20 章减少扫描列数后耗时是否下降6.2 把时间智能改写成自己的业务口径书里第 8 章的时间智能写法可以直接落到自己的模型里PY Sales CALCULATE( [Total Sales], SAMEPERIODLASTYEAR( Date[Date] ) )这段公式的前提是模型中有一张标记为日期表的连续日期表并且与订单表的关系方向正确。跑通之后再自己试写 TOTALMTD本月累计和 TOTALYTD年度累计。时间计算的三个基本模式都能独立完成日常工作里的大部分“同期对比”需求就不需要再临时搜方案了。6.3 用计算组模板替换重复度量值计算组可以理解为一套“度量值模板”。针对时间对比你可以创建一个计算组在里面定义“上月”“上年同期”等计算项把同一个基础度量值套上不同模板。核心公式是CALCULATE( SELECTEDMEASURE(), DATEADD( Date[Date], -1, MONTH ) )SELECTEDMEASURE() 代表用户在报表里实际拖入的任意度量值。这样就不必为每个指标单独写“上月销售额”“上月毛利”“上月订单数”这类重复度量值。第 9 章对计算项的算顺序和格式串有更细的规则按书上的说明来不要自创优先级否则会出现结果准确但格式混乱的问题。我做这套练习时印象最深的是第 5 章里关于 CALCULATE 筛选覆盖的推演。以前写占比类指标大方向对偶尔数字对不上只能靠猜。后来把 KEEPFILTERS 和 ALL 的差异按书里的逻辑逐项验证了一遍才算真正理解。从那以后我给自己立了一条规矩每个度量值写完先回到上下文规则里“过”一遍再交给业务方。这本书不像速查手册更像一台校验机器能把你对 DAX 的所有假设扳到正确轨道上。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
