微軟Power BI用戶花3年搞懂：80%業務問題只需5個公式

CALCULATE、SUMX、DATESINPERIOD、FILTER、DIVIDE——這五個函數的名字，在Power BI社區被搜索了超過1200萬次。

但詭異的是，90%的初學者仍在收藏夾里囤著200多個DAX函數的速查表，仿佛備考一樣背誦。一位在零售行業做了四年數據分析的從業者告訴我：「我前三年都在假裝自己懂DAX，直到發現每天用的其實就那五個。」

這不是技能焦慮，是信息過載制造的幻覺。

CALCULATE：業務問題的「如果」按鈕

想象你手里有一個計算器，但每次按數字鍵之前，必須先告訴它「假裝現在是另一種情況」。這就是CALCULATE干的事——它改變計算的上下文，而不碰原始數據。

原文作者給出的例子很直白：你想知道高端產品線的銷售額，但不想動原始表格。寫成公式就是CALCULATE(SUM(Sales[Amount]), Products[Category] = "High-End")。第一個參數是你要算什么，后面的條件是「假裝只看高端類別」。

這個函數的真正價值在于提問方式。業務場景里全是「如果」——如果只看華東區？如果剔除退貨？如果對比去年同期？沒有CALCULATE，每個問題都要新建一張表；有了它，一個度量值（Measure）就能變出十幾種視角。

作者把它稱為「the king」，不是夸張。在真實的Power BI項目里，CALCULATE的嵌套深度直接決定了分析模型的靈活度。我見過最復雜的零售分析模型，核心邏輯是四層CALCULATE套娃：先鎖時間、再鎖區域、再鎖產品層級、最后動態對比。

SUMX：為什么簡單求和會騙人

很多初學者栽在第一個坑：直接用SUM算總收入。如果數據表里有「單價」和「數量」兩列，SUM(Price) * SUM(Quantity)會給出荒謬的結果——它先加總所有單價，再乘以所有數量，完全喪失行級關系。

SUMX的X代表「逐行計算」。公式SUMX(Sales, Sales[Price] * Sales[Quantity])的意思是：遍歷Sales表的每一行，把單價和數量乘好，最后再把所有行的結果加起來。

這個區別在業務里是要命的。假設你賣兩種產品：A單價100元賣10件，B單價10元賣100件。錯誤算法會算出(100+10)*(10+100)=12100，正確結果是100*10+10*100=2000。差了一個數量級。

原文作者提到SUMX是「row-by-row calculator」，這個類比精準。X函數家族還有AVERAGEX、MINX、MAXX，邏輯相同：先迭代，再聚合。處理加權平均、分段計價、動態折扣這些場景，非X函數不可。

DATESINPERIOD：時間維度的自動化

手動改日期篩選器是分析師的重復勞動噩夢。每個月初打開報表，把「最近30天」改成「最近30天」——聽起來荒謬，但無數人這么干了幾年。

DATESINPERIOD的公式結構有點繞：DATESINPERIOD('Date'[Date], MAX('Date'[Date]), -3, MONTH)。拆解一下：以日期表的最大日期為錨點，往回推3個月。負號代表過去，MONTH代表單位，換成DAY或YEAR就是另外兩種粒度。

這個函數的隱藏價值是「相對時間」思維。業務問題很少問「2024年3月到5月」，而是問「最近90天」「滾動12個月」「同比周期」。DATESINPERIOD把絕對日期轉成相對邏輯，報表永遠自動對準最新數據。

作者強調它「automates your reports」，這背后是BI的核心賣點：一次搭建，持續生效。沒有這個時間函數，Power BI就退化成Excel的高級版。

FILTER和DIVIDE：防御性編程思維

這兩個函數放在一起看，會發現作者的一個隱性偏好：處理臟數據和邊界情況。

FILTER解決的是「動態條件」問題。前面的CALCULATE能篩固定值，比如Category="High-End"，但如果條件是「銷售額超過1000的客戶」呢？這個閾值是算出來的，不是原始列里寫死的。

原文的例子嵌套了三層：外層CALCULATE算客戶數，中間FILTER篩客戶，內層再CALCULATE算每個客戶的銷售額。這種「用計算結果當篩選條件」的模式，在客戶分層、RFM分析、異常檢測里高頻出現。

DIVIDE則是更基礎的防御。做除法時，分母為零是常態——新店還沒開張、新產品還沒動銷、某區域暫時斷貨。原生除法符「/」會返回Infinity或NaN，報表上炸出一堆錯誤值。

DIVIDE([Total Profit], [Total Revenue], 0)的第三個參數是「備用值」。分母為零時返回0，報表干凈，下游計算不會連鎖崩潰。這個細節區分了「能跑」和「能用的」模型。

作者把這叫「safe way」，本質是產品經理的兜底思維：用戶不會按說明書出招，系統必須自己擦屁股。

一個真實場景的組合拳

原文最后拋了一個零售經理的日常問題：「哪些產品利潤率超20%，且最近90天銷量過500件？」

拆解這個需求，五個函數全部登場：DATESINPERIOD鎖定最近90天，SUMX算銷量（如果涉及多字段），CALCULATE切換計算上下文，FILTER篩出利潤率和銷量的雙重條件，DIVIDE保證利潤率計算不報錯。

這不是炫技，是業務語言的直接翻譯。好的DAX模型讀起來像白話：「算一下，在那些利潤率夠高、賣得夠多的產品里，情況是怎樣的？」

作者說「You don't need to be a programmer」，這句話的潛臺詞更值得玩味。Power BI的競爭對手是Python、R、SQL，但微軟的贏法從來不是功能最全，而是把技術概念包裝成業務人員能直覺理解的形狀。五個函數覆蓋80%場景，剩下的20%留給專業開發者——這個分工本身，就是產品定位的精準切割。

一位在快消行業做數據架構的讀者留言：「我帶過十幾個新人，發現學得快的不是背函數多的，而是先搞懂CALCULATE上下文切換的。那個頓悟時刻之后，看其他函數都像看說明書。」

你收藏夾里那個200函數的DAX速查表，最后一次打開是什么時候？