Zagadnienia dotyczące wydajności punktu końcowego analizy SQL

Punkt końcowy analityki SQL umożliwia wykonywanie zapytań do danych w lakehouse przy użyciu języka T-SQL i protokołu TDS. Wykorzystuje silnik Fabric Data Warehouse.

Wskazówka

Aby uzyskać kompleksowe wskazówki dotyczące optymalizacji tabel Delty na potrzeby wykorzystania punktów końcowych do analizy SQL, w tym zaleceń dotyczących rozmiaru plików i grup wierszy, zobacz Konserwacja i optymalizacja tabeli między obciążeniami.

Każdy lakehouse ma jeden punkt końcowy analizy SQL. Liczba punktów końcowych analizy SQL w obszarze roboczym odpowiada liczbie lakehouse’ów oraz zmirroryzowanych baz danych udostępnionych w tym obszarze roboczym.

Proces działający w tle odpowiada za skanowanie lakehouse’ów pod kątem zmian i aktualizowanie punktu końcowego analizy SQL tak, aby uwzględniał wszystkie zmiany zatwierdzone w lakehouse’ach w obszarze roboczym. Platforma Fabric transparentnie zarządza procesem synchronizacji. Po wykryciu zmiany w lakehouse, proces działający w tle aktualizuje metadane, a punkt końcowy analizy SQL odzwierciedla zmiany zatwierdzone w tabelach lakehouse. W normalnych warunkach operacyjnych opóźnienie między usługą Lakehouse i punktem końcowym analizy SQL wynosi mniej niż minutę. Rzeczywisty czas może się różnić od kilku sekund do minut w zależności od wielu czynników, które omówiono w tym artykule. Proces w tle działa, gdy endpoint analityki SQL jest aktywny i zatrzymuje się po 15 minutach bez aktywności zapytań.

Guidance

Automatyczne odnajdywanie metadanych śledzi zmiany zatwierdzone w usłudze Lakehouse i jest pojedynczym wystąpieniem dla obszaru roboczego usługi Fabric. Jeśli zaobserwujesz zwiększone opóźnienie synchronizacji zmian między lakehouse'ami a punktem końcowym analizy SQL, może to wynikać z dużej liczby lakehouse'ów w jednym obszarze roboczym. W takim scenariuszu rozważ migrację każdego lakehouse do oddzielnego obszaru roboczego, ponieważ takie podejście pozwala skalować automatyczne wykrywanie metadanych.
Pliki Parquet są niezmienne zgodnie z projektem. W przypadku aktualizacji lub operacji usunięcia tabela Delta dodaje nowe pliki Parquet z zestawem zmian, co zwiększa liczbę plików z upływem czasu, w zależności od częstotliwości aktualizacji i usunięć. Jeśli nie planujesz konserwacji, ten wzorzec ostatecznie tworzy obciążenie odczytu i ten warunek ma wpływ na czas potrzebny na synchronizację zmian do punktu końcowego analizy SQL. Aby rozwiązać ten problem, zaplanuj regularne operacje konserwacji tabeli lakehouse.
W pewnych scenariuszach możesz zauważyć, że zmiany wprowadzone w lakehouse nie są widoczne w powiązanym punkcie końcowym analizy SQL. Możesz na przykład utworzyć nową tabelę w usłudze Lakehouse, ale nie jest jeszcze wymieniona w punkcie końcowym analizy SQL. Możesz też zapisać dużą liczbę wierszy w tabeli w lakehouse, jednak te dane nie są jeszcze widoczne w punkcie końcowym analityki SQL. Możesz rozpocząć synchronizację metadanych na żądanie w portalu Fabric lub użyć Refresh SQL Analytics endpoint metadata REST API.
Proces automatycznej synchronizacji nie obsługuje wszystkich funkcji Delta. Aby uzyskać więcej informacji na temat funkcji obsługiwanych przez poszczególne silniki w Platformie Fabric, zobacz Współdziałanie formatu tabeli Delta Lake.
Jeśli podczas procesu ETL (Extract, Transform and Load) występuje bardzo duży wolumen zmian w tabelach, wystąpi oczekiwane opóźnienie do czasu przetworzenia wszystkich zmian.

Optymalizowanie tabel lakehouse na potrzeby wykonywania zapytań dotyczących punktu końcowego analizy SQL

Gdy punkt końcowy analityki SQL odczytuje tabele przechowywane w lakehouse, wydajność zapytań zależy w dużym stopniu od fizycznego układu plików Parquet stanowiących ich podstawę. Silnik równolegle wykonuje skanowanie na poziomie plików Parquet. Zbyt wiele małych plików zwiększa narzut plików i metadanych, podczas gdy zbyt mało dużych plików może ograniczać równoległość skanowania.

Dla tabel napisanych przez Spark używaj domyślnych ustawień w Fabric Spark runtime 2.0 lub nowszym poziomie. Te środowiska wykonawcze umożliwiają domyślnie adaptacyjny rozmiar pliku docelowego do wyboru najbardziej optymalnego rozmiaru pliku docelowego według tabeli, od 128 MB dla mniejszych tabel do 1 GB dla największych tabel. Unikaj ustawiania statycznych wartości docelowych lub dowolnego limitu liczby wierszy ponad domyślne konfiguracje. Limit wierszy nie uwzględnia szerokości wiersza i może tworzyć małe pliki dla wąskich tabel.

Jeśli używasz Fabric Spark runtime 1.3, włącz adaptacyjne docelowe rozmiary plików i cele kompaktowości na poziomie plików, które są dostępne jako funkcje opcjonalne.

V-Order przynosi korzyści przede wszystkim funkcji Power BI Direct Lake i chociaż może poprawić kompresję w przypadku niektórych obciążeń, zazwyczaj nie jest domyślnie wymagany ani zalecany do uzyskania optymalnej wydajności punktu końcowego analizy SQL.

Domyślne ustawienia zapisu nie zastępują konserwacji tabel. Stosuj następujące praktyki, aby zachować zdrowy układ w miarę zmian tabel:

Włącz automatyczną kompresję dla obciążeń, gdzie okresowe dodatkowe synchroniczne opóźnienia zapisu są akceptowalne. Auto kompaktowanie to funkcja Spark, która działa tylko wtedy, gdy w tabeli jest zbyt wiele małych plików.
Zaplanuj okresowe zadania OPTIMIZE dla obciążeń, w przypadku których dodatkowe okresowe opóźnienie wynikające z automatycznej kompakcji nie spełnia umów SLA dotyczących aktualizacji danych.
Wykonuj VACUUM zgodnie z wymaganiami dotyczącymi przechowywania i podróży w czasie, aby usunąć pliki, do których dziennik Delta już nie odwołuje. VACUUM Zmniejsza to przechowywaną przestrzeń, ale nie poprawia aktywnego układu plików.
Unikaj partycjonowania o wysokiej kardynalności oraz niestandardowych konfiguracji zapisu, które prowadzą do tworzenia wielu małych plików.

Jeśli nie używasz automatycznej kompresji, aby zidentyfikować tabele wymagające konserwacji, użyj potoku danych oraz procedury sys.sp_get_table_health_metrics T-SQL przed uruchomieniem OPTIMIZE. Aby zapoznać się z samouczkiem, zobacz Optimize Lakehouse tables based on health checks (Optymalizowanie tabel usługi Lakehouse na podstawie kontroli kondycji).

Note

Aby uzyskać wskazówki dotyczące ogólnej konserwacji tabel lakehouse, zobacz Run table maintenance from Lakehouse (Uruchamianie konserwacji tabel z usługi Lakehouse).

Zagadnienia dotyczące rozmiaru partycji

Układ partycji wpływa na to, jak długo punkt końcowy analizy SQL zajmuje wykrycie i synchronizację zmian. Duża liczba partycji lub małych plików Parquet zwiększa narzut skanowania metadanych. Postępuj zgodnie z następującymi rozwiązaniami:

Unikaj kolumn partycjonowania o wysokiej krotności, ponieważ mogą powodować utworzenie osobnej partycji dla każdej unikalnej wartości. Wybierz kolumnę, która generuje partycje bliskie lub większe niż 1 GB. Więcej informacji można znaleźć w artykule Delta Lake table partitioning.
Pobieranie wsadowe i strumieniowe może tworzyć małe pliki, gdy zmiany są częste lub niewielkie. Użyj regularnej konserwacji tabel lakehouse do kompaktowania tych plików.

Aby ocenić rozmiar i liczbę plików każdej partycji, użyj przykładowego skryptu do szczegółów partycji.

Przykładowy skrypt szczegółów partycji

Użyj poniższego notesu, aby wydrukować raport opisujący rozmiar i szczegóły partycji podpierających tabelę Delta.

Po pierwsze, podaj ścieżkę ABFSS dla swojej tabeli Delta w zmiennej delta_table_path.
- Możesz uzyskać ścieżkę ABFSS tabeli delta z Eksploratora w portalu Fabric. Kliknij prawym przyciskiem myszy nazwę tabeli, a następnie wybierz COPY PATH z listy opcji.
Skrypt generuje wszystkie partycje dla tabeli Delta.
Skrypt iteruje poszczególne partycje w celu obliczenia całkowitego rozmiaru i liczby plików.
Skrypt zwraca szczegóły partycji, plików na partycje i rozmiar partycji w GB.

Pełny skrypt można skopiować z następującego bloku kodu:

# 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']}")

Opinia

Czy ta strona była pomocna?

Ostatnia aktualizacja o 2026-09-16