在 Power BI Desktop 中使用 DirectQuery
當您使用 Power BI Desktop 連線到任何資料來源時,可以匯入資料的複本。 對於某些資料來源,您也可以直接連接到資料來源,而不需使用 DirectQuery 匯入資料。 如需支援 DirectQuery 的資料來源完整清單,請參閱 DirectQuery 支援的資料來源。
以下是使用匯入和 DirectQuery 連線模式之間的差異:
匯入:所選資料表和資料行的資料複本會匯入Power BI Desktop。 當您建立或與視覺效果互動時,Power BI Desktop會使用匯入的資料。 若要查看初始匯入或最近重新整理之後的基礎資料變更,您必須再次匯入完整資料集以重新整理資料。
DirectQuery:不會將資料匯入Power BI Desktop。 對於關聯式來源,您可以選取要出現在 [Power BI Desktop欄位] 清單中的資料表和資料行。 對於 SAP Business Warehouse (SAP BW) 等多維度來源,所選 Cube 的維度和量值會出現在 [ 欄位 ] 清單中。 當您建立或與視覺效果互動時,Power BI Desktop查詢基礎資料來源,因此您一律會檢視目前的資料。
使用 DirectQuery 時,當您建立或與視覺效果互動時,必須查詢基礎來源。 重新整理視覺效果所需時間取決於基礎資料來源的效能。 如果最近要求服務要求所需的資料,Power BI Desktop會使用最近的資料來減少顯示視覺效果所需的時間。 從[常用]功能區選取 [重新整理] 會以目前資料重新整理所有視覺效果。
使用 DirectQuery 時,有許多資料模型和資料轉換可用,但有一些效能型限制。 如需 DirectQuery 優點、限制和建議的詳細資訊,請參閱 Power BI 中的 DirectQuery。
DirectQuery 優點
使用 DirectQuery 的一些優點包括:
DirectQuery 可讓您在非常大型的資料集上建置視覺效果,因此無法透過預先匯總匯入所有資料。
DirectQuery 報表一律使用目前的資料。 查看基礎資料變更需要您重新整理資料,並重新匯入大型資料集以重新整理資料可能不可行。
1 GB 資料集限制不適用於 DirectQuery。
使用 DirectQuery 連線
若要使用 DirectQuery 連接到資料來源:
在Power BI Desktop功能區的 [常用] 群組中,選取 [取得資料],然後選取 DirectQuery 支援的資料來源,例如SQL Server。
在連線的對話方塊中,于 [資料連線模式] 底下,選取 [DirectQuery]。
發佈到 Power BI 服務
您可以將 DirectQuery 報表發佈至Power BI 服務,但您必須採取額外的步驟,Power BI 服務才能開啟報表。
若要將Power BI 服務連線到 Azure SQL Database 以外的 DirectQuery 資料來源,Azure Synapse Analytics (先前稱為 SQL Data Warehouse) 、Amazon Redshift 和 Snowflake Data Warehouse、安裝內部部署資料閘道並註冊資料來源。
如果您使用 DirectQuery 搭配雲端來源,例如 Azure SQL Database、Azure Synapse、Amazon Redshift 或 Snowflake Data Warehouse,則不需要內部部署資料閘道。 您仍然必須提供認證,Power BI 服務才能開啟已發佈的報表。 如果沒有認證,當您嘗試開啟已發佈的報表或探索使用 DirectQuery 連線建立的資料集時,就會發生錯誤。
若要提供開啟報表並重新整理資料的認證:
在Power BI 服務中,選取右上角的齒輪圖示,然後選擇 [設定]。
在 [ 設定 ] 頁面上,選取 [ 資料集 ] 索引標籤,然後選擇使用 DirectQuery 的資料集。
在 [資料來源連線] 下,提供連線至資料來源的認證。
注意
如果您使用 DirectQuery 搭配具有私人 IP 位址的 Azure SQL Database,則需要使用內部部署閘道。
考量與限制
DirectQuery 模式不支援某些Power BI Desktop功能,或有限制。 Power BI 服務中的某些功能,例如快速深入解析,也不適用於使用 DirectQuery 的資料集。 當您決定是否要使用 DirectQuery 時,請考慮這些功能限制。 也請考慮下列因素:
效能和負載考慮
DirectQuery 會將所有要求傳送至源資料庫,因此視覺效果所需的重新整理時間取決於基礎來源傳回結果所需的時間。 建議的回應時間是接收視覺效果要求資料的建議回應時間。 重新整理時間超過 30 秒,對取用報表的使用者會產生無法接受的不良體驗。 在Power BI 服務中花費超過四分鐘的查詢逾時,而且使用者收到錯誤。
源資料庫的負載也取決於取用已發佈報表的 Power BI 使用者數目,特別是當報表使用資料列層級安全性 (RLS) 時。 由多位使用者共用的非 RLS 儀表板磚重新整理會將單一查詢傳送至資料庫,但重新整理使用 RLS 的儀表板磚需要每個使用者一個查詢。 增加的查詢會大幅增加負載,並可能會影響效能。
一百萬個數據列限制
DirectQuery 會針對從雲端資料來源傳回的資料定義一百萬個數據列限制,這是非內部部署的任何資料來源。 內部部署來源受限於每個資料列大約 4 MB 的已定義承載,視專屬壓縮演算法而定,或整個視覺效果的 16 MB。 進階容量可以設定不同的最大資料列限制,如部落格文章Power BI Premium新的容量設定中所述。
Power BI 會建立盡可能有效率的查詢,但某些產生的查詢可能會從基礎資料來源擷取太多資料列。 例如,這種情況可能發生于包含高基數資料行的簡單圖表,並將匯總選項設定為 [不要摘要]。 視覺效果必須只有基數低於 1 百萬的資料行,或必須套用適當的篩選。
資料列限制不適用於用來選取資料集 DirectQuery 傳回的匯總或計算,只會套用至傳回的資料列。 例如,在資料來源上執行的查詢可以匯總 1 億個數據列。 只要傳回至 Power BI 的資料少於 1 百萬個數據列,查詢就可以正確傳回結果。 如果資料超過 1 百萬個數據列,Power BI 會顯示錯誤,但進階容量中有不同的系統管理員設定限制。 錯誤狀態: 外部資料源查詢的結果集已超過允許的大小上限為 '10000000' 個數據列。
安全性考量
根據預設,使用發行集之後輸入的認證,Power BI 服務取用已發佈報表的所有使用者都會連接到基礎資料來源。 這種情況與匯入的資料相同。 所有使用者都會看到相同的資料,不論基礎來源所定義的任何安全性規則為何。
如果您需要使用 DirectQuery 來源實作的每個使用者安全性,請使用 RLS 或針對來源設定 Kerberos 限制驗證。 Kerberos 無法供所有來源使用。 如需詳細資訊,請參閱使用 Power BI 的資料列層級安全性 (RLS) 和設定從 Power BI 服務 到內部部署資料來源的 Kerberos 型 SSO。
其他 DirectQuery 限制
使用 DirectQuery 的一些其他限制包括:
如果Power Query 編輯器查詢過於複雜,就會發生錯誤。 若要修正錯誤,您必須刪除Power Query 編輯器有問題的步驟,或切換至匯入模式。 SAP BW 之類的多維度來源無法使用Power Query 編輯器。
DirectQuery 中無法使用自動日期/時間階層。 DirectQuery 模式不支援依年份、季、月或日向下鑽研日期資料行。
對於資料表或矩陣視覺效果,從 DirectQuery 來源傳回超過 500 個數據列的結果會有 125 個數據行的限制。 這些結果會顯示資料表或矩陣中的捲軸,可讓您擷取更多資料。 在此情況下,資料表或矩陣中的資料行數目上限為 125。 如果您必須在單一資料表或矩陣中包含超過 125 個數據行,請考慮建立使用
MIN
、MAX
、FIRST
或LAST
的量值,因為它們不會計入此最大值。您無法從匯入變更為 DirectQuery 模式。 如果您匯入所有必要的資料,則可以從 DirectQuery 模式切換為匯入模式。 無法切換回,主要是因為 DirectQuery 不支援的功能集。 透過多維度來源的 DirectQuery 模型,例如 SAP BW,無法從 DirectQuery 切換到匯入模式,因為外部量值有不同的處理方式。
Power BI 服務不支援從具有單一登入 (SSO) 驗證之資料來源參考 DirectQuery 資料表的匯出資料表和匯出資料行。