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, ...)];