Power BI無疑已經走了很長一段路，它以其作為自助服務工具的強大根基，易於使用的功能以及在企業領域的持續推動和推動而發展。但是，我們仍然可以發現許多開發和維護Power BI解決方案可以通過應用一些更改而受益匪淺，這些更改將導致Power BI解決方案響應速度更快，消耗的資源更少，更符合最佳實踐並總體上表現更好。本文將和大家重點分享Power BI性能介紹和最佳實踐的五大秘訣。
在Power BI中開發任何新的解決方案時，我們總是希望結合我們探索的所有技巧，以獲取性能和最佳實踐，因此，個人建議你也在整個Power BI開發過程中實施這些技巧。
秘訣一 減少列數，減少行數
在許多情況下，僅因為Power BI可以處理大數據量，我們才將所需數據加載到Power BI中。但是，隨著解決方案開始向外擴展，這可能直接影響性能。通過選擇“獲取數據”按鈕，適當的連接器以及連接類型（如果適用），將數據導入Power BI的過程完成後，我們還應該問自己以下問題：
- 這些列/行是否可以幫助我們分析數據？
- 這些列/行是否可以幫助我們進行決策？
- 我們將在計算中使用這些列/行還是建立關係？
如果有問題的數據要提取到Power BI中，但不滿足上述條件，我們應該將其排除在解決方案之外。比如：當僅需要分析今年的當前績效與上一年的對比時，為什麼要提取最近5年的數據呢？當我們只需要產品名稱的一列時，為什麼要導入產品維度的所有描述性列？同樣，在提取數據時很容易加載所有內容而不進行此過程，但是要確保我們的Power BI解決方案消耗更少的資源並以最高的性能執行，我們應該使查詢包含更少的列（窄）和更少的行（短）。
為了在上面添加一些細節，在將數據提取到Power BI中時，該過程將通過Power Query進行任何數據整形和數據轉換操作，然後將數據加載到Power Pivot中，該數據是一個壓縮的列式數據庫，用於存儲數據通過VertiPaq引擎存儲在內存中。現在，我們不打算詳細介紹VertiPaq引擎，但是要擺脫這一點非常重要的一件事是，VertiPaq引擎是列式存儲引擎，因此可以壓縮列。出於這個原因，我們應該更加註意我們要攝取的列數，而不是行數。這在下圖中突出顯示，我們最好少列多行。
秘訣二 將轉換推向源端
Power Query是功能強大的數據轉換和數據整形工具，可以輕鬆地直接在Power BI中直接處理轉換。實際上，它是一個很棒的工具，我們可以嘗試在Power Query中進行所有操作。但是，很多時候我遇到過使用各種類型的轉換來處理數以千萬計的行的解決方案，因此可以通過將一些工作負載推回源頭來提高性能。
將工作負載推回源端，意味著什麼？讓我們分解一下以理解它。打開Power BI Desktop時，它是一塊空白畫布，因為平臺中不存在任何數據，因此我們要做的第一件事是選擇“獲取數據”。從這裡開始，我們選擇合適的連接器以將數據提取到Power BI中。然後，我們可以選擇“轉換數據”，這將打開Power Query（相當於單擊功能區中的“ Edit Queries”）。在Power Query中時，我們可以應用各種轉換來成形數據，但是，重要的是要了解，在此階段，我們僅將內存中的前1000行存儲為預覽。
Power Query首先將前1000行存儲在內存中，然後在“應用的步驟”窗格中應用轉換。
畢竟，這是有道理的，可以想象在使用Power Query並等待應用轉換時將所有數據存儲到內存中，這肯定會增加等待時間。實際上，這等效於每次應用轉換時單擊“關閉並應用”。因此，一旦我們完成所有轉換的應用並且我們的數據處於預期格式，則單擊“關閉並應用”，Power Query會將數據加載到Power Pivot，後者將所有數據存儲到內存中，然後在已應用的步驟窗格中應用轉換。
單擊“關閉並應用”後，Power Query會將所有數據加載到Power Pivot並在已應用步驟窗格中應用轉換。
現在我們已經掌握了以上知識，讓我們回到將工作量推回源頭意味著什麼的問題？由於Power BI將數據存儲在內存中，因此將所有數據加載到內存中然後應用轉換效率要低得多，而不是直接在源中應用任何轉換並將結果集簡單加載到Power BI中。減少了處理數據導入所需的資源數量，並提高了查詢性能。
現在，這可能意味著需要對基礎數據源進行一些工作，在某些情況下，由於缺乏基礎技術的技能，權限級別或適當的團隊來執行所需的更改的等待時間，這些數據可能會受到一些阻礙。這將我們帶到了查詢摺疊機制，該過程是將直接在Power Query中應用的所有轉換（用M語言編寫）轉換為基礎數據源的本地語言的過程，因此所有轉換都不會在您的計算機上完成，而是在源代碼方面。
您可以直接在Power BI Desktop中利用查詢摺疊功能，但是您應該注意一些因素，例如：
- 基礎數據源必須支持接受查詢摺疊請求的概念。這包括關係數據庫，OData源（例如SharePoint列表），Exchange和Active Directory。
- 並非所有類型的轉換都支持查詢摺疊，例如，如果您具有“刪除最前面的行”，則不會將其發送回源端。
- 一旦應用了不支持查詢摺疊的轉換步驟，接下來要執行的所有其他步驟將要求首先將數據加載到內存中。
秘訣三 禁用查詢負載
在許多性能優化的方案中，我發現許多表已加載到Power BI中，這些表不用於報告，建立關係或創建計算。在繼續之前，任何加載到Power Query中的查詢都將加載到Power Pivot，因此會消耗寶貴的內存。現在，存在這些表的常見原因是它們在Power Query中充當登臺表，因此僅被攝取以轉換另一組數據。
例如，你已經將包含所有員工詳細信息的數據集“ A”攝取到Power BI中，但是，對於必須執行的分析，需要“ NI”列，該列存儲在名為數據集“ B”的另一源中。因此，數據集“ B”也被加載到Power BI中，僅用於與數據集“ A”進行合併，並派生列“ NI”。
完成此操作後，通常可以將數據集“ A”和數據集“ B”都加載到Power Pivot中。請停止這步習慣性的操作吧！我們應該右鍵單擊數據集“ B”，然後取消選擇“啟用負載”，這將禁用Power Query將該查詢加載到Power Pivot中，因此不會不必要地消耗內存。
當我們禁止將查詢加載到Power Pivot時，這並不意味著諸如刷新之類的轉換將在刷新時中斷。兩個數據集之間在Power Query中應用的所有轉換步驟都將運行，就像從未禁用該查詢一樣。唯一的區別是，它將不會加載到模型中並且無法用於報告，因此減少了內存消耗。
秘訣四 刪除高基數列
在我們繼續進行此技巧之前，重要的是要了解高基數列是指Power BI中提取的具有唯一值百分比很高的列。如前所述，數據已加載到Power Pivot（這是一個壓縮的列式數據庫）中，我們之所以要刪除高基數列，是因為壓縮高基數列時壓縮工作效率低得多。
列包含的唯一值越多，壓縮的效率就越低。
我們經常用來解釋高基數列的示例是Power BI中通常提取的列，即“ DateTime”。如果我們使用的是三年的數據，則唯一日期的計數將為1095。現在，如果將日期和時間合併為一個列，則必須將1095乘以所有可能的時間組合。因此，如果我們存儲的時間屬性是一天中的小時，則“ DateTime”列中的單個值的格式為dd-mm-yyyy hh，則唯一值的數量將超過1095，而是乘以所有可能的時間值24，因為我們一天中有24小時。因此，從1095個唯一值開始，我們現在得到1095乘以24，即26,280。如果我們還有分鐘和幾秒鐘，那麼唯一值的數量將急劇增加，從而導致壓縮效率降低。
要識別高基數列，我們可以使用Power Query中提供的“列分佈”之類的功能，甚至可以更好地使用我們建議使用VertiPaq分析器來識別高基數列。重要說明，如果您在Power BI中使用列分配功能，則除非更改，否則這僅適用於前1000行。
秘訣五 與星型圖對齊
這是迄今為止官方一直推薦的Power BI中最重要的性能提示。實際上，至關重要的是，我們也將繼續努力推動將你的數據建模為接近星型模式，解決你當前不知道的問題，並阻止在以後出現的問題。如果在創建Power BI解決方案時需要執行任何操作，則將使模型與Kimball Star Schema接近。
星型模式可以以較少的表和較少的關係來對Power BI中的數據進行建模，從而使所有內容儘可能地接近。
它由一個包含有用於測量的數字屬性的事實表組成。考慮一下諸如收入或可用庫存之類的數字列，這些數字列經過彙總和計數，以幫助我們進行數據分析。此外，星型模式在Fact表周圍包含Dimension表，這些表具有用於向數字屬性提供上下文的描述性屬性。例如，我們通過“庫存情況表”知道我們有300個可用庫存項目，但是通過“產品尺寸表”，我們知道哪個特定項目。
使用星型模式的主要原因是為了更快地檢索數據和創建可伸縮的BI解決方案。為了進一步分解，將數據建模為星型模式所帶來的一些好處是：
- 簡潔性：易於閱讀，使用和理解。事實包含要測量和計數的數字屬性，而維度包含要過濾的描述性屬性
- 性能：較少的表以及表之間的關係較少，因此增加了數據檢索時間
- 功能：充分利用Power BI的向下鑽取，追溯和其他各種功能來分析數據
- 模型大小：由於限制表和關係的數量，減少了消耗的內存量
- 可擴展性：易於擴展以適應新的尺寸，列和度量
從上面我們分享的所有技巧中，可以輕鬆地將數據模型與星型架構對齊，這是我們應該一直努力實現的最重要的技巧。更多Power BI 技巧請關注小悅，後續會有更多關於Power BI 性能技巧文章哦！
Power BI模型中星型架構的重要性（一）
Power BI模型中星型架構的重要性（二）
【2020】Power BI 3月產品功能更新
淺談數據倉庫建設中的數據建模方法
閱讀更多 PowerBI365 的文章
