Power BI用戶花了3年才懂：80%業務問題靠這5個函數

微軟Power BI全球月活用戶突破3000萬，但DAX（數據分析表達式，Data Analysis Expressions）的棄用率始終居高不下。不是工具太難，是多數人一開始就學錯了方向——試圖背下200多個函數，而非掌握真正解決問題的 handful。

一位在零售行業做了8年數據分析師的作者，最近把壓箱底的經驗攤牌了：日常工作中，5個函數覆蓋80%的業務場景。

CALCULATE：業務問題的"假設引擎"

這個函數被作者稱為"the king"，核心能力是改變計算上下文。用產品術語說，它是個場景模擬器。

實際業務場景：銷售總監想看高端產品線的業績，但不想動原始數據模型。傳統做法是復制一張新表、手動篩選，CALCULATE讓你在一行公式里完成假設——

High End Sales = CALCULATE(SUM(Sales[Amount]), Products[Category] = "High-End")

作者的原話很直白：「It lets you ask questions like 'what if?' without changing your original data.」

對比Excel用戶的慣性操作：建透視表、拖字段、反復刷新。CALCULATE把"假設分析"壓縮成一個可復用的度量值，報表自動響應篩選器變化。

SUMX：為什么簡單求和會"撒謊"

作者把SUMX定義為"row-by-row calculator"。這不是炫技，是糾偏——很多業務指標用SUM算出來是錯的。

典型陷阱：計算總收入時，直接SUM(Price) × SUM(Quantity)。數學上成立，業務上荒謬。如果A商品單價100賣1件，B商品單價1賣100件，錯誤算法會告訴你"平均單價50.5"，實際加權平均是1.98。

SUMX的解法：逐行計算Price × Quantity，再匯總。

Total Revenue = SUMX(Sales, Sales[Price] * Sales[Quantity])

作者強調，這類"X函數"（還有AVERAGEX、COUNTX等）處理的是復雜邏輯，簡單SUM無法觸及的顆粒度。

DATESINPERIOD：時間維度的自動化

BI工具的核心價值之一是時間智能，但多數報告的時間篩選是靜態的——"上個月""本季度"需要手動更新。

DATESINPERIOD讓時間窗口動態化。作者給的例子是滾動3個月銷售額：

Sales Last 3 Months = CALCULATE( SUM(Sales[Amount]), DATESINPERIOD('Date'[Date], MAX('Date'[Date]), -3, MONTH) )

關鍵設計：MAX('Date'[Date])錨定數據最新日期，-3表示回溯，MONTH定義粒度。報表每天刷新，"最近3個月"自動推移，無需人工干預。

作者的原話點出了痛點：「Instead of manually filtering dates every month, this automates your reports.」

FILTER：當篩選條件本身就是計算結果

常規篩選器針對原始列值：Category = "Electronics"、Region = "North"。但業務問題常要篩選"累計消費超過1000的客戶"——這個閾值是算出來的，不是表里現成的。

作者舉的例子是高價值客戶計數：

High Value Customers = CALCULATE( DISTINCTCOUNT(Customers[ID]), FILTER( Customers, CALCULATE(SUM(Sales[Amount])) > 1000 ) )

注意嵌套結構：外層CALCULATE定義計算目標（去重客戶數），內層FILTER把客戶表縮減為"銷售額>1000"的子集。FILTER的第二個參數是個布爾表達式，但可以包含計算邏輯。

作者的評價：「It allows you to filter based on the result of a calculation, not just raw data.」

DIVIDE：一個防御性設計省掉80%的調試時間

除法在數據世界里是地雷。分母為零、空值、數據類型不匹配，都會讓報表炸出"Infinity"或"NaN"，業務用戶直接懵掉。

DIVIDE的第三個參數是"安全墊"：

Profit Margin = DIVIDE([Total Profit], [Total Revenue], 0)

作者解釋：「The last part (the 0) tells the formula, 'If the revenue is zero, just show zero instead of breaking.'」

這個設計思維值得注意——不是追求數學嚴謹性，是優先保證報表可用性。業務場景里，"顯示0"比"報錯中斷"更有價值。

組合實戰：一個查詢串起全部5個函數

作者用零售經理的真實需求收尾：找出"利潤率超20%且近90天銷量超500件"的產品。

拆解這個需求：

? 利潤率 = DIVIDE([Total Profit], [Total Revenue], 0) > 0.2
? 近90天 = DATESINPERIOD('Date'[Date], MAX('Date'[Date]), -3, MONTH)（假設按月粒度）
? 銷量條件 = SUMX(Sales, Sales[Quantity]) > 500
? 整體計算 = CALCULATE配合FILTER，把上述條件疊加上下文

作者沒有給出完整代碼，但邏輯鏈條清晰：復雜業務問題 = 基礎函數的樂高式組合。

文章最后，作者拋出一個反直覺結論：「You don't need to be a programmer to be good at business analytics. You just need to know how to ask the right questions and master these 5 building blocks.」

但這里有個開放問題：當AI代碼生成工具（如GitHub Copilot、Power BI的DAX公式建議）越來越成熟，"掌握5個基礎函數"這個策略，是更保值了，還是更快被替代了？