Najlepsze praktyki dotyczące usługi Delta Lake

W tym artykule opisano najlepsze rozwiązania dotyczące korzystania z usługi Delta Lake.

Omówienie najlepszych rozwiązań

Poniżej przedstawiono ogólne zalecenia dotyczące większości obciążeń usługi Delta Lake:

• Używaj tabel zarządzanych w Unity Catalog. Zobacz Tabele zarządzane przez katalog Unity w usłudze Azure Databricks dla Delta Lake i Apache Iceberg.
• Użyj optymalizacji predykcyjnej. Zobacz Optymalizacja predykcyjna dla tabel zarządzanych przez Unity Catalog.
• Użyj klastrowania płynnego. Zobacz Używaj płynnego grupowania dla tabel.
• Podczas usuwania i ponownego tworzenia tabeli w tej samej lokalizacji należy zawsze użyć instrukcji CREATE OR REPLACE TABLE . Zobacz Usuwanie lub zastępowanie tabeli Delta.

Usuń legacyjne konfiguracje Delta

Databricks zaleca usunięcie większości jawnych starszych konfiguracji Delta z konfiguracji Spark i właściwości tabeli podczas uaktualniania do nowej wersji środowiska Databricks Runtime. Starsze konfiguracje mogą uniemożliwiać stosowanie nowych optymalizacji i wartości domyślnych wprowadzonych przez usługę Databricks do migrowanych obciążeń.

Kompaktowanie plików

Optymalizacja predykcyjna automatycznie uruchamia polecenia OPTIMIZE i VACUUM na tabelach zarządzanych katalogiem Unity Catalog. Zobacz Optymalizacja predykcyjna dla tabel zarządzanych przez Unity Catalog.

Usługa Databricks zaleca częste uruchamianie polecenia OPTIMIZE w celu kompaktowania małych plików.

Nie używaj buforowania w Spark z Delta Lake

Usługa Databricks nie zaleca używania buforowania platformy Spark z następujących powodów:

• Utracisz wszelką możliwość pomijania danych, które mogą pochodzić z dodatkowych filtrów nałożonych na pamięć podręczną DataFrame.
• Dane, które są buforowane, mogą nie zostać zaktualizowane, jeśli do tabeli uzyskuje się dostęp przy użyciu innego identyfikatora.

Różnice między Delta Lake i Parquet na platformie Apache Spark

Usługa Delta Lake automatycznie obsługuje następujące operacje. Nigdy nie należy wykonywać tych operacji ręcznie:

• REFRESH TABLE: Tabele Delta zawsze zwracają najbardziej aktualne informacje, więc nie ma potrzeby ręcznego wywoływania REFRESH TABLE po zmianach.
• Dodawanie i usuwanie partycji: usługa Delta Lake automatycznie śledzi zestaw partycji znajdujących się w tabeli i aktualizuje listę w miarę dodawania lub usuwania danych. W związku z tym nie ma potrzeby uruchamiania ALTER TABLE [ADD|DROP] PARTITION ani MSCK.
• Ładowanie pojedynczej partycji: bezpośrednie odczytywanie partycji nie jest konieczne. Na przykład nie trzeba uruchamiać spark.read.format("parquet").load("/data/date=2017-01-01"). Zamiast tego użyj klauzuli WHERE do pomijania danych, takiej jak spark.read.table("<table-name>").where("date = '2017-01-01'").
• Nie modyfikuj ręcznie plików danych: Delta Lake używa dziennika transakcji do atomowego zatwierdzania zmian w tabeli. Nie należy bezpośrednio modyfikować, dodawać ani usuwać plików danych Parquet w tabeli delty, ponieważ może to prowadzić do utraty danych lub uszkodzenia tabeli.

Zwiększanie wydajności scalania usługi Delta Lake

Możesz skrócić czas potrzebny na scalenie, korzystając z następujących metod:

• Zmniejsz przestrzeń wyszukiwania dla dopasowań: domyślnie merge operacja przeszukuje całą tabelę delty w celu znalezienia dopasowań w tabeli źródłowej. Jednym ze sposobów przyspieszenia merge jest zmniejszenie przestrzeni wyszukiwania przez dodanie znanych ograniczeń w warunku dopasowania. Załóżmy na przykład, że masz tabelę podzieloną na country i date, i chcesz użyć merge do zaktualizowania informacji z ostatniego dnia i określonego kraju. Dodanie następującego warunku sprawia, że zapytanie jest szybsze, ponieważ wyszukuje dopasowania tylko w odpowiednich partycjach:

  events.date = current_date() AND events.country = 'USA'
  

  Ponadto to zapytanie zmniejsza również prawdopodobieństwo konfliktów z innymi operacjami współbieżnymi. Aby uzyskać więcej informacji, zobacz Poziomy izolacji i konflikty zapisu w usłudze Azure Databricks.

• Pliki kompaktowe: jeśli dane są przechowywane w wielu małych plikach, odczytywanie danych w celu wyszukiwania dopasowań może stać się powolne. W celu zwiększenia przepływności odczytu można skompaktować małe pliki w większe pliki. Aby uzyskać szczegółowe informacje, zobacz Optymalizowanie układu pliku danych.

• Kontroluj partycje tasowania dla operacji zapisu: merge operacja wielokrotnie tasuje dane w celu obliczenia i zapisania zaktualizowanych danych. Liczba zadań używanych do mieszania jest kontrolowana przez konfigurację sesji platformy Spark spark.sql.shuffle.partitions. Ustawienie tego parametru nie tylko steruje równoległością, ale także określa liczbę plików wyjściowych. Zwiększenie wartości zwiększa równoległość, ale także generuje większą liczbę mniejszych plików danych.

• Włącz zoptymalizowane zapisy: w przypadku tabel merge partycjonowanych może utworzyć znacznie większą liczbę małych plików niż liczba partycji mieszania. Dzieje się tak, ponieważ każde zadanie miksowania może zapisywać wiele plików w wielu partycjach i może stać się wąskim gardłem dla wydajności. Liczbę plików można zmniejszyć, włączając zoptymalizowane zapisy. Zobacz Zoptymalizowane operacje zapisu dla Delta Lake na platformie Azure Databricks.

• Dostrajanie rozmiarów plików w tabeli: usługa Azure Databricks może automatycznie wykrywać, czy tabela delty ma częste merge operacje, które ponownie zapisują pliki i mogą zmniejszyć rozmiar plików przepisanych w oczekiwaniu na dalsze ponowne zapisywanie plików w przyszłości. Aby uzyskać szczegółowe informacje, zobacz sekcję dotyczącą dostrajania rozmiarów plików.

• Low Shuffle Merge: Low Shuffle Merge zapewnia zoptymalizowaną implementację MERGE , która zapewnia lepszą wydajność dla najbardziej typowych obciążeń. Ponadto zachowuje istniejące optymalizacje układu danych, takie jak Z-ordering dla danych, które nie zostały zmodyfikowane.