了解和最佳化資料流程重新整理
Power BI 資料流程可讓您連線、轉換、合併及散發資料以進行下游分析。 資料流程中的一個關鍵要素是重新整理流程，這會套用您在資料流程中撰寫的轉換步驟，並更新項目本身中的資料。
若要了解執行階段、效能，以及您是否充分利用資料流程，您可以在重新整理資料流程之後下載重新整理記錄。
了解重新整理
有兩種重新整理類型適用於資料流程：
完整，其會執行資料的完整排清和重新載入。
累加式(僅限 Premium)，其會根據您所設定以時間為基礎的規則 (以篩選表示) 來處理資料子集。 日期資料行的篩選會在 Power BI 服務中動態地將資料分割至不同範圍。 設定累加式重新整理之後，資料流程會自動改變您的查詢以包含依日期篩選。 您可以使用 Power Query 中的進階編輯器來微調或自訂重新整理，以編輯自動產生的查詢。 如果您自備 Azure Data Lake Storage，您可以根據設定的重新整理原則來查看資料的時間配量。
注意
若要深入了解累加式重新整理及其運作方式，請參閱搭配資料流程使用累加式重新整理。
累加式重新整理可啟用 Power BI 中的大型資料流程，且具有下列優點：
第一次重新整理之後的重新整理速度較快，原因如下：
- Power BI 會重新整理使用者指定的最後 N 個分割區 (其中分割區為日/週/月等)，或
- Power BI 只會重新整理需要重新整理的資料。 例如，只重新整理 10 年中最後五天的語意模型。
- 只要您指定想要檢查變更的資料行，Power BI 就只會重新整理已變更的資料。
重新整理更可靠 - 不需要再維護長時間執行的連線，即可變更來源系統。
減少資源耗用量 - 要重新整理的資料較少可減少記憶體和其他資源的整體耗用。
Power BI 會盡可能平行處理分割區，因此重新整理速度可能更快。
在任何這類重新整理案例中，如果重新整理失敗，則資料不會更新。 您的資料在最新的重新整理完成之前可能會過時，或者您可以手動重新整理資料，以便完成而不會發生錯誤。 重新整理會在分割區或實體上進行，因此如果累加式重新整理失敗或實體發生錯誤，則不會發生整個重新整理交易。 換句話說，如果資料流程的分割區 (累加式重新整理原則) 或實體失敗，則整個重新整理作業會失敗，而且不會更新任何資料。
了解和最佳化重新整理
若要進一步了解資料流程重新整理作業如何執行，請瀏覽至其中一個資料流程來檢閱資料流程的重新整理記錄。 選取資料流程的 [更多選項 (...)]。 然後選擇 [設定] > [重新整理記錄]。 您也可以在 [工作區] 中選取資料流程。 然後選擇 [更多選項 (…)] >[重新整理記錄]。
[重新整理記錄] 提供重新整理概觀，包括類型 ([隨選] 或 [排程])、持續時間及執行狀態。 若要查看 CSV 檔案形式的詳細資料，請選取重新整理描述資料列最右邊的下載圖示。 下載的 CSV 包含下表所述的屬性。 相較於 Pro 根據位於共用容量上的資料流程提供資訊，Premium 重新整理會根據額外的計算和資料流程功能提供更多資訊。 因此，下列某些計量僅適用於 Premium。
| 項目 | 說明 | 優點 | 高級 |
|---|---|---|---|
| 已於此日期要求 | 排程重新整理或按一下 [立即重新整理] 的時間 (當地時間)。 | ✔ | ✔ |
| 資料流程名稱 | 您的資料流程名稱。 | ✔ | ✔ |
| 資料流程重新整理狀態 | 可能的狀態包括 [已完成]、[失敗] 或 [已略過] (適用於實體)。 連結實體等使用案例可能會導致出現 [已略過] 狀態。 | ✔ | ✔ |
| 實體名稱 | 資料表名稱。 | ✔ | ✔ |
| 分割區名稱 | 此項目取決於資料流程是否為 Premium，以及 Pro 是否由於不支援累加式重新整理而顯示為 [不適用]。 Premium 會顯示 FullRefreshPolicyPartition 或 IncrementalRefreshPolicyPartition-[日期範圍]。 | ✔ | |
| 重新整理狀態 | 個別實體或分割區的重新整理狀態，提供所重新整理資料的時間配量狀態。 | ✔ | ✔ |
| 開始時間 | 在 Premium 中，此項目是資料流程排入佇列以處理實體或分割區的時間。 如果資料流程具有相依性，且需要等候上游資料流程的結果集才能開始處理，則此時間可能會有所不同。 | ✔ | ✔ |
| 結束時間 | 結束時間是資料流程實體或分割區完成的時間 (如果適用)。 | ✔ | ✔ |
| 期間 | 資料流程重新整理的總經過時間 (以 HH:MM:SS 表示)。 | ✔ | ✔ |
| 已處理的資料列數 | 針對指定的實體或分割區，資料流程引擎已掃描或寫入的資料列數目。 此項目不一定會根據您執行的作業來包含資料。 當您未使用計算引擎，或由於資料就地處理而使用閘道時，就可能會省略資料。 | ✔ | |
| 已處理的位元組數 | 針對指定的實體或分割區，資料流程引擎已寫入的資料 (以位元組表示)。 在此特定資料流程上使用閘道時，不會提供此資訊。 |
✔ | |
| 認可上限 (KB) | [認可上限] 是尖峰認可記憶體，可用於診斷 M 查詢未最佳化時的記憶體不足失敗。 當您在此特定資料流程上使用閘道時，不會提供此資訊。 |
✔ | |
| 處理器時間 | 針對指定的實體或分割區，資料流程引擎執行轉換所花費的時間 (以 HH:MM:SS 表示)。 當您在此特定資料流程上使用閘道時，不會提供此資訊。 |
✔ | |
| 等待時間 | 針對指定的實體或分割區，根據 Premium 容量上的工作負載，實體花在等候狀態的時間。 | ✔ | |
| 計算引擎 | 針對指定的實體或分割區，重新整理作業如何使用計算引擎的詳細資料。 值如下： - 不適用 - 已折疊 - 已快取 - 已快取 + 已折疊 本文稍後會更詳細地說明這些項目。 |
✔ | |
| 錯誤 | 如果適用，則會根據實體或分割區詳細說明錯誤訊息。 | ✔ | ✔ |
資料流程重新整理指引
重新整理統計資料提供您可用來最佳化及加速資料流程效能的寶貴資訊。 在下列各節中，我們會說明一些案例、要注意的事項，以及如何根據提供的資訊進行最佳化。
協調流程
在相同的工作區中使用資料流程可簡化協調流程。 例如，您可能在同一個工作區中有資料流程 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 中的連接器。
- 使用 Power BI Pro 的 Power BI 資料流程也可能會遇到實體或資料流程本身內長時間執行的查詢逾時。 Power BI Premium 工作區中不存在該限制。
逾時指引
Power BI Pro 資料流程的逾時閾值如下：
- 個別實體層級為兩小時。
- 整個資料流程層級為三小時。
例如，如果您有包含三個資料表的資料流程，任何資料表都不能超過兩小時，且如果持續時間超過三小時，整個資料流程就會逾時。
如果您遇到逾時，請考慮最佳化資料流程查詢，並考慮在來源系統上使用查詢折疊。
另請考慮升級至 Premium Per User，該版本不受這些逾時限制，而且由於許多 Power BI Premium Per User 功能，因此可提供更高的效能。
持續時間過長
複雜或大型資料流程可能需要更多時間來重新整理，未最佳化的資料流程也是如此。 下列各節提供如何緩解重新整理持續時間過長情況的指引。
重新整理持續時間過長的指引
改善資料流程重新整理持續時間過長的第一個步驟，就是根據最佳做法來建置資料流程。 值得注意的模式包括：
- 針對稍後可在其他轉換中使用的資料，使用連結實體。
- 使用計算實體來快取資料，以減少來源系統上的資料載入和資料擷取負擔。
- 將資料分割成暫存資料流程和轉換資料流程，以將 ETL 分成不同的資料流程。
- 最佳化展開資料表作業。
- 遵循複雜資料流程的指引。
接下來，它可能有助於您評估是否可以使用累加式重新整理。
使用累加式重新整理可提升效能。 針對重新整理作業提交查詢時，務必將分割區篩選推送到來源系統。 若要向下推送篩選，表示資料來源應該支援查詢折疊，您也可以透過函式或其他方式表達商務邏輯，以便協助 Power Query 消除和篩選檔案或資料夾。 大部分支援 SQL 查詢的資料來源都支援查詢折疊，而某些 OData 摘要還可能支援篩選。
不過，一般檔案、Blob 和 API 等資料來源通常不支援篩選。 如果資料來源後端不支援篩選，則無法向下推送。 在此情況下，交互式引擎可在本機補償並套用篩選，這可能需要從資料來源擷取完整的語意模型。 此作業會導致累加式重新整理變慢，而且在使用時，該程序可能會用盡 Power BI 服務或內部部署資料閘道中的資源。
由於每個資料來源都有不同的查詢折疊層級支援，因此您應該執行驗證，以確認篩選邏輯已包含在來源查詢中。 為了簡化上述過程，Power BI 會嘗試使用 Power Query Online 中的步驟摺疊指標為您執行此驗證。 其中許多最佳化都是設計階段體驗，但您有機會在重新整理之後分析和最佳化重新整理效能。
最後，請考慮最佳化您的環境。 您可以透過下列最佳化來擴大容量、調整資料閘道大小，以及降低網路延遲，將 Power BI 環境最佳化：
使用 Power BI Premium 或 Premium Per User 的可用容量時，您可以透過增加 Premium 執行個體或將內容指派給不同的容量來提升效能。
每當 Power BI 必須存取無法直接透過網際網路取得的資料時，就需要閘道。 您可以在內部部署伺服器或虛擬機器上安裝內部部署資料閘道。
- 若要了解閘道工作負載與大小調整建議，請參閱內部部署的資料閘道大小調整。
- 另請評估將資料先帶入暫存資料流程，再使用連結與計算實體來參考下游資料。
網路延遲可能會因要求到達 Power BI 服務所需時間增加以及傳遞回應所需時間增加而影響重新整理效能。 Power BI 中的租用戶會指派給特定區域。 若要判斷您的租用戶所在位置，請參閱尋找組織的預設區域。 租用戶中的使用者存取 Power BI 服務時，其要求一律會路由傳送至該區域。 例如，當要求到達 Power BI 服務時，服務可能會將額外要求傳送至底層資料來源或資料閘道，而這些要求也受限於網路延遲。
- Azure Speed Test 這類工具可以指出用戶端與 Azure 區域之間的網路延遲。 一般而言，若要將網路延遲的影響降到最低，請盡量將資料來源、閘道和 Power BI 叢集保留在最接近的位置。 最好位於相同區域。 如果網路延遲是問題，則您可以透過將其放置在雲端裝載的虛擬機器中，嘗試將閘道與資料來源放置在更接近 Power BI 叢集的位置。
高處理器時間
如果您看到高處理器時間，您可能有未折疊的昂貴轉換。 高處理器時間可能是由於您所擁有的套用步驟數目，或您要建立的轉換類型所造成。 所有這些可能情況都會導致較高的重新整理時間。
高處理器時間的指引
有兩個選項可最佳化高處理器時間。
首先，使用資料來源本身內的查詢折疊，這應該會直接減少資料流程計算引擎的負載。 資料來源內的查詢折疊可讓來源系統執行大部分的工作。 然後，資料流程就可以使用來源的原生語言傳遞查詢，而不必在初始查詢之後執行記憶體中的所有計算。
並非所有資料來源都可以執行查詢折疊，即使可以執行查詢折疊，也可能會有執行無法折疊至來源之特定轉換的資料流程。 在此情況下，增強型計算引擎是 Power BI 引進的功能，可特別改善轉換的效能高達 25 倍。
使用計算引擎將效能提到最高
雖然 Power Query 具有查詢折疊的設計階段可見度，但計算引擎資料行會提供是否使用內部引擎本身的詳細資料。 當您有複雜的資料流程，而且正在記憶體中執行轉換時，計算引擎會很有幫助。 在此情況下，由於計算引擎資料行會提供是否使用引擎本身的詳細資料，因此增強型重新整理統計資料可能會很有幫助。
下列各節提供使用計算引擎及其統計資料的指引。
警告
在設計階段，當從另一個資料流程取用資料時，編輯器中的折疊指標可能會顯示查詢未折疊。 檢查來源資料流程是否已啟用增強型計算，以確保在來源資料流程上啟用折疊。
計算引擎狀態的指引
開啟增強型計算引擎並了解各種狀態會很有幫助。 在內部，增強型計算引擎會使用 SQL 資料庫來讀取和儲存資料。 最好在這裡對查詢引擎執行轉換。 下列段落提供各種情況，以及每種情況的因應措施指引。
不適用 - 此狀態表示未使用計算引擎，因為：
- 您使用的是 Power BI Pro 資料流程。
- 您已明確關閉計算引擎。
- 您在資料來源上使用查詢折疊。
- 您正在執行無法利用用來加速查詢之 SQL 引擎的複雜轉換。
如果過了很長的時間仍取得 [不適用] 的狀態，請確定其已開啟且未意外關閉。 一個建議的模式是使用暫存資料流程，一開始將資料放入 Power BI 服務，然後在資料位於暫存資料流程之後，根據該資料建置資料流程。 該模式可以降低來源系統上的負載，搭配計算引擎使用時，可加快轉換速度並提升效能。
已快取 - 如果您看到 [已快取] 狀態，表示資料流程已儲存在計算引擎中，並可在另一個查詢中參考。 如果您將其當做連結實體使用，則此情況會會非常適合，因為計算引擎會快取該資料供下游使用。 您不需要在同一個資料流程中多次重新整理快取的資料。 如果您想要將其用於 DirectQuery，此情況也可能非常適合。
在相同資料流程或相同工作區的不同資料流程中快取時，初始擷取的效能影響會在稍後有所回報。
如果您的實體持續時間很長，請考慮關閉計算引擎。 為了快取實體，Power BI 會將其寫入至記憶體和 SQL。 如果是一次性實體，為使用者帶來的效能優勢可能不值得雙重擷取的不利影響。
已折疊 - [已折疊] 表示資料流程能夠使用 SQL 計算來讀取資料。 計算實體會使用 SQL 中的資料表來讀取資料，而使用的 SQL 與查詢的建構相關。
如果在您使用內部部署或雲端資料來源時，先將資料載入暫存資料流程，再於此資料流程中參考，則會顯示 [已折疊] 狀態。 此狀態僅適用於參考另一個實體的實體。 這表示您的查詢是在 SQL 引擎之上執行，而且可能透過 SQL 計算來改善。 若要確保 SQL 引擎處理您的轉換，請使用支援 SQL 折疊的轉換，例如查詢編輯器中的合併 (聯結)、群組依據 (彙總) 和附加 (聯集) 動作。
已快取 + 已折疊 - 當您看到 [已快取 + 已折疊] 時，資料重新整理可能已最佳化，因為您有一個實體同時參考了另一個實體，以及由另一個上游實體所參考。 此作業也會在 SQL 之上執行，因此也可能透過 SQL 計算來改善。 若要確保盡可能獲得最佳效能，請使用支援 SQL 折疊的轉換，例如查詢編輯器中的合併 (聯結)、群組依據 (彙總) 和附加 (聯集) 動作。
計算引擎效能最佳化的指引
下列步驟可讓工作負載觸發計算引擎，從而持續提升效能。
相同工作區中的計算與連結實體：
針對「擷取」，請著重於盡快將資料放入儲存體，只有在篩選降低整體語意模型大小時，才使用篩選。 將您的轉換邏輯與此步驟分開。 接下來，將您的轉換和商務邏輯分成相同工作區中的不同資料流程。 使用連結或計算實體。 這麼做可讓引擎啟用和加速計算。 簡單比喻，這就像在廚房中準備食物：準備食物通常是獨立且不同的步驟，從取得原始食材，到將食物放入烤箱中等事前處理。 同樣地，您必須另外準備好邏輯，才能利用計算引擎。
請務必執行可摺疊的作業，例如合併、聯結、轉換等等。
此外，在已發佈的方針和限制內建置資料流程。
計算引擎已開啟，但效能緩慢時：
在調查計算引擎已開啟，但效能不佳的案例時，請採取下列步驟：
- 限制存在於不同工作區之間的計算與連結實體。
- 如果已開啟計算引擎的初始重新整理，並接著在資料湖「與」快取中寫入資料， 此雙重寫入會導致重新整理速度變慢。
- 如果資料流程連結至多個資料流程，請確定您已為來源資料流程的重新整理進行排程，使其不會同時重新整理。
考量與限制
Power BI Pro 授權具有資料流程重新整理限制，每天最多可重新整理 8 次。