Power BI 中的 DirectQuery

  • 發行項

在 Power BI Desktop 或 Power BI 服務 中，您可以透過不同的方式連線到許多不同的數據源。 您可以將 數據匯 入 Power BI，這是取得資料最常見的方式。 您也可以直接連線到原始來源存放庫中的一些數據，稱為 DirectQuery。 本文主要討論 DirectQuery 功能。

本文章說明：

  • 不同的Power BI資料連線選項。
  • 關於何時使用 DirectQuery 而不是匯入的指引。
  • 使用 DirectQuery 的限制和影響。
  • 建議，以順利使用 DirectQuery。
  • 如何診斷 DirectQuery 效能問題。

本文著重於在 Power BI Desktop 中建立報表時的 DirectQuery 工作流程，但也涵蓋透過 Power BI 服務 中的 DirectQuery 連線。

注意

DirectQuery 也是 SQL Server Analysis Services 的功能。 此功能與 Power BI 中的 Direct Query 共用許多詳細數據，但也有重要的差異。 本文主要涵蓋 Power BI 的 DirectQuery，而非 SQL Server Analysis Services。

如需搭配 SQL Server Analysis Services 使用 DirectQuery 的詳細資訊，請參閱使用適用於 Power BI 語意模型和 Analysis Services 的 DirectQuery （預覽版）。 您也可以下載 SQL Server 2016 Analysis Services 中的 PDF DirectQuery。

Power BI 數據連線模式

Power BI 會連線到大量的不同數據源，例如：

  • Salesforce 和 Dynamics 365 等在線服務。
  • SQL Server、Access 和 Amazon Redshift 等資料庫。
  • Excel、JSON 和其他格式的簡單檔案。
  • Spark、網站和 Microsoft Exchange 等其他數據源。

您可以將來自這些來源的數據匯入 Power BI。 針對某些來源，您也可以使用 DirectQuery 進行連線。 如需支援 DirectQuery 的來源摘要，請參閱 DirectQuery 支持的數據源。 已啟用 DirectQuery 的來源主要是可提供良好互動式查詢效能的來源。

您應該盡可能將數據匯入 Power BI。 匯入會利用Power BI的高效能查詢引擎，並提供高度互動式、功能完整的體驗。

如果匯入數據無法達到目標，例如，如果數據經常變更，而且報表必須反映最新的數據，請考慮使用 DirectQuery。 只有在基礎數據源在一般匯總查詢的不到五秒內才能提供互動式查詢結果，而且可以處理產生的查詢負載時，DirectQuery 才可行。 請仔細考慮使用 DirectQuery 的限制和含意。

Power BI 匯入和 DirectQuery 功能會隨著時間而演進。 使用匯入數據時提供更多彈性的變更可讓您更頻繁地匯入，並消除使用 DirectQuery 的一些缺點。 無論改善為何，基礎數據源的效能在使用 DirectQuery 時都是一個主要考慮。 如果基礎數據源速度緩慢，則使用該來源的 DirectQuery 仍然無法執行。

下列各節涵蓋連線至數據的三個選項：匯入、DirectQuery 和即時連線。 本文的其餘部分著重於 DirectQuery。

匯入連線

當您連線到 SQL Server 之類的數據源，並在 Power BI Desktop 中匯入數據時，會發生下列結果：

  • 當您一開始 取得資料時，您選取的每個資料表集都會定義會傳回一組數據的查詢。 您可以在載入資料之前編輯這些查詢，例如套用篩選、匯總數據或聯結不同的數據表。

  • 載入時，查詢所定義的所有數據都會匯入 Power BI 快取。

  • 在 Power BI Desktop 中建置視覺效果會查詢快取的數據。 Power BI 存放區可確保查詢快速，而且視覺效果的所有變更都會立即反映。

  • 視覺效果不會反映數據存放區中基礎數據的變更。 您必須重新匯入以重新整理數據。

  • 將報表發行至 Power BI 服務 做為 .pbix 檔案，會建立並上傳包含匯入數據的語意模型。 然後，您可以排程數據重新整理，例如每天重新匯入數據。 視原始數據源的位置而定，可能需要設定內部部署數據閘道以進行重新整理。

  • 在 Power BI 服務 開啟現有的報表或撰寫新報表，再次查詢匯入的數據，以確保互動。

  • 您可以將視覺效果或整個報表頁面釘選為 Power BI 服務 中的儀錶板磚。 每當基礎語意模型重新整理時，圖格就會自動重新整理。

DirectQuery 連線

當您使用 DirectQuery 連線到 Power BI Desktop 中的數據源時，會發生下列結果：

  • 您可以使用 [取得數據 ] 來選取來源。 對於關係型來源，您仍然可以選取一組數據表，以邏輯方式傳回一組數據的查詢。 針對 SAP Business Warehouse （SAP BW） 等多維度來源，您只選取來源。

  • 載入時，不會將數據匯入 Power BI 存放區。 相反地，當您建置視覺效果時，Power BI Desktop 會將查詢傳送至基礎數據源以擷取必要的數據。 重新整理視覺效果所需時間取決於基礎資料來源的效能。

  • 基礎數據的任何變更都不會立即反映在現有的視覺效果中。 仍然需要重新整理。 Power BI Desktop 會針對每個視覺效果重新傳送必要的查詢，並視需要更新視覺效果。

  • 將報表發行至 Power BI 服務 會建立並上傳語意模型，與匯入相同。 不過，該語意模型未包含任何數據。

  • 在 Power BI 服務 中開啟現有的報表或撰寫新報表，會查詢基礎數據源以擷取必要的數據。 視原始數據源的位置而定，可能需要設定內部部署數據閘道以取得數據。

  • 您可以將視覺效果或整個報表頁面釘選為儀錶板磚。 為了確保開啟儀錶板的速度很快，圖格會依排程自動重新整理，例如每小時。 您可以根據數據變更的頻率和查看最新數據的重要性，來控制重新整理頻率。

  • 當您開啟儀錶板時，圖格會在上次重新整理時反映數據，不一定是對基礎來源所做的最新變更。 您可以重新整理開啟的儀錶板，以確保其為最新狀態。

即時連線

當您連線到 SQL Server Analysis Services 時，您可以選擇匯入數據，或使用 與所選數據模型的即時連線 。 使用即時連線類似於 DirectQuery。 不會匯入任何數據，而且會查詢基礎數據源以重新整理視覺效果。

例如，當您使用 import 連接到 SQL Server Analysis Services 時，您可以針對外部 SQL Server Analysis Services 來源定義查詢，然後匯入數據。 如果您即時連線，則不會定義查詢，而且整個外部模型會顯示在欄位清單中。

當您連線到下列來源時，也適用這種情況，但沒有匯入數據的選項：

  • Power BI 語意模型，例如連接到已發行至服務的 Power BI 語意模型，以撰寫新的報表。

  • Microsoft Dataverse。

當您發佈使用即時連線的 SQL Server Analysis Services 報表時，Power BI 服務 的行為會以下列方式類似於 DirectQuery 報表：

  • 在 Power BI 服務 開啟現有的報表或撰寫新報表，會查詢基礎 SQL Server Analysis Services 來源，可能需要內部部署數據網關。

  • 儀錶板磚會依排程自動重新整理，例如每小時。

即時連線也有數種方式與 DirectQuery 不同。 例如，即時連線一律會將開啟報表的使用者身分識別傳遞至基礎 SQL Server Analysis Services 來源。

DirectQuery 使用案例

使用 DirectQuery 進行 連線 在下列案例中很有用。 在這些案例中，將數據留在其原始來源位置是必要或有益的。

Power BI 中的 DirectQuery 提供下列案例中最大的優點：

  • 數據經常變更，而且您需要近乎實時的報告。
  • 您必須處理大型數據，而不需要預先匯總。
  • 基礎來源會定義並套用安全性規則。
  • 適用數據主權限制。
  • 來源是包含量值的多維度來源，例如 SAP BW。

數據經常變更，而且您需要近乎實時的報告

您可以使用Power BI Pro或Power BI 進階版 訂用帳戶，每小時最多重新整理一次匯入數據的模型。 如果數據持續變更，而且報表必須顯示最新的數據，則使用匯入與排程重新整理可能無法符合您的需求。 雖然此案例支持的數據磁碟區有限制，但您可以直接將數據串流至 Power BI。

使用 DirectQuery 表示開啟或重新整理報表或儀錶板一律會顯示來源中的最新數據。 儀錶板磚也可以更頻繁地更新，每 15 分鐘一次。

數據非常大

如果數據非常大，則匯入所有數據都不可行。 DirectQuery 不需要大量的數據傳輸，因為它會就地查詢數據。 不過，大型數據也可能使針對該基礎來源的查詢效能太慢。

您不一定必須匯入完整的詳細數據。 Power Query 編輯器 可讓您輕鬆地在匯入期間預先匯總數據。 在技術上，您可以完全匯入每個視覺效果所需的匯總數據。 雖然 DirectQuery 是大型數據的最簡單的方法，但如果基礎數據源對 DirectQuery 而言太慢，匯入匯總數據可能會提供解決方案。

這些詳細數據與單獨使用Power BI有關。 如需在Power BI 中使用大型模型的詳細資訊，請參閱Power BI中的大型語意模型 進階版。 數據重新整理的頻率沒有限制。

基礎來源會定義安全性規則

當您匯入數據時，Power BI 會使用目前使用者的 Power BI Desktop 認證，或從 Power BI 服務 排程重新整理所設定的認證，連接到數據源。 在發佈和共用已匯入數據的報表時，您必須小心只與允許查看數據的用戶共用，或者您必須將數據列層級安全性定義為語意模型的一部分。

DirectQuery 可讓報表查看器的認證傳遞至基礎來源，以套用安全性規則。 DirectQuery 支援對 Azure SQL 數據源的單一登錄，以及透過數據網關聯機至內部部署 SQL 伺服器。 如需詳細資訊，請參閱 Power BI 中閘道的單一登錄 （SSO） 概觀。

適用數據主權限制

某些組織有數據主權原則，這表示數據無法離開組織內部部署。 此數據會根據數據匯入提供解決方案的問題。 使用 DirectQuery，數據會保留在基礎來源位置。 不過，即使使用 DirectQuery，Power BI 服務 仍會保留視覺效果層級的數據快取，因為已排程重新整理磚。

基礎數據源會使用量值

SAP HANA 或 SAP BW 等基礎數據源包含 量值。 量值表示匯入的數據已經處於特定匯總層級，如查詢所定義。 要求較高層級匯總數據的視覺效果，例如 TotalSales by Year，會進一步匯總匯總值。 此匯總適用於加法量值，例如 Sum 和 Min，但可能是非加法量值的問題，例如 Average 和 DistinctCount。

輕鬆地從來源直接取得視覺效果所需的正確匯總數據，需要傳送每個視覺效果的查詢，如同 DirectQuery。 當您連線到 SAP BW 時，選擇 DirectQuery 會允許此量值處理。 如需詳細資訊，請參閱 DirectQuery 和 SAP BW。

目前，透過 SAP HANA 的 DirectQuery 會將數據視為與關係型來源相同，併產生類似匯入的行為。 如需詳細資訊，請參閱 DirectQuery 和 SAP HANA。

DirectQuery 限制

使用 DirectQuery 有一些潛在的負面影響。 其中一些限制會根據您使用的確切來源而稍有不同。 下列各節列出使用 DirectQuery 的一般影響，以及與效能、安全性、轉換、模型化和報告相關的限制。

一般含意

使用 DirectQuery 的一些一般含意和限制如下：

  • 如果數據變更，您必須重新整理以顯示最新的數據。 假設使用快取，不保證視覺效果一律會顯示最新的數據。 例如，視覺效果可能會顯示過去一天的交易。 交叉分析篩選器變更可能會重新整理視覺效果，以顯示過去兩天的交易，包括最近抵達的交易。 但是，將交叉分析篩選器傳回其原始值可能會再次顯示快取的先前值。 選取 [ 重新 整理] 以清除任何快取，並重新整理頁面上的所有視覺效果以顯示最新的數據。

  • 如果數據變更，則無法保證視覺效果之間的一致性。 不同的視覺效果，無論是在同一個頁面或不同的頁面上，都可以在不同的時間重新整理。 如果基礎來源中的數據正在變更，則不保證每個視覺效果都會在同一時間點顯示數據。

    假設單一視覺效果可能需要多個查詢，例如，若要取得詳細數據和總計，甚至不保證單一視覺效果內的一致性。 若要保證此一致性，每當任何視覺效果重新整理時，都需要重新整理所有視覺效果的額外負荷，以及使用基礎數據源中快照隔離等成本高昂的功能。

    您可以選取 [重新 整理] 來重新整理頁面上的所有視覺效果，以大幅減輕此問題。 即使是匯入模式，當您從多個數據表匯入數據時，維護一致性也有類似的問題。

  • 您必須在Power BI Desktop 中重新整理，以反映架構變更。 發行報表之後，重新整理 Power BI 服務 會重新整理報表中的視覺效果。 但是，如果基礎來源架構變更，則 Power BI 服務 不會自動更新可用的欄位清單。 如果數據表或數據行已從基礎來源移除，重新整理時可能會導致查詢失敗。 若要更新模型中的欄位以反映變更，您必須在 Power BI Desktop 中開啟報表，然後選擇 [ 重新整理]。

  • 任何查詢上可以傳回 1 百萬個數據列的限制。 固定限制為1百萬個數據列，可在任何單一查詢中傳回至基礎來源。 此限制通常沒有實際的影響，而且視覺效果不會顯示那麼多點。 不過，在Power BI 未完全優化傳送的查詢，並要求超過限制的一些中繼結果時，可能會發生此限制。

    建置視覺效果時，也會在路徑上建立更合理的最終狀態時發生此限制。 例如，如果客戶超過 100 萬個客戶，包括 Customer 和 TotalSalesQuantity 可能會達到此限制，直到您套用一些篩選。 傳回的錯誤是： 對外部數據源的查詢結果集已超過允許的大小上限 '1000000' 個數據列。

    注意

    進階版 容量可讓您超過一百萬個數據列限制。 如需詳細資訊，請參閱 中繼數據列集計數上限。

  • 您無法將模型從匯入變更為 DirectQuery 模式。 如果您匯入所有必要的數據，可以將模型從 DirectQuery 模式切換為匯入模式。 無法切換回 DirectQuery 模式，主要是因為 DirectQuery 模式不支援的功能集。 對於 SAP BW 等多維度來源，由於外部量值的不同處理，您無法從 DirectQuery 切換至匯入模式。

效能和負載影響

當您使用 DirectQuery 時，整體體驗取決於基礎數據源的效能。 如果重新整理每個視覺效果，例如在變更交叉分析篩選器值之後，需要不到五秒的時間，則體驗是合理的，雖然相較於匯入數據的立即回應，可能會感到緩慢。 如果來源緩慢導致個別視覺效果需要數十秒的時間重新整理，體驗就會變得不合理。 查詢甚至可能會逾時。

除了基礎來源的效能，放置於來源上的負載也會影響效能。 每位開啟共享報表的使用者，以及重新整理的每個儀錶板磚，都會將每個視覺效果至少一個查詢傳送至基礎來源。 來源必須能夠處理這類查詢負載，同時維持合理的效能。

安全性含意

除非基礎數據源使用 SSO，否則 DirectQuery 報表一律會使用相同的固定認證，在發行至 Power BI 服務 之後連接到來源。 發佈 DirectQuery 報表之後，您必須設定要使用的用戶認證。 在您設定認證之前，嘗試在 Power BI 服務 中開啟報表會導致錯誤。

提供使用者認證之後，Power BI 會針對開啟報表的人員使用這些認證，與匯入的數據相同。 除非數據列層級安全性定義為報表的一部分，否則每個用戶都會看到相同的數據。 即使基礎來源中定義了安全性規則，您也必須同樣注意共用報表與匯入的數據相同。

  • 連線 DirectQuery 模式中的 Power BI 語意模型和 Analysis Services 一律會使用 SSO，因此安全性類似於 Analysis Services 的即時連線。

  • 從 Power BI Desktop 連線到 SQL Server 時，不支援替代認證。 您可以使用目前的 Windows 認證或資料庫認證。

  • 您可以使用複合模型，在 DirectQuery 模型中使用多個數據源。 當您使用多個數據源時，請務必瞭解 基礎數據源之間數據來回移動的安全性影響 。

數據轉換限制

DirectQuery 會限制您可以在 Power Query 編輯器 內套用的數據轉換。 透過匯入的數據，您可以輕鬆地套用一組複雜的轉換，以清除和重塑數據，再使用它來建立視覺效果。 例如，您可以剖析 JSON 檔，或將數據從數據行樞紐至數據列表單。 DirectQuery 中的這些轉換會更加有限。

當您連線到 SAP BW 之類的線上分析處理 （OLAP） 來源時，您無法定義任何轉換，而且整個外部模型都是取自來源。 對於 SQL Server 之類的關係型來源，您仍然可以為每個查詢定義一組轉換，但這些轉換會因為效能原因而受到限制。

任何轉換都必須在每個查詢上套用至基礎來源，而不是在數據重新整理時套用一次。 轉換必須能夠合理地轉譯成單一原生查詢。 如果您使用太複雜的轉換，您會收到錯誤，指出必須刪除該轉換，或聯機模型已切換為匯入。

此外，[取得數據] 對話框或 Power Query 編輯器 會在產生並傳送的查詢中使用子選取專案，以擷取視覺效果的數據。 Power Query 編輯器 中定義的查詢在此內容中必須有效。 特別是，您無法搭配通用數據表運算式使用查詢，也無法使用叫用預存程序的查詢。

模型限制

此內容中的模型化一詞表示使用數據撰寫報表時，精簡和擴充原始數據的行為。 模型化的範例包括：

  • 定義數據表之間的關聯性。
  • 加入新的計算，例如計算結果列和量值。
  • 重新命名和隱藏數據行和量值。
  • 定義階層。
  • 定義數據行格式設定、預設摘要和排序順序。
  • 群組或叢集值。

當您使用 DirectQuery 時，您仍然可以進行其中許多模型擴充，並使用擴充原始數據的原則來改善稍後的耗用量。 不過，某些模型化功能無法使用或受限於 DirectQuery。 套用限制以避免效能問題。

下列限制適用於所有 DirectQuery 來源。 更多限制可能會套用至個別來源。

  • 沒有內建日期階層： 使用匯入的數據，每個 date/datetime 數據行預設也會有內建的日期階層。 例如，如果您匯入包含 OrderDate 數據行的銷售訂單數據表，並在視覺效果中使用 OrderDate，則可以選擇要使用的適當日期層級，例如年、月或日。 DirectQuery 不提供此內建日期階層。 如果基礎來源中有 Date 數據表，如同許多數據倉儲中常見的一樣，您可以使用數據分析表示式 （DAX） 時間智慧函式。

  • 日期/時間僅支援秒層級： 對於使用時間數據行的語意模型，Power BI 只會對基礎 DirectQuery 來源發出查詢，直到秒詳細數據層級，而不是毫秒。 從源數據行中移除毫秒數據。

  • 匯出數據行的限制： 匯出數據行只能是內部數據列，也就是說，它們只能參考相同數據表的其他數據行值，而不使用任何聚合函數。 此外，允許的 DAX 純量函式，例如 LEFT()，僅限於可推送至基礎來源的函式。 函式會根據來源的確切功能而有所不同。 在撰寫匯出數據行的DAX查詢時，不支援的函式不會列在自動完成中，而且在使用時會產生錯誤。

  • 不支援父子式 DAX 函式： 在 DirectQuery 模式中時，無法使用通常處理父子式結構的函式系列 DAX PATH() ，例如帳戶圖表或員工階層。

  • 無叢集： 當您使用 DirectQuery 時，無法使用叢集功能自動尋找群組。

報告限制

DirectQuery 模型支持幾乎所有的報告功能。 只要基礎來源提供適當的效能層級，您就可以使用與匯入數據相同的視覺效果集。

一般限制是 DirectQuery 語意模型中文字數據行中的數據長度上限為 32,764 個字元。 報告較長的文字會導致錯誤。

下列 Power BI 報告功能可能會導致 DirectQuery 型報表中的效能問題：

  • 量值篩選： 使用量值或數據行匯總的視覺效果可以包含這些量值中的篩選。 例如，下圖顯示依類別的 SalesAmount，但僅適用於銷售量超過 2000 萬的類別。

    Screenshot showing showing measures that contain filters

    此方法會導致兩個查詢傳送至基礎來源：

    • 第一個查詢會擷取符合 SalesAmount 大於 2000 萬條件的類別。
    • 第二個查詢會擷取視覺效果的必要數據，其中包含符合條件的 WHERE 類別。

    如果有數百或數千個類別，這個方法通常運作良好，如此範例所示。 如果類別數目較大，效能可能會降低。 如果有超過一百萬個類別，查詢就會失敗。

  • TopN 篩選： 您可以定義進階篩選，只篩選某些量值所排名的頂端或底端 N 值。 例如，篩選可以包含前10個類別。 此方法會再次將兩個查詢傳送至基礎來源。 不過，第一個查詢會從基礎來源傳回所有類別，然後 TopN 根據傳回的結果來決定 。 根據所涉及的數據行基數，這種方法可能會導致效能問題或查詢失敗，因為查詢結果有一百萬個數據列限制。

  • 中位數： 任何匯總，例如 Sum 或 Count Distinct，會推送至基礎來源。 不過，基礎來源通常 median 不支持匯總。 針對 median，會從基礎來源擷取詳細數據，並從傳回的結果計算中位數。 這個方法很合理，可計算在相對較少的結果中位數。

    如果基數很大，因為一百萬個數據列限制，可能會發生效能問題或查詢失敗。 例如，查詢 國家/地區人口 中位數可能是合理的，但 銷售價格 中位數可能不合理。

  • 進階文字篩選，例如 'contains'：文字數據行的進階篩選允許和 begins with等contains篩選。 這些篩選可能會導致某些數據源的效能降低。 特別是，如果您需要完全相符，請勿使用默認 contains 篩選條件。 雖然結果可能會根據實際數據而相同，但效能可能會因為索引而大不相同。

  • 多重選取交叉分析篩選器： 根據預設，交叉分析篩選器只允許進行單一選取。 在篩選中允許多重選取可能會導致效能問題。 例如，如果用戶選取 10 個感興趣的產品，則每個新選取專案會導致查詢傳送至來源。 雖然使用者可以在查詢完成之前選取下一個專案，但此方法會導致基礎來源的額外負載。

  • 數據表視覺效果的總計： 根據預設，數據表和矩陣會顯示總計和小計。 在許多情況下，取得這類總計的值需要將個別的查詢傳送至基礎來源。 當您使用 DistinctCount 匯總時，或所有使用 DirectQuery over SAP BW 或 SAP HANA 的情況，都會套用此需求。 您可以使用 [ 格式 ] 窗格來關閉這類總計。

DirectQuery 建議

本節提供如何成功使用 DirectQuery 的高階指引，因為其含意。

基礎數據源效能

驗證簡單的視覺效果會在五秒內重新整理，以提供合理的互動式體驗。 如果視覺效果需要超過 30 秒才能重新整理，則報表發行之後的進一步問題可能會使解決方案無法運作。

如果查詢速度緩慢，請檢查傳送至基礎來源的查詢，以及效能緩慢的原因。 如需詳細資訊，請參閱 效能診斷。

本文未涵蓋整個潛在基礎來源集合的各種資料庫優化建議。 下列標準資料庫做法適用於大部分情況：

  • 為了提升效能，請根據整數數據行建立關聯性，而不是聯結其他數據類型的數據行。

  • 建立適當的索引。 索引建立通常表示在支援索引的來源中使用數據行存放區索引，例如 SQL Server。

  • 更新來源中的任何必要統計數據。

模型設計

當您定義模型時，請遵循下列指引：

  • 避免 Power Query 編輯器 中的複雜查詢。 Power Query 編輯器 會將複雜的查詢轉譯成單一 SQL 查詢。 單一查詢會出現在傳送至該數據表之每個查詢的子選擇中。 如果該查詢很複雜，可能會導致每個傳送的查詢發生效能問題。 您可以以滑鼠右鍵按兩下 Power Query 編輯器 中 [套用的步驟] 底下的最後一個步驟，然後選擇 [檢視原生查詢]，以取得一組步驟的實際 SQL 查詢。

  • 讓量值保持簡單。 至少一開始，將量值限製為簡單的匯總。 如果量值以令人滿意的方式運作，您可以定義更複雜的量值，但請注意效能。

  • 避免計算結果列的關聯性。 在需要執行多數據行聯結的資料庫中，Power BI 不允許將多個數據行的關聯性作為主鍵或外鍵。 常見的因應措施是使用匯出數據行串連數據行，並以該數據行的聯結為基礎。

    此因應措施適用於匯入的數據，但對於 DirectQuery，它會在表達式上產生聯結。 該結果通常會防止使用任何索引，並導致效能不佳。 唯一的因應措施是實際將多個數據行具體化為基礎數據源中的單一數據行。

  • 避免在 『uniqueidentifier』 資料行上建立關聯性。 Power BI 原生不支持 uniqueidentifier 數據類型。 定義數據行之間的 uniqueidentifier 關聯性會導致查詢與包含轉換的聯結。 同樣地，這種方法通常會導致效能不佳。 唯一的因應措施是具體化基礎數據源中替代類型的數據行。

  • 隱藏關聯性的 『to』 資料行。 關聯性上的數據 to 行通常是數據表的主 to 鍵。 該數據行應該隱藏，但如果隱藏，它就不會出現在欄位清單中，而且無法在視覺效果中使用。 關聯性所依據的數據行通常是 系統數據行，例如數據倉儲中的 Surrogate 索引鍵。 最好隱藏這類數據行。

    如果數據行具有意義，請引進可見的導出數據行，且其表達式等於主鍵，例如：

        ProductKey_PK   (Destination of a relationship, hidden)
    ProductKey (= [ProductKey_PK],   visible)
    ProductName
    ...

  • 檢查所有計算結果列和數據類型變更。 當您搭配 複合模型使用 DirectQuery 時，可以使用匯出數據表。 這些功能不一定有害，但它們會產生包含表達式的查詢，而不是簡單的數據行參考。 這些查詢可能會導致索引未使用。

  • 避免雙向交叉篩選關聯性。 使用雙向交叉篩選可能會導致查詢語句效能不佳。 如需雙向交叉篩選的詳細資訊，請參閱 在Power BI Desktop中為 DirectQuery 啟用雙向交叉篩選，或下載 雙向交叉篩選 白皮書。 本文中的範例適用於 SQL Server Analysis Services，但基本點也適用於 Power BI。

  • 實驗設定 假設引用完整性。 [ 假設關聯性完整性 ] 設定可讓查詢使用 INNER JOIN 而非 OUTER JOIN 語句。 本指南通常可改善查詢效能，不過這取決於數據源的特定數據。

  • 請勿在 Power Query 編輯器 中使用相對數據篩選。 可以在 Power Query 編輯器 中定義相對日期篩選。 例如，您可以篩選到日期在過去 14 天內的數據列。

    Screenshot that shows filtering rows for the last 14 days.

    不過，此篩選會根據固定日期轉譯成篩選，例如查詢的撰寫時間，如原生查詢中所見。

    Screenshot that shows filtering rows in a native SQL query.

    此資料可能不是您想要的數據。 若要確保篩選是根據報表執行時的日期套用，請套用報表中的日期篩選。 您可以建立計算結果列，以使用 DAX DATE() 函式計算天數，並在篩選中使用該計算結果列。

報表設計

當您建立使用 DirectQuery 連線的報表時，請遵循下列指引：

  • 請考慮使用減少查詢選項： Power BI 提供報表選項來傳送較少的查詢，並停用在產生的查詢需要很長的時間執行時，導致體驗不佳的特定互動。 當您在Power BI Desktop 中與報表互動時，這些選項也適用於用戶取用 Power BI 服務中的報表時。

    若要在 Power BI Desktop 中存取這些選項，請移至 [檔案>選項和設定選項]>，然後選取 [減少查詢]。

    Screenshot that shows Query reduction options.

    [ 查詢縮減 ] 畫面上的選取專案可讓您顯示交叉分析篩選器或篩選選取專案的 [ 套用 ] 按鈕。 在您選取篩選或交叉分析篩選器上的 [ 套用 ] 按鈕之前，不會傳送任何查詢。 然後，查詢會使用您的選取專案來篩選數據。 此按鈕可讓您在套用交叉分析篩選器之前，先進行數個交叉分析篩選器和篩選選項。

  • 先套用篩選： 一律在建置視覺效果開始時套用任何適用的篩選。 例如，不要拖曳 TotalSalesAmount 和 ProductName，然後篩選至特定年份，而是在開頭套用 Year 的篩選條件。

    建置視覺效果的每個步驟都會傳送查詢。 雖然在第一個查詢完成之前可能會進行另一個變更，但此方法仍會在基礎來源上留下不必要的負載。 早期套用篩選通常會讓中繼查詢成本較低。 若未能提早套用篩選，可能會導致達到100萬個數據列限制。

  • 限制頁面上的視覺效果數目： 當您開啟頁面或變更頁面層級交叉分析篩選器或篩選時，頁面上的所有視覺效果都會重新整理。 平行查詢的數目有限制。 隨著視覺效果數目增加，某些視覺效果會以序列方式重新整理，這會增加重新整理頁面所需的時間。 因此，最好限制單一頁面上的視覺效果數目，並改為擁有更多更簡單的頁面。

  • 請考慮關閉視覺效果之間的互動： 根據預設，報表頁面上的視覺效果可用來交叉篩選和交叉醒目提示頁面上的其他視覺效果。 例如，如果您在餅圖上選取 1999，柱形圖會交叉醒目提示以顯示 1999 年類別的銷售。

    Screenshot that shows multiple visuals with cross-filtering and cross-highlighting.

    DirectQuery 中的交叉篩選和交叉醒目提示需要將查詢提交至基礎來源。 如果回應使用者選取專案所花費的時間不合理，您應該關閉此互動。

    您可以使用 [查詢縮減 ] 設定來停用整個報表的交叉醒目提示，或逐一案例。 如需詳細資訊，請參閱 視覺效果如何在Power BI報表中互相交叉篩選。

聯機數目上限

您可以設定每個基礎數據源開啟的 DirectQuery 連線數目上限，以控制同時傳送至每個數據源的查詢數目。

DirectQuery 會開啟預設的最大 10 個並行連線數目。 若要變更 Power BI Desktop 中目前檔案的最大數目，請移至 [檔案>選項] 和 [設定>][選項]，然後在左窗格的 [目前檔案] 區段中選取 [DirectQuery]。

Screenshot that shows setting maximum DirectQuery connections.

只有在目前報表中至少有一個 DirectQuery 來源時，才會啟用此設定。 值會套用至所有 DirectQuery 來源，以及新增至該報表的任何新 DirectQuery 來源。

增加 每個數據源 的連線數目上限可傳送更多查詢，最多傳送至基礎數據源的最大數目。 當許多視覺效果位於單一頁面上，或許多用戶同時存取報表時，此方法很有用。 達到連線數目上限后，進一步的查詢會排入佇列，直到聯機變成可用為止。 較高的限制會導致基礎來源的負載增加，因此不保證設定可改善整體效能。

將報表發佈至 Power BI 服務 之後，並行查詢數目上限也會取決於發佈報表的目標環境所設定的固定限制。 Power BI、Power BI 進階版 和 Power BI 報表伺服器 會施加不同的限制。 下表列出每個 Power BI 環境每個數據源的作用中連線上限。 這些限制適用於雲端數據源和內部部署數據源，例如 SQL Server、Oracle 和 Teradata。

Environment 每個數據源的上限
Power BI Pro 10 個使用中聯機
Power BI Premium 取決於 語意模型 SKU 限制
Power BI 報表伺服器 10 個使用中聯機

注意

當您啟用 增強型元數據時，DirectQuery 連線設定的最大數目會套用至所有 DirectQuery 來源，這是 Power BI Desktop 中建立之所有模型的預設設定。

Power BI 服務 中的 DirectQuery

Power BI Desktop 支援所有 DirectQuery 數據源，某些來源也可直接從 Power BI 服務 內取得。 例如，企業使用者可以使用Power BI連線到Salesforce 中的數據，並立即取得儀錶板，而不使用Power BI Desktop。

只有下列兩個已啟用 DirectQuery 的來源可以直接在 Power BI 服務 中使用：

  • Spark
  • Azure Synapse Analytics （先前稱為 SQL 數據倉儲）

即使是這兩個來源，還是最好在Power BI Desktop內啟動 DirectQuery 使用。 雖然一開始在 Power BI 服務 中建立連接很容易，但進一步增強產生的報告有一定限制。 例如，在服務中，您無法建立任何計算，或使用許多分析功能，或重新整理元數據以反映基礎架構的變更。

Power BI 服務 中 DirectQuery 報表的效能取決於基礎數據源上放置的負載程度。 負載取決於：

  • 共用報表和儀錶板的用戶數目。
  • 報表的複雜度。
  • 報表是否定義數據列層級安全性。

Power BI 服務 中的報表行為

當您在 Power BI 服務 中開啟報表時，目前可見頁面重新整理的所有視覺效果。 每個視覺效果至少需要一個基礎數據源的查詢。 某些視覺效果可能需要一個以上的查詢。 例如，視覺效果可能會顯示來自兩個不同事實數據表的匯總值，或包含更複雜的量值，或包含 Count Distinct 之類的非加總量值總計。 移至新頁面會重新整理這些視覺效果。 重新整理會將一組新的查詢傳送至基礎來源。

報表上的每個用戶互動可能會導致視覺效果重新整理。 例如，在交叉分析篩選器上選取不同的值需要傳送一組新的查詢來重新整理所有受影響的視覺效果。 選取視覺效果以交叉醒目提示其他視覺效果，或變更篩選條件也是如此。 同樣地，建立或編輯報表需要針對路徑上每個步驟傳送查詢，才能產生最終視覺效果。

結果有一些快取。 如果最近取得完全相同的結果，視覺效果的重新整理就會立即完成。 如果已定義數據列層級安全性，則不會跨使用者共用這些快取。

使用 DirectQuery 會對 Power BI 服務 針對已發行報表提供的某些功能施加一些重要的限制：

  • 不支援快速深入解析： Power BI 快速深入解析會搜尋語意模型的不同子集，同時套用一組複雜的演算法來探索潛在的有趣見解。 因為快速深入解析需要高效能查詢，因此使用 DirectQuery 的語意模型無法使用此功能。

  • 使用 [在 Excel 中探索] 會導致效能不佳： 您可以使用 [在 Excel 中探索] 功能來探索語意模型 ，這可讓您在 Excel 中建立數據透視表和數據透視表。 此功能支援使用 DirectQuery 的語意模型，但效能比在 Power BI 中建立視覺效果慢。 如果您的案例使用 Excel 很重要，請在決定是否使用 DirectQuery 時考慮此問題。

  • Excel 不會顯示階層： 例如，當您使用 [在 Excel 中進行分析] 時，Excel 不會顯示使用 DirectQuery 的 Azure Analysis Services 模型或 Power BI 語意模型中定義的任何階層。

儀錶板重新整理

在 Power BI 服務 中，您可以將個別視覺效果或整個頁面釘選到儀錶板作為磚。 以 DirectQuery 語意模型為基礎的磚會自動重新整理，方法是依排程將查詢傳送至基礎數據源。 根據預設，語意模型每小時重新整理一次，但您可以將每周和每 15 分鐘重新整理設定為語意模型設定的一部分。

如果模型中未定義任何數據列層級安全性，則會重新整理每個磚一次，而且結果會跨所有用戶共用。 如果您使用數據列層級安全性，則每個磚都需要將每個使用者的個別查詢傳送至基礎來源。

可能會有較大的乘數效果。 具有10個磚的儀錶板，與100位用戶共用，使用具有數據列層級安全性的 DirectQuery 在語意模型上建立，每次重新整理時，至少有1000個查詢會傳送至基礎數據源。 請仔細考慮使用數據列層級安全性和重新整理排程的設定。

查詢逾時

逾時 4 分鐘適用於 Power BI 服務 中的個別查詢。 花費超過四分鐘的查詢會失敗。 此限制旨在防止執行時間過長所造成的問題。 您應該只針對可以提供互動式查詢效能的來源使用 DirectQuery。

效能診斷

本節說明如何診斷效能問題，或如何取得更詳細的信息來優化報表。

開始診斷 Power BI Desktop 中的效能問題，而不是在 Power BI 服務 中。 效能問題通常是以基礎來源的效能為基礎。 您可以在更隔離的 Power BI Desktop 環境中更輕鬆地識別和診斷問題。

此方法一開始會排除某些元件，例如 Power BI 閘道。 如果 Power BI Desktop 中未發生效能問題，您可以調查 Power BI 服務 中報表的詳細數據。

Power BI Desktop 效能分析器 是用來識別問題的實用工具。 嘗試將任何問題隔離到一個視覺效果，而不是頁面上的許多視覺效果。 如果 Power BI Desktop 頁面上的單一視覺效果緩慢，請使用 效能分析器 來分析 Power BI Desktop 傳送至基礎來源的查詢。

您也可以檢視某些基礎數據源發出的追蹤和診斷資訊。 即使來源沒有追蹤，追蹤檔案也可能包含查詢執行方式的實用詳細數據，以及如何加以改善。 您可以使用下列程式來檢視 Power BI 傳送的查詢及其運行時間。

使用 SQL Server Profiler 查看查詢

根據預設，Power BI Desktop 會將事件記錄在指定的會話期間，記錄到名為 FlightRecorderCurrent.trc 的追蹤檔案。 追蹤檔案位於目前使用者的Power BI Desktop 資料夾中，位於名為 AnalysisServicesWorkspaces 的資料夾。

對於某些 DirectQuery 來源，此追蹤檔案包含傳送至基礎數據源的所有查詢。 下列資料來源會將查詢傳送至記錄：

  • SQL Server
  • Azure SQL Database
  • Azure Synapse Analytics （先前稱為 SQL 數據倉儲）
  • Oracle
  • Teradata
  • SAP HANA

您可以使用 SQL Server Profiler 來讀取追蹤檔案，這是免費下載 SQL Server Management Studio 的一部分。

Screenshot that shows SQL Server Profiler.

若要開啟目前會話的追蹤檔案：

  1. 在 Power BI Desktop 工作階段期間，選取 [檔案>選項和設定>選項]，然後選取 [診斷]。

  2. 在 [損毀傾印集合] 底 下，選取 [ 開啟損毀傾印/追蹤] 資料夾。

    Screenshot that shows the link to open the traces folder.

    Power BI Desktop\Traces 資料夾隨即開啟。

  3. 流覽至父資料夾，然後流覽至 AnalysisServicesWorkspaces 資料夾，其中包含 Power BI Desktop 每個開啟實例的一個工作區資料夾。 這些資料夾會以整數後綴命名，例如 AnalysisServicesWorkspace2058279583。 當相關聯的 Power BI Desktop 工作階段結束時，會刪除工作區資料夾。

    在目前 Power BI 工作階段的工作區資料夾內， \Data 資料夾包含 FlightRecorderCurrent.trc 追蹤檔案。 記下位置。

  4. 開啟 SQL Server Profiler，然後選取 [檔案>開啟>追蹤檔案]。

  5. 流覽至或輸入目前 Power BI 工作階段的追蹤檔案路徑，然後開啟 FlightRecorderCurrent.trc。

SQL Server Profiler 會顯示來自目前會話的所有事件。 下列螢幕快照會醒目提示查詢的事件群組。 每個查詢群組都有下列事件：

  • 和 Query BeginQuery End 事件，代表透過變更 Power BI UI 中的視覺效果或篩選所產生的 DAX 查詢的開始和結束，或從篩選或轉換 Power Query 編輯器 中的數據。

  • 一或多個 和 DirectQuery BeginDirectQuery End 事件組，代表傳送至基礎數據源的查詢，做為評估 DAX 查詢的一部分。

Screenshot of SQL Server Profiler with Query Begin and Query End events.

多個 DAX 查詢可以平行執行，因此可以交錯來自不同群組的事件。 您可以使用 ActivityID 值來判斷哪些事件屬於同一個群組。

下列數據行也感興趣：

  • TextData： 事件的文字詳細數據。 針對 Query Begin 和 Query End 事件，詳細數據是 DAX 查詢。 針對 DirectQuery Begin 和 DirectQuery End 事件，詳細數據是傳送至基礎來源的 SQL 查詢。 目前選取事件的 TextData 也會出現在畫面底部的窗格中。
  • EndTime： 事件完成的時間。
  • 持續時間： 持續時間，以毫秒為單位，執行DAX或SQL查詢所花費的時間。
  • 錯誤： 是否發生錯誤，在此情況下，事件也會以紅色顯示。

若要擷取追蹤，以協助診斷潛在的效能問題：

  1. 開啟單一Power BI Desktop 工作階段，以避免造成多個工作區資料夾的混淆。

  2. 在 Power BI Desktop 中執行一組感興趣的動作。 請再包含一些動作，以確保感興趣的事件會排清到追蹤檔案中。

  3. 開啟 SQL Server Profiler 並檢查追蹤。 請記住，關閉 Power BI Desktop 會刪除追蹤檔案。 此外，Power BI Desktop 中的進一步動作不會立即出現。 您必須關閉並重新開啟追蹤檔案，才能看到新的事件。

讓個別會話保持相當小，也許 10 秒的動作，而不是數百秒。 這種方法可讓您更輕鬆地解譯追蹤檔案。 追蹤檔案的大小也有限制。 對於長時間的會話，有可能捨棄早期事件。

了解查詢的格式

Power BI Desktop 查詢的一般格式會針對所參考的每個數據表使用子選擇。 Power Query 編輯器 查詢會定義子選取查詢。 例如，假設您在 SQL Server 中有下列 TPC-DS 資料表：

Screenshot that shows TPC-DS tables in SQL Server.

執行下列查詢：

SalesAmount (SUMX(Web_Sales, [ws_sales_price]*[ws_quantity]))
by Item[i_category]
for Date_dim[d_year] = 2000

在 Power BI 中產生下列視覺效果：

Screenshot that shows the visual result of a query.

重新整理該視覺效果會在下圖中產生 SQL 查詢。 、 Item和 Date_dim有三個子選取查詢Web_Sales，每個查詢都會傳回個別數據表上的所有數據行，即使視覺效果只參考四個數據行。

Screenshot of the SQL query used as provided.

Power Query 編輯器 定義確切的子選取查詢。 此子選取查詢的使用尚未顯示，以影響 DirectQuery 支援的數據源效能。 SQL Server 之類的數據源會優化其他數據行的參考。

Power BI 會使用此模式，因為分析師會直接提供 SQL 查詢。 Power BI 會使用所提供的查詢，而不需要嘗試重寫查詢。

相關內容

如需 Power BI 中 DirectQuery 的詳細資訊，請參閱：

本文說明所有數據源通用的 DirectQuery 層面。 如需特定來源的詳細數據，請參閱下列文章：