共用方式為

Power BI 實作規劃：資料層級稽核

  • 發行項

注意

本文是 Power BI 實作規劃系列文章的其中一篇。 此系列主要著重於 Microsoft Fabric 中的 Power BI 體驗。 如需有關此系列的簡介，請參閱 Power BI 實作規劃。

此資料層級稽核文章適合多種對象閱讀：

  • 數據建立者和工作區系統管理員： 需要瞭解其建立、發佈和共用之語意模型、數據流和數據超市的使用方式、採用和效能的使用者。
  • Power BI 管理員：負責監督組織中 Power BI 的管理員。 Power BI 管理員可能需要與 IT、安全性、內部稽核和其他相關小組共同作業。 對效能進行疑難排解時，Power BI 管理員也可能需要與內容建立者共同作業。
  • Power BI 容量管理員：負責監督組織中的 Premium 容量的管理員。 對效能進行疑難排解時，Power BI 容量管理員可能需要與內容建立者共同作業。
  • 卓越中心、IT 和 BI 小組：同時負責監督 Power BI 的小組。 他們可能需要與 Power BI 管理員和其他相關小組共同作業。
  • 系統管理員：負責建立和保護 Azure Log Analytics 資源的小組，以及管理資料來源的資料庫管理員。

重要

此文章有時會提及 Power BI Premium 或其容量訂用帳戶 (P SKU)。 請注意，Microsoft 目前正在整合購買選項，並按容量 SKU 淘汰 Power BI Premium。 新客戶和現有客戶應考慮改為購買 Fabric 容量訂用帳戶 (F SKU)。

如需詳細資訊，請參閱 Power BI Premium 授權的重要更新 (英文) 和 Power BI Premium 常見問題集 (部分機器翻譯)。

本文涵蓋的概念主要適用於針對三個內容傳遞範圍建立的解決方案，即企業 BI、部門 BI 和團隊 BI。 個人 BI 解決方案的建立者也可能受益於本文提供的資訊，但他們並非主要對象。

當基礎語意模型和/或資料來源效能不佳時，報表和視覺效果就無法達到良好的效能。 本文著重於語意模型、資料流程和資料超市的稽核與監視。 這是稽核和監視系列中的第二篇文章，因為工具和技術比報表層級稽核一文中說明的更為複雜。 在理想情況下，您會在使用者建立報表之前建立共用語意模型 (供多個報表重複使用)。 因此，建議將本文與報表層級稽核一文一起閱讀。

由於 Power BI 語意模型的建置基礎為 Analysis Services 表格式引擎，您可以連線至本機資料模型 (在 Power BI Desktop 中) 或 Premium 語意模型 (在 Power BI 服務中)，就像是 Analysis Services 資料庫一樣。 因此，Analysis Services 的許多稽核和監視功能都可用於 Power BI Premium 語意模型。

注意

若要進一步了解 Analysis Services 中裝載的模型，請參閱監視概觀。

本文的其餘部分主要著重於發佈至 Power BI 服務的模型。

語意模型事件記錄檔

資料建立者和擁有者的語意模型在經過一段時間後可能會出現狀況。 語意模型可能：

為了確保此類模型建立的內容具備可用性、良好效能並且可供妥善採用，您應對您負責管理的資料資產進行使用和效能上的稽核。 您可以使用資料集事件記錄檔，擷取基於語意模型而發生的活動，包括使用者產生和系統產生的活動。 我們也稱之為追蹤事件、資料集記錄或資料集活動記錄。 系統管理員通常會將其稱為低階追蹤事件，因其較為詳細。

注意

數據集名稱變更已在 Power BI 服務 和檔中推出，不過可能有一些實例，例如事件記錄作業名稱，但變更尚未發生。

您應分析語意模型追蹤事件，以執行下列作業：

  • 稽核語意模型上發生的所有活動。
  • 對語意模型效能、記憶體使用量和查詢效率進行疑難排解並最佳化。
  • 調查語意模型重新整理詳細資料和持續時間。
  • 監視 Power Query 所傳送的 Power Query 公式語言 (M 查詢)。
  • 監視傳送至語意模型 (Analysis Services 引擎) 的 DAX 公式和運算式。
  • 確認是否已根據工作負載和平衡全新資料與最佳效能的需求選取了正確的儲存模式。
  • 稽核在哪些語意模型上針對哪些使用者叫用了哪些資料列層級安全性角色。
  • 了解並行使用者數目。
  • 驗證語意模型 (例如，在認可語意模型之前或將其發佈至生產工作區之前，驗證資料品質和效能)。

Power BI 語意模型所產生的事件衍生自 Azure Analysis Services 可用的現有診斷記錄。 您可以擷取和分析許多類型的追蹤事件，如以下幾節所述。

Azure Log Analytics

Azure Log Analytics 是 Azure 監視器服務的元件之一。 Azure Log Analytics 與 Power BI 的整合可讓您從 Power BI 工作區中的所有語意模型擷取語意模型事件。 其支援僅限於 Premium 工作區。 設定整合並啟用連線 (針對 Power BI Premium 工作區) 之後，即會自動擷取語意模型事件，並將其持續傳送至 Azure Log Analytics 工作區。 語意模型記錄會儲存在 Azure 資料總管中，這是為了擷取大量近乎即時的遙測資料而最佳化的僅限附加資料庫。

您應將 Power BI Premium 工作區指派給 Azure 中的 Log Analytics 工作區。 您必須在 Azure 訂用帳戶中建立新的 Log Analytics 資源，才能啟用此類型的記錄。

來自一或多個 Power BI 工作區的記錄會傳送至目標 Log Analytics 工作區。 您可以選擇以下幾種方式來組織資料。

  • 一個目標工作區用於所有稽核資料：將所有資料儲存在一個 Log Analytics 工作區中。 相同的系統管理員或使用者會存取所有資料時，這會很有幫助。
  • 依主題領域組織目標工作區：依主題領域組織內容。 允許不同的系統管理員或使用者從 Azure Log Analytics 存取稽核資料時，此技巧尤有幫助。 例如，當您需要區隔銷售資料與營運資料時。
  • 每個 Power BI 工作區各有一個目標工作區：在 Power BI 工作區與 Azure Log Analytics 工作區之間設定一對一關聯性。 當您有特別敏感的內容，或資料受限於特定合規性或法規需求時，這將有其效用。

提示

徹底檢閱關於此功能的文件和常見問題集，以清楚了解其可能的作用與技術需求。 在將這項功能廣泛提供給組織中的工作區管理員使用之前，請考慮以一個 Power BI 工作區執行技術概念證明 (POC)。

重要

雖然名稱相似，但 Azure Log Analytics 所擷取的資料與 Power BI 活動記錄並不相同。 Azure Log Analytics 會從 Analysis Services 引擎擷取詳細層級的追蹤事件。 其唯一的目的是要協助您對語意模型效能進行分析與疑難排解。 其範圍位於工作區層級。 相對地，活動記錄的目的則是協助您了解特定使用者活動發生的頻率 (例如編輯報表、重新整理語意模型，或建立應用程式)。 其範圍是整個 Power BI 租用戶。

若要進一步了解您可以為 Power BI 租用戶稽核的使用者活動，請參閱租用戶層級稽核。

Azure Log Analytics 工作區連線管理員的租用戶設定可控制哪些使用者群組 (也具有必要工作區管理員角色的使用者) 可將 Power BI 工作區連線至現有的 Azure Log Analytics 工作區。

您必須符合安全性必要條件，才能設定整合。 因此，請考慮僅針對在 Azure Log Analytics 中具有必要權限的 Power BI 工作區管理員 (或可應要求取得這些權限的人員) 啟用 Power BI 租用戶設定。

提示

在規劃階段之初即應與您的 Azure 系統管理員共同作業，特別是難以在組織中取得新建 Azure 資源的核准時，更應如此。 您也需要規劃安全性必要條件。 請決定是否要將權限授與 Azure 中的 Power BI 工作區管理員，或是否要將權限授與 Power BI 中的 Azure 系統管理員。

Azure Log Analytics 所擷取的語意模型記錄包括語意模型查詢、查詢統計資料、詳細重新整理活動、Premium 容量耗用的 CPU 時間等等。 因為這是 Analysis Services 引擎的詳細層級記錄，因此資料可能會很詳細。 語意模型活動較多的大型工作區，往往會有龐大的資料量。

在搭配使用 Azure Log Analytics 與 Power BI 時若要達到最佳成本：

  • 只有在您主動對語意模型活動進行疑難排解、測試、最佳化或調查時，才將 Power BI 工作區連線至 Azure Log Analytics。 連線後，將會對工作區中的所有語意模型執行追蹤。
  • 當您不再需要主動對語意模型活動進行疑難排解、測試、最佳化或調查時，請中斷 Azure Log Analytics 與 Power BI 工作區的連線。 中斷連線後，就會終止對工作區中的所有語意模型執行追蹤。
  • 確定您了解 Azure Log Analytics 用來對資料擷取、儲存體和查詢進行計費的成本模型。
  • 請勿將資料儲存在 Log Analytics 中超過預設的 30 天保留期間。 這是因為語意模型分析通常著重於立即性的疑難排解活動。

有數種方式可以存取傳送至 Azure Log Analytics 的事件。 您可以使用：

  • 預先建置適用於 Power BI 語意模型的 Log Analytics 範本應用程式。
  • 適用於 Azure 資料總管 (Kusto) 的 Power BI Desktop 連接器。 使用 Kusto 查詢語言 (KQL)，分析儲存在 Log Analytics 中的資料。 如果您有 SQL 查詢的經驗，就會發現 KQL 有許多相似之處。
  • Azure 資料總管中的 Web 型查詢體驗。
  • 可執行 KQL 查詢的任何查詢工具。

提示

由於有大量的語意模型追蹤事件，建議您開發 DirectQuery 模型來分析資料。 DirectQuery 模型可讓您近乎即時地查詢資料。 這些事件通常會在五分鐘內到達。

如需詳細資訊，請參閱控管 Azure 連線。

檢查清單 - 規劃使用 Azure Log Analytics 時的關鍵決策和動作包括：

  • 考量技術 POC：規劃小型專案，以確保您完全了解技術需求、安全性需求、要擷取的事件，以及如何分析記錄。
  • 決定哪些工作區應與 Log Analytics 整合：確認哪些 Premium 工作區包含您有意分析的語意模型。
  • 決定是否應為任何工作區全程啟用 Log Analytics：若要達到最佳成本，請確認是否有需要永久啟用記錄的情況 (或特定工作區)。 決定在未進行疑難排解時是否應中斷工作區的連線。
  • 決定 Log Analytics 資料應保留多久：確認是否需要設定比預設值 30 天更久的保留期間。
  • 釐清要求新的 Log Analytics 工作區的程序：與 Azure 系統管理員共同作業，釐清 Power BI 工作區管理員應如何提交新 Log Analytics 資源的要求。
  • 決定安全性的運作方式：與 Azure 系統管理員共同作業，決定是要將 Azure Log Analytics 工作區的權限授與 Power BI 工作區管理員，還是將 Power BI 工作區的權限授與 Azure 系統管理員。 當您做出此安全性決策時，請考量您對工作區定期連線和中斷連線的計劃 (以達成最佳成本)。
  • 決定如何組織目標 Log Analytics 工作區：請考量應以多少個 Azure Log Analytics 工作區來組織一或多個 Power BI 工作區中的資料。 此決策應與誰可以存取記錄資料的安全性決策一致。
  • 決定允許哪些工作區管理員連線：確認哪些群組的工作區管理員可將 Power BI 工作區連線至 Log Analytics 工作區。 設定 Azure Log Analytics 工作區連線管理員的租用戶設定，以因應此決策。
  • 建立 Azure Log Analytics 資源：與 Azure 系統管理員共同作業，以建立每個 Log Analytics 工作區。 確認並更新在 Azure 中指派的權限，以確保 Power BI 設定會順利進行，不會發生任何問題。 驗證儲存在 Azure 中的資料位於正確的地理區域。
  • 設定每個 Power BI 工作區的 Log Analytics 連線：與 Power BI 工作區管理員共同作業，設定每個 Power BI 工作區的 Log Analytics 連線。 確認記錄資料正確流向 Log Analytics 工作區。
  • 建立查詢以分析資料：設定 KQL 查詢，以根據您的使用案例和目前的需求，分析 Log Analytics 中的資料。
  • 納入 Power BI 工作區管理員的指引：為 Power BI 工作區管理員提供如何要求新的 Log Analytics 工作區以及如何連線至 Power BI 工作區的資訊和必要條件。 此外，請說明中斷 Power BI 工作區連線的適當時機。
  • 提供分析資料的指引和範例查詢：為工作區管理員建立 KQL 查詢，讓他們能更輕鬆地開始分析已擷取的資料。
  • 監視成本：與 Azure 系統管理員共同作業，以持續監視 Log Analytics 成本。

SQL Server Profiler

您可以使用 SQL Server Profiler (SQL Profiler ) 來擷取 Power BI 語意模型事件。 這是 SQL Server Management Studio (SSMS) 的元件之一。 SSMS 的基礎為源自 SQL Server 的 Analysis Services 架構，因此支援連線至 Power BI 語意模型。

您可以在語意模型生命週期的不同階段使用 SQL Profiler。

  • 在資料模型開發期間：SQL Profiler 可作為外部工具連線至 Power BI Desktop 中的資料模型。 此方法適用於想要驗證其資料模型或進行效能微調的資料建模者。
  • 將語意模型發佈至 Power BI 服務之後：SQL Profiler 可以連線至 Premium 工作區中的語意模型。 SSMS 是眾多支援使用 XMLA 端點進行連線的用戶端工具之一。 若您想要對 Power BI 服務中已發佈的語意模型進行稽核、監視、驗證、疑難排解或微調，此方法將有其效用。

您也可以使用 SQL Profiler 作為 DAX Studio 中的外部工具。 您可以使用 DAX Studio 來啟動 Profiler 追蹤、剖析資料，以及格式化結果。 使用 DAX Studio 的資料建模者通常會優先使用此方法，而不是直接使用 SQL Profiler。

注意

使用 SQL Profiler 是與分析資料的活動不同的使用案例。 您可以在 Power Query 編輯器中分析資料，以深入了解其特性。 雖然資料分析是資料建模者的重要活動，但並不在本文的討論範圍內。

下列情況下，請考慮使用 SQL Profiler，而非 Azure Log Analytics：

  • 您的組織不允許您在 Azure 中使用或建立 Azure Log Analytics 資源。
  • 您想要擷取 Power BI Desktop 中的資料模型 (尚未發佈至 Power BI 服務中的 Premium 工作區) 的事件。
  • 您想要在短時間內擷取一個語意模型 (而不是 Premium 工作區中的所有語意模型) 的事件。
  • 您想要僅在追蹤期間內擷取特定事件 (例如，僅擷取查詢結束事件)。
  • 您想要頻繁啟動和停止追蹤 (例如，當您需要擷取現在發生的語意模型事件時)。

如同 Azure Log Analytics (本文先前所述)，SQL Profiler 所擷取的語意模型事件衍生自 Azure Analysis Services 可用的現有診斷記錄。 不過，可用的事件有一些差異。

提示

許多書籍、文章和部落格文章都提到如何使用 SQL Profiler 來監視 Analysis Services。 這些資訊也多半與監視 Power BI 語意模型有關。

重要

您也可以使用 SQL Profiler，監視從 Power BI 服務傳送至基礎資料來源 (例如，SQL Server 關聯式資料庫) 的查詢。 不過，追蹤關聯式資料庫的功能已淘汰。 連線至 Analysis Services 引擎的功能仍受支援，未遭到淘汰。 如果您熟悉 Analysis Services 擴充事件，並想要加以使用，您可以從 SSMS 連線至 Power BI Desktop 中的資料模型。 不過，不支援將其用於 Power BI Premium。 因此，本節僅著重於標準 SQL Profiler 連線。

[允許 XMLA 端點並使用內部部署語意模型在 Excel 中分析] 租用戶設定可控制哪些使用者群組 (也已指派給參與者、成員或管理員工作區角色，或個別語意模型的建置權限) 可以使用 XMLA 端點來查詢和/或維護 Power BI 服務中的語意模型。 如需使用 XMLA 端點的詳細資訊，請參閱進階資料模型管理使用案例。

注意

您也可以利用 SQL Profiler 對特定 DAX 運算式進行偵錯和疑難排解。 您可以將 SQL Profiler 作為外部工具連線至 Power BI Desktop。 尋找 DAX 評估記錄事件類別，以檢視 DAX 運算式的中繼結果。 當您在模型計算中使用 EVALUATEANDLOG DAX 函式時，就會產生該事件。

此函式僅供開發和測試之用。 您應先將其從資料模型計算中移除，再將資料模型發佈至生產工作區。

檢查清單 - 規劃使用 SQL Profiler 時的關鍵決策和動作包括：

  • 決定誰可以安裝 SSMS 或 DAX Studio：確認您是否允許組織中的所有 Power BI 內容建立者安裝 SSMS 和/或 DAX Studio，以便能使用 SQL Profiler。 決定這些輔助工具是要應要求安裝，還是隨著為組織中已核准的資料建立者安裝的標準軟體集一起安裝。
  • 將 SQL Profiler 新增至 Power BI Desktop 中的 [外部工具] 功能表：如果資料建立者會經常使用 SQL Profiler，請要求 IT 人員自動將其新增至 Power BI Desktop 中的 [外部工具] 功能表，供這些使用者使用。
  • 決定誰可以使用 XMLA 端點：確認是要允許所有使用者藉由使用 XMLA 端點來連線至已發佈的語意模型，還是僅限於已核准的資料建立者。 設定 [允許 XMLA 端點並使用內部部署語意模型在 Excel 中分析] 租用戶設定，以因應此決策。
  • 提供分析資料的指引和範例查詢：建立資料建立者的文件，使其了解稽核及監視語意模型的建議方式。 提供常見使用案例的指引，讓他們能更輕鬆地開始收集和分析追蹤資料。

資料模型中繼資料

由於 Power BI 語意模型是以 Analysis Services 引擎作為建置基礎，因此您有權存取可查詢資料模型中繼資料的工具。 中繼資料包含與資料模型有關的一切，包括資料表名稱、資料行名稱和量值運算式。

動態管理檢視

Analysis Services 動態管理檢視 (DMV) 可查詢資料模型中繼資料。 您可以使用 DMV 在某個時間點稽核、記錄及最佳化資料模型。

具體而言，您可以：

  • 稽核模型所使用的資料來源。
  • 探索模型中的哪些物件耗用了最多記憶體。
  • 確認資料行資料可達到的壓縮效率。
  • 在未使用的模型中尋找資料行。
  • 稽核作用中的使用者工作階段和連線。
  • 確認模型的結構。
  • 檢閱計算資料表、匯出資料行、量值和資料列層級安全性 (RLS) 規則所使用的 DAX 運算式。
  • 識別物件與量值之間的相依性。

提示

DMV 會擷取語意模型目前狀態的相關資訊。 請將 DMV 傳回的資料視為某個時間點當下現況的快照集。 反之，語意模型事件記錄檔 (本文先前所述) 則會擷取在追蹤連線處於作用中狀態時語意模型發生之活動的相關資訊。

SSMS 是通常用來執行 DMV 查詢的工具。 您也可以使用 Invoke-ASCmd PowerShell Cmdlet 來建立和執行查詢 DMV 的 XMLA 指令碼。

第三方工具和外部工具也廣受 Power BI 社群使用。 這些工具會使用公開記載的 DMV 來簡化存取，以及處理 DMV 所傳回的資料。 範例之一是 DAX Studio，其中包含存取 DMV 的明確功能。 DAX Studio 也包含內建的檢視計量功能，一般稱之為 Vertipaq Analyzer。 Vertipaq Analyzer 有一個使用者介面，用來分析資料模型中的資料表、資料行、關聯性和分割區的結構與大小。 您也可以將資料模型中繼資料匯出 (或匯入) 至 .vpax 檔案。 匯出的檔案只包含關於資料模型結構和大小的中繼資料，而不會儲存任何模型資料。

提示

需要資料模型方面的協助時，請考慮與他人共用 .vpax 檔案。 如此，您即無須與他共用模型資料。

您可以在語意模型生命週期的不同階段使用 DMV 查詢。

  • 在資料模型開發期間：您選擇的工具可作為外部工具連線至 Power BI Desktop 中的資料模型。 此方法適用於想要驗證其資料模型或進行效能微調的資料建模者。
  • 將語意模型發佈至 Power BI 服務之後：您選擇的工具可以連線至 Premium 工作區中的語意模型。 SSMS 是眾多支援使用 XMLA 端點進行連線的用戶端工具之一。 若您想要對 Power BI 服務中已發佈的語意模型進行稽核或驗證，此方法將有其效用。

提示

如果您決定自行撰寫 DMV 查詢 (例如，在 SSMS 中)，請留意 DMV 並不支援所有 SQL 作業。 此外，Power BI 不支援某些 DMV (因其所需的 Analysis Services 伺服器管理員權限不受 Power BI 支援)。

[允許 XMLA 端點並使用內部部署語意模型在 Excel 中分析] 租用戶設定可控制哪些使用者群組 (也已指派給參與者、成員或管理員工作區角色，或個別語意模型的建置權限) 可以使用 XMLA 端點來查詢和/或維護 Power BI 服務中的語意模型。

如需使用 XMLA 端點、第三方工具和外部工具的詳細資訊，請參閱進階資料模型管理使用案例。

最佳做法分析器

最佳做法分析器 (BPA) 是表格式編輯器的功能之一，後者是廣受 Power BI 社群採用的第三方工具。 BPA 包含一組可自訂的規則，可協助您稽核資料模型的品質、一致性和效能。

提示

若要設定 BPA，請下載 Microsoft 在 GitHub 上提供的最佳做法規則集。

首先，BPA 可偵測能夠減少效能問題的次佳設計決策，藉以協助您改善模型的一致性。 將自助資料建模者分散到組織的不同區域，會很有幫助。

BPA 也可以協助您稽核及控管資料模型。 例如，您可以確認資料模型是否包含任何資料列層級安全性 (RLS) 角色。 或者，您可以驗證是否所有模型物件都有描述。 舉例來說，當您的目標是要確保資料模型包含資料字典時，這會很有幫助。

BPA 可以公開設計問題，協助卓越中心確認是否需要更多訓練或文件。 它可以採取行動，為資料建立者指出最佳做法及提供組織指導方針。

提示

請記住，BPA 可以偵測是否有某個特性 (例如資料列層級安全性) 存在。 不過，可能難以確認是否已正確設定。 因此，主題專家可能需要進行審查。 相反地，特定特性不存在不一定表示設計不當；資料建模者在產生特定設計時可能有充分的理由。

檢查清單 - 規劃存取資料模型中繼資料時的關鍵決策和動作包括：

  • 決定誰可以安裝 SSMS：確認您是否要允許組織中的所有 Power BI 內容建立者安裝 SSMS，以便能連線至已發佈的語意模型。 決定是要應要求加以安裝，還是隨著為組織中已核准的資料建立者安裝的標準軟體集一起安裝。
  • 決定誰可以安裝第三方工具：確認您是否要允許組織中的所有 Power BI 內容建立者安裝第三方工具 (例如 DAX Studio 和表格式編輯器)，以便能監視本機資料模型和/或已發佈的語意模型。 決定是要應要求加以安裝，還是隨著為組織中已核准的資料建立者安裝的標準軟體集一起安裝。
  • 設定最佳做法規則：決定哪些最佳做法分析器規則可以掃描您組織中的資料模型。
  • 決定誰可以使用 XMLA 端點：確認是要允許所有使用者藉由使用 XMLA 端點來連線至語意模型，還是僅限於已核准的資料建立者。 設定 [允許 XMLA 端點並使用內部部署語意模型在 Excel 中分析] 租用戶設定，以因應此決策。
  • 為內容建立者提供指引：建立資料建立者的文件，讓他們了解分析語意模型的建議方式。 提供常見使用案例的指引，讓他們能更輕鬆地開始收集和分析 DMV 結果以及/或使用最佳做法分析器。

資料模型和查詢效能

Power BI Desktop 包含數個工具，可協助資料建立者對其資料模型進行疑難排解和調查。 這些功能適用於想要驗證其資料模型，並在發佈至 Power BI 服務之前進行效能微調的資料建模者。

效能分析器

使用 Power BI Desktop 中提供的效能分析器，稽核及調查資料模型的效能。 效能分析器可協助報表建立者測量個別報表元素的效能。 不過，效能問題的根本原因往往與資料模型設計有關。 因此，語意模型建立者也可能因使用效能分析器而獲益。 如果是由不同的內容建立者負責建立報表與語意模型，他們在對效能問題進行疑難排解時，可能需要共同作業。

提示

您可以使用 DAX Studio 匯入及分析效能分析器所產生的記錄檔。

如需效能分析器的詳細資訊，請參閱報表層級稽核。

查詢診斷

使用 Power BI Desktop 中提供的查詢診斷，調查 Power Query 的效能。 這在進行疑難排解時，以及您需要了解 Power Query 引擎的作用時，都可派上用場。

可從查詢診斷取得的資訊包括：

  • 與錯誤訊息相關的額外詳細資料 (例外狀況發生時)。
  • 傳送至資料來源的查詢。
  • 查詢折疊是否發生。
  • 查詢所傳回的資料列數目。
  • 資料重新整理作業期間可能發生的速度減緩。
  • 背景事件和系統產生的查詢。

根據您想要尋找的內容，您可以啟用一個或所有記錄：彙總、詳細、效能計數器，以及資料隱私權分割區。

您可以在 Power Query 編輯器中啟動工作階段診斷。 啟用後即會收集查詢和重新整理作業，直到診斷追蹤停止。 診斷停止後，資料就會直接填入查詢編輯器中。 Power Query 會建立診斷群組 (資料夾)，並在其中新增數個查詢。 然後，您可以使用標準 Power Query 功能來檢視及分析診斷資料。

或者，您可以在 Power BI Desktop 中，經由 [選項] 視窗的 [診斷] 區段啟用追蹤。 記錄檔會儲存至本機電腦的資料夾。 這些記錄檔會在您關閉 Power BI Desktop 後 (此時會停止追蹤) 填入資料。 Power BI Desktop 關閉後，您可以使用慣用的程式 (例如文本編輯器) 開啟記錄檔，加以檢視。

查詢評估和折疊

Power Query 支援多種功能以協助您了解查詢評估，包括查詢計劃。 此外也可協助您確認是要對整個查詢執行查詢折疊，還是針對查詢中的部分步驟執行。 查詢折疊是效能微調最重要的層面之一。 當您監視資料來源時，檢閱 Power Query 所傳送的原生查詢也很有幫助，本文稍後將有相關說明。

Premium 計量應用程式

進行疑難排解時，與 Power BI Premium 容量管理員共同作業可能會有幫助。 容量管理員有權存取 Power BI Premium 使用率和計量應用程式。 此應用程式可為您提供許多與容量中發生的活動有關的資訊。 該資訊可協助您對語意模型問題進行疑難排解。

提示

Premium 容量管理員可將存取權授與其他使用者 (非容量管理員)，使其能夠存取 Premium 計量應用程式。

Premium 計量應用程式包含內部語意模型和一組初始報表。 此應用程式可協助您對 Power BI Premium 容量 (P SKU) 或 Power BI Embedded (A SKU) 容量執行近乎即時的監視。 這包括過去二到四週的資料 (視計量而定)。

使用 Premium 計量應用程式對語意模型進行疑難排解和最佳化。 例如，您可以識別佔用大量記憶體，或 CPU 使用率經常偏高的語意模型。 若要尋找接近容量大小限制的語意模型，這也是很有用的工具。

檢查清單 - 考量要使用哪些方法來監視資料模型與查詢效能時的關鍵決策和動作包括：

  • 識別語意模型查詢效能目標：確定您已充分了解何謂良好的語意模型效能。 確認何時需要特定的查詢效能目標 (例如，支援報表的查詢必須在五秒內轉譯)。 在此情況下，請確實將目標傳達給組織中的資料建立者。
  • 識別語意模型重新整理效能目標：確認何時需要特定的資料重新整理目標 (例如，在早上 5 點之前，以不到 15 分鐘的時間完成資料重新整理作業)。 在此情況下，請確實將目標傳達給組織中的資料建立者。
  • 教育您的支援小組：確定您的內部使用者支援小組熟悉診斷功能，而有能力在需提供協助時支援 Power BI 使用者。
  • 聯繫支援小組和資料庫管理員：確定您的支援小組知道如何正確聯繫每個資料來源的管理員 (例如，對查詢折疊進行疑難排解時)。
  • 與 Premium 容量管理員共同作業：與您的容量管理員合作，對已指派給 Premium 容量或 Power BI Embedded 容量的工作區中包含的語意模型進行疑難排解。 適當時，可以要求存取 Premium 計量應用程式。
  • 為內容建立者提供指引：建立資料建立者的文件，讓他們了解疑難排解的具體動作。
  • 包含在訓練教材中：為資料建立者提供相關指引，指出如何建立效能良好的資料模型。 協助他們及早養成良好的設計習慣。 重點是要讓資料建立者了解如何做出良好的設計決策。

資料來源監視

有時，您必須直接監視 Power BI 連線到的特定資料來源。 例如，您可能有某個資料倉儲工作負載增加，且使用者報告效能降低。 一般而言，資料庫管理員或系統管理員會監視資料來源。

您可以監視資料來源，以執行下列作業：

  • 稽核哪些使用者正在將查詢傳送至資料來源。
  • 稽核哪些應用程式 (例如 Power BI) 正在將查詢傳送至資料來源。
  • 檢閱有哪些查詢陳述式在何時由哪些使用者傳送至資料來源。
  • 確認查詢執行所耗費的時間。
  • 稽核來源系統在使用單一登入 (SSO) 時如何叫用資料列層級安全性。

Power BI 內容建立者在分析監視結果後，可能會執行許多動作。 他們可能會：

  • 微調並精簡傳送至資料來源的查詢，使其盡可能有效率。
  • 驗證並微調傳送至資料來源的原生查詢。
  • 減少匯入資料模型中的資料行數目。
  • 移除匯入資料模型中的高精確度和高基數資料行。
  • 減少匯入至資料模型中的歷史資料量。
  • 調整 Power BI 資料重新整理時間，以利分散資料來源的需求。
  • 利用累加式資料重新整理來減輕資料來源的負載。
  • 將多個語意模型合併為共用語意模型，以減少 PowerBI 資料重新整理次數。
  • 調整自動頁面重新整理設定以提高重新整理頻率，進而減輕資料來源的負載。
  • 簡化計算，以降低查詢傳送至資料來源的複雜度。
  • 變更資料儲存模式 (例如，變更為匯入模式而非 DirectQuery)，以減輕資料來源的持續性查詢負載。
  • 使用減少查詢技術，減少傳送至資料來源的查詢數目。

系統管理員可能會執行其他動作。 他們可能會：

  • 導入中繼資料層，例如 Power BI 資料流程 (當資料倉儲不是可行的選項時)。 Power BI 內容建立者可以使用資料流程作為資料來源，而不直接連線至資料來源。 中繼資料層可以減輕來源系統的負載。 此外，還具備將資料準備邏輯集中化的附加優勢。 如需詳細資訊，請參閱自助資料準備使用案例。
  • 變更資料來源位置，以減輕網路延遲的影響 (例如，對 Power BI 服務、資料來源和閘道使用相同的資料區域)。
  • 將資料來源最佳化，使其能更有效率地擷取 Power BI 的資料。 幾種常見的技術包括建立資料表索引、建立索引檢視、建立保存的計算資料行、維護統計資料、使用記憶體內部或資料行存放區資料表，以及建立具體化檢視。
  • 指示使用者使用資料來源的唯讀複本，而不是原始生產資料庫。 複本可作為高可用性 (HA) 資料庫策略的一部分。 唯讀複本的優點之一是可減少來源系統上的爭用。

可用來監視資料來源的工具和技術，取決於技術平台。 例如，您的資料庫管理員可以使用擴充事件或查詢存放區來監視 Azure SQL Database 和 SQL Server 資料庫。

有時，Power BI 會透過資料閘道存取資料來源。 閘道可處理從 Power BI 服務到特定資料來源類型的連線。 不過，其作用不只是連線至資料。 閘道包含在機器上執行處理和資料轉換的混搭引擎。 此外也會壓縮及加密資料，使其能夠安全有效地傳輸至 Power BI 服務。 因此，非受控或非最佳化的閘道可能會造成效能瓶頸。 建議您與閘道管理員聯繫，取得監視閘道的協助。

提示

您的 Power BI 管理員可以編譯完整的租用戶清查 (包括譜系)，以及存取活動記錄中的使用者活動。 將譜系與使用者活動相互關聯，管理員即可識別最常使用的資料來源和閘道。

如需租用戶清查和活動記錄的詳細資訊，請參閱租用戶層級稽核。

檢查清單 - 規劃監視資料來源時的關鍵決策和動作包括：

  • 確認特定目標：監視資料來源時，請確實釐清您需要達成的目標，以及疑難排解的目標。
  • 與資料庫管理員共同作業：在監視特定資料來源時，請與資料庫或系統管理員合作以取得其協助。
  • 與閘道管理員共同作業：對於透過資料閘道連線的資料來源，在疑難排解時請與閘道管理員共同作業。
  • 聯繫支援小組和資料庫管理員：確定您的支援小組知道如何正確聯繫每個資料來源的管理員 (例如，對查詢折疊進行疑難排解時)。
  • 更新訓練和指引：為資料建立者納入關於如何使用組織資料來源的重要資訊和提示。 請納入在發生問題時該如何處理的相關資訊。

資料重新整理監視

資料重新整理作業牽涉到將資料從基礎資料來源匯入至 Power BI 語意模型、資料流程或資料超市。 您可以排程資料重新整理作業，或視需要加以執行。

服務等級協定

IT 人員通常會使用服務等級協定 (SLA) 來記錄對資料資產的預期。 對於 Power BI，請考慮將 SLA 用於重要內容或企業層級內容。 這通常包括使用者預期語意模型中的更新資料何時可供使用。 例如，您可以設置所有資料重新整理都必須在每天早上 7 點前完成的 SLA。

語意模型記錄

來自 Azure Log Analytics 或 SQL Profiler 的語意模型事件記錄檔 (如本文先前所述) 包含關於語意模型現況的詳細資訊。 擷取的事件包含語意模型重新整理活動。 在需要對語意模型重新整理進行疑難排解和調查時，事件記錄檔尤有效用。

Premium 容量語意模型

若您有裝載在 Power BI Premium 容量中的內容，您就有更多功能可監視資料重新整理作業。

  • 管理入口網站中的 Power BI 重新整理摘要頁面包含重新整理歷程記錄的摘要。 此摘要提供重新整理持續時間和錯誤訊息的相關資訊。
  • Power BI Premium 使用率和計量應用程式也包含實用的重新整理資訊。 在您需要調查 Power BI Premium 容量 (P SKU) 或 Power BI Embedded (A SKU) 容量的重新整理活動時，這將有其效用。

增強型語意模型重新整理

內容建立者可以搭配使用增強型重新整理與在群組中重新整理資料集 Power BI REST API，以程式設計方式起始語意模型重新整理。 使用增強型重新整理時，您可以監視歷史、目前和擱置的重新整理作業。

資料重新整理排程監視

Power BI 管理員可以監視租用戶中的資料重新整理排程，以確認在特定時間範圍內是否有許多重新整理作業排程在相同時間 (例如早上 5 點到 7 點之間，這可能是特別忙碌的資料重新整理時間)。 管理員有權從名為掃描器 API 的中繼資料掃描 API 存取語意模型重新整理排程中繼資料。

Power BI REST API

對於重要的語意模型，請勿單獨憑藉電子郵件通知來監視資料重新整理問題。 請考慮在可讓您監視、分析及處理資料重新整理歷程記錄的集中式存放區中編譯這些歷程記錄。

您可以使用下列工具擷取資料重新整理歷程記錄：

提示

強烈建議您監視語意模型的重新整理歷程記錄，以確保目前的資料可供報表和儀表板使用。 這也有助於您了解是否符合 SLA。

檢查清單 - 規劃資料重新整理監視時的關鍵決策和動作包括：

  • 確認特定目標：監視資料重新整理時，請確實釐清您需要達成的目標，以及應監視的範圍 (例如生產語意模型、經認證的語意模型等等)。
  • 考慮設定 SLA：確認 SLA 是否有助於設定資料可用性的預期，以及資料重新整理排程應於何時執行。
  • 與資料庫和閘道管理員共同作業：與您的資料庫或系統管理員和閘道管理員合作，對資料重新整理進行監視或疑難排解。
  • 支援小組的知識轉移：確定您的支援小組知道如何在發生資料重新整理問題時協助內容建立者。
  • 更新訓練和指引：為資料建立者納入關於如何對組織資料來源和常見資料來源的資料進行重新整理的重要資訊和提示。 請納入如何管理資料重新整理的最佳做法和組織喜好設定。
  • 對通知使用支援電子郵件地址：對於重要內容，請將重新整理通知設定為使用支援電子郵件地址。
  • 設定集中式重新整理監視：使用 Power BI REST API 來編譯資料重新整理歷程記錄。

資料流程監視

您可以使用 Power Query Online 來建立 Power BI 資料流程。 許多查詢效能功能以及先前所述的 Power Query 診斷均適用。

(選擇性) 您可以將工作區設定為使用 Azure Data Lake Storage Gen2 進行資料流程儲存 (名為自備儲存體)，而不使用內部儲存體。 使用自備儲存體時，請考慮啟用遙測，以便監視儲存體帳戶的計量。 如需詳細資訊，請參閱自助資料準備使用案例，以及進階資料準備使用案例。

您可以使用 Power BI REST API 來監視資料流程交易。 例如，使用取得資料流程交易 API 來檢查資料流程重新整理的狀態。

您可以使用 Power BI 活動記錄來追蹤 Power BI 資料流程的使用者活動。 如需詳細資訊，請參閱租用戶層級稽核。

提示

您可以採用許多最佳做法將資料流程設計最佳化。 如需詳細資訊，請參閱資料流程最佳做法。

資料超市監視

Power BI 資料超市包含數個整合式元件，包括資料流程、受控資料庫和語意模型。 請參閱本文的前幾節，以了解如何稽核和監視每個元件。

您可以使用 Power BI 活動記錄來追蹤 Power BI資料超市的使用者活動。 如需詳細資訊，請參閱租用戶層級稽核。

相關內容

在此系列中的下一篇文章中，了解租用戶層級稽核。