在 Power BI Desktop 中使用 DirectQuery

有了 Power BI Desktop,當連線到資料來源時,隨時可將資料的複本匯入 Power BI Desktop。 對於某些資料來源,可用的替代方式是:使用 DirectQuery 直接連線到資料來源。

支援的資料來源

如需支援 DirectQuery 的資料來源完整清單,請參閱 DirectQuery 支援的資料來源

如何使用 DirectQuery 連線

當您使用 [取得資料 ] 連線到 DirectQuery 所支援的資料來源時,[連線] 對話方塊可讓您選取您要連線的方式。 例如,在 [Power BI Desktop]功能區底下,選取 [取得資料>SQL Server。 在 [SQL Server 資料庫] 對話方塊中,[資料連線模式] 會顯示 [匯入] 和 [DirectQuery] 的選項:

Import and DirectQuery options, SQL Server Database dialog, Power BI Desktop

以下是選取 [匯入] 和 [DirectQuery] 之間的差異:

  • 匯入:將選取的資料表和資料行匯入至 Power BI Desktop。 當您建立視覺效果或與其互動時,Power BI Desktop 會使用匯入的資料。 若要查看自初始匯入或最近重新整理之後的基礎資料變更,您必須重新整理資料,以再次匯入完整的資料集。

  • DirectQuery:沒有任何資料匯入或複製到 Power BI Desktop。 針對關聯式來源,選取的資料表和資料行會出現在 [欄位] 清單。 針對多維度來源,例如 SAP Business Warehouse,選取 Cube 的維度及量值會出現在 [欄位] 清單。 當您建立視覺效果或與其互動時,Power BI Desktop 會查詢基礎資料來源,因此您一律都在檢視當下的資料。

使用 DirectQuery 時,有許多資料模型和資料轉換可以使用,但仍有一些限制。 當您建立視覺效果或與其互動時,必須查詢基礎來源。 重新整理視覺效果所需時間取決於基礎資料來源的效能。 當服務要求所需資料在最近已被要求時,Power BI Desktop 便會使用最新資料來減少顯示視覺效果所需的時間。 如果您從 [常用] 功能區選取 [重新整理],則所有視覺效果都會以目前的資料重新整理。

您可以從 Power BI 和 DirectQuery 一文中取得 DirectQuery 的詳細描述。 如需使用 DirectQuery 時的優點、限制和重要考量等詳細資訊,請參閱下列各節。

使用 DirectQuery 的優點

使用 DirectQuery 有一些好處:

  • DirectQuery 可讓您透過非常大型的資料集來建置視覺效果,因無法使用預先彙總來先行匯入所有資料。
  • 基礎資料變更可能需要重新整理資料。 針對某些報表,顯示目前的資料可能需要大量資料傳輸,因而無法重新匯入資料。 相較之下,DirectQuery 報表一律會使用目前的資料。
  • 1 GB 的資料集限制「不」適用於 DirectQuery。

考量與限制

目前使用 DirectQuery 會有一些限制:

  • 如果Power Query 編輯器查詢過於複雜,就會發生錯誤。 若要補救錯誤,請刪除Power Query 編輯器中有問題的步驟,或入資料,而不是使用 DirectQuery。 對於 SAP Business Warehouse 之類的多維度來源,沒有Power Query 編輯器

  • 在 Power BI 服務中,若導出資料表與導出資料行所參考的 DirectQuery 資料表來自具有單一登入 (SSO) 驗證的資料來源,則不提供支援。

  • DirectQuery 中無法使用自動日期/時間。 例如,DirectQuery 模式不支援使用年、季、月或日) 來向下切入 (日期資料行的特殊處理方式。

  • 雲端來源 (有一百萬個數據列限制,這是非內部部署) 的任何資料來源,內部部署來源限制為每個資料列約 4 MB 的已定義承載, (視專屬壓縮演算法) 或整個視覺效果的 16MB 資料大小而定。 使用 Premium 容量時可能會引發某些限制。 這項限制不會影響使用 DirectQuery 傳回時,用來建立資料集的彙總或計算。 只會影響傳回的資料列。 Premium 容量可以設定資料列上限,如這篇文章 \(英文\) 所述。

    例如,您可以使用在資料來源上執行的查詢來彙總 1 千萬個資料列。 如果傳回的 Power BI 資料小於1 百萬個資料列,則查詢會使用 DirectQuery 正確地將該彙總的結果傳回到 Power BI。 如果 DirectQuery 傳回超過 1 百萬個資料列,Power BI 會傳回錯誤 (除非是使用 Premium 容量,且資料列計數低於系統管理員所設定的限制)。

  • 對於 DirectQuery 來源有超過 500 個數據列的結果,資料表或矩陣中有 125 個數據行的限制。 在資料表或矩陣中顯示包含超過 500 個數據列的結果時,您會看到捲軸,可讓您擷取更多資料。 在此情況下,資料表或矩陣中的資料行數目上限為 125。 如果您必須在單一資料表或矩陣中包含超過 125 個數據行,請考慮使用 MIN、MAX、FIRST 或 LAST 建立量值,因為它們不會計入此最大值。

  • 篩選包含 9999 年 12 月 31 日日期資料行的日期資料行時,DirectQuery 中存在已知問題,在未擷取實際日期資訊時,通常會當做特殊日期預留位置使用。 雖然從分析中篩選 9999 年 12 月 31 日很常見,但使用 is不是 篩選無法正確篩選出該特殊日期。 若要避免在該日期存在時發生不正確的篩選,請使用在 或 之後或開啟或之前篩選該特殊日期。 下列範例提供詳細資訊,以瞭解潛在的篩選問題,以及避免問題的最佳方式。

    在此範例中,我們使用只包含兩個數據列且具有兩個日期的簡單資料集。 日期會以美國中常見的格式格式化:月份後面接著一天,後面接著一年。 第一個資料列包含 2022 年 3 月 5 日的日期,而第二個數據列包含 9999 年 12 月 31 日:

    Example data to explain filter issue with special date of December 31st, 9999. The data contains two rows: first row contains March 5th, 2022 and the second row contains December 31st, 9999

    如果您想要隔離或移除包含 9999 年 12 月 31 日的資料列,您可能會在包含日期的資料行上建立篩選,並將它設定為在值為 或不等於 9999 年 12 月 31 日時顯示專案,如下圖所示。 不過請注意,傳回的結果不是預期的結果,因為視覺效果不會傳回任何資料,而不是傳回一個資料列,如預期所示:

    Setting a filter to show items when the value is or is not equal to December 31st, 9999 will filter all data and thus return incorrect results.

    不過,當值在 9999 年12 月31 日或 9999 年 12 月 31日之前或之後,設定篩選來顯示專案:

    Setting a filter to is on or before December 31st, 9999 returns the correct results: the rows that contain December 31st, 9999 are removed.

    Setting a filter to is on or after December 31st, 9999 returns the correct results: only the rows that contain December 31st, 9999 are returned.

使用 DirectQuery 時的重要考量

使用 DirectQuery 時,應考慮下列三點:

  • 效能和負載:所有 DirectQuery 要求都會傳送到來源資料庫,因此所需視覺效果重新整理時間取決於該後端來源以一或多個查詢結果進行回應所花費的時間。 針對視覺效果使用 DirectQuery 的建議回應時間 (正在傳回要求的資料) 為 5 秒以下;建議的時間上限為 30 秒。 超過此時間會讓取用報表的使用者體驗低落至無法接受的程度。 將報表發佈到 Power BI 服務之後,超過數分鐘的任何查詢都會逾時,且使用者會收到錯誤。

    您也必須考慮來源資料庫上的負載,這會視取用已發行報表的 Power BI 使用者數目而定。 使用資料列層級安全性 (RLS) 可能也會有顯著的影響。 由多位使用者共用的非 RLS 儀表板磚會導致產生資料庫的單一查詢。 不過,在儀表板磚上使用 RLS,通常表示重新整理磚需要「每個使用者」執行一個查詢,進而大幅增加源資料庫的負載,且可能會影響效能。

    Power BI 會建立盡可能有效率的查詢。 不過在特定情況下,產生的查詢可能效率不足,而無法避免重新整理失敗。 這種情況的其中一個範例是,產生的查詢會從後端資料來源擷取非常大量資料列。 在此情況下,會發生下列錯誤:

    The resultset of a query to external data source has exceeded
    

    如果有一個簡單圖表包含基數很高的資料行,而且彙總選項設定為 [不摘要],就可能會發生此情況。 此視覺效果必須只能包含其基數低於 1 百萬的資料行,否則就必須套用適當的篩選。

  • 安全性:取用已發佈報表的所有使用者,預設都會使用發佈至 Power BI 服務之後輸入的認證來連接到後端資料來源。 此程序對於匯入的資料而言都相同:不論後端來源中是否有定義任何安全性規則,所有使用者都會看到相同的資料。

    想要使用 DirectQuery 來源實作每個使用者安全性的客戶,應使用 RLS 或針對來源設定 Kerberos 限制驗證。 Kerberos 無法供所有來源使用。 深入了解 RLS深入了解 DirectQuery中的 Kerberos

  • 支援的功能:DirectQuery 模式不支援 Power BI Desktop 的某些功能,或有一些限制。 此外,Power BI 服務的某些功能 (例如 [快速見解]) 不適用於使用 DirectQuery 的資料集。 在決定是否要使用 DirectQuery 時,您應該考慮這些功能限制。

注意

搭配 Azure SQL Database 和私人 IP 位址使用 DirectQuery 時,需要內部部署閘道。

發行至 Power BI 服務

使用 DirectQuery 建立的報表可以發佈至 Power BI 服務。

如果使用的資料來源不需要內部部署資料閘道 (Azure SQL DatabaseAzure Synapse Analytics (先前SQL Data Warehouse) 或Redshift) ,您必須先提供認證,Power BI 服務才會顯示已發佈的報表。 請遵循下列指示來提供認證:

  1. 登入 Power BI

  2. 在 Power BI 服務中,選取設定齒輪圖示,然後選擇 [設定] 功能表項目。

    Settings, Power BI service

  3. 在 Power BI 服務的 [設定] 頁面中,選取 [資料集] 索引標籤,選擇使用 DirectQuery 的資料集,然後選取 [編輯認證]。

  4. 新增認證。 否則,當您開啟已發佈的報表或探索以 DirectQuery 連線所建立資料集時,就會發生錯誤。

若要為Azure SQL Database以外的資料來源建立資料連線,Azure Synapse Analytics (先前SQL Data Warehouse) RedshiftSnowflake Data Warehouse使用 DirectQuery,請安裝內部部署資料閘道 並註冊資料來源。 如需詳細資訊,請參閱什麼是內部部署資料閘道?

後續步驟

如需 DirectQuery 的詳細資訊,請參閱下列資源: