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.

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 jest uruchamiany tylko wtedy, gdy punkt końcowy analizy SQL jest aktywny i zatrzymuje się po 15 minutach braku aktywności.

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. Istnieje możliwość rozpoczęcia synchronizacji metadanych na żądanie.
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.

Nie potrzebujesz V-Order, aby poprawić wydajność punktu końcowego analizy SQL, ponieważ Spark zapisuje pliki Parquet skompresowane algorytmem Snappy, co zmniejsza operacje wejścia/wyjścia zarówno podczas odczytu, jak i zapisu.

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

Wybór kolumny partycji dla tabeli Delta w lakehouse wpływa również na czas synchronizacji zmian z punktem końcowym SQL analityki. Liczba i rozmiar partycji kolumny partycji są ważne dla wydajności:

Kolumna o wysokiej kardynalności (złożona głównie lub całkowicie z unikalnych wartości) powoduje dużą liczbę partycji. Duża liczba partycji negatywnie wpływa na wydajność skanowania odnajdywania metadanych pod kątem zmian. Jeśli kardynalność kolumny jest wysoka, wybierz inną kolumnę do partycjonowania.
Rozmiar każdej partycji może również mieć wpływ na wydajność. Użyj kolumny, która daje partycję o rozmiarze co najmniej 1 GB (lub zbliżonym do 1 GB). Stosuj się do najlepszych praktyk dotyczących utrzymania i partycjonowania tabel Delta. Aby uzyskać skrypt Python do oceny partycji, zobacz skrypt Sample, aby uzyskać szczegółowe informacje o partycji.

Duża liczba małych plików parquet zwiększa czas synchronizacji zmian między usługą Lakehouse i skojarzonym z nim punktem końcowym analizy SQL. Może się okazać, że masz dużą liczbę plików Parquet w tabeli Delta z jednego lub kilku powodów:

Jeśli wybierzesz partycję dla tabeli delty z dużą liczbą unikatowych wartości, tabela zostanie podzielona na partycje według każdej unikatowej wartości i może być nadmiernie partycjonowana. Wybierz kolumnę partycji, która nie ma wysokiej kardynalności, i powoduje utworzenie co najmniej 1 GB poszczególnych partycji.
Szybkości pozyskiwania danych wsadowych i przesyłanych strumieniowo mogą również powodować powstawanie małych plików, zależnie od częstotliwości i wielkości zmian, które są zapisywane w architekturze lakehouse. Na przykład może wystąpić niewielka liczba zmian wprowadzanych do lakehouse, co powoduje powstawanie małych plików parquet. Aby rozwiązać ten problem, zaimplementuj regularną konserwację tabel lakehouse.

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

Automatycznie wygenerowany schemat w punkcie końcowym analizy SQL usługi Lakehouse

Dla każdej tabeli delty w usłudze Lakehouse punkt końcowy analizy SQL automatycznie generuje tabelę w odpowiednim schemacie. Silnik punktu końcowego analizy SQL jest oparty na silniku Fabric Data Warehouse.

Aby uzyskać więcej informacji, zobacz Synchronizacja metadanych punktu końcowego analizy SQL. Można również programowo wymusić odświeżenie automatycznego skanowania metadanych przy użyciu interfejsu API REST odświeżania metadanych punktu końcowego SQL.

Opinia

Czy ta strona była pomocna?

Last updated on 2026-08-27