Udostępnij za pośrednictwem


Optymalizacja tabel usługi Delta Lake i kolejność V

Format tabel Lakehouse i Delta Lake są centralne dla usługi Microsoft Fabric, zapewniając, że tabele są zoptymalizowane pod kątem analizy, jest kluczowym wymaganiem. W tym przewodniku opisano pojęcia, konfiguracje i sposoby ich stosowania do najczęściej używanych wzorców użycia danych big data.

Co to jest V-Order?

V-Order to optymalizacja czasu zapisu w formacie pliku parquet, który umożliwia szybkie odczyty w aparatach obliczeniowych usługi Microsoft Fabric, takich jak Power BI, SQL, Spark i inne.

Usługi Power BI i aparaty SQL wykorzystują technologię Microsoft Verti-Scan i pliki parquet uporządkowane w wersji V w celu osiągnięcia czasu dostępu do danych w pamięci. Spark i inne aparaty obliczeniowe inne niż Verti-Scan korzystają również z plików uporządkowanych w wersji V ze średnio 10% szybszym czasem odczytu, w niektórych scenariuszach do 50%.

Funkcja V-Order działa, stosując specjalne sortowanie, dystrybucję grup wierszy, kodowanie słownika i kompresję plików parquet, co wymaga mniej zasobów sieciowych, dysków i procesora CPU w aparatach obliczeniowych w celu ich odczytania, zapewniając wydajność i wydajność. Sortowanie w kolejności wirtualnej ma 15% wpływu na średni czas zapisu, ale zapewnia nawet 50% większą kompresję.

Jest zgodny ze standardem parquet typu open source o 100%; wszystkie aparaty parquet mogą odczytywać go jako zwykłe pliki parquet. Tabele różnicowe są bardziej wydajne niż kiedykolwiek wcześniej; funkcje, takie jak Z-Order, są zgodne z V-Order. Właściwości tabeli i polecenia optymalizacji można używać w kontrolce V-Order na partycjach.

Kolejność V jest stosowana na poziomie pliku parquet. Tabele delta i jego funkcje, takie jak Z-Order, kompaktowanie, próżnia, podróż czasowa itp. są ortogonalne do V-Order, w związku z tym są zgodne i mogą być używane razem w celu uzyskania dodatkowych korzyści.

Kontrolowanie zapisów w kolejności wirtualnej

Kolejność wirtualna jest domyślnie włączona w usłudze Microsoft Fabric i na platformie Apache Spark jest kontrolowana przez następujące konfiguracje.

Konfigurowanie Wartość domyślna opis
spark.sql.parquet.vorder.enabled prawda Steruje zapisem na poziomie sesji V-Order.
TBLPROPERTIES("delta.parquet.vorder.enabled") fałsz Domyślny tryb V-Order w tabelach
Opcja zapisywania ramek danych: parquet.vorder.enabled Unset Kontrolowanie zapisów w kolejności wirtualnej przy użyciu modułu zapisywania ramki danych

Użyj następujących poleceń, aby kontrolować użycie zapisów w kolejności wirtualnej.

Sprawdzanie konfiguracji zamówienia wirtualnego w sesji platformy Apache Spark

%%sql 
SET spark.sql.parquet.vorder.enabled 

Wyłączanie zapisywania zamówień wirtualnych w sesji platformy Apache Spark

%%sql 
SET spark.sql.parquet.vorder.enabled=FALSE 

Włączanie zapisu w kolejności wirtualnej w sesji platformy Apache Spark

Ważne

Po włączeniu na poziomie sesji. Wszystkie zapisy parquet są wykonywane z włączoną obsługą zamówienia wirtualnego. Obejmuje to tabele inne niż delty parquet i tabele delty z właściwością tabeli ustawioną parquet.vorder.enabled na true wartość lub false.

%%sql 
SET spark.sql.parquet.vorder.enabled=TRUE 

Kontrolowanie kolejności maszyn wirtualnych przy użyciu właściwości tabeli delty

Włącz właściwość tabeli V-Order podczas tworzenia tabeli:

%%sql 
CREATE TABLE person (id INT, name STRING, age INT) USING parquet TBLPROPERTIES("delta.parquet.vorder.enabled" = "true");

Ważne

Gdy właściwość tabeli jest ustawiona na true, polecenia INSERT, UPDATE i MERGE będą działać zgodnie z oczekiwaniami i wykonać optymalizację czasu zapisu. Jeśli konfiguracja sesji V-Order jest ustawiona na wartość true lub funkcja spark.write ją włączy, zapisy będą mieć wartość V-Order, nawet jeśli właściwość TBLPROPERTIES jest ustawiona na wartość false.

Włącz lub wyłącz polecenie V-Order, zmieniając właściwość tabeli:

%%sql 
ALTER TABLE person SET TBLPROPERTIES("delta.parquet.vorder.enabled" = "true");

ALTER TABLE person SET TBLPROPERTIES("delta.parquet.vorder.enabled" = "false");

ALTER TABLE person UNSET TBLPROPERTIES("delta.parquet.vorder.enabled");

Po włączeniu lub wyłączeniu klasy V-Order przy użyciu właściwości tabeli mają wpływ tylko przyszłe zapisy w tabeli. Pliki Parquet zachowują kolejność używaną podczas tworzenia. Aby zmienić bieżącą strukturę fizyczną w celu zastosowania lub usunięcia klasy V-Order, przeczytaj sekcję "Sterowanie kolejnością maszyn wirtualnych podczas optymalizowania tabeli" poniżej.

Sterowanie kolejnością wirtualną bezpośrednio na operacjach zapisu

Wszystkie polecenia zapisu platformy Apache Spark dziedziczą ustawienie sesji, jeśli nie jest jawne. Wszystkie następujące polecenia zapisują się przy użyciu klasy V-Order, niejawnie dziedzicząc konfigurację sesji.

df_source.write\
  .format("delta")\
  .mode("append")\
  .saveAsTable("myschema.mytable")

DeltaTable.createOrReplace(spark)\
  .addColumn("id","INT")\
  .addColumn("firstName","STRING")\
  .addColumn("middleName","STRING")\
  .addColumn("lastName","STRING",comment="surname")\
  .addColumn("birthDate","TIMESTAMP")\
  .location("Files/people")\
  .execute()

df_source.write\
  .format("delta")\
  .mode("overwrite")\
  .option("replaceWhere","start_date >= '2017-01-01' AND end_date <= '2017-01-31'")\
  .saveAsTable("myschema.mytable") 

Ważne

V-Order dotyczy tylko plików, których dotyczy predykat.

W sesji, w której spark.sql.parquet.vorder.enabled nie ustawiono wartości false lub ustawiono wartość false, następujące polecenia będą zapisywane przy użyciu polecenia V-Order:

df_source.write\
  .format("delta")\
  .mode("overwrite")\
  .option("replaceWhere","start_date >= '2017-01-01' AND end_date <= '2017-01-31'")\
  .option("parquet.vorder.enabled ","true")\
  .saveAsTable("myschema.mytable")

DeltaTable.createOrReplace(spark)\
  .addColumn("id","INT")\
  .addColumn("firstName","STRING")\
  .addColumn("middleName","STRING")\
  .addColumn("lastName","STRING",comment="surname")\
  .addColumn("birthDate","TIMESTAMP")\
  .option("parquet.vorder.enabled","true")\
  .location("Files/people")\
  .execute()

Co to jest optymalizacja zapisu?

Obciążenia analityczne w aparatach przetwarzania danych big data, takich jak Apache Spark, działają najbardziej wydajnie podczas korzystania ze standardowych większych rozmiarów plików. Relacja między rozmiarem pliku, liczbą plików, liczbą procesów roboczych platformy Spark i jego konfiguracjami odgrywa kluczową rolę w zakresie wydajności. Pozyskiwanie danych do tabel data lake może mieć dziedziczone cechy ciągłego pisania wielu małych plików; ten scenariusz jest powszechnie znany jako "problem z małym plikiem".

Optymalizacja zapisu to funkcja Delta Lake w usłudze Microsoft Fabric i usłudze Azure Synapse Analytics w a aparatie Apache Spark, która zmniejsza liczbę zapisanych plików i ma na celu zwiększenie indywidualnego rozmiaru zapisanych danych. Rozmiar pliku docelowego można zmienić na wymagania dotyczące obciążenia przy użyciu konfiguracji.

Ta funkcja jest domyślnie włączona w środowisku Uruchomieniowym usługi Microsoft Fabric dla platformy Apache Spark. Aby dowiedzieć się więcej na temat optymalizowania scenariuszy użycia zapisu, przeczytaj artykuł Potrzeba optymalizacji zapisu na platformie Apache Spark.

Optymalizacja scalania

Polecenie Delta Lake MERGE umożliwia użytkownikom aktualizowanie tabeli delty przy użyciu zaawansowanych warunków. Może aktualizować dane z tabeli źródłowej, widoku lub ramki danych do tabeli docelowej przy użyciu polecenia MERGE. Jednak bieżący algorytm w dystrybucji typu open source usługi Delta Lake nie jest w pełni zoptymalizowany pod kątem obsługi niezmodyfikowanych wierszy. Zespół funkcji delta platformy Microsoft Spark zaimplementował niestandardową optymalizację scalania niskiego mieszania, niezmodyfikowane wiersze są wykluczane z kosztownej operacji mieszania, która jest wymagana do aktualizowania dopasowanych wierszy.

Implementacja jest kontrolowana przez konfigurację spark.microsoft.delta.merge.lowShuffle.enabled , która jest domyślnie włączona w środowisku uruchomieniowym. Nie wymaga żadnych zmian w kodzie i jest w pełni zgodny z dystrybucją typu open source usługi Delta Lake. Aby dowiedzieć się więcej na temat scenariuszy użycia funkcji Low Shuffle Merge, przeczytaj artykuł Low Shuffle Merge optimization on Delta tables (Optymalizacja scalania z niskimi mieszaniami w tabelach różnicowych).

Konserwacja tabeli delty

W miarę zmiany tabel różnicowych wydajność i wydajność magazynowania mają tendencję do obniżenia wydajności z następujących powodów:

  • Nowe dane dodane do tabeli mogą wypaczyć dane.
  • Współczynnik pozyskiwania danych wsadowych i przesyłanych strumieniowo może przynieść wiele małych plików.
  • Operacje aktualizacji i usuwania ostatecznie tworzą obciążenie odczytu; Pliki parquet są niezmienne zgodnie z projektem, więc tabele delty dodaje nowe pliki parquet z zestawem zmian, dodatkowo wzmacniając problemy nałożone przez pierwsze dwa elementy.
  • Pliki danych i pliki dziennika nie są już potrzebne w magazynie.

Aby zachować tabele w najlepszym stanie, aby zapewnić najlepszą wydajność, wykonaj operacje kompaktowania pojemników i czyszczenia w tabelach delty. Bin-compaction jest osiągany przez polecenie OPTIMIZE ; scala wszystkie zmiany w większych, skonsolidowanych plikach parquet. Czyszczenie magazynu dereferenced jest osiągane przez polecenie VACUUM .

Polecenia konserwacji tabeli OPTIMIZE i VACUUM mogą być używane w notesach i definicjach zadań platformy Spark, a następnie orkiestrowane przy użyciu możliwości platformy. Usługa Lakehouse w usłudze Fabric oferuje funkcję używania interfejsu użytkownika do przeprowadzania konserwacji tabeli ad hoc zgodnie z opisem w artykule Dotyczącym konserwacji tabeli usługi Delta Lake.

Ważne

Prawidłowe projektowanie struktury fizycznej tabeli na podstawie częstotliwości pozyskiwania i oczekiwanych wzorców odczytu jest prawdopodobnie ważniejsze niż uruchomienie poleceń optymalizacji opisanych w tej sekcji.

Kontrolowanie kolejności maszyn wirtualnych podczas optymalizowania tabeli

Następujące struktury poleceń bin-compact i ponowne zapisywanie wszystkich plików, których dotyczy problem, przy użyciu V-Order, niezależnie od ustawienia TBLPROPERTIES lub ustawienia konfiguracji sesji:

%%sql 
OPTIMIZE <table|fileOrFolderPath> VORDER;

OPTIMIZE <table|fileOrFolderPath> WHERE <predicate> VORDER;

OPTIMIZE <table|fileOrFolderPath> WHERE <predicate> [ZORDER  BY (col_name1, col_name2, ...)] VORDER;

Gdy ZORDER i VORDER są używane razem, platforma Apache Spark wykonuje kompaktację bin, ZORDER, VORDER sekwencyjnie.

Następujące polecenia bin-compact i ponowne zapisywanie wszystkich plików, których dotyczy problem, przy użyciu ustawienia TBLPROPERTIES. Jeśli właściwość TBLPROPERTIES jest ustawiona na wartość V-Order, wszystkie pliki, których dotyczy problem, są zapisywane jako V-Order. Jeśli właściwość TBLPROPERTIES nie jest ustawiona lub ustawiona na wartość false na V-Order, dziedziczy ustawienie sesji; aby usunąć kolejność V-Order z tabeli, ustaw konfigurację sesji na wartość false.

%%sql 
OPTIMIZE <table|fileOrFolderPath>;

OPTIMIZE <table|fileOrFolderPath> WHERE predicate;

OPTIMIZE <table|fileOrFolderPath> WHERE predicate [ZORDER BY (col_name1, col_name2, ...)];