在 Fabric Data Warehouse(預覽版)中使用資料叢集

適用於:✅ Microsoft Fabric 中的 SQL 分析端點和倉儲

這很重要

這項功能目前處於預覽階段。

Fabric Data Warehouse 中的資料叢集能組織資料以加快查詢效能並降低計算使用。 本教學將逐步說明如何建立帶有資料聚類的資料表,從建立群組資料表到檢查其效能。

先決條件

  • 具有有效訂閱的 Microsoft Fabric 租戶帳戶。
  • 請確定您有啟用 Microsoft Fabric 的工作區:建立工作區。
  • 確保你已經建立倉庫。 要建立新的倉庫,請參考「 在 Microsoft Fabric 中建立倉庫」。
  • 基本了解 T-SQL 和查詢資料的方法。

匯入範例資料

本教學使用紐約計程車樣本資料集。 要將紐約計程車資料匯入你的倉庫。 可以使用「 將範例資料載入到資料倉儲」的教學 教學。

建立一個帶有資料分群的表格

本教學需要兩份 NYTaxi 表格:一份是從教學匯入的一般表格,另一份是使用資料分群的副本。 請使用以下指令 CREATE TABLE AS SELECT (CTAS),基於原始 NYTaxi 表格建立一個新表格:

CREATE TABLE nyctlc_With_DataClustering 
WITH (CLUSTER BY (lpepPickupDatetime)) 
AS SELECT * FROM nyctlc

備註

本範例假設了 Load Sample data to Data Warehouse 教學中 NY 計程車資料集的表格名稱。 如果你使用了不同的表格名稱,請調整指令中的nyctlc以替換成你的表格名稱。

此指令會建立原始 NYTaxi 表格的精確複製品,但在欄位 lpepPickupDatetime 上加入資料聚類。 接著,我們用這個欄位來查詢。

查詢數據

在 NYTaxi 表格上執行查詢,並在 NYTaxi_With_DataClustering 表格重複完全相同的查詢以作比較。

備註

在本次分析中,檢視兩次執行的冷快取效能是有益的——也就是說,不使用 Fabric Data Warehouse 的快取功能。 因此,在查看查詢洞察結果前,請先執行每個查詢一次。

我們使用一個在資料倉儲中常用的查詢。 此查詢計算從日期2008-12-31到2014-06-30之間各年的平均票價:

SELECT
    YEAR(lpepPickupDatetime), 
    AVG(fareAmount) as [Average Fare]
FROM 
    NYTaxi
WHERE 
    lpepPickupDatetime BETWEEN '2008-12-31' AND '2014-06-30'
GROUP BY 
    YEAR(lpepPickupDatetime)
ORDER BY 
    YEAR(lpepPickupDatetime) DESC
OPTION (LABEL = 'Regular');

備註

在本查詢中使用的 標籤選項,在我們使用 Regular來比較表格的 查詢細節與後來應用資料分群技術時,非常有用。

接著,我們重複完全相同的查詢,但使用使用資料聚類的表格版本:

SELECT 
    YEAR(lpepPickupDatetime), 
    AVG(fareAmount) as [Average Fare]
FROM 
    NYTaxi_With_DataClustering
WHERE 
    lpepPickupDatetime BETWEEN '2008-12-31' AND '2014-06-30'
GROUP BY 
    YEAR(lpepPickupDatetime)
ORDER BY 
    YEAR(lpepPickupDatetime) DESC
OPTION (LABEL = 'Clustered');

第二個查詢使用標籤 Clustered ,讓我們之後能用 Query Insights 來識別這個查詢。

檢視資料分群的成效

設定叢集後,你可以利用查詢洞察評估其效果。 Fabric Data Warehouse 中的查詢洞察捕捉歷史查詢執行資料,並將其彙整成可行的洞察,例如辨識長期執行或頻繁執行的查詢。

在此情況下,我們使用 Query Insights 來比較一般案例與群組案例掃描資料的差異。

使用下列查詢:

SELECT 
    label, 
    submit_time, 
    row_count,
    total_elapsed_time_ms, 
    allocated_cpu_time_ms, 
    result_cache_hit, 
    data_scanned_disk_mb, 
    data_scanned_memory_mb, 
    data_scanned_remote_storage_mb, 
    command 
FROM 
    queryinsights.exec_requests_history 
WHERE 
    command LIKE '%NYTaxi%' 
    AND label IN ('Regular','Clustered')
ORDER BY 
    submit_time DESC;

此查詢會從 exec_requests_history 檢視中取得詳細資訊。 更多資訊請參見 queryinsights.exec_requests_history(Transact-SQL)。

查詢會以以下方式篩選結果:

  • 只擷取包含 NYTaxi 指令名稱文字的列(如測試查詢所用)
  • 只擷取標籤值為一般或叢集的列

備註

查詢細節可能需要幾分鐘才能在 Query Insights 中顯示出來。 如果你的 Query Insights 查詢沒有結果,幾分鐘後再試一次。

執行此查詢後,我們觀察到以下結果:

比較兩個標籤:叢集與常規標籤的查詢執行指標的表格。一般查詢使用了更多資源。

這兩筆查詢的列數都是 6 次,提交時間也差不多。 查詢顯示Clusteredtotal_elapsed_time_ms分別為1794年、 allocated_cpu_time_ms 1676年及data_scanned_remote_storage_mb77.519年。 查詢結果 Regular 顯示 total_elapsed_time_ms 分別為2651、 allocated_cpu_time_ms 2600和 data_scanned_remote_storage_mb 177.700。 這些數據顯示,儘管兩項查詢結果相同,但 Clustered 版本 CPU 使用時間約比 Regular 版本少36%,且掃描的磁碟資料量約少56%。 兩次查詢執行都未使用快取。 這些都是重要的成果,有助於降低查詢執行時間與消耗量,並使該 lpepPickupDatetime 欄位成為資料聚類的有力候選對象。

備註

這是一個小型資料表,約有 7600 萬列和 2GB 的資料量。 儘管此查詢的彙總結果只回傳六列(每一年範圍內一列),但在結果彙總前,它會掃描提供的日期範圍中的大約 830 萬筆數據列。 實際生產資料若資料量較大,則能提供更顯著的結果。 你的結果可能會因容量大小、快取結果或查詢時的同時性而有所不同。

從你的工作負載中選擇分群欄位

對於生產資料表,使用觀察到的查詢模式,而不是猜測要聚類的欄位。 該 sqldw-cli 技能 的操作功能會分析 Query Insights 歷程記錄,依遠端掃描的資料量為重複出現的查詢模式排序,並識別在 WHERE 述詞中使用的欄位。

開始前,先安裝 Skills for Fabric,確認倉庫有近期查詢活動,並確認你擁有貢獻者工作區角色或更高級別。 接著,打開 GitHub Copilot CLI,並使用類似這樣的提示:

Use the sqldw-cli skill to recommend clustering columns for
<workspace-name>/<warehouse-name> based on the last seven days of workload.
Rank candidates by total remote data scanned, consider columns used in WHERE
predicates, and explain each column's cardinality and data type suitability.
Use read-only diagnostics.

此技能識別對掃描影響最大的查詢模式,從這些查詢中擷取表格與篩選欄位,並對群集候選者進行排名。 請依照以下指引檢視建議:

  • 優先選擇經常用於篩選大型資料表,且具有中至高基數值的欄位,例如日期或識別碼。
  • 優先考慮在 WHERE 子句中用於具選擇性的範圍述詞或等值述詞的資料行。
  • 不要只因為欄位出現在等量連接條件下就選擇它們。 這些條件並未從資料分群中受益。
  • 群組欄位不要超過四欄,且不要增加超過工作量所需的欄位。

例如,假設某個電子商務倉庫中,Sales.SalesOrder 包含 15 億筆資料列,而 Sales.OrderLine 包含 60 億筆資料列。 在分析重複性查詢後,技能可能會回傳以下建議:

叢集建議表。SalesOrder 根據 428 次查詢執行及 38 TB 掃描的遠端資料使用 OrderDate。OrderLine 根據 612 次查詢執行及 52 TB 掃描使用 ShipDate。

日期欄位之所以是強有力的候選選項,是因為它們能過濾最大的資料表、支援常見的範圍謂詞,並且比低基數 OrderStatus 欄位如 或 SalesRegion提供更多檔案跳躍機會。

sqldw-cli操作功能為唯讀。 它會推薦欄位,但不會建立或替換表格。 在你檢視建議後,使用 CTAS 建立一份表格的群組副本:

CREATE TABLE Sales.SalesOrder_clustered
WITH (CLUSTER BY (OrderDate))
AS
SELECT * FROM Sales.SalesOrder;

比較叢集與非叢集工作負載以驗證其影響。 驗證叢集資料表後,先重新命名原始資料表,然後再將叢集資料表重新命名為原始名稱:

EXEC sp_rename 'Sales.SalesOrder', 'SalesOrder_old';
EXEC sp_rename 'Sales.SalesOrder_clustered', 'SalesOrder';

原始表格仍可於 Sales.SalesOrder_old 取得,以供還原使用。 在移除原始資料表前,先確認相依工作負載和新資料表。 當你不再需要回復副本時,請將其刪除:

DROP TABLE Sales.SalesOrder_old;