SQL 分析端點效能考量
適用於:✅Microsoft Fabric 中的 SQL 分析端點
SQL 分析端點可讓您使用 T-SQL 語言和 TDS 通訊協定,查詢 Lakehouse 中的資料。 每個 Lakehouse 都有一個 SQL 分析端點。 工作區中的 SQL 分析端點數目符合該工作區中佈建的 Lakehouse 和鏡像資料庫數目。
幕後處理負責掃描 Lakehouse 是否有變更,並將 SQL 分析端點保持在最新狀態,以取得工作區中所有提交至 Lakehouse 的變更。 同步處理程序會由 Microsoft Fabric 平台透明管理。 在 Lakehouse 中偵測到變更時,幕後處理會更新中繼資料,而 SQL 分析端點會反映已提交至 Lakehouse 資料表的變更。 在正常運作條件下,Lakehouse 與 SQL 分析端點之間的延隔時間小於一分鐘。 根據本文中挖掘的一些因素,實際時間長度可能會因幾秒到分鐘而有所不同。
Lakehouse 中的 SQL 分析端點會自動產生結構描述
SQL 分析端點會管理自動產生的資料表,因此工作區使用者無法進行修改。 使用者可以藉由新增自己的 SQL 結構描述、檢視、程序和其他資料庫物件,來擴充資料庫模型。
針對 Lakehouse 中的每個 Delta 數據表,SQL 分析端點會自動在適當的架構中產生數據表。 如需 SQL 分析端點自動產生的結構描述資料類型,請參閱 Microsoft Fabric 中的資料類型。
在 SQL 分析端點中建立資料表會稍有延遲。 一旦您在 Lake 中建立或更新 Delta Lake 數據表,就會自動建立/重新整理參考 Delta Lake 數據表的 SQL 分析端點數據表。
重新整理資料表所需的時間量與 Delta 資料表的最佳化程度有關。 如需詳細資訊,請檢閱 Delta Lake 資料表最佳化和 V 順序 ,以深入了解重要案例,及有關如何有效率地維護 Delta 資料表以實現最大效能的深入指南。
您可以在 Fabric 入口網站中手動強制重新整理自動中繼資料掃描。 在 SQL 分析端點的頁面上,選取 [總管] 工具列中的 [重新整理] 按鈕,以重新整理結構描述。 移至 [查詢] 您的 SQL 分析端點,然後尋找 [重新整理] 按鈕,如下圖所示。
指引
- 自動中繼資料探索會追蹤提交至 Lakehouse 的變更,而且是每個 Fabric 工作區的單一實行個體。 如果您觀測到 Lakehouse 與 SQL 分析端點之間同步變更的延遲增加,則可能是因為一個工作區中有大量的 Lakehouse。 在這種情況下,請考慮將每個 Lakehouse 移轉至不同的工作區,因為這樣可以調整自動中繼資料探索。
- 依設計,Parquet 檔案是不可變的。 當有更新或刪除作業時,Delta 資料表會新增新的 Parquet 檔案與變更集,隨時間增加檔案數目,具體視更新和刪除的頻率而定。 如果沒有排程維護,此模式最終會產生讀取額外負荷,而這會影響將變更同步至 SQL 分析端點所需的時間。 若要解決此問題,請排程一般 Lakehouse 資料表維護作業。
- 在某些情況下,您可能會發現提交至 Lakehouse 的變更不會顯示在關聯的 SQL 分析端點中。 例如,您可能已在 Lakehouse 中建立新的資料表,但其並未列在 SQL 分析端點中。 或者,您可能已將大量資料列提交至 Lakehouse 中的資料表,但 SQL 分析端點中看不到此資料。 我們建議啟動隨選中繼資料同步,從 SQL 查詢編輯器 [重新整理] 緞帶選項觸發。 這個選項會強制隨選中繼資料同步,而不是等待背景中繼資料同步完成。
- 並非所有差異功能都由自動同步處理程序瞭解。 如需 Fabric 中每個引擎所支援功能的詳細資訊,請參閱 Delta Lake 互操作性。
- 如果在擷取轉換和載入 (ETL) 處理期間有非常大的數據表變更,則在處理所有變更之前,可能會發生預期的延遲。
分割區大小考量
Lakehouse 中 Delta 資料表的分割區資料行選擇也會影響將變更同步至 SQL 分析端點所需的時間。 分割區資料行的分割區數目和大小對於效能而言很重要:
- 具有高基數的資料行 (主要或完全由唯一值組成) 會導致大量的分割區。 大量分割區會對中繼資料探索掃描變更的效能造成負面影響。 如果資料行的基數很高,請選擇另一個資料行來進行資料分割。
- 每個分割區的大小也會影響效能。 我們建議使用會導致分割區至少 (或接近) 1 GB 的資料行。 我們建議遵循 Delta 資料表維護的最佳做法;最佳化。 如需評估分割區的 Python 指令碼,請參閱分割區詳細資料的範例指令碼。
大量的小型 Parquet 檔案會增加在 Lakehouse 與其關聯 SQL 分析端點之間同步變更所需的時間。 基於一或多個原因,您最終可能會在 Delta 資料表中產生大量的 Parquet 檔案:
- 如果您選擇 Delta 資料表的分割區,其中包含大量唯一值,則會依每個唯一值進行資料分割,而且可能會過度分割。 選擇沒有高基數的分割區資料行,並產生至少 1 GB 的個別分割區大小。
- 批次和串流資料擷取速率也可能會導致小型檔案,視寫入 Lakehouse 的變更頻率和大小而定。 例如,Lakehouse 可能會有少量的變更,而這會產生小型的 Parquet 檔案。 若要解決此問題,我們建議實作一般 Lakehouse 資料表維護。
分割區詳細資料的範例指令碼
使用以下筆記本列印一份報告,其中詳細說明支援 Delta 資料表的分割區的大小和詳細資料。
- 首先,您必須在變數
delta_table_path
中提供 Delta 資料表的 ABSFF 路徑。- 您可以從 Fabric 入口網站 [總管] 取得 Delta 資料表的 ABFSS 路徑。 以滑鼠右鍵按一下資料表名稱,然後從選項清單中選取
COPY PATH
。
- 您可以從 Fabric 入口網站 [總管] 取得 Delta 資料表的 ABFSS 路徑。 以滑鼠右鍵按一下資料表名稱,然後從選項清單中選取
- 指令碼會輸出 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']}")