瞭解和優化數據流重新整理

  • 發行項

Power BI 數據流可讓您連線、轉換、合併及散發數據以進行下游分析。 數據流中的關鍵元素是重新整理程式，它會套用您在數據流中撰寫的轉換步驟，並更新專案本身中的數據。

若要瞭解運行時間、效能，以及您是否充分利用數據流，您可以在重新整理數據流之後下載重新整理記錄。

瞭解重新整理

有兩種類型的重新整理適用於資料流：

  • Full，其會執行數據的完整排清和重載。

  • 累加式 （僅限 進階版），它會根據您設定的時間型規則來處理數據子集，以篩選方式表示。 日期數據行上的篩選會將數據動態分割成 Power BI 服務 中的範圍。 設定累加式重新整理之後，數據流會自動改變查詢以包含依日期篩選。 您可以使用Power Query中的 進階編輯器 來微調或自訂重新整理，以編輯自動產生的查詢。 如果您自備 Azure Data Lake 儲存體，您可以根據您設定的重新整理原則來查看資料的時間配量。

    注意

    若要深入瞭解累加式重新整理及其運作方式，請參閱 搭配數據流使用累加式重新整理。

累加式重新整理可讓Power BI中的大型數據流具有下列優點：

  • 第一次重新整理之後的重新整理速度較快，原因如下：

    • Power BI 會重新整理使用者指定的最後 N 個數據分割（其中數據分割是日/周/月等等），或
    • Power BI 只會重新整理需要重新整理的數據。 例如，只重新整理 10 年語意模型的過去五天。
    • 只要您指定要檢查變更的數據行，Power BI 只會重新整理已變更的數據。

  • 重新整理更可靠 - 不再需要維護與揮發性來源系統的長時間執行連線。

  • 減少資源耗用量 - 重新整理的數據較少，可減少記憶體和其他資源的整體耗用量。

  • 在可能的情況下，Power BI 會在分割區上使用平行處理，這可能會導致更快速的重新整理。

在這些重新整理案例中，如果重新整理失敗，則數據不會更新。 您的數據可能已過時，直到最新的重新整理完成，或者您可以手動重新整理數據，然後可以完成而不會發生錯誤。 重新整理發生在分割區或實體上，因此，如果累加式重新整理失敗，或實體發生錯誤，則不會發生整個重新整理交易。 另一種方式是，如果數據流的數據分割（累加式重新整理原則）或實體失敗，則整個重新整理作業會失敗，而且不會更新任何數據。

瞭解並優化重新整理

若要進一步了解數據流重新整理作業的執行方式，請流覽至其中一個數據流，以檢閱 數據流的重新整理歷程記錄 。 選取 數據流的 [更多選項][... ]。 然後選擇 [重新整理記錄] 設定>。 您也可以在工作區中選取數據流。 然後選擇 [其他選項]（...） >重新整理歷程記錄。

Screenshot of dataflows refresh history.

重新 整理歷程記錄 提供重新整理的概觀，包括類型 – 依需求 或 排程、持續時間及執行狀態。 若要查看 CSV 檔案形式的詳細數據，請選取重新整理描述數據列最右邊的下載圖示。 下載的 CSV 包含下表所述的屬性。 進階版 重新整理會根據額外的計算和數據流功能，提供更多資訊，以及位於共用容量上的 Pro 型數據流。 因此，下列某些計量僅適用於 進階版。

項目 說明 優點 Premium
要求於 已排程時間重新整理，或立即按兩下 [當地時間] 重新整理。 ✔ ✔
數據流名稱 數據流的名稱。 ✔ ✔
數據流重新整理狀態 已完成、失敗或略過（針對實體）是可能的狀態。 鏈接實體之類的使用案例是人們可能看到略過的原因。 ✔ ✔
實體名稱 資料表名稱。 ✔ ✔
數據分割名稱 此專案取決於數據流是否為進階，且 Pro 顯示為 NA，因為它不支援累加式重新整理。 進階版 會顯示 FullRefreshPolicyPartition 或 IncrementalRefreshPolicyPartition-[DateRange]。 ✔
重新整理狀態 個別實體或分割區的重新整理狀態，提供重新整理數據的時間配量狀態。 ✔ ✔
開始時間 在 進階版 中，此專案是數據流排入佇列以處理實體或分割區的時間。 如果數據流具有相依性，而且需要等候上游數據流的結果集開始處理，這個時間可能會有所不同。 ✔ ✔
結束時間 結束時間是數據流實體或分割區完成的時間，如果適用的話。 ✔ ✔
期間 數據流以 HH：MM：SS 表示的重新整理時間總計。 ✔ ✔
已處理的數據列 針對指定的實體或分割區，數據流引擎掃描或寫入的數據列數目。 此專案不一定會根據您執行的作業來包含數據。 未使用計算引擎時，或當您使用閘道作為數據處理時，可能會省略數據。 ✔
已處理的位元組 針對指定的實體或分割區，數據流引擎所寫入的數據，以位元組表示。

在此特定數據流上使用閘道時，不會提供此資訊。		 ✔
最大認可 （KB） Max Commit 是尖峰認可記憶體，可用於診斷 M 查詢未優化時的記憶體不足失敗。

當您在此特定數據流上使用閘道時，不會提供此資訊。		 ✔
處理器時間 對於指定的實體或分割區，時間以 HH：MM：SS 表示數據流引擎執行轉換所花費的時間。

當您在此特定數據流上使用閘道時，不會提供此資訊。		 ✔
等待時間 針對指定的實體或分割區，根據 進階版 容量上的工作負載，實體花費在等候狀態的時間。 ✔
計算引擎 針對指定的實體或分割區，重新整理作業如何使用計算引擎的詳細數據。 值如下：
-那
-摺疊
-快取
- 快取 + 折疊

本文稍後會更詳細地說明這些元素。		 ✔
錯誤 如果適用，每個實體或分割區會描述詳細的錯誤訊息。 ✔ ✔

數據流重新整理指引

重新整理統計數據提供您可用來優化及加速數據流效能的寶貴資訊。 在下列各節中，我們會說明一些案例、要注意的事項，以及如何根據提供的資訊進行優化。

協調流程

在相同的工作區中使用數據流可讓您直接協調流程。 例如，您可能在單一工作區中有數據流 A、B 和 C，並鏈結如 A > B > C。如果您重新整理來源 （A），下游實體也會重新整理。 不過，如果您重新整理 C，則必須獨立重新整理其他人。 此外，如果您在數據流 B 中新增數據源（未包含在 A 中），數據不會重新整理為協調流程的一部分。

您可能想要將不符合受控協調流程Power BI執行的項目鏈結在一起。 在這些案例中，您可以使用 API 和/或使用 Power Automate。 您可以參考 API 檔和PowerShell 腳稿 ，以程式設計方式重新整理。 Power Automate 連接器可讓您執行此程式，而不需要撰寫任何程序代碼。 您可以看到 詳細的範例，其中包含特定逐步解說，以進行 循序重新整理。

監視

使用本文稍早所述的增強式重新整理統計數據，您可以取得詳細的每個數據流重新整理資訊。 但是，如果您想要查看具有全租使用者或全工作區重新整理概觀的數據流，或許可以建置監視儀錶板，您可以使用 API 或 PowerAutomate 範本。 同樣地，對於傳送簡單或複雜通知等使用案例，您可以使用PowerAutomate連接器，或使用 API 建置您自己的自定義應用程式。

逾時錯誤

優化執行擷取、轉換和載入 （ETL） 案例所需的時間是理想的。 在 Power BI 中，適用下列情況：

  • 某些連接器具有您可以設定的明確逾時設定。 如需詳細資訊，請參閱 Power Query 中的 連線 ors。
  • Power BI 數據流，使用 Power BI Pro，也可以體驗在實體或數據流本身內長時間執行的查詢逾時。 Power BI 進階版 工作區中並不存在該限制。

逾時指引

Power BI Pro 數據流的逾時閾值如下：

  • 個別實體層級的兩小時。
  • 整個數據流層級的三小時。

例如，如果您有具有三個數據表的數據流，則個別數據表不需要兩個多小時，如果持續時間超過三小時，整個數據流就會逾時。

如果您遇到逾時，請考慮優化數據流查詢，並考慮在來源系統上使用 查詢折疊 。

另外，請考慮升級至每位使用者 進階版，這不受這些逾時限制，而且因為許多Power BI 進階版 Per User 功能而提供更高的效能。

持續時間長

複雜或大型數據流可能需要更多時間來重新整理，因為數據流的優化效能不佳。 下列各節提供如何減輕長時間重新整理持續時間的指引。

長時間重新整理持續時間的指引

改善數據流長時間重新整理持續時間的第一個步驟是根據 最佳做法來建置數據流。 值得注意的模式包括：

接下來，它有助於評估您是否可以使用累加式重新整理。

使用 累加式重新整理 可以改善效能。 請務必在提交查詢以進行重新整理作業時，將數據分割篩選推送至來源系統。 若要向下推送篩選表示數據源應該支持查詢折疊，或者您可以透過函式或其他方法表達商業規則，以協助Power Query消除和篩選檔案或資料夾。 大部分支援 SQL 查詢的數據源都支持查詢折疊，而某些 OData 摘要也支持篩選。

不過，一般檔案、Blob 和 API 等數據源通常不支持篩選。 如果數據源後端不支持篩選，則無法下推。 在這種情況下，混搭引擎會補償並套用本機篩選，這可能需要從數據源擷取完整的語意模型。 此作業可能會導致累加式重新整理變慢，而且如果已使用，程式可能會用盡 Power BI 服務 或內部部署數據網關中的資源。

假設每個數據源各層級的查詢折疊支援，您應該執行驗證，以確保篩選邏輯包含在來源查詢中。 為了簡化此動作，Power BI 會嘗試為您執行此驗證，並搭配 Power Query Online 的步驟折疊指標。 其中許多優化都是設計時間體驗，但在重新整理發生之後，您有機會分析和優化重新整理效能。

最後，請考慮優化您的環境。 您可以藉由相應增加容量、調整數據閘道大小，以及使用下列優化來減少網路等待時間，以優化 Power BI 環境：

  • 使用 Power BI 進階版 或 進階版 Per User 可用的容量時，您可以藉由增加 進階版 實例或將內容指派給不同的容量來提升效能。

  • 每當 Power BI 需要存取無法直接透過因特網存取的數據時，就需要閘道。 您可以在 內部部署伺服器上或虛擬機上安裝內部部署資料閘道 。

    • 若要瞭解閘道工作負載和重設大小建議，請參閱 內部部署數據閘道大小調整。
    • 也評估將數據先帶入暫存數據流，並使用連結和計算的實體來參考下游數據。

  • 網路等待時間會增加要求到達 Power BI 服務 所需的時間，以及傳遞響應，從而影響重新整理效能。 Power BI 中的租使用者會指派給特定區域。 若要判斷租使用者所在的位置，請參閱 尋找組織的默認區域。 當租使用者中的使用者存取 Power BI 服務 時，其要求一律會路由傳送至該區域。 當要求到達 Power BI 服務 時，服務接著可能會傳送額外的要求，例如，傳送至基礎數據源或數據網關，這也會受限於網路等待時間。

    • Azure 速度測試之類的工具提供用戶端與 Azure 區域之間的網路等待時間指示。 一般而言，若要將網路等待時間的影響降到最低，請盡量讓數據源、網關和 Power BI 叢集保持接近。 最好位於相同區域。 如果網路等待時間是個問題，請嘗試將閘道和數據源放在雲端裝載的虛擬機內，以更接近Power BI 叢集。

高處理器時間

如果您看到高處理器時間，您可能會有未折疊的昂貴轉換。 高處理器時間可能是因為您擁有的已套用步驟數目，或您要建立的轉換類型。 所有這些可能性都可能導致較高的重新整理時間。

高處理器時間的指導方針

優化高處理器時間有兩個選項。

首先，使用數據源本身內的查詢折疊，這應該會直接減少數據流計算引擎的負載。 數據源內的查詢折疊可讓來源系統執行大部分的工作。 然後，數據流就可以以來源的原生語言傳遞查詢，而不必在初始查詢之後執行記憶體中的所有計算。

並非所有數據源都可以執行查詢折疊，即使可能進行查詢折疊，也可能有執行無法折疊至來源之特定轉換的數據流。 在這種情況下，增強型 計算引擎 是Power BI引進的功能，可特別改善轉換的效能高達25倍。

使用計算引擎將效能最大化

雖然 Power Query 具有查詢折疊的設計時間可見度，但計算引擎數據行會提供有關內部引擎本身是否使用的詳細數據。 當您有複雜的數據流，並在記憶體中執行轉換時，計算引擎會很有説明。 這種情況是增強式重新整理統計數據很有用的地方，因為計算引擎數據行會提供引擎本身是否使用的詳細數據。

下列各節提供使用計算引擎及其統計數據的指引。

警告

在設計時間，編輯器中的折疊指標可能會顯示從另一個數據流取用數據時，查詢不會折疊。 檢查來源數據流是否已啟用增強的計算，以確保啟用來源數據流上的折疊。

計算引擎狀態的指引

開啟增強型計算引擎並瞭解各種狀態很有説明。 在內部，增強型計算引擎會使用 SQL 資料庫來讀取和儲存數據。 最好在這裡對查詢引擎執行轉換。 下列段落提供各種情況，以及每個案例的指導方針。

NA - 此狀態表示未使用計算引擎，原因可能是：

  • 您使用的是 Power BI Pro 數據流。
  • 您已明確關閉計算引擎。
  • 您在資料來源上使用查詢折疊。
  • 您正在執行無法利用用來加速查詢的 SQL 引擎的複雜轉換。

如果您遇到很長的持續時間，但仍會取得 NA 的狀態，請確定它已開啟且不會意外關閉。 建議的模式是使用預備數據流，一開始將數據放入 Power BI 服務，然後在暫存數據流之後，在此數據之上建置數據流。 該模式可以降低來源系統上的負載，以及計算引擎，為轉換提供速度提升並改善效能。

快 取 - 如果您看到 快 取狀態，數據流數據會儲存在計算引擎中，並可供參考做為另一個查詢的一部分。 如果您將其當做連結實體使用，則這種情況很理想，因為計算引擎會快取該數據以供下游使用。 快取的數據不需要在同一個數據流中重新整理多次。 如果您想要將它用於 DirectQuery，這種情況也可能很理想。

快取時，在相同數據流或相同工作區的不同數據流中，對初始擷取的效能影響會有所回報。

如果您的實體持續時間很大，請考慮關閉計算引擎。 若要快取實體，Power BI 會將它寫入記憶體和 SQL。 如果是單一用途實體，則使用者的效能權益可能不值得雙重擷取的懲罰。

折疊 - 折迭 表示數據流能夠使用 SQL 計算來讀取數據。 計算實體會使用 SQL 中的數據表來讀取數據，而使用的 SQL 與查詢的建構相關。

當您使用內部部署或雲端數據源時，會隨即出現折疊狀態，您必須先將數據載入暫存數據流，並參考此數據流中的數據。 此狀態僅適用於參考另一個實體的實體。 這表示您的查詢是在 SQL 引擎之上執行，而且它們有可能透過 SQL 計算來改善。 若要確保 SQL 引擎會處理您的轉換，請使用支援 SQL 折疊的轉換，例如合併式（聯結）、群組依據（匯總），以及在 查詢編輯器 中附加 （union） 動作。

快取 + 折疊 - 當您看到快取 + 折疊時，數據重新整理可能已優化，因為您有一個實體同時參考另一個實體，而且是由另一個實體上游參考。 此作業也會在 SQL 之上執行，因此，SQL 計算也有可能改善。 若要確定您獲得最佳的效能，請使用支援 SQL 折疊的轉換，例如合併式（聯結）、依匯總分組，以及在 查詢編輯器 中附加 （union） 動作。

計算引擎效能優化的指引

下列步驟可讓工作負載觸發計算引擎，進而一律改善效能。

在相同工作區中計算和連結的實體：

若要 擷取，請專注於將數據儘快放入記憶體，只有在篩選條件減少整體語意模型大小時才使用篩選。 將您的轉換邏輯與此步驟分開。 接下來，將您的轉換和商業規則分成相同工作區中的個別數據流。 使用連結或計算實體。 這麼做可讓引擎啟用和加速計算。 對於簡單的類比，它就像廚房的食物準備：食物準備通常是一個分開和不同的步驟，從收集您的原料，以及將食物放入烤箱的必要條件。 同樣地，您必須先個別準備邏輯，才能利用計算引擎。

請確定您執行折疊的作業，例如合併、聯結、轉換和其他 作業。

此外，在已發佈的指導方針和限制內建置數據流。

當計算引擎開啟，但效能緩慢：

調查計算引擎所在的案例時，請執行下列步驟，但效能不佳：

  • 限制存在於整個工作區的計算和鏈接實體。
  • 如果您的初始重新整理是在開啟計算引擎時，數據會寫入 Lake 和 快取中。 此雙寫入會導致重新整理速度變慢。
  • 如果您有數據流連結至多個數據流，請務必排程來源數據流的重新整理，讓它們不會同時重新整理。

考量與限制

Power BI Pro 授權每天有 8 次重新整理的數據流重新整理限制。

相關內容