共用方式為

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 中的 DirectQuery 共用許多詳細數據，但也有重要的差異。 本文將著重說明與 Power BI 搭配使用的 DirectQuery，而非 SQL Server Analysis Services。

如需搭配 SQL Server Analysis Services 使用 DirectQuery 的詳細資訊，請參閱在 Power BI Desktop 中使用複合模型。 您也可以下載此 PDF SQL Server 2016 Analysis Services 中的 DirectQuery (英文)。

Power BI 資料連線模式

Power BI 會連線到大量的各種資料來源，例如：

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

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

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

例如，如果數據經常變更，而且報表必須反映最新的數據，請考慮使用 DirectQuery，以達到您的目標。 只有在基礎資料來源可以針對一般彙總查詢在五秒內提供互動式查詢，且能夠處理產生的查詢負載時，才適合使用 DirectQuery。 請審慎考量使用 DirectQuery 的限制和影響。

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

下列各節涵蓋下列三個選項來聯機至數據：import、DirectQuery 和實時連線。 本文的其餘部分著重於 DirectQuery。

匯入連線

當您連線到 SQL Server 之類的數據源，並在 Power BI Desktop 中匯入數據時，會出現下列連線狀況：

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

  • 載入時，這些查詢定義的所有資料都會匯入 Power BI 快取。

  • 在 Power BI Desktop 中建立的視覺效果會查詢快取資料。 Power BI 存放區可確保查詢迅捷，且視覺效果的所有變更都會立即反映。

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

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

  • 在 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 相似。 此時不會匯入任何資料，而是查詢基礎資料來源以重新整理視覺效果。

例如，當您使用匯入連線至 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 Premium訂用帳戶更頻繁地重新整理模型。 如果資料持續變更，且報表必須顯示最新資料，則使用匯入與排程的重新整理可能無法滿足您的需求。 您可以將資料直接串流到 Power BI 中，不過在此情況下支援的資料量有限。

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

資料很大

如果資料非常大，則不可能匯入所有資料。 DirectQuery 會就地查詢資料，因此無需傳輸大量資料。 不過，大型資料也可能導致針對該基礎來源的查詢效能過於緩慢。

您不一定必須匯入完整、詳細的數據。 Power Query 編輯器可讓您在匯入期間輕鬆地預先彙總資料。 從技術上而言，您可以只匯入每個視覺效果所需的彙總資料。 雖然 DirectQuery 是處理大型資料最簡單的方法，但如果基礎資料來源效能對於 DirectQuery 而言過於緩慢，匯入彙總資料也是一個解決方案。

這些細節與單獨使用 Power BI 有關。 如需在 Power BI 中使用大型模型的詳細資訊，請參閱 Power BI Premium 中的大型語意模型 (部分機器翻譯)。 重新整理資料的頻率並無限制。

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

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

DirectQuery 可讓報表檢視者的認證傳遞至基礎來源，藉此套用安全性規則。 DirectQuery 支援對 Azure SQL 資料來源的單一登入 (SSO)，以及透過資料閘道連線至內部部署 SQL 伺服器。 如需詳細資訊，請參閱 Power BI中內部部署數據閘道的單一登入 （SSO） 概觀。

套用資料主權限制

某些組織設有資料主權相關原則，換句話說，資料不可以離開組織內部。 此資料會導致以資料匯入為基礎的解決方案產生問題。 使用 DirectQuery 時，資料會保留在基礎來源位置。 不過，即使是使用 DirectQuery，由於磚會進行排定的重新整理，因此 Power BI 服務仍會保留一些視覺效果層級的資料快取。

基礎資料來源會使用量值

SAP HANA 或 SAP BW 等基礎資料來源包含「量值」。 量值表示匯入的資料已經處於特定彙總層級，如查詢所定義。 要求較高層級彙總資料的視覺效果 (例如依據 Year 的 TotalSales) 會將彙總值進一步彙總。 此彙總對於加總量值 (例如 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 中開啟報表，然後選擇 [重新整理]。

  • 任何查詢可傳回的資料列上限為 100 萬個。 任何單一查詢中可傳回至基礎來源的固定限制為 100 萬個資料列。 此限制通常沒有實際的影響，而且視覺效果不會顯示那麼多資料點。 不過，當 Power BI 未完全最佳化傳送的查詢，且要求的一些中繼結果超過限制時，可能會遇到此限制。

    在建置視覺效果時，為了產生更合理的最終狀態，也可能會遇到此限制。 例如，若未套用篩選條件，當客戶超過 100 萬人時，納入 Customer 和 TotalSalesQuantity 將會達到此限制。 傳回的錯誤為：外部資料來源的查詢結果集，超過允許列數的最大值 '1000000'。

    注意

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

  • 您無法將模型從匯入變更為 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 的 DirectQuery 連線時，不支援替代認證。 您可使用目前的 Windows 認證或資料庫認證。

  • 您可以使用複合模型 (部分機器翻譯)，在 DirectQuery 模型中使用多個資料來源。 當您使用多個資料來源時，請務必了解在基礎資料來源之間來回移動資料的安全性影響 (部分機器翻譯)。

資料轉換限制

DirectQuery 會限制您在 Power Query 編輯器中可套用的資料轉換。 透過匯入的資料，您可以輕鬆地套用一組複雜的轉換，藉此清除和重整資料，再用於建立視覺效果。 例如，您可以剖析 JSON 文件，或將資料從資料行樞紐至資料列表單。 這些轉換在 DirectQuery 中有更多限制。

當您連線到 SAP BW 之類的線上分析處理 (OLAP) 來源時，您無法定義任何轉換，並且整個外部模型都是取自來源。 至於 SQL Server 等關聯式來源，您仍可對每個查詢定義一組轉換，但基於效能考量，這些轉換會受到限制。

任何轉換都必須套用至針對基礎來源的每個查詢，而不是在資料重新整理時套用一次。 轉換必須能夠合理地轉譯成單一原生查詢。 如果您使用太複雜的轉換，您會收到錯誤，指出它必須刪除，或必須切換連接模型才能匯入。

此外，[取得資料] 對話方塊或 Power Query 編輯器會在產生的查詢內使用子選擇，並傳送以擷取視覺效果的資料。 在 Power Query 編輯器中定義的查詢必須在此內容中有效。 請特別注意，您無法使用包含通用資料表運算式的查詢，也無法使用叫用預存程序的查詢。

模型限制

「模型化」一詞在此內容中表示將未經處理資料進行精簡及擴充的行為，屬於使用資料撰寫報表的一部分。 模型化的範例包括：

  • 定義資料表之間的關聯性。
  • 新增計算，例如計算結果欄和量值。
  • 重新命名及隱藏資料行和量值。
  • 定義階層。
  • 定義資料行格式設定、預設摘要和排序次序。
  • 將值分入群組或叢集。

在使用 DirectQuery 時，您仍然可以進行其中許多模型擴充，並使用擴充未經處理資料的原則來改善之後的使用量。 不過，某些模型化功能將無法使用或受限於 DirectQuery。 套用這些限制是為避免效能問題。

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

  • 沒有內建日期階層：使用匯入的資料時，每個日期/日期時間資料行也預設提供內建的日期階層。 例如，如果您匯入包含 OrderDate 資料行的銷售訂單資料表，並在視覺效果中使用 OrderDate，則可以選擇要使用的適當日期層級，例如年、月或日。 使用 DirectQuery 時無法使用此內建日期階層。 如果基礎來源中有 Date 資料表 (常見於許多資料倉儲)，您可以照常使用 Data Analysis Expressions (DAX) 時間智慧函式。

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

  • 計算結果欄限制：計算結果欄只能是內部資料列，換句話說，這些欄只會參考相同資料表的其他資料行值，不能使用任何彙總函式。 此外，允許的 DAX 純量函式 (例如 LEFT()) 僅限於可推送至基礎來源的函式。 此類函式會根據來源的確切功能而有所不同。 撰寫計算結果欄的 DAX 查詢時，自動完成功能中不會列出不支援的函式，且使用這些函式將會導致錯誤。

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

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

報告限制

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

有一個一般限制是 DirectQuery 語意模型的文字資料行資料長度上限為 32,764 個字元。 報告超出此長度的文字會導致錯誤。

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

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

    螢幕擷取畫面：顯示包含篩選的量值

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

    • 第一個查詢會擷取符合 SalesAmount 超過 2000 萬這個條件的類別。
    • 第二個查詢會擷取視覺效果的必要資料，其中包含符合 WHERE 條件的類別。

    如果像此範例中有數百個或數千個類別，此方法執行起來通常沒有問題。 如果類別數目遠高於此，效能就可能會降低。 如果類別超過一百萬個，查詢就會失敗。

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

  • 中位數：任何彙總 (例如 Sum 或 Count Distinct) 都會發送至基礎來源。 不過， median 基礎來源通常不支持匯總。 針對 median，將會從基礎來源擷取詳細資料，然後從傳回的結果計算中位數。 這個方法適合用於計算在結果數量相對較少的中位數。

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

  • 進階文字篩選 (例如「contains」)：文字資料行的進階篩選允許 contains 和 begins with 等篩選。 這些篩選會導致某些資料來源的效能降低。 請特別注意，如果您需要完全相符，請勿使用預設的 contains 篩選條件。 雖然根據實際資料，結果可能相同，但效能可能會因索引而有相當大的差異。

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

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

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 天內的資料列。

    螢幕擷取畫面：顯示篩選過去 14 天內的資料列。

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

    螢幕擷取畫面：顯示原生 SQL 查詢中的篩選資料列。

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

報表設計

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

  • 考慮使用減少查詢選項：Power BI 有提供報表選項可減少傳送的查詢，以及停用所產生查詢執行時間過長導致較差體驗的互動。 當您在 Power BI Desktop 中與報表互動時，以及使用者取用 Power BI 服務中的報表時，都適用這些選項。

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

    螢幕擷取畫面：顯示減少查詢選項。

    [減少查詢] 畫面上的選取項目，可讓您顯示在交叉分析篩選器或篩選選取項目的 [套用] 按鈕。 在您選取篩選條件或交叉分析篩選器上的 [套用] 按鈕之前，將不會傳送任何查詢。 然後，查詢會使用您的選取項目來篩選資料。 此按鈕可讓您在套用交叉分析篩選器之前，先選取數個交叉分析篩選器和篩選選項。

  • 先套用篩選：請一律在建立視覺效果一開始就套用任何適用的篩選。 例如，您可以在一開始就套用年份篩選，而不是在 TotalSalesAmount 和 ProductName 中拖曳，再篩選為特定年份。

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

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

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

    顯示具有交叉篩選和交叉醒目提示之多個視覺效果的螢幕快照。

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

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

最大連線數目

您可以設定 DirectQuery 為每個基礎資料來源開啟的最大連線數目，以控制同時傳送至每個資料來源的查詢數目。

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

螢幕擷取畫面：顯示設定 DirectQuery 的連線上限。

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

增加 [每個資料來源的連線數目上限]，可允許傳送更多查詢至基礎資料來源，上限為指定的最大數目。 此方法在單一頁面上有許多視覺效果時，或是許多使用者同時存取報表時，將有其效用。 一旦達到最大連線數目，進一步的查詢會排入佇列，直到有連線可供使用。 更高的上限會導致基礎來源負載增加，因此設定不保證能改善整體效能。

將報表發佈至 Power BI 服務之後，並行查詢數目上限也取決於報表所發佈目標環境設定的固定限制。 Power BI、Power BI Premium 和 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。

Power BI 服務中只能直接使用下列兩個支援 DirectQuery 的來源：

  • 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 在語意模型上建立，每次重新整理時，至少有1,000個查詢會傳送至基礎數據源。 在使用資料列層級安全性，以及設定重新整理排程時，請務必仔細考量。

查詢逾時

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 的一部分。

顯示 SQL Server Profiler 的螢幕擷取畫面。

若要開啟目前工作階段的追蹤檔案：

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

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

    螢幕擷取畫面：顯示開啟追蹤資料夾的連結。

    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 Begin 和 Query End 事件，表示透過在 Power BI UI 中變更視覺效果或篩選，或從在 Power Query 編輯器中篩選或轉換資料時，所產生 DAX 查詢的開始和結束。

  • DirectQuery Begin 與 DirectQuery End 事件的一或多個配對，代表在評估 DAX 查詢過程中傳送至基礎資料來源的查詢。

螢幕擷取畫面：具有查詢開始和查詢結束事件的 SQL Server Profiler。

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

下列資料行也值得注意：

  • TextData：事件的文字詳細資料。 Query Begin 和 Query End 事件的詳細資料是 DAX 查詢。 DirectQuery Begin 和 DirectQuery End 事件的詳細資料則是傳送至基礎來源的 SQL 查詢。 目前所選事件的 TextData 也會出現在畫面底部的窗格中。
  • EndTime：事件完成的時間。
  • Duration：執行 DAX 或 SQL 查詢所花費的持續時間 (毫秒)。
  • Error：是否發生錯誤，發生時事件也會以紅色顯示。

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

  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 (英文) 資料表：

螢幕擷取畫面：顯示 SQL Server 中的 TPC-DS 資料表。

執行下列查詢：

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

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

螢幕擷取畫面：顯示查詢視覺效果的結果。

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

螢幕擷取畫面：以提供方式使用的 SQL 查詢。

Power Query 編輯器會定義確切的子選擇查詢。 此子選擇查詢的使用看起來並未影響 DirectQuery 支援的資料來源效能。 SQL Server 等資料來源會直接最佳化，而不需要參考其他資料行。

Power BI 會使用此模式，因為分析人員會直接提供 SQL 查詢。 Power BI 會直接使用所提供的查詢，不會嘗試改寫查詢。

相關內容

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

本文說明所有資料來源常見的 DirectQuery 層面。 如需特定來源的詳細資料，請參閱下列文章：