SQL 分析端點效能考量

SQL 分析端點讓你能利用 T-SQL 語言和 TDS 協定查詢湖屋中的資料。它利用了Fabric Data Warehouse引擎。

Tip

關於優化 Delta 資料表以滿足 SQL 分析端點消耗的完整跨工作負載指引，包括檔案大小與列群組建議，請參閱跨工作負載資料表維護與優化。

每個 Lakehouse 都有一個 SQL 分析端點。工作區中的 SQL 分析端點數目符合該工作區中佈建的 Lakehouse 和鏡像資料庫數目。

背景程序負責掃描湖屋中的變更，並使 SQL 分析端點保持最新狀態，以反映工作區中提交至各湖屋的所有變更。 Fabric 平台透明地管理同步流程。在 Lakehouse 中偵測到變更時，幕後處理會更新中繼資料，而 SQL 分析端點會反映已提交至 Lakehouse 資料表的變更。在正常運作條件下，Lakehouse 與 SQL 分析端點之間的延隔時間小於一分鐘。實際時間長度可能從幾秒到幾分鐘不等，取決於本文所討論的多種因素。背景程序在 SQL 分析端點啟動時執行，且在沒有查詢活動的情況下 15 分鐘後停止。

Guidance

自動中繼資料探索可追蹤提交至 Lakehouse 的變更，並在每個 Fabric 工作區中作為獨立實例存在。如果你觀察到湖屋與 SQL 分析端點同步變更延遲增加，可能是因為同一工作區有大量湖屋。在這種情況下，可以考慮將每個湖屋遷移到獨立的工作區，因為這種方式能讓自動元資料發現更為可擴展。
依設計，Parquet 檔案是不可變的。當有更新或刪除操作時，Delta 表格會隨變更集新增 Parquet 檔案，隨時間增加檔案數量，取決於更新與刪除的頻率。如果你不安排維護作業，這種模式最終會造成讀取開銷，而這種情況會影響將變更同步至 SQL 分析端點所需的時間。若要解決此問題，請安排定期Lakehouse 資料表維護作業。
在某些情況下，你可能會發現提交至資料湖倉的變更在相關的 SQL 分析端點中無法看到。舉例來說，你可能在 lakehouse 建立一個新資料表，但它還沒列入 SQL 分析端點。或者，您可能會將大量資料列提交至湖屋中的資料表，但這些資料在 SQL 分析端點中仍尚不可見。你可以在 Fabric 入口網站啟動按需的元資料同步，或使用 Refresh SQL 分析端點元資料 REST API。
自動同步流程並不支援所有 Delta 功能。如需 Fabric 中每個引擎所支援功能的詳細資訊，請參閱 Delta Lake 數據表格式互作性。
如果在擷取、轉換與載入（ETL）處理過程中有極大量的表格變更，預期會有一個延遲，直到所有變更都處理完畢。

優化 lakehouse 資料表以提升 SQL 分析端點的查詢效能

當 SQL 分析端點讀取儲存在湖屋中的資料表時，查詢效能高度依賴底層 Parquet 檔案的實體佈局。引擎在 Parquet 檔案層級以平行方式進行掃描。過多小檔案會增加檔案和元資料的負擔，而過少的大檔案則會限制掃描平行性。

對於 Spark 撰寫的資料表，請使用 Fabric Spark 2.0 或更新版本的預設設定。這些執行時預設允許自適應目標檔案大小，依資料表選擇最優的目標檔案大小，從較小資料表的 128 MB 到最大資料表的 1 GB。避免在預設配置上設定靜態目標或任意的列數限制。列限制不考慮列寬度，可能會讓檔案變小，導致資料表較窄。

如果你使用 Fabric Spark 1.3 執行時版本，請啟用自適應目標檔案大小與檔案層級壓縮目標，這些功能可作為選擇加入的功能提供。

V-Order 主要有助於 Power BI Direct Lake，雖然能改善部分工作負載的壓縮，但通常並非預設必要或推薦，以達到最佳 SQL 分析端點效能。

預設寫入設定並不能取代資料表維護。在表格變動時，請採用以下做法來維持良好的版面配置：

若工作負載可接受週期性增加的同步寫入延遲，請啟用自動壓縮。自動壓縮是 Spark 的一項功能，只有在資料表中有太多小檔案時才會執行。
針對自動壓縮造成的週期性額外延遲無法滿足資料更新 SLA 的工作負載，排定定期執行的 OPTIMIZE 作業。
依照您的保留與時間回溯需求執行 VACUUM，以移除 Delta 日誌不再參照的檔案。 VACUUM 雖然減少了保留的儲存空間，但並不會改善主動檔案的配置。
避免使用高基數分區及會產生大量小檔案的自訂寫入器設定。

如果你不使用自動壓縮，要找出需要維護的資料表，請先使用資料管線和 sys.sp_get_table_health_metrics T-SQL 儲存程序再執行 OPTIMIZE。如需教學課程，請參閱根據健康情況檢查來最佳化 Lakehouse 資料表。

Note

如需有關 Lakehouse 資料表一般維護的指引，請參閱從 Lakehouse 執行資料表維護。

分割區大小考量

分割區配置會影響 SQL 分析端點發現並同步變更所需的時間。大量分割區或小型 Parquet 檔案會增加元資料掃描的開銷。請遵循以下做法：

避免使用高基數的分區欄位，因為這可能會為每個唯一值建立一個分區。選擇會產生接近或大於 1 GB 的分割區的欄位。更多資訊請參閱三角洲湖資料表分割。
當變更頻繁或幅度很小時，批次和串流擷取可能會產生小型檔案。使用定期Lakehouse 資料表維護來壓縮這些檔案。

要評估每個分割區的大小與檔案數量，請使用範例腳本來了解分割區細節。

分割區詳細資料的範例指令碼

請使用以下筆記本列印一份報告，詳細說明 Delta 表格底下的分割區大小與細節。

首先，在變數 delta_table_path中提供 Delta 表的 ABFSS 路徑。
- 您可以從 Fabric 入口網站的瀏覽器取得 Delta 資料表的 ABFSS 路徑。以滑鼠右鍵按一下資料表名稱，然後從選項清單中選取 COPY PATH 。
腳本會輸出 Delta 資料表的所有分割。
指令碼會逐一查看每個分割區，以計算檔案的總大小和數目。
指令碼會輸出分割區的詳細資料、每個分割區的檔案，以及每個分割區的大小 (GB)。

你可以從以下程式碼區塊複製完整腳本：

# Purpose: Print out details of partitions, files per partitions, and size per partition in GB.
from notebookutils import mssparkutils

# Define ABFSS path for your delta table. You can get ABFSS path of a delta table by simply right-clicking on table name and selecting COPY PATH from the list of options.
delta_table_path = "abfss://<workspace id>@<onelake>.dfs.fabric.microsoft.com/<lakehouse id>/Tables/<tablename>"

# List all partitions for given delta table
partitions = mssparkutils.fs.ls(delta_table_path)

# Initialize a dictionary to store partition details
partition_details = {}

# Iterate through each partition
for partition in partitions:
  if partition.isDir:
      partition_name = partition.name
      partition_path = partition.path
      files = mssparkutils.fs.ls(partition_path)
      
      # Calculate the total size of the partition

      total_size = sum(file.size for file in files if not file.isDir)
      
      # Count the number of files

      file_count = sum(1 for file in files if not file.isDir)
      
      # Write partition details

      partition_details[partition_name] = {
          "size_bytes": total_size,
          "file_count": file_count
      }
      
# Print the partition details
for partition_name, details in partition_details.items():
  print(f"{partition_name}, Size: {details['size_bytes']:.2f} bytes, Number of files: {details['file_count']}")

意見反應

此頁面對您有幫助嗎？

Last updated on 2026-09-16