DAX 陷阱 AutoExist 及解決方案
程序員不要吐槽本文的標(biāo)題，我知道 AutoExist 不是陷阱也不是 BUG，這只是為了那些沒有必要花精力理解這個不需要理解的概念的業(yè)務(wù)伙伴搜索標(biāo)題時用的。
對于普通用戶來說，你沒有必要為了學(xué)習(xí)一個概念而學(xué)習(xí)一個概念。
這里講述的這件事是純 IT 的，因此，你需要做的是：知道這是什么事，然后收藏本文即可，無需理解也無需閱讀完畢。
等你遇到這個問題的時候，在收藏中搜索 DAX 陷阱 即可回看本文。
至于：AutoExist 這個單詞，你也一定不會記得的。
問題重述
來看一個例子，【場景 1】如下：
其中用的公式如下：
ProductCount = COUNTROWS( '產(chǎn)品' )
ProductCount.All = CALCULATE( COUNTROWS( '產(chǎn)品' ) , ALL('產(chǎn)品'[產(chǎn)品子類別] ) )很容易上圖的內(nèi)容，由于有 “產(chǎn)品類別” 的篩選，導(dǎo)致產(chǎn)品數(shù)是該兩個大類別下的總數(shù)。注意：當(dāng)前產(chǎn)品子類別沒有被篩選。
記住這個數(shù)字：905，表示兩個產(chǎn)品大類別下的產(chǎn)品數(shù)。
此時，選擇一個產(chǎn)品子類別，來看看效果【場景 2】：
產(chǎn)品子類別下的產(chǎn)品數(shù)：119，這是由于收到了產(chǎn)品子類別的篩選。
然而，對于清除了產(chǎn)品子類別篩選的計算，其結(jié)果是：461，而不是 905，這個結(jié)果非常詭異。
詭異之處
下面用清晰的邏輯來表述其中的詭異：
【場景 1】可知 “技術(shù)” 和 “家具” 下的產(chǎn)品數(shù)是 905；
【場景 2】看到清除了產(chǎn)品子類別的篩選后，“技術(shù)” 和 “家具” 下的產(chǎn)品數(shù)是 461；
【場景 1】與【場景 2】矛盾。
潛在結(jié)論：Power BI 出現(xiàn)了 BUG。
如果你學(xué)習(xí)了 DAX，你會這樣想：
雖然 ALL (' 產(chǎn)品 '[產(chǎn)品子類別] ) 清除了產(chǎn)品子類別的篩選，但是它不會清除產(chǎn)品類別的篩選，因此，在【場景 2】中，清除了產(chǎn)品子類別的篩選，但受到與【場景 1】中相同的產(chǎn)品類別的篩選，因此，結(jié)果應(yīng)該是：905，而實際結(jié)果是 461，這很詭異，像是一個 BUG。
如果不是 BUG 的話，那么一定出現(xiàn)了更復(fù)雜的情況。
一定會遇到的陷阱：AutoExist
業(yè)務(wù)的小伙伴不必理解這里說的東西，后文會給出解決方案。
這里的確不是 BUG，而是 Power BI 的 DAX 引擎就是這么設(shè)計的，這里觸發(fā)了 DAX 在計算時候的一個機制導(dǎo)致了這種效果。這個機制叫：AutoExist。
若滿足以下條件則會觸發(fā)該機制：
若在某個表上存在兩列或以上的篩選，該篩選將參與 SUMMARIZECOLUMNS 運算，則會觸發(fā) AutoExist 機制，該機制將某個表上存在兩列或以上的篩選先合并成一個篩選，再參加計算。
這里要滿足兩個條件：
同一個表的兩個列或以上的篩選。如：本例中的產(chǎn)品子類別以及產(chǎn)品類別的兩個列。
要參與 SUMMARIZECOLUMNS 運算。如：在 Power BI 中所有圖表都是由 SUMMARIZECOLUMNS 返回的運算結(jié)果。
不難看出：
在 Power BI 中使用任何圖表都會自然的觸發(fā)條件 2，而用戶的確常常會做切片器，而且來自同一個表的不同的列，那么，也很容易觸發(fā)條件 1，這樣一來，這個叫
AutoExist 的機制是很容易被觸發(fā)的。
因此，Power BI 用戶，尤其是編寫了 DAX 的公式，大概率會遇到這個問題的。
為什么要有 AutoExist
由于本文一上來講了一個問題，導(dǎo)致大家可能對 AutoExist 有個先入為主的不好印象，其實，AutoExist 是一個在不知不覺中幫助我們的重要機制。Power BI 要解決的重要問題就是：
如何在一個巨量的數(shù)據(jù)空間中，迅速縮減到圖表所需要的一個數(shù)據(jù)子集，通過篩選實現(xiàn)這個目的，而一個表上的多個篩選，如果在計算時分別對待，則會觸發(fā)笛卡爾積的排列組合運算，導(dǎo)致性能問題，而 AutoExist 機制正好將不可能出現(xiàn)的排列組合給預(yù)先剔除掉，確保沒有笛卡爾積的問題。
而幸運的是，在絕大多數(shù)情況，這種機制都工作良好，用戶是不會發(fā)覺有什么特別的東西在后臺運作，用戶只是感覺 Power BI 篩選數(shù)據(jù)好快好快。
案例解析
已經(jīng)知道了 AutoExist 的運作機理以及它的意義，而且絕大多數(shù)都不會出問題，那么，本案例中的問題是怎么被觸發(fā)或者說不幸的成為一個問題了呢？
在出問題的【場景 2】中，其篩選是這樣的：
表列：產(chǎn)品子類別 IN {"復(fù)印機"}
表列：產(chǎn)品類別 IN {"技術(shù)","家具"}
由于表列：產(chǎn)品子類別和表列：產(chǎn)品類別都來自同一個表：產(chǎn)品表，則它們在進入計算前，會被合并，如下：
由于在產(chǎn)品表中，產(chǎn)品子類表的 “復(fù)印機” 是與產(chǎn)品類別的 “技術(shù)” 對應(yīng)的，而沒有與產(chǎn)品類別的 “家具” 對應(yīng)的可能，因此，這個篩選得以合并為：
(產(chǎn)品子類別，產(chǎn)品類別) IN { ( "復(fù)印機" , "技術(shù)" ) }
也就是說：“家具” 消失了。
因此，可以推斷案例中【場景 2】的結(jié)果 461 應(yīng)該是：產(chǎn)品類別 “技術(shù)” 下的所有產(chǎn)品，而不再包括產(chǎn)品類別 “家具” 下的產(chǎn)品。驗證如下：
果然如此。
通過觀察 DAX 公式，以及觸發(fā)了 AutoExist 產(chǎn)生的問題，可以總結(jié)到：如果在公式中有 ALL 掉某表一部分列且報表中有來自該表的多個列的篩選時則可能觸發(fā)此問題。
解決方案
由于觸發(fā) AutoExist 需要兩個條件，其中 SUMMARIZECOLUMNS 運算是不可避免的，在 Power BI 中圖表都默認(rèn)使用了這個計算，那方案只有是不讓它來自一個表的多列。那么，在觸發(fā)了 AutoExist 陷阱的時候，將來自同一個表的多列分別構(gòu)造獨立的維度即可。如下所示：
此時，來看下效果：
此時，看到了正確的結(jié)果 905 個產(chǎn)品。
總結(jié)
AutoExist 是內(nèi)置于 DAX 底層運算中用于提升性能的技術(shù)特性，它在絕大多數(shù)時候都扮演了積極且重要的角色，但有時可能會導(dǎo)致副作用，這種可能導(dǎo)致副作用的詭異現(xiàn)象的觸發(fā)條件常常如下：
度量值的公式中有修改（如：清除，常常使用 ALL）某表一部分列篩選
報表中有來自該表的多個列的篩選
則 AutoExist 特性在后臺自動運轉(zhuǎn)時可能導(dǎo)致詭異的計算結(jié)果，稱此為：AutoExist 問題陷阱。
需要注意的是：AutoExist 是故意這么設(shè)計的，它既不是 DAX 的缺陷，也不是 DAX 的 BUG，只是由于對 DAX 運行原理不夠了解而踏入的一個陷阱。
更要注意的是：業(yè)務(wù)人員永遠不需要去也不應(yīng)該去了解該特性的技術(shù)細節(jié)，正如本文的絕大部分文字都可以不必閱讀。只需要記憶：
DAX 有個陷阱叫：Auto 啥的來著。
當(dāng)一個表有兩列分別作為切片器時又寫了一個 DAX 公式里 ALL 掉了其中一列。
數(shù)字就會不對。
解決方法是：把那列單獨做個表出來即可。
時間來到 2022 年，Power BI 的學(xué)習(xí)方式已經(jīng)不是幾年前，一起高喊 DAX 牛逼的日子，而是精細化的拆解出一套業(yè)務(wù)人員與技術(shù)人員的有效區(qū)隔，業(yè)務(wù)人員應(yīng)該將注意力集中在業(yè)務(wù)本身，以及如果使用 DAX 來表達業(yè)務(wù)問題本身。業(yè)務(wù)人員只需要知道：
怎么做是一個正確而安全的習(xí)慣
如何識別潛在的問題
當(dāng)出現(xiàn)問題了如何快速修復(fù)
繼續(xù)關(guān)注業(yè)務(wù)本身
這是我們將持續(xù)為業(yè)務(wù)分析師帶來的價值。毫無疑問，這些都會囊括在《BI 真經(jīng)》的內(nèi)容中。
在訂閱了BI佐羅講授的《BI真經(jīng)》之《BI進行時》課程區(qū)，除了可以下載本文案例，還可以觀看視頻講解。
Power BI 終極系列課程《BI真經(jīng)》
BI真經(jīng) - 讓數(shù)據(jù)真正成為你的力量
掃碼與精英一起討論 Power BI，驗證碼：data2022
點擊“閱讀原文”進入學(xué)習(xí)中心
↙