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

Dotyczy:✅ punkt końcowy analizy SQL w usłudze Microsoft Fabric

Punkt końcowy analizy SQL umożliwia wykonywanie zapytań dotyczących danych w usłudze Lakehouse przy użyciu języka T-SQL i protokołu TDS. Każdy magazyn lakehouse ma jeden punkt końcowy analizy SQL. Liczba punktów końcowych analizy SQL w obszarze roboczym jest zgodna z liczbą magazynów typu lakehouse i dublowanych baz danych aprowizowania w tym jednym obszarze roboczym.

Proces w tle jest odpowiedzialny za skanowanie bazy danych Lakehouse pod kątem zmian i aktualizowanie punktu końcowego analizy SQL dla wszystkich zmian zatwierdzonych w magazynach typu lakehouse w obszarze roboczym. Proces synchronizacji jest niewidocznie zarządzany przez platformę Microsoft Fabric. Po wykryciu zmiany w usłudze Lakehouse proces 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 są rozbieżne w tym artykule.

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

Punkt końcowy analizy SQL zarządza automatycznie wygenerowanymi tabelami, aby użytkownicy obszaru roboczego nie mogli ich modyfikować. Użytkownicy mogą wzbogacić model bazy danych, dodając własne schematy SQL, widoki, procedury i inne obiekty bazy danych.

Dla każdej tabeli delty w usłudze Lakehouse punkt końcowy analizy SQL automatycznie generuje tabelę w odpowiednim schemacie. Aby uzyskać informacje o automatycznie wygenerowanych typach danych schematu dla punktu końcowego analizy SQL, zobacz Typy danych w usłudze Microsoft Fabric.

Tabele w punkcie końcowym analizy SQL są tworzone z niewielkim opóźnieniem. Po utworzeniu lub zaktualizowaniu tabeli usługi Delta Lake w usłudze Lake tabela punktu końcowego analizy SQL odwołująca się do tabeli usługi Delta Lake zostanie utworzona/odświeżona automatycznie.

Czas potrzebny na odświeżenie tabeli jest związany z tym, jak zoptymalizowane są tabele delty. Aby uzyskać więcej informacji, zapoznaj się z tematem Optymalizacja tabel usługi Delta Lake i Kolejność wirtualna, aby dowiedzieć się więcej na temat kluczowych scenariuszy oraz szczegółowego przewodnika dotyczącego efektywnego utrzymywania tabel delty w celu uzyskania maksymalnej wydajności.

Możesz ręcznie wymusić odświeżenie automatycznego skanowania metadanych w portalu sieci szkieletowej. Na stronie punktu końcowego analizy SQL wybierz przycisk Odśwież na pasku narzędzi Eksploratora , aby odświeżyć schemat. Przejdź do obszaru Zapytanie dotyczące punktu końcowego analizy SQL i wyszukaj przycisk odświeżania, jak pokazano na poniższej ilustracji.

Wskazówki

• Automatyczne odnajdywanie metadanych śledzi zmiany zatwierdzone w usłudze Lakehouse i jest pojedynczym wystąpieniem dla obszaru roboczego usługi Fabric. Jeśli obserwujesz zwiększone opóźnienie zmian synchronizacji między magazynami typu lakehouse i punktem końcowym analizy SQL, może to być spowodowane dużą liczbą magazynów typu lakehouse w jednym obszarze roboczym. W takim scenariuszu rozważ migrację każdego magazynu typu lakehouse do oddzielnego obszaru roboczego, ponieważ umożliwia to automatyczne odnajdywanie metadanych do skalowania.
• Pliki Parquet są niezmienne zgodnie z projektem. W przypadku aktualizacji lub operacji usuwania tabela delty doda nowe pliki parquet z zestawem zmian, zwiększając liczbę plików w czasie, w zależności od częstotliwości aktualizacji i usuwania. Jeśli nie zaplanowano konserwacji, w końcu ten wzorzec tworzy obciążenie odczytu i ma to wpływ na czas potrzebny na synchronizację zmian w punkcie końcowym analizy SQL. Aby rozwiązać ten problem, zaplanuj regularne operacje konserwacji tabel lakehouse.
• W niektórych scenariuszach można zauważyć, że zmiany zatwierdzone w usłudze Lakehouse nie są widoczne w skojarzonym punkcie końcowym analizy SQL. Na przykład możesz utworzyć nową tabelę w usłudze Lakehouse, ale nie jest ona wymieniona w punkcie końcowym analizy SQL. Może też zostać zatwierdzona duża liczba wierszy do tabeli w usłudze Lakehouse, ale te dane nie są widoczne w punkcie końcowym analizy SQL. Zalecamy zainicjowanie synchronizacji metadanych na żądanie wyzwolonej z opcji wstążki Odśwież edytor zapytań SQL. Ta opcja wymusza synchronizację metadanych na żądanie, a nie oczekiwanie na zakończenie synchronizacji metadanych w tle.
• Nie wszystkie funkcje funkcji delta są zrozumiałe przez proces automatycznej synchronizacji. Aby uzyskać więcej informacji na temat funkcji obsługiwanych przez poszczególne aparaty w sieci szkieletowej, zobacz Delta Lake Interoperability (Współdziałanie usługi Delta Lake).
• Jeśli podczas przetwarzania wyodrębniania transformacji i ładowania (ETL) zmienia się bardzo duża liczba tabel, może wystąpić oczekiwane opóźnienie do momentu przetworzenia wszystkich zmian.

Zagadnienia dotyczące rozmiaru partycji

Wybór kolumny partycji dla tabeli delty w usłudze Lakehouse ma również wpływ na czas potrzebny do zsynchronizowania zmian z punktem końcowym analizy SQL. Liczba i rozmiar partycji kolumny partycji są ważne dla wydajności:

• Kolumna o wysokiej kardynalności (głównie lub całkowicie z unikatowych 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ść. Naszym zaleceniem jest użycie kolumny, która spowoduje utworzenie partycji co najmniej (lub blisko) 1 GB. Zalecamy stosowanie najlepszych rozwiązań dotyczących konserwacji tabel różnicowych; optymalizacja. Aby poznać skrypt języka Python do oceny partycji, zobacz Przykładowy skrypt, 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 w tabeli delty znajduje się duża liczba plików parquet z co najmniej jednej przyczyny:

• Jeśli wybierzesz partycję dla tabeli różnicowej z dużą liczbą unikatowych wartości, zostanie ona 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, że rozmiar pojedynczej partycji wynosi co najmniej 1 GB.
• Współczynniki pozyskiwania danych wsadowych i przesyłanych strumieniowo mogą również powodować małe pliki w zależności od częstotliwości i rozmiaru zmian zapisywanych w lakehouse. Na przykład może wystąpić niewielka liczba zmian przechodzących do lakehouse, co spowodowałoby niewielkie pliki parquet. Aby rozwiązać ten problem, zalecamy zaimplementowanie regularnej konserwacji tabel lakehouse.

Przykładowy skrypt szczegółów partycji

Użyj poniższego notesu, aby wydrukować raport ze szczegółowymi informacjami o rozmiarze i szczegółach partycji będących podstawą tabeli różnicowej.

1. Najpierw należy podać ścieżkę ABSFF dla tabeli delty w zmiennej delta_table_path.
   • Ścieżkę ABFSS tabeli różnicowej można pobrać z Poziomu Eksploratora portalu sieci szkieletowej. Kliknij prawym przyciskiem myszy nazwę tabeli, a następnie wybierz COPY PATH z listy opcji.
2. Skrypt zwraca wszystkie partycje dla tabeli delty.
3. Skrypt iteruje poszczególne partycje w celu obliczenia całkowitego rozmiaru i liczby plików.
4. 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']}")

Powiązana zawartość

• Lepsze razem: jezioro i magazyn
• Wytyczne dotyczące wydajności magazynu danych sieci szkieletowej
• Ograniczenia punktu końcowego analizy SQL