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 Microsoft Fabric w sposób niewidoczny 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ę.

Duża liczba małych plików Parquet tworzy obciążenie i negatywnie wpływa na wydajność zapytań. Aby zapewnić przewidywalną i wydajną wydajność, zachowaj magazyn tabel, tak aby każdy plik Parquet zawierał dwa miliony wierszy. Ta liczba wierszy zapewnia zrównoważony poziom równoległości bez fragmentowania zestawu danych w zbyt małe wycinki.

Oprócz wskazówek dotyczących liczby wierszy rozmiar pliku jest równie ważny. Punkt końcowy analizy SQL działa najlepiej, gdy pliki Parquet są wystarczająco duże, aby zminimalizować obciążenie związane z obsługą plików, ale nie tak duże, aby ograniczyć wydajność skanowania równoległego. W przypadku większości obciążeń utrzymywanie poszczególnych plików Parquet na poziomie około 400 MB stanowi najlepszy kompromis. Aby osiągnąć tę równowagę, wykonaj następujące czynności:

  1. Ustaw maxRecordsPerFile wartość 2000 000 przed wprowadzeniem zmian danych.
  2. Przeprowadź zmiany danych (pozyskiwanie danych, aktualizacje, usuwanie).
  3. Ustaw maxFileSize wartość 4 GB.
  4. Uruchom program OPTIMIZE. Aby uzyskać szczegółowe informacje na temat korzystania z usługi OPTIMIZE, zobacz Run table maintenance from Lakehouse (Uruchamianie konserwacji tabeli z usługi Lakehouse).

Poniższy skrypt zawiera szablon dla tych kroków i należy go uruchomić na lakehouse:

from delta.tables import DeltaTable

# 1. CONFIGURE LIMITS

# Cap files to 2M rows during writes. This should be done before data ingestion occurs. 
spark.conf.set("spark.sql.files.maxRecordsPerFile", 2000000)

# 2. INGEST DATA
# Here, you ingest data into your table 

# 3. CAP FILE SIZE (~4GB)
spark.conf.set("spark.databricks.delta.optimize.maxFileSize", 4 * 1024 * 1024 * 1024)

# 4. RUN OPTIMIZE (bin-packing)
spark.sql("""
    OPTIMIZE myTable
""")

Aby utrzymać rozmiary plików na odpowiednim poziomie, okresowo uruchamiaj operacje optymalizacji Delta, takie jak OPTIMIZE, zwłaszcza w przypadku tabel, do których często są wykonywane przyrostowe wstawienia, aktualizacje i usunięcia. Te operacje konserwacji kompaktują małe pliki w odpowiednie rozmiary, co pomaga zapewnić wydajne przetwarzanie zapytań przez punkt końcowy analizy SQL.

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 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 (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). Postępuj zgodnie z najlepszymi praktykami dotyczącymi konserwacji i optymalizacji tabel Delta oraz optymalizacji. 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 w tabeli delty znajduje się duża liczba plików parquet z co najmniej jednej przyczyny:

  • 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 notatnika, aby wygenerować raport ze szczegółowymi informacjami o rozmiarze i cechach partycji wspierających tabelę delta.

  1. Najpierw podaj ścieżkę ABFSS dla tabeli delty 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.
  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']}")

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.

Treści powiązane

  • Last updated on