編頁報表的數據擷取指引

  • 發行項

本文以設計Power BI 編頁報表的報表作者身分為目標。 它提供建議，協助您設計有效且有效率的數據擷取。

數據源類型

編頁報表原生支持關係型和分析數據源。 這些來源會進一步分類為雲端式或內部部署。 內部部署數據源，無論是裝載於內部部署還是虛擬機中，都需要數據網關，Power BI 才能連線。 雲端式表示 Power BI 可以使用因特網連線直接連線。

如果您選擇數據來源類型（可能是新項目中的情況），建議您使用雲端式數據源。 編頁報表可以連線到較低的網路等待時間，特別是當數據源位於與 Power BI 租使用者相同的區域中時。 此外，您也可以使用單一登錄 （SSO） 連線到這些來源。 這表示報表使用者的身分識別可以流向數據源，允許強制執行每個用戶的數據列層級許可權。 目前，只有內部部署數據源 SQL Server 和 Oracle 支援 SSO（請參閱 Power BI 編頁報表支援的數據源）。

注意

雖然目前無法使用 SSO 連線到內部部署資料庫，但您仍然可以強制執行數據列層級許可權。 其完成方式是將 UserID 內建字段傳遞至數據集查詢參數。 數據源必須以正確篩選查詢結果的方式儲存用戶主體名稱 （UPN） 值。

例如，假設每個銷售人員都會儲存為 Salesperson 數據表中的數據列。 數據表具有UPN的數據行，以及銷售人員的銷售區域。 在查詢時，數據表會依報表使用者的 UPN 進行篩選，而且也會與使用內部聯結的銷售事實相關。 如此一來，查詢就會有效地將銷售事實數據列篩選到報表用戶銷售區域的那些數據列。

關係型數據源

一般而言，關係型數據源非常適合操作樣式報表，例如銷售發票。 它們也適用於需要擷取非常大型數據集的報表（超過10,000個數據列）。 關係型數據源也可以定義預存程式，這些預存程式可由報表數據集執行。 預存程式提供數個優點：

  • 參數化
  • 封裝程式設計邏輯，允許更複雜的數據準備（例如臨時表、資料指標或純量使用者定義函式）
  • 改善可維護性，可讓預存程式邏輯輕鬆更新。 在某些情況下，不需要修改和重新發佈編頁報表即可完成（提供數據行名稱和數據類型保持不變）。
  • 更好的效能，因為其執行計劃會快取以供重複使用
  • 跨多個報表重複使用預存程式

在 Power BI 報表產生器 中，您可以使用關係型查詢設計工具，以圖形方式建構查詢語句，但僅適用於 Microsoft 數據源。

分析數據源

分析數據源，也稱為 數據模型 或只是 模型，非常適合操作和分析報表，而且即使在非常大的數據量上也能提供快速摘要的查詢結果。 模型量值和 KPI 可以封裝複雜的商務規則，以達成數據的摘要。 不過，這些數據源不適合需要擷取非常大量數據的報表（超過10,000個數據列）。

在 Power BI 報表產生器 中，您可以選擇兩個查詢設計工具：Analysis Services DAX 查詢設計工具，以及 Analysis Services MDX 查詢設計工具。 這些設計工具可用於 Power BI 語意模型（先前稱為數據集）數據源，或任何 SQL Server Analysis Services 或 Azure Analysis Services 模型—表格式或多維度。

我們建議您使用 DAX 查詢設計工具，使其完全符合您的查詢需求。 如果模型未定義您需要的量值，則必須切換至查詢模式。 在此模式中，您可以藉由新增表達式來自定義查詢語句（以達到摘要）。

MDX 查詢設計工具需要您的模型包含量值。 設計工具有 DAX 查詢設計工具不支援的兩項功能。 具體而言，它可讓您：

  • 定義查詢層級導出成員 （在 MDX 中）。
  • 設定數據區域以要求 非詳細數據群組中的伺服器匯總 。 如果您的報表需要呈現半或非加總量值的摘要（例如時間智慧計算或相異計數），則使用伺服器匯總比擷取低階詳細數據列以及讓報表計算摘要更有效率。

查詢結果大小

一般而言，最好只擷取報表所需的數據。 因此，請勿擷取報表不需要的數據行或數據列。

若要限制數據列，您應該一律套用限制最嚴格的篩選，並定義匯總查詢。 匯總查詢群組並摘要源數據以擷取較高粒紋的結果。 例如，假設您的報表必須呈現銷售人員銷售的摘要。 不要擷取所有銷售訂單數據列，而是建立數據集查詢，依銷售人員分組，並匯總每個群組的銷售量。

以表達式為基礎的欄位

可以透過以表達式為基礎的字段來擴充報表數據集。 例如，如果您的數據集來源是客戶名字和姓氏，您可能會想要串連這兩個字段的欄位來產生客戶全名。 若要達成此計算，您有兩個選項。 您可以：

  • 建立 導出欄位，這是以表達式為基礎的數據集欄位。
  • 將表達式直接插入數據集查詢中（使用數據源的原生語言），這會導致一般數據集欄位。

我們建議盡可能使用後者的選項。 將表達式直接插入數據集查詢有兩個好的理由：

  • 您的數據源可能會比 Power BI 更有效率地評估表達式（尤其是關係資料庫的情況）。
  • 報表效能已改善，因為不需要PowerBI在報表轉譯之前具體化匯出欄位。 當數據集擷取大量數據列時，匯出字段可以明顯擴充報表轉譯時間。

欄位名稱

當您建立數據集時，其字段會自動命名為查詢數據行。 這些名稱可能不是易記或直覺式。 來源查詢資料行名稱也可能包含報表定義語言 （RDL） 物件識別碼中禁止的字元（例如空格和符號）。 在此情況下，禁止的字元會取代為底線字元 （_）。

建議您先確認所有功能變數名稱都易記、簡潔，但仍有意義。 如果沒有，建議您在開始報表配置之前重新命名它們。 這是因為重新命名的欄位不會對報表版面配置中使用的表達式產生波紋變更。 如果您決定在報表版面配置開始之後重新命名字段，則必須尋找並更新所有中斷的表達式。

篩選與參數

您的編頁報表設計可能會有報表參數。 報表參數通常用來提示報表用戶篩選報表。 身為編頁報表作者，您有兩種方式可以達成報表篩選。 您可以將報表參數對應至：

  • 數據集 篩選，在此情況下，報表參數值會用來篩選數據集已擷取的數據。
  • 數據集 參數，在此情況下，報表參數值會插入傳送至數據源的原生查詢中。

注意

所有報表數據集都會 以每個會話為基礎 快取最多 10 分鐘 ，超過其上次使用時間。 提交新的參數值（篩選）、以不同格式轉譯報表，或以某種方式與報表設計互動，例如切換可見性或排序時，可以重複使用數據集。

接著，請考慮銷售報表的範例，該報表具有單一報表參數，以依單一年份篩選報表。 數據集會擷取所有年份的銷售量。 因為報表參數會對應至數據集篩選，所以這樣做。 報表會顯示所要求年份的數據，這是數據集數據的子集。 當報表使用者將報表參數變更為不同的年份，然後檢視報表時，Power BI 不需要擷取任何源數據。 相反地，它會將不同的篩選套用至已快取的數據集。 快取數據集之後，篩選速度可能非常快。

現在，請考慮不同的報表設計。 這次報表設計會將銷售年報表參數對應至數據集參數。 如此一來，Power BI 會將年份值插入原生查詢，而數據集只會擷取該年份的數據。 每次報表用戶變更年份報表參數值，然後檢視報表時，數據集只會擷取該年份的新查詢結果。

這兩種設計方法都可以篩選報表數據，而且這兩種設計都適用於報表設計。 不過，優化的設計將取決於預期的數據量、數據波動性，以及報表用戶的預期行為。

當您預期數據集數據列的不同子集將重複使用許多次時，建議您 篩選 數據集（藉此節省轉譯時間，因為不需要擷取新數據）。 在此案例中，您可以辨識擷取較大數據集的成本，可以取捨到將重複使用的次數。 因此，這對產生耗時的查詢很有説明。 但請小心—以每個用戶為基礎快取大型數據集可能會對效能和容量輸送量造成負面影響。

當您預期不太可能要求不同的數據集數據列子集時，建議您 進行數據集參數化 ，或當篩選的數據集數據列數目可能非常大（且快取效率不佳時）。 當您的數據存放區不穩定時，此設計方法也運作良好。 在此情況下，每個報表參數值變更都會導致擷取最新的數據。

非原生數據源

如果您需要根據編頁報表原本不支援 的數據源來開發編頁報表，您應該先在 Power BI Desktop 中開發數據模型。 如此一來，您就可以連線到 Power BI 支援的數百個數據源。 發行至 Power BI 服務 之後，您就可以開發連接到 Power BI 語意模型的編頁報表。

資料整合

如果您需要結合多個數據來源的數據，您有兩個選項：

  • 合併報表數據集：如果編頁報表原生支持數據源，您可以考慮建立使用Lookup或LookupSet 報表產生器 函式的匯出字段。
  • 開發 Power BI Desktop 模型：不過，您在 Power BI Desktop 中開發數據模型可能會更有效率。 您可以使用Power Query，根據任何 支援的數據源來結合查詢。 發行至 Power BI 服務 之後，您就可以開發連接到 Power BI 語意模型的編頁報表。

網路延遲

網路等待時間可能會增加要求到達 Power BI 服務 所需的時間，以及傳遞回應，進而影響報告效能。 Power BI 中的租使用者會指派給特定區域。

提示

若要判斷您的租用戶位於何處，請參閱 Power BI 租用戶位於何處？

當租使用者中的使用者存取 Power BI 服務 時，其要求一律會路由傳送至此區域。 當要求到達 Power BI 服務 時，服務接著可能會傳送其他要求，例如，傳送至基礎數據源或數據網關，這些要求也受限於網路等待時間。 一般而言，若要將網路等待時間的影響降到最低，請盡量讓數據源、網關和 Power BI 容量保持接近。 最好是它們位於相同的區域內。 如果網路等待時間是個問題，請嘗試將閘道和數據源放在雲端裝載的虛擬機內，以更接近您的Power BI容量。

SQL Server 複雜數據類型

因為 SQL Server 是內部部署數據源，因此 Power BI 必須透過網關聯機。 不過，閘道不支援擷取複雜數據類型的數據。 複雜數據類型包括內建類型，例如 GEOMETRY 和 GEOGRAPHY 空間數據類型，以及 hierarchyid。 它們也可以包含透過 Microsoft.NET Framework Common Language Runtime （CLR） 中元件類別實作的使用者定義型別。

在地圖視覺效果中繪製空間數據和分析需要 SQL Server 空間數據。 因此，當 SQL Server 是數據源時，就無法使用地圖視覺效果。 若要清楚，如果您的數據源是 Azure SQL 資料庫，因為 Power BI 不會透過網關聯機，所以會正常運作。

影像可用來將標誌或圖片新增至報表版面配置。 當影像與報表數據集所擷取的數據列相關時，您有兩個選項：

  • 您也可以從數據源擷取影像數據（如果已經儲存在數據表中）。
  • 當影像儲存在網頁伺服器上時，您可以使用動態表達式來建立影像 URL 路徑。

如需詳細資訊和建議，請參閱 編頁報表的影像指引。

備援數據擷取

您的報表可能會擷取多餘的數據。 當您刪除數據集查詢欄位，或報表有未使用的數據集時，就會發生這種情況。 避免這些情況，因為它們會造成數據源、網路和Power BI容量資源的不必要的負擔。

已刪除的查詢欄位

在 [數據集屬性] 視窗的 [欄位] 頁面上，可以刪除數據集查詢欄位（查詢欄位對應至數據集查詢所擷取的數據行）。 不過，報表產生器 不會從數據集查詢中移除對應的數據行。

如果您需要從數據集刪除查詢欄位，建議您從資料集查詢中移除對應的數據行。 報表產生器 會自動移除任何多餘的查詢欄位。 如果您確實刪除查詢欄位，請務必也修改資料集查詢語句來移除資料行。

未使用的資料集

執行報表時，會評估所有數據集，即使它們未系結至報表物件也一樣。 基於這個理由，請務必先移除任何測試或開發數據集，再發佈報表。

相關內容

如需本文的詳細資訊，請參閱下列資源：