掌握正確的Power BI優(yōu)化技巧，可以幫助我們提高使用效率及使用感受，下面就總結(jié)下我整理出來的Power BI優(yōu)化最佳實踐。文中出現(xiàn)的測試數(shù)據(jù)，均使用本地電腦環(huán)境進行測試，僅做對比測試，相關(guān)數(shù)據(jù)，來至多次測試結(jié)果的平均值。
文章原來的初衷是寫Power BI性能優(yōu)化部分，不過隨著文章的不斷深入，知識邊界順帶就拓寬了很多，于此題目就變成了Power BI優(yōu)化最佳實踐。
內(nèi)容導航
一、從數(shù)據(jù)庫加載數(shù)據(jù)更快
二、只導入需要的表列
三、使用合適的數(shù)據(jù)格式2
四、不在Power Query做復雜的數(shù)據(jù)清洗
五、使用SQL加載到Power Query
六、使用參數(shù)化
七、不做大寬表
八、使用合適的數(shù)據(jù)粒度
九、減少使用新建列
十、使用表和文件夾管理度量值
十一、命名規(guī)范
十二、模型分層
十三、永遠使用一對多關(guān)系
十四、反結(jié)構(gòu)化設(shè)計
十五、關(guān)閉數(shù)據(jù)加載的所有選項
十六、優(yōu)化DAX公式
十七、減少頁面可視化對象數(shù)量
十八、使用增量刷新
十九、減少列不重復值
二十、硬件優(yōu)化
二十一、定期更新Power BI
由于文中涉及大量的專業(yè)知識，受限于作者的水平，可能存在有誤的地方。若發(fā)現(xiàn)錯誤之處，還望不惜賜教。測試數(shù)據(jù)樣本及測試環(huán)境如下。
行數(shù)：100萬列數(shù)：44列Excel文件大小：（約276M）數(shù)據(jù)庫：MySQL（8.0.28.0）CPU：AMD 5600U內(nèi)存頻率： BI版本：2021年12月
一、從數(shù)據(jù)庫加載數(shù)據(jù)更快
從數(shù)據(jù)庫加載數(shù)據(jù)，比從本地Excel文件加載數(shù)據(jù)，速度更快。同樣的數(shù)據(jù)量，多個文件比單個文件快。
總結(jié)：可以很明顯的看出，從數(shù)據(jù)庫加載同樣大小的數(shù)據(jù)，速度最快，而且非常明顯。其中從文件夾下面加載多個Excel文件的速度，超出意外的更快，而且貌似文件越多，速度還有提升的趨勢。最沒想到的是單個Excel文件加載居然是最慢的。其他人也可以測測是不是真的這樣。
二、只導入需要的表列
加載多余的列，會造成兩個不好的影響：
以上圖的對比來看，從MySQL加載44列需要35s，加載11列只需要18s，速度快了一倍。所以，減少加載的列，可以明顯減少數(shù)據(jù)加載所需的時間。
總結(jié)：只加載需要的表列，就是該條優(yōu)化的最佳實踐。
三、使用合適的數(shù)據(jù)格式
使用訂單金額作為測試列
當一個數(shù)值足夠大的時候，儲存為文本和存儲為整數(shù)的文件大小差異會變小。
總結(jié)：可以看出，同樣的100萬行數(shù)值，以整數(shù)類型存儲，占用的存儲空間最小。在實際操作中，可以將客戶編號、類型編號等存儲為整數(shù)類型。
四、不在Power Query做復雜的數(shù)據(jù)清洗
Power Query功能強大有目共睹。但在處理一些復雜計算的時候，對硬件配置要求比較高，尤其是對CPU的要求很高。因此不建議在Power Query中做太過復雜或會造成計算變慢的操作。比如使用分組依據(jù)、合并查詢等，就會明顯造成數(shù)據(jù)加載速度變慢，數(shù)量越大，差異就越明顯。
當然，對于真正的高手來說，熟練掌握各種緩存機制及高端操作，依然可以把Power Query的運算做的很快，不過這些并不適合新手。在你無法輕松駕馭Power Query之前，依然建議遵循減少使用的原則。
舉個例子：
Power Query單獨清洗，時間長的原因是，Power Query需要將整表加載進來，然后再使用合并查詢、篩選、分組統(tǒng)計，因此時間比直接使用SQL查詢要長很多。而且隨著后續(xù)操作的步驟越來越復雜，速度也會越來越慢。
總結(jié)：如果你的數(shù)據(jù)源質(zhì)量很差，且沒有太多其他選擇，同時數(shù)據(jù)量又不太大的情況下，也是可以選擇使用Power Query做一些數(shù)據(jù)清洗的，畢竟工具的定位就是數(shù)據(jù)清洗。活學活用，找到自己的平衡點。
五、使用SQL加載到Power Query
這種方式有很多優(yōu)點。
使用Power Query加載一段SQL獲取數(shù)據(jù)，相當于加載的是數(shù)據(jù)庫視圖查詢。當庫表結(jié)構(gòu)變動時，對于這段連接關(guān)系影響最小，也就是減少了耦合。在模型后期的維護中，工作量最小。
并且可以靈活的調(diào)整這段查詢語句。在某些場合，我們不僅僅只使用一張表，那么就可以使用SQL做拼接之后，直接加載這段查詢語句，而不需要IT再做其他的支持。
而相對的，不建議做的事情就是。加載了整張表，或者加載了很多表，在Power Query中使用合并查詢或分組依據(jù)功能進行計算，則計算效率會下降非常明顯。
還有一個細節(jié)，有些數(shù)據(jù)來源不支持編寫SQL查詢。比如從獲取數(shù)據(jù)，只能直接添加表到Power Query。這種情況下，推薦使用ODBC作為中繼，將源數(shù)據(jù)配置成ODBC連接，然后使用Power BI連接ODBC數(shù)據(jù)源，這個時候是支持編寫SQL查詢的。
總結(jié)：如果是從數(shù)據(jù)庫加載的數(shù)據(jù)，建議優(yōu)先使用SQL進行類似的計算，然后使用Power Query加載這段SQL。
六、使用參數(shù)化
比如，你需要加載100張表到模型中，使用了一些數(shù)據(jù)源。在后續(xù)的維護中，數(shù)據(jù)庫的數(shù)據(jù)進行了遷移，則需要對不同的數(shù)據(jù)來源進行調(diào)整。如果沒有事先把路徑作為參數(shù)，那么再修改來源的時候，會增加必須要的量。
當然，參數(shù)化的使用不僅僅局限于此，使用的場景很廣泛，在設(shè)計時，需要提前考慮。
總結(jié)：參數(shù)化是設(shè)計的初衷，為了解耦，耦合太深會增加很多不必要的工作量。
七、不做大寬表
Power BI是有一套自己的運行規(guī)則，初學者在使用Power BI時，會想當然的按照自己的理解來使用Power BI，由于方法不對，會產(chǎn)生一種Power BI也不過如此的錯覺，真正的原因可能是，打開的方式不對。
簡單來說，Power BI使用維度建模，盡量減少在事實表上的維度，將維度單獨成表，通過關(guān)系，將維度表與事實表進行關(guān)聯(lián)，使數(shù)據(jù)塌縮到最小維度。一方面可以提高運算速度，另一方面可以減少文件內(nèi)存占用。
最簡單的實踐操作就是，事實表去維度化，將維度單獨成表，使用表關(guān)系與事實表關(guān)聯(lián)。
總結(jié)：掌握一些維度建模的知識，了解什么是維度建模，才能更好的使用Power BI。Power BI和那些號稱是BI，結(jié)果背后還是在拼大寬表的BI工具，是完全不同的。
八、使用合適的數(shù)據(jù)粒度
Power BI雖然強大，但是架不住一股腦的塞數(shù)據(jù)。因此，在實際的建模或分析過程中，除了優(yōu)化加載的表列，還需要對分析所用的數(shù)據(jù)粒度進行整合。
比如分析只看到月，那么就沒必要加載到每天的數(shù)據(jù)。數(shù)據(jù)分析只看到天，就沒必要添加到小時或分分鐘維度的數(shù)據(jù)。
總結(jié)：選用合適的數(shù)據(jù)粒度，讓工作事半功倍。
九、減少使用新建列
請注意，此處說的是減少使用，不是不能使用。這主要基于兩個方面的考慮。
一方面，對于新手，無法編寫復雜的DAX，那么可以使用新建列來減少難度，但同時需要明白，添加列這個動作，自己到底在做什么，而不是無腦的使用新建列進行輔助計算。
另一方面則是，計算速度和內(nèi)存之間的平衡。比如增加一列之后，能極大的提高某個度量值的計算速度，那么為了不影響可視化的展示，是可以犧牲掉內(nèi)存來保計算效率的。
十、使用表和文件夾管理度量值
編寫的度量值，默認會放到你選擇的那個表，或者默認放在排序在一個的表中。這樣的度量值不利于管理，推薦的方法是，新建一個表，然后用于存放度量值。同時仍可以在表中，增加文件夾來管理這些度量值。
度量值管理關(guān)于這部分，網(wǎng)上已經(jīng)有很多人寫了相關(guān)的文章，我不做細節(jié)的展開，如需要可以參考：
簡單三個步驟，輕松管理你的Power BI度量值
/p/
十一、命名規(guī)范
表命名
表的命名上，每個人都可以采用自己的一套規(guī)則。前提是能清晰的區(qū)分出來不同功能的表，比如從命名規(guī)則上，是否可以區(qū)分出事實表、維度表、參數(shù)表、輔助計算的視圖表等等。舉例：
事實表：F Model 銷售明細
維度表：D Model 商品主數(shù)據(jù)
參數(shù)表：C Model 天數(shù)
視圖表：D View 輔助作圖
度量值命名：度量值的命名規(guī)則推薦使用定語后置。舉例：
在基礎(chǔ)度量值名稱的基礎(chǔ)上，通過不斷在后面添加描述。這樣命名有兩個好處：
十二、模型分層
模型分層主要在復雜模型中做為一種解決方案。
該功能的實現(xiàn)，依賴于將同一個度量值顯示在不同的文件夾中進行管理。
舉例：
模型層：將直接取之于事實表的度量值，放到模型層。當源數(shù)據(jù)有邏輯變動時，僅需要修改模型層的度量值即可。
視圖層：視圖層的度量值，全部取值于模型層，當模型層的度量值變更時，視圖層度量值不用單獨維護。包括一些為特殊可視化所編寫的度量值，也放在該文件夾下。比如也可以每頁可視化報告做一個子文件夾，用于管理可視化頁面上的度量值。
項目層：項目層是一個更大的概念。比如在一個模型中，有不同的分析項目，而每個分析項目又有很多可視化頁面。某個特定的項目，從不同的場景中取了一些度量值。由于使用的度量值散落于各處，當我們查看某個項目相關(guān)的指標時，可以將該項目使用的度量值，都顯示在被命名為該項目的文件夾下。
關(guān)系視圖中，選中度量值，在顯示文件夾中，以逗號間隔，就可以將同一個度量值，顯示在多個文件夾下面。
十三、永遠使用一對多關(guān)系
請永遠使用一對多關(guān)系，除非你知道你在做什么。
為什么不推薦使用多對多，或者多對一，是計算結(jié)果不正確嗎？其實不是這樣的，原因是按照一對多的關(guān)系進行思考和公式的編寫，可以讓模型關(guān)系變得簡單和易于理解。而多對多和多對一的關(guān)系則會讓模型內(nèi)部的交互變得復雜，而造成模型關(guān)系混亂。
請注意，并不是禁止使用，既然設(shè)計了這樣的功能，就有其使用的價值。前提就是當你使用多對多關(guān)系或者使用多對一關(guān)系時，你需要明白你自己真正在做的是什么，而不是隨隨便便拉一根線那么簡單。
比如在做權(quán)限控制的一些場景中，則需要開啟多對多的雙向安全篩選。這種情況下就必須使用多對多關(guān)系才能完成。
總結(jié)：在你真正理解Power BI模型關(guān)系之前，建議請遵守該條規(guī)定，可以讓你的模型更簡單。
十四、反結(jié)構(gòu)化設(shè)計
反結(jié)構(gòu)化的設(shè)計初衷在于為了滿足某種訴求，用于犧牲設(shè)計上的規(guī)范如何比對excel表格兩列數(shù)據(jù)中的相同部分?，同時這個訴求又非常的合理。
比如你有一份商品主數(shù)據(jù)，同時有一份手工指定的特殊商品清單。按照維度建模的規(guī)范，應(yīng)該將該特殊指定的表，作為商品主數(shù)據(jù)的維度表，組成雪花模型。
規(guī)范設(shè)計下，數(shù)據(jù)大小的占用。
在設(shè)計上很規(guī)范，沒有問題，然而我們發(fā)現(xiàn)一個新的現(xiàn)象。
如果把這份特殊的商品清單，在商品主數(shù)據(jù)上，新增一列，將符合的SKU標記為1。
再看下反結(jié)構(gòu)化設(shè)計下，數(shù)據(jù)大小的占用。
兩個PBIX文件大小的對比。
從文件實際的大小來看，采用反結(jié)構(gòu)設(shè)計，可以節(jié)省30%的空間占用。30%的空間優(yōu)化對于一個模型來說非常的有誘惑力。
總結(jié)：這只是一個縮影，可以推廣到很多具體的使用場景，甚至可以反設(shè)計到事實表上，具體可以靈活掌握。在做這件事之前，一定要清楚你在做什么，而不是無腦加列。前提還是在模型規(guī)范化設(shè)計的基礎(chǔ)上，在局部使用，而不是完全進行反結(jié)構(gòu)化設(shè)計，一定要認清反結(jié)構(gòu)化設(shè)計的初衷是什么。
十五、關(guān)閉數(shù)據(jù)加載的所有選項
比如在Power Query中加載了一個1億行的表，如果該功能不關(guān)閉，那么在打開Power Query時，該查詢會從數(shù)據(jù)庫獲取這1億數(shù)據(jù)，并展示前1000行數(shù)據(jù)的預覽。在展示前1000行之前，數(shù)據(jù)庫需要將1億數(shù)據(jù)所在的表，全部加載到內(nèi)存中，然后才從內(nèi)存讀取前1000行，對服務(wù)器造成不必要的壓力，甚至會造成服務(wù)器的癱瘓。
關(guān)閉該功能后，如果需要查看某個查詢的最新結(jié)果，可以在選擇對應(yīng)的表查詢后，點擊刷新預覽按鈕，則只刷新當前表的數(shù)據(jù)。
十六、優(yōu)化DAX公式
DAX公式主要是由FE(公式)引擎和SE(存儲)引擎共同作用的結(jié)果。
執(zhí)行 DAX 查詢涉及兩個引擎：
在DAX公式的優(yōu)化方向上，則希望優(yōu)先使用FE引擎計算，盡可能減少SE引擎的計算或增加SE緩存命中的數(shù)量。
公式的計算效果有三種狀態(tài)：
請注意：DAX的公式優(yōu)化，在很多時候是有極限的，優(yōu)化到一定地步就無法再優(yōu)化。
在某些場景下，公式的算法進行優(yōu)化后，可能會有幾倍甚至幾百倍上千倍的性能差異，在解決特定計算場景時，優(yōu)化DAX算法或者公式的編寫技巧，是非常有必要的。
這部分佐羅老師寫的更詳細，大家直接參考即可：
DAX中有哪些性能優(yōu)化方法？
////
比如使用佐羅老師的，視圖層算法。在很多場景中，是可以提高計算速度的。
關(guān)于視圖層算法，請參考：
DAX 性能優(yōu)化 高級視圖算法 性能提升成千上萬倍
/p/
總結(jié)：DAX公式的性能優(yōu)化，需要積累一定的知識儲備才能達到更好的效果。也可以通過探索DAX函數(shù)的計算原理，搭配出最佳函數(shù)組合，用以達到最佳計算性能。
十七、減少頁面可視化對象數(shù)量
減少報表頁面可視化圖表的數(shù)量，可以減少圖表渲染的時間，從而增加頁面加載的速度。
比如我們要做5個不同指標的卡片圖，那么我們有兩個選擇。一個是使用5張卡片圖，另一個是使用矩陣。
雖然都是計算5個指標，但其實際在頁面加載的速度則有明顯的區(qū)別。
比如，下面的圖片中。效果看起來是完全一樣的，不過上面是5個卡片圖，下面是一個矩陣。實際頁面加載中，下面的矩陣只渲染一張圖表，因此速度快了5倍左右。
除此之外，建議優(yōu)先使用默認的視覺對象。相較于應(yīng)用市場中的視覺對象，默認的視覺對象加載更快。
總結(jié)：報表可視化頁面，視覺對象的數(shù)量要適當，太多容易造成加載速度變慢，太少又會造成內(nèi)容不夠豐滿。
十八、使用增量刷新
增量刷新適合以下場景：
增量刷新，則可以看我的另一篇文章：
Power BI增量刷新如何配置(顛覆認知)
/p/
總結(jié)：增量刷新在規(guī)范的項目中，是不錯的選擇。但如果你只是在本地分析，則無法使用該功能。
十九、減少列不重復值
減少列不重復值，是縮小Power BI文件大小的方法。
Power BI表格模型的數(shù)據(jù)存儲于 ，這是一個位于內(nèi)存中的列式數(shù)據(jù)庫，與行式數(shù)據(jù)庫不同，這是一種以列形式存儲數(shù)據(jù)的結(jié)構(gòu)。
這部分請參考高飛老師的講解：
理解基數(shù)
/--/
這是一種存儲機制，可以縮小表格存儲所需的空間。
總結(jié)：舉例來說，對于日期時間的處理，最佳實踐就是：日期和時間分開兩列，若時間不參與計算，則不加載。如果將日期和時間放在一列，則會增加列基數(shù)，文件會變的更大。
二十、硬件優(yōu)化
以上講過了Power BI在軟件上的優(yōu)化。軟件的優(yōu)化是有一定局限性的，若硬件不與之匹配，則軟件的優(yōu)化效果不會太明顯。因此，在Power BI性能優(yōu)化最佳實踐中，硬件優(yōu)化是最直接，最簡的方式。那么，如何通過硬件的提升，來提高Power BI的運算速度呢，該提哪部分配置性價比最高呢？
1、CPU
CPU是影響Power BI計算速度的第一因素，且是CPU單核性能。而市面上這樣的CPU往往還都比較便宜，5000元左右的預算，就可以買到一個相當不錯的機器。
CPU性能，參考網(wǎng)站：
/.html
按照 Mark倒序，從大到小，即可看出CPU一列中，哪個CPU排名最靠前，那么這個CPU在計算Power BI的時候就越快。
截止發(fā)文，計算Power BI最快的CPU是I9-，不過這樣的CPU價格都比較貴，可以退而求其次，找到一個性價比比較高的CPU，比如I7-。
關(guān)于如何測試你電腦CPU的性能在什么級別，可以參考佐羅的文章：
輕松測試電腦性能，幫您選好電腦
/p/
CPU的使用建議是，測試的時長不超過10秒，原則上越快越好。目前我遇到過最快的，大概在4秒，我自用的電腦在6秒-7秒，你也測測你電腦CPU的性能吧！
總結(jié)：CPU的升級，是最直接最簡單提升Power BI計算速度的方法。這部分的提升，是DAX性能優(yōu)化所無法彌補的。
2、內(nèi)存
在內(nèi)存方面，很多人都會認為如何比對excel表格兩列數(shù)據(jù)中的相同部分?，內(nèi)存越大，計算越快。在Power BI的計算中，實際并不是這樣，真正影響Power BI計算速度的是內(nèi)存頻率。一個頻率是的8G內(nèi)存，是一定比一個頻率是的32G內(nèi)存計算更快的。
內(nèi)存頻率變化的直觀感受，反映到Power BI的操作中就是，你寫完一個度量值并回車，很快就執(zhí)行完成。反之就是你還需要等待3-5秒才計算完成，尤其是在一些復雜的計算中，這個時間差異尤為明顯。
該經(jīng)驗主要來源于，我使用同一個模型在不同的電腦上進行測試的結(jié)果。
目前從理論上來說，肯定是內(nèi)存頻率越高，計算速度越快。
截至發(fā)文，市面上主流的內(nèi)存頻率是，并且已經(jīng)出現(xiàn)了搭載諸如、內(nèi)存頻率的電腦。作為個人推薦的話，建議不低于，如果有條件，那當然是越快越好啦！
總結(jié)： CPU(單核性能) > 內(nèi)存頻率 > 內(nèi)存大小
3、其他
其他部分包括：硬盤、網(wǎng)卡、網(wǎng)速等。在Power BI的部署和生產(chǎn)環(huán)境中，依然也會產(chǎn)生不同的影響。比如顯卡會影響頁面渲染的速度，網(wǎng)速會影響可視化加載的速度等等。
4、企業(yè)級硬件部署
本地部署
企業(yè)級的本地部署，Power BI一般都會放到專用的服務(wù)器上。基于以上總結(jié)過的硬件配置經(jīng)驗，實際在計算過程中，企業(yè)級的服務(wù)器，在表現(xiàn)上，可能不如5000元的筆記本。服務(wù)器的配置偏重一般都在多核并行計算上，但單核性能的表現(xiàn)上卻很一般。所以，企業(yè)級的本地部署，需要考慮下服務(wù)器的硬件搭配，尤其是CPU類型，同時平衡單核性能和并發(fā)。
云端部署
同樣的道理，目前經(jīng)過測試后的數(shù)據(jù)顯示。即便使用Power BI ，其計算速度依然不如5000元的筆記本更快。
如果只是個人使用Power BI，你花5000元買個筆記本，完全不用自卑，因為已經(jīng)比企業(yè)級的部署更快了。
云端加更多的資源，解決的還是高并發(fā)，對于單個用戶而言，速度上不會有明顯的變化。
關(guān)于云端計算速度和本地PC電腦計算速度的對比，請參考：
個人版來了，免費體驗
/p/
二十一、定期更新Power BI
新的版本，往往意味著更多的功能和更優(yōu)秀的性能。定期更新到較新的版本，也有助于對Power BI的優(yōu)化。
全文總結(jié)：
最佳實踐就是平衡的藝術(shù)。
Power BI性能優(yōu)化最佳實踐的核心就是平衡，了解自己所需的和可以舍棄的，從而找到最佳平衡點。最佳實踐不是結(jié)果，而是狀態(tài)。
由于文中涉及大量的專業(yè)知識，受限于作者的水平，可能存在有誤的地方。若發(fā)現(xiàn)錯誤之處，不吝賜教。