問題
當使用大型數據模型，緩慢的基礎數據源或Power BI中的復雜報表時，我們有時會陷入與性能問題作斗爭的困境。這會花費大量的開發時間，而這些時間本來應該用於報表開發。我已經介紹了一些最佳實踐和實用實施，您可以在對性能問題進行故障排除或優化Power BI報表性能時考慮這些最佳實踐。
由於加載大數據模型而可能導致的典型問題包括：
- 需要不同的許可證容量來存儲模型。Power Premium Pro只能容納1GB的型號，盡管Premium允許的最大尺寸為13GB。
- 較大的數據模型大小通常會增加對諸如內存之類的容量資源的爭用。這不允許在更長的時間段內同時加載更多模型，從而導致更高的收回率。
- 較大的模型實現較慢的數據刷新，從而導致較高的延遲報告，較低的數據集刷新吞吐量以及對源系統和容量資源的壓力增加。
為了便於理解，本技巧分為三個帖子。
解
優化或對性能問題進行故障排除時，可以考慮幾個選項，但是我將集中精力處理本系列中的以下選項。
- 實施垂直過濾
- 在Power Query中創建的自定義列的首選項
- 在數據加載選項設置中禁用“自動日期/時間”
- 使用數據的一部分進行開發或水平過濾
- 嘗試在DAX度量計算中使用更多變量
- 禁用非必需表的Power Query查詢負載
在本系列文章中，我僅縮小了在Power BI環境中可以完成的工作，可以在Power BI環境之外進行更多選擇以加快Power BI中的查詢性能，包括創建索引，通過在源處進行操作來更改數據集。在連接到Power BI等之前
本系列的第1部分將重點討論上述前兩個項目可以解決的問題。
在Power BI中實現垂直過濾
表列的兩個主要目的包括報告 和模型結構。因此，優良作法是僅設計僅具有所需列的模型。無論Vertipaq存儲引擎在幫助壓縮和優化數據方面有多高效，實現減小模型大小的方法仍然非常重要。因此，要實現這一點，下面有一個示例，說明如何通過實現垂直過濾（即刪除不必要的列）來減小大小模型。
在下圖中，我已將AdventureOrder 2014數據庫中的SalesOrderHeader表導入到Power BI數據模型中。
導入的表有26列，其中包括4個datetime列。因此，當我將該模型保存到文件位置時，可以查看模型的大小，如下所示，該大小當前為3,125KB。
但是，如果這是一個非常大的模型，則可以想象它的大小會更大，而應用垂直過濾的方法將是刪除不支持報告和模型結構的列。在下圖中，我刪除了大約七列。
現在，如果我們再次查看PBIX文件的保存位置，我們可以看到它已將模型大小從3,125KB減少到1,744KB，大約是初始大小的一半。同樣，當使用非常大的數據模型（呈指數增長）時，這可能是一個很大的差異。
在Power Query中創建的自定義列的首選項
最好的做法是創建更多的計算列，就像用M語言定義的Power Query 計算列一樣。眾所周知， 將表列添加為DAX計算列的效率不如使用Power Query選項有效，但是，有一些例外情況可以證明，其中某些計算列只能在DAX中完成。如下所示，需要注意的是，Vertipaq存儲引擎以與Power Query M語言計算列相同的方式存儲模型DAX計算列，但是在計算的DAX中效率低下和數據刷新時間延長引起的問題列的產生是由於數據結構的存儲方式以及較低的壓縮效率。
在下圖中，我創建了一個列來更改“ OnlineOrderFlag”列的值，該列是布爾（True / False）列。如果值為“ TRUE”，我們希望為“在線”，如果值為“ FALSE”，我們希望為“店內”。這可以通過兩種方式完成，即Power Query M計算列或DAX計算列。
首先，讓我們看看如何在Power Query M計算列中做到這一點。
可以在下面看到新的計算列“ OrderFlag”。
其次，我們可以在Power BI Desktop的DAX計算列中執行相同的操作，如下圖所示。
可以在下面看到新的計算列“ OrderFlagDAX”。
接下來，我分別為在Power Query和DAX中創建的列創建了兩個Slicer視覺效果，以便我們可以比較並查看刷新后的性能。請注意，這是一個較小的模型，請想象一下對較大數據模型的影響。為了進行比較，我利用了Power BI桌面中的 Performance Analyzer，如下所示。
如下圖所示，“ OrderFlag”大約花費75毫秒來刷新，而“ OrderFlagDAX”大約花費104毫秒來刷新。下圖將顯示這不是由於DAX查詢的執行，而是由於切片器可視化程序用於准備查詢，等待其他可視化程序完成或執行其他后台處理所需的時間。這就是效率發揮作用的地方。
在第2部分中，我們將研究禁用“自動日期/時間”和實現 水平過濾如何有助於提高性能並減少Power BI開發中的低效率。