共用方式為

評估並最佳化 Microsoft Fabric 容量

  • 發行項

本文說明如何評估和最佳化 Microsoft Fabric 容量上的負載。 它也會說明解決多載情況的策略，並提供指引來協助最佳化每個 Fabric 體驗的計算。

雖然 Fabric 容量模型可簡化設定並啟用共同作業，但很有可能耗盡容量的共用計算資源。 您支付的資源費用可能也會多於必要費用。 當某些 Fabric 體驗的設計未遵循最佳做法時，可能會發生這些情況。

請務必降低耗盡共用資源的風險，Fabric 作為受管理的服務，以兩種方式自動解決這類問題。

  • 高載和平滑可確保 CPU 密集活動快速完成，而不需要更高的 SKU (而且可以在一天中的任何時間執行)。
  • 當容量遇到持續和高 CPU 需求時 (高於 SKU 限制)，節流延遲或拒絕作業。

平滑可降低節流的可能性 (雖然仍可能發生節流)。 平滑是針對限制配置使用量的方式，但它與工作的執行無關。 平滑不會變更效能，只會在較長時間內分散耗用計算的帳戶，因此不需要較大的 SKU 來處理尖峰計算。

若要深入了解 Fabric 容量，請參閱 Microsoft Fabric 概念和授權和 Fabric 容量 – 新功能的須知事項和即將推出的內容。

規劃和預算工具

規劃容量的大小可能是一項挑戰。 這是因為必要的計算可能會因為執行作業、執行作業的效能 (例如，在 Notebooks 中執行 DAX 查詢或 Python 程式碼的效率)，或並行層級而有很大不同。

為了協助您判斷正確的容量大小，您可以佈建試用容量或隨用隨付 F SKU，以測量購買 F SKU 保留執行個體之前所需的實際容量大小。

提示

從小型開始，然後視需要逐漸增加容量大小，這一直是一個很好的策略。

監視容量

您應該監視使用率，以充分利用您的容量。 最重要的是，請務必了解 Fabric 作業是互動或背景的。 例如，來自 Power BI 報表的 DAX 查詢是互動式作業的隨選要求，而語意模型重新整理則是背景作業。 如需作業及其如何在 Fabric 內取用資源的詳細資訊，請參閱 Fabric 作業。

監視可以向您顯示正在進行節流。 當有許多或長時間執行的互動式作業時，可能會發生節流。 一般而言，與 SQL 和 Spark 體驗相關的背景作業會執行平滑，這表示其分散在 24 小時期間中。

Fabric 容量計量應用程式是監視和視覺化最近使用率的最佳方式。 應用程式會細分為項目類型 (語意模型、筆記本、管線和其他)，並協助您識別使用高階計算的項目或作業 (以便將其最佳化)。

系統管理員可以使用管理員監視工作區來了解常用項目 (以及整體採用)。 他們也可以使用監視中樞來檢視租用戶中的目前和最近活動。 某些作業的詳細資訊也可能可從記錄分析或內部部署的資料閘道記錄取得。

管理高計算使用量

當容量使用率很高，並開始顯示節流或拒絕時，有三種策略可以解決此問題：最佳化、擴大和擴增。

最好設定通知，以了解容量使用率何時超過設定閾值。 此外，請考慮使用工作負載特定的設定來限制作業的大小 (例如 Power BI 查詢逾時或資料列限制，或 Spark 工作區設定)。

最佳化

內容建立者應一律最佳化其 Fabric 項目的設計，以確保其高效，並使用最少的計算資源。 本文稍後會提供每個 Fabric 體驗的特定指引。

相應增加

您可以擴大容量，以暫時或永久增加 SKU 大小 (具有更多計算容量)。 擴大可確保容量上的所有項目都有足夠可用的計算資源，並避免節流。

您也可以調整 Fabric F SKU 大小、暫停和繼續，以配合取用模式。

橫向擴增

您可以藉由將部分工作區或項目移至不同的 Fabric 容量來擴增，以分散工作負載。 當需要不同的容量策略、設定或系統管理員時，它可能是一個很好的選項。 佈建多個容量也是有助於隔離高優先順序項目，以及自助或開發內容的計算的良好策略。 例如，貴組織中的主管預期會有高度響應的報表和儀表板。 這些報表和儀表板可以位於專屬於主管報告的個別容量中。

您也可以考慮將 Power BI 工作區移至共用容量，前提是取用者擁有可讓他們繼續存取內容的 Power BI Pro 授權。

設定浪湧保護

突波保護 藉由限制計算背景作業的總耗用量，幫助避免容量的過度使用。 這樣可減少總計算，因此互動式延遲或拒絕的可能性較低。 如果有資源限制或拒絕的期間，它也有助於系統容量更快復原。 您可以為每個容量設定激增保護。 突波保護有助於防止節流和拒絕，但並不是容量優化、擴充容量和擴展的替代方案。

當激增保護作用中時，背景工作會遭到拒絕。 這表示即使在啟用激增保護時，您的容量也會受到影響。 通過使用浪湧保護，您可以調整使用容量，以最佳平衡容量內的計算需求。 若要完全保護關鍵解決方案，建議您將它們隔離在適當大小的容量中。

依 Fabric 體驗計算最佳化

Fabric 中的體驗和項目會以不同的方式運作，因此您不一定以相同方式最佳化它們。 本節會根據經驗列出 Fabric 項目，以及您可以採取的最佳化動作。

Fabric 資料倉儲

資料倉儲會使用無伺服器架構，且其節點會自動由服務管理。 容量使用量是根據作用中每個查詢容量單位秒來計算，而不是佈建前端和後端節點的時間量。

所有資料倉儲作業都是背景作業，且會在 24 小時內平滑。

SQL 分析端點的目標是預設提供效能體驗。 為此，相較於 SQL Server 或 Azure Synapse Analytics 專用 SQL 集區，可用的查詢微調選項較少。

以下是一些需要考慮的要點，以協助將計算降至最低。

  • 使用最理想的 T-SQL 來撰寫查詢。 可能的話，請限制可能會不必要地增加查詢資源使用量的資料行、計算、彙總和其他作業數目。
  • 設計資料表以盡可能使用最小的資料類型。 您選擇的資料類型可能會嚴重影響 SQL 引擎所產生的查詢計劃。 例如，將 VARCHAR 欄位從長度 500 減少到 25，或變更 DECIMAL(32, 8) 為 DECIMAL(10, 2) 可能會導致為查詢配置的資源大幅減少。
  • 使用星型結構描述設計來減少讀取的資料列數目，並將查詢聯結降至最低。
  • 確定統計資料存在且為最新。 統計資料在產生最佳執行計畫方面扮演了重要角色。 它們會在運行時間自動建立，但您可能需要手動更新它們，尤其是在載入或更新資料之後。 請考慮使用 FULLSCAN 選項來建立統計資料，而不是依賴使用取樣的自動產生統計資料。
  • 使用內建檢視來監視查詢和使用方式，特別是在疑難排解問題時。
    • sys.dm_exec_requests 動態管理檢視 (DMV) 提供所有主動執行查詢的相關資訊，但不會儲存任何歷程記錄資訊。 Fabric 工具箱 提供使用此 DMV 的查詢，並藉由聯結至其他檢視來提供查詢文字等詳細資料，讓使用者更容易使用查詢結果。
    • 查詢深入解析是 Fabric 資料倉儲的一項功能，可提供 SQL 分析端點上歷史查詢活動的整體檢視。 具體來說，queryinsights.exec_requests_history 檢視會提供每個完整 SQL 要求的相關資訊。 它針對每個查詢執行提供所有相關詳細資料，這些詳細資料可以與容量計量應用程式中找到的作業 ID 相互關聯。 監視容量使用量最重要的資料行包括：distributed_statement_id、command (query text)、start_time 和 end_time。

網狀架構 資料工程師和網狀架構 資料科學

Data Engineering 和 Data Science 體驗會使用 Spark 計算，在 Fabric Lakehouse 中處理、分析和儲存資料。 Spark 計算是以虛擬核心來設定和測量。 不過，Fabric 會使用 CU 作為各種項目所耗用的計算量值，包括 Spark 筆記本、Spark 工作定義和 Lakehouse 工作。

在 Spark 中，一個 CU 會轉譯為計算的兩個 Spark 虛擬核心。 例如，當客戶購買 F64 SKU 時，128 個 Spark 虛擬核心可供 Spark 體驗使用。

所有 Spark 作業都是背景作業，且會在 24 小時內平滑。

如需詳細資訊，請參閱 Fabric Spark 中的計費和使用率報告。

以下是一些需要考慮的要點，以協助將計算降至最低。

  • 一律努力撰寫有效率的 Spark 程式碼。 如需詳細資訊，請參閱 在 Azure Synapse Analytics 中最佳化 Apache Spark 作業和最佳化 Apache Spark 寫入的需求。
  • 保留 Spark 工作所需的執行程式，以釋放其他 Spark 工作或工作負載的資源。 否則，您會增加 Spark 工作失敗並具有 HTTP 430 狀態的機會，這表示容量要求太多。 您可以在 Fabric 監視中樞檢視配置給筆記本的執行程式數目，您也可以在其中判斷筆記本使用的實際執行程式數目。 Spark 工作只會保留必要的節點，並允許在 SKU 限制內平行提交。
  • Spark 集區只能設定為使用 SKU 所支援的最大虛擬核心數目。 不過，您可以接受 SKU 限制內的平行 Spark 工作，來擴增資料工程工作負載。 這種方法通常稱為高載因數，預設會針對容量層級的 Spark 工作負載啟用。 如需詳細資訊，請參閱並行節流和佇列。
  • 作用中的 Spark 工作階段可能會累積容量的 CU 使用率。 基於這個理由，請務必在不使用時停止使用中的 Spark 工作階段。 請注意，預設的 Spark 工作階段到期時間設定為 20 分鐘。 使用者可以變更 Notebooks 中或 Spark 工作定義的工作階段逾時。

Real-Time Intelligence

KQL 資料庫 CU 使用量是根據資料庫活動的秒數和使用的虛擬核心數目來計算。 例如，當您的資料庫使用四個虛擬核心且活動 10 分鐘時，您將使用 2,400 (4 x 10 x 60) 秒的 CU。

所有 KQL 資料庫作業都是互動式作業。

自動縮放機制可用來判斷 KQL 資料庫的大小。 它可確保根據使用模式達成最佳成本和最佳效能。

為了讓資料可供其他 Fabric 引擎使用，KQL 資料庫會與 OneLake 同步。 根據 KQL 資料庫所執行的讀取和寫入交易數目，從您的容量使用 CU。 它會使用 OneLake 讀取和寫入計量，這相當於 Azure Data Lake Storage (ADLS) Gen2 帳戶上的讀取和寫入作業。

Data Factory

本節涉及 Data Factory 中資料流程和資料管線的最佳化。

所有作業都是背景作業，且會在 24 小時內平滑。

以下是一些需要考慮的要點，以協助將計算降至最低。

  • 避免效率不佳的 Power Query 邏輯，以將昂貴的資料轉換 (例如合併和排序) 降到最低並最佳化。
  • 盡可能努力實現查詢折疊。 其可藉由減少資料來源與目的地之間需要傳輸的資料量，來改善資料流程的效能。 當查詢折疊未發生時，Power Query 會從資料來源擷取所有資料，並在本機執行轉換，這可能會低效且緩慢。
  • 使用小型資料磁碟區和/或執行簡單轉換時，停用檢閱及測試。 在某些情況下可能需要檢閱及測試，例如當您載入資料倉儲時。
  • 避免比資料來源所需更頻繁地重新整理資料。 例如，如果資料來源每 24 小時更新一次，則每小時重新整理資料不會再提供任何價值。 相反地，請考慮以適當的頻率重新整理資料，以確保資料是最新且準確的。

Power BI

Power BI 的作業為互動式或背景式。

下列互動作業通常會導致高計算使用量。

  • 未遵循最佳做法的語意模型。 例如，它們可能不會採用具有一對多關聯性的星型結構描述設計。 或者，它們可能包含複雜且昂貴的資料列層級安全性 (RLS) 篩選器。 請考慮使用表格式編輯器和最佳做法分析程式來判斷是否遵循最佳做法。
  • DAX 度量沒有效率。
  • 報表頁面包含太多視覺物件，這可能會導致視覺物件重新整理緩慢。
  • 報表視覺物件會顯示高基數結果 (資料列或資料行太多)，或包含太多量值。
  • 容量體驗高並行，因為對於容量大小，使用者太多。 請考慮啟用查詢擴增以改善高並行語意模型的用戶體驗 (但不會產生更多總計算)。

下列背景作業通常會導致高計算使用量。

  • Power Query 邏輯中效率不佳或過於複雜的資料轉換。
  • 大型事實資料表沒有查詢折疊或累加式重新整理。
  • 報表高載，也就是同時產生大量 Power BI 報表或編頁報表時。

相關內容

更多問題嗎？ 請嘗試詢問 Fabric 社群。