Utrzymanie i optymalizacja tabel współdzielonych między obciążeniami w usłudze Microsoft Fabric

Tabele Delta w usłudze Microsoft Fabric obsługują wiele silników przetwarzania, każdy z nich ma różne cechy wydajności i wymagania dotyczące optymalizacji. Ten przewodnik zawiera kompleksowe ramy umożliwiające zrozumienie sposobu, w jaki tabele napisane przez jeden silnik są wykorzystywane przez inne silniki oraz jak odpowiednio zoptymalizować strategie zarządzania tabelami.

Zrozumienie relacji między wydajnością odczytu i wzorcami zapisu w różnych silnikach jest niezbędne do projektowania wydajnych platform danych. Celem jest zapewnienie, że producenci danych tworzą układy tabel, które optymalizują wydajność odczytu dla odbiorców podrzędnych, niezależnie od tego, czy użytkownicy korzystają z platformy Spark, punktu końcowego analizy SQL, usługi Power BI Direct Lake, czy magazynu.

Macierz scenariuszy zapisu i odczytu

W poniższej tabeli przedstawiono podsumowanie oczekiwanych cech wydajności typowych kombinacji zapisu i odczytu wraz z zalecanymi strategiami optymalizacji. Ta macierz służy do identyfikowania scenariusza i zrozumienia odpowiednich wskazówek.

Metoda zapisu	Aparat odczytu	Oczekiwane luki	Zalecana strategia
Partia Spark	Spark	Brak przerw	Domyślne konfiguracje zapisu platformy Spark są wystarczające
Przetwarzanie wsadowe Spark	Punkt końcowy analizy SQL	Brak przerw	Włączanie automatycznego kompaktowania i optymalizowania zapisu
Przesyłanie strumieniowe na platformie Spark	Spark	Możliwe małe pliki	Automatyczne kompaktowanie i optymalizowanie zapisu przy użyciu zaplanowanej funkcji OPTIMIZE
Przesyłanie strumieniowe na platformie Spark	Punkt końcowy analizy SQL	Małe pliki i punkty kontrolne	Automatyczne kompaktowanie, optymalizacja zapisu i dzielenie warstw typu medallion
Magazyn	Spark	Brak przerw	Optymalizacja zarządzana przez system obsługuje układ
Magazyn	Punkt końcowy analizy SQL	Brak przerw	Optymalizacja zarządzana przez system obsługuje układ

Optymalne układy plików według silnika

Różne mechanizmy konsumpcji mają różne optymalne układy plików. Zrozumienie tych celów pomaga odpowiednio skonfigurować operacje zapisu i zadania konserwacji.

Wskazówki dotyczące interfejsu analizy SQL i przechowywania danych Fabric

Aby uzyskać optymalną wydajność z punktem końcowym analizy SQL i magazynem, użyj następujących ustawień:

Rozmiar pliku docelowego: około 400 MB na plik
Rozmiar grupy wierszy: około 2 miliony wierszy na grupę
V-Order: poprawia wydajność odczytu o 10%

Magazyn używa tych kryteriów do odnajdywania kandydatów do kompaktowania:

Obciążenie związane z plikiem tabeli wynosi ponad 10%
Liczba logicznie usuniętych wierszy w tabeli przekracza 10%
Rozmiar tabeli jest większy niż 1024 wierszy

Podczas wykonywania kompaktowania proces wybiera kandydatów na podstawie następujących kryteriów:

Każdy plik jest mniejszy niż 25% idealnego rozmiaru (na podstawie liczby wierszy)
Każdy plik ma więcej niż 20% usuniętych wierszy

Spark

Platforma Spark jest niezawodna podczas odczytywania różnych rozmiarów plików. Aby uzyskać optymalną wydajność:

Rozmiar pliku docelowego: od 128 MB do 1 GB w zależności od rozmiaru tabeli
Rozmiar grupy wierszy: od 1 miliona do 2 milionów na grupę wierszy
V-Order: nie jest wymagana w przypadku wydajności odczytu w Spark (może dodać koszt zapisu 15–33%)

Odczyty platformy Spark korzystają z adaptacyjnego rozmiaru pliku docelowego, który automatycznie dostosowuje się na podstawie rozmiaru tabeli:

Tabele poniżej 10 GB: cel 128 MB
Tabele powyżej 10 TB: do 1 GB miejsca docelowego

Power BI Direct Lake

Aby uzyskać optymalną wydajność usługi Direct Lake:

Rozmiar grupy wierszy docelowych: 8 milionów lub więcej wierszy na grupę wierszy w celu uzyskania najlepszej wydajności
V-Order: Krytyczne dla 40-60% poprawy wydajności zapytań przy zimnym cache'u
Liczba plików: zminimalizuj liczbę plików, aby zmniejszyć obciążenie związane z transkodowaniem
Spójne rozmiary plików: ważne dla przewidywalnej wydajności zapytań

Modele semantyczne usługi Direct Lake działają najlepiej, gdy:

Dane kolumn są uporządkowane w wersji V dla kompresji zgodnej z protokołem VertiPaq
Grupy wierszy są wystarczająco duże, aby efektywnie scalać słownik
Wektory usuwania są zminimalizowane przez zwykłe kompaktowanie

Aby uzyskać więcej informacji, zobacz Omówienie wydajności zapytań w usłudze Direct Lake.

Odwzorowywanie

Dublowanie automatycznie rozmiaruje pliki na podstawie woluminu tabeli:

Rozmiar tabeli	Wiersze na grupę wierszy	Wiersze na plik
Mały (do 10 GB)	2 miliony	10 mln
Średni (od 10 GB do 2,56 TB)	4 miliony	60 milionów
Duży (ponad 2,56 TB)	8 mln	80 milionów

Tworzenie wzorców i konfiguracji

Wzorce zapisu platformy Spark

Zapisy w Spark używają następujących domyślnych konfiguracji:

Konfiguracja	Wartość domyślna	Opis
`spark.microsoft.delta.optimizeWrite.fileSize`	128 MB	Rozmiar pliku docelowego dla zoptymalizowanych zapisów
`spark.databricks.delta.optimizeWrite.enabled`	Różni się w zależności od profilu	Umożliwia automatyczne łączenie plików
`spark.databricks.delta.autoCompact.enabled`	Disabled	Umożliwia kompaktowanie po zapisie
`spark.sql.files.maxRecordsPerFile`	Unlimited	Maksymalna liczba rekordów na plik

Aby skonfigurować zapisy platformy Spark na potrzeby podrzędnego użycia kodu SQL:

# Enable optimize write for better file layout
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable auto-compaction for automatic maintenance
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

Aby uzyskać więcej informacji na temat profilów zasobów i ich wartości domyślnych, zobacz Konfigurowanie konfiguracji profilu zasobów.

Wzorce zapisu magazynu

Magazyn automatycznie optymalizuje układ danych podczas zapisu:

V-Order jest domyślnie włączony na potrzeby optymalizacji odczytu.
Automatyczne kompaktowanie jest uruchamiane jako proces w tle.
Zarządzanie punktami kontrolnymi jest obsługiwane automatycznie.

Magazyn tworzy pliki zoptymalizowane pod kątem użycia kodu SQL bez ręcznej interwencji. Tabele zapisywane przez Magazyn Danych są z natury zoptymalizowane pod kątem interfejsu analizy SQL i odczytów z magazynu.

Operacje konserwacji tabel

POLECENIE OPTIMIZE

Polecenie OPTIMIZE konsoliduje małe pliki w większe pliki:

-- Basic optimization
OPTIMIZE schema_name.table_name

-- Optimization with V-Order for Power BI consumption
OPTIMIZE schema_name.table_name VORDER

-- Optimization with Z-Order for specific query patterns
OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Ważne

Polecenie OPTIMIZE to polecenie Spark SQL. Należy go uruchomić w środowiskach Spark, takich jak notesy, definicje zadań platformy Spark lub interfejs konserwacji usługi Lakehouse. Punkt końcowy analizy SQL i edytor zapytań SQL magazynu nie obsługują tego polecenia.

Aby uzyskać więcej informacji, zobacz Kompaktowanie tabel.

Automatyczne kompaktowanie

Automatyczne kompaktowanie automatycznie ocenia kondycję partycji po każdej operacji zapisu i wyzwala optymalizację synchroniczną po wykryciu fragmentacji pliku:

# Enable at session level
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
""")

Użyj automatycznego kompaktowania dla potoków przetwarzania z częstymi małymi zapisami (przesyłanie strumieniowe lub mikropartie), aby uniknąć ręcznego planowania i utrzymywać pliki skompaktowane automatycznie.

Automatyczne kompaktowanie i optymalizowanie zapisu zwykle dają najlepsze wyniki, gdy są używane razem. Optymalizacja zapisu zmniejsza liczbę zapisanych małych plików, a automatyczne kompaktowanie obsługuje pozostałą fragmentację.

Aby uzyskać więcej informacji, zobacz Autokompaktacja.

Optymalizowanie zapisu

Optymalizowanie zapisu zmniejsza obciążenie związane z małymi plikami, wykonując kompaktowanie przed zapisem, co powoduje zmniejszenie liczby większych plików:

# Enable at session level
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.optimizeWrite' = 'true')
""")

Optymalizowanie zapisu jest korzystne dla:

Tabele partycjonowane
Tabele z częstymi małymi wstawkami
Operacje dotykające wielu plików (MERGE, UPDATE, DELETE)

Kompaktowanie przed zapisem (optymalizowanie zapisu) jest zwykle mniej kosztowne niż kompaktowanie po zapisie (optymalizowanie). Aby uzyskać więcej informacji, zobacz Optymalizowanie zapisu.

POLECENIE VACUUM

Polecenie VACUUM usuwa stare pliki, do których dziennik tabeli delty nie odwołuje się już:

-- Remove files older than the default retention period (7 days)
VACUUM schema_name.table_name

-- Remove files older than specified hours
VACUUM schema_name.table_name RETAIN 168 HOURS

Domyślny okres przechowywania wynosi siedem dni. Ustawienie krótszych okresów przechowywania wpływa na możliwości podróży w czasie w systemie Delta i może powodować problemy z jednoczesnymi czytelnikami lub autorami.

Aby uzyskać więcej informacji, zobacz Konserwacja tabel lakehouse.

Optymalizacja V-Order

V-Order to optymalizacja czasu zapisu, która stosuje sortowanie, kodowanie i kompresję zgodne z protokołem VertiPaq do plików Parquet:

Usługa Power BI Direct Lake: 40–60% poprawa zapytań dla zimnego cache'u
Punkt końcowy analityki SQL i magazyn danych: około 10% poprawy wydajności odczytu
Spark: bez inherentnej korzyści przy odczycie; 15–33% wolniejsze zapisy

Kiedy włączyć kolejność V-Order

V-Order zapewnia największą korzyść dla:

Tabele warstwy złotej obsługujące Power BI Direct Lake
Tabele często odpytywane za pośrednictwem punktu końcowego analizy SQL
Obciążenia z dużym obciążeniem odczytu, w których wydajność zapisu jest mniej krytyczna

Kiedy unikać V-Order

Rozważ wyłączenie V-Order dla:

Tabele warstw z brązu skoncentrowane na szybkości pozyskiwania
Potoki Spark-to-Spark, w których SQL i Power BI nie wykorzystują danych
Obciążenia z dużym obciążeniem zapisu, w których opóźnienie danych ma krytyczne znaczenie

Konfigurowanie V-Order

V-Order jest domyślnie wyłączony w nowych obszarach roboczych Fabric. Aby ją włączyć:

# Enable at session level (default for all writes)
spark.conf.set('spark.sql.parquet.vorder.default', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.parquet.vorder.enabled' = 'true')
""")

Aby selektywnie zastosować V-Order w oparciu o użycie Direct Lake, rozważ zautomatyzowanie włączania V-Order dla tabel używanych w modelach semantycznych Direct Lake. Tabele niewykorzystywane przez Direct Lake mogą pozostać bez kolejności V-Order dla lepszej wydajności zapisu.

Aby uzyskać więcej informacji, zobacz optymalizacja tabel Delta Lake i V-Order.

Klastrowanie płynne i kolejność Z

Klasteryzacja cieczy

Klaster Liquid jest zalecanym podejściem dla organizacji danych. W przeciwieństwie do tradycyjnego partycjonowania, Liquid Clustering:

Dostosowuje się do zmieniających się wzorców zapytań
Wymaga OPTIMIZE zastosowania klastrowania
Zapewnia lepsze pomijanie plików dla filtrowanych zapytań

Włącz funkcję Liquid Clustering podczas tworzenia tabeli:

CREATE TABLE schema_name.table_name (
    id INT,
    category STRING,
    created_date DATE
) CLUSTER BY (category)

Z-Order

Z-Order kolokuje powiązane dane w tych samych plikach, dzięki czemu uzyskujesz lepszą wydajność zapytań względem predykatów filtrów.

OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Użyj opcji Z-Order, gdy:

Tabela jest podzielona na partycje, ponieważ klaster Liquid nie działa z tabelami podzielonymi na partycje.
Twoje zapytania często filtrują jednocześnie dwie lub więcej kolumn.
Predykaty są wystarczająco selektywne, aby skorzystać z pomijania plików.

Zalecenia dotyczące architektury medalonu

Architektura medalionu (warstwy Brązowa, Srebrna, Złota) udostępnia platformę do optymalizowania strategii konserwacji tabel w oparciu o przeznaczenie każdej warstwy.

Warstwa brązu (strefa lądowania)

Tabele z brązu koncentrują się na wydajności zapisu i niskiej latencji w trakcie pobierania danych.

Priorytet optymalizacji: Szybkość pozyskiwania danych nad wydajność odczytu
Partycjonowanie: akceptowalne, ale zniechęcone do nowych implementacji
Małe pliki: Są akceptowalne, ponieważ koncentracja jest na szybkości przetwarzania.
V-Order: Niezalecane (dodaje obciążenie zapisu)
Automatyczne kompaktowanie: Umożliwia zmniejszenie liczby małych plików, co może być kosztem szybkości pozyskiwania
Wektory usuwania: włącz dla tabel ze wzorcami scalania

Tablice brązowe nie powinny być udostępniane bezpośrednio na punkt końcowy analityki SQL ani dla użytkowników Power BI Direct Lake.

Warstwa Srebrna (strefa wyselekcjonowana)

Stoły Silver równoważą wydajność zapisu i odczytu:

Priorytet optymalizacji: równowaga między pozyskiwaniem i wydajnością zapytań
Rozmiary plików: umiarkowane (128–256 MB) do obsługi operacji zapisu i odczytu
V-Order: Opcjonalne; włącz, jeśli punkt końcowy analizy SQL lub użycie usługi Power BI jest znaczące
Liquid Clustering or Z-Order: zalecane, aby zwiększyć wydajność zapytań
Automatyczne kompaktowanie i optymalizowanie zapisu: włącz na podstawie wymagań podrzędnych
Wektory usuwania: włącz dla tabel z częstymi aktualizacjami
Zaplanowana optymalizacja: agresywne uruchamianie w celu utrzymania układu plików

Warstwa złota (strefa serwisowa)

Złote tabele ustalają priorytety wydajności odczytu dla użycia przez użytkowników końcowych:

Priorytet optymalizacji: Wydajność odczytu na potrzeby analizy
Rozmiary plików: duże (od 400 MB do 1 GB) w celu uzyskania optymalnej wydajności sql i usługi Power BI
V-Order: wymagana dla Power BI Direct Lake; korzystna dla punktu końcowego analizy SQL
Klastrowanie płynów: wymagane do optymalnego pomijania plików
Optymalizowanie zapisu: wymagane w przypadku spójnych rozmiarów plików
Zaplanowana optymalizacja: uruchamianie agresywne w celu zachowania optymalnego układu

Zoptymalizuj tabele złota różnie, w zależności od podstawowego silnika zużycia.

Silnik zużycia	Porządek V	Rozmiar pliku docelowego	Rozmiar grupy wierszy
Punkt końcowy analizy SQL	Tak	400 MB	2 miliony wierszy
Power BI Direct Lake	Tak	Od 400 MB do 1 GB	Ponad 8 milionów wierszy
Spark	Opcjonalnie	Od 128 MB do 1 GB	1–2 miliony wierszy

Wiele kopii tabeli

Dopuszczalne jest utrzymywanie wielu kopii tabel zoptymalizowanych pod kątem różnych wzorców zużycia:

Tabela Silver zoptymalizowana pod kątem przetwarzania platformy Spark
Tabela Gold zoptymalizowana pod kątem punktu końcowego analizy SQL i usługi Power BI Direct Lake
Potoki danych, które przekształcają i umieszczają odpowiednią strukturę na każdej warstwie

Pamięć masowa jest niedroga w stosunku do obliczeń. Optymalizacja tabel pod kątem wzorców zużycia zapewnia lepsze środowisko użytkownika niż próba obsługi wszystkich użytkowników z jednego układu tabeli.

Identyfikowanie kondycji tabeli

Przed optymalizacją tabel oceń bieżącą kondycję tabeli, aby zrozumieć potrzeby optymalizacji.

Bezpośrednie sprawdzanie plików Parquet

Możesz przeglądać folder tabeli w OneLake, aby przejrzeć rozmiary poszczególnych plików Parquet. Tabele w dobrej kondycji mają równomiernie rozłożone rozmiary plików. Wyszukaj:

Spójne rozmiary plików: Pliki powinny mieć mniej więcej taki sam rozmiar (w odległości 2x od siebie).
Brak bardzo małych plików: pliki poniżej 25 MB wskazują fragmentację.
Brak bardzo dużych plików: pliki ponad 2 GB mogą zmniejszyć równoległość.

Nierówna dystrybucja rozmiaru plików często wskazuje brak kompaktowania lub niespójnych wzorców zapisu w różnych zadaniach.

OPTYMALIZOWANIE PRZEBIEGU SUCHEGO W usłudze Spark SQL

DRY RUN Użyj opcji , aby wyświetlić podgląd plików, które kwalifikują się do optymalizacji bez wykonywania kompaktowania:

-- Preview files eligible for optimization
OPTIMIZE schema_name.table_name DRY RUN

Polecenie zwraca listę plików, które zostaną przepisane podczas optymalizacji. Użyj tego aby:

Przed uruchomieniem należy ocenić zakres optymalizacji.
Omówienie fragmentacji pliku bez modyfikowania tabeli.
Szacowanie czasu optymalizacji na podstawie liczby plików, których dotyczy problem.

Dystrybucja rozmiaru pliku

Użyj następującego podejścia do analizowania rozmiarów i dystrybucji plików:

from delta.tables import DeltaTable

# Get table details
details = spark.sql("DESCRIBE DETAIL schema_name.table_name").collect()[0]
print(f"Table size: {details['sizeInBytes'] / (1024**3):.2f} GB")
print(f"Number of files: {details['numFiles']}")

# Average file size
avg_file_size_mb = (details['sizeInBytes'] / details['numFiles']) / (1024**2)
print(f"Average file size: {avg_file_size_mb:.2f} MB")

Dystrybucja może być niesymetryczna, ponieważ pliki w pobliżu głowy tabeli lub z określonej partycji mogą nie być zoptymalizowane.

Rozkład można ocenić, uruchamiając zapytanie, które grupuje według kluczy partycjonowania lub klastrowania tabeli.

Określanie potrzeb optymalizacji

Na podstawie silnika zużycia porównaj rzeczywiste rozmiary plików z rozmiarami docelowymi:

Engine	Rozmiar pliku docelowego	Jeśli pliki są mniejsze	Jeśli pliki są większe
Punkt końcowy analizy SQL	400 MB	Uruchom `OPTIMIZE`	Pliki są dopuszczalne
Power BI Direct Lake	Od 400 MB do 1 GB	Uruchom `OPTIMIZE VORDER`	Pliki są dopuszczalne
Spark	Od 128 MB do 1 GB	Włącz automatyczne kompaktowanie	Pliki są dopuszczalne

Historia tabel i dziennik transakcji

Przejrzyj historię tabel, aby zrozumieć wzorce zapisu i częstotliwość konserwacji:

-- View table history
DESCRIBE HISTORY schema_name.table_name

-- Check for auto-compaction runs
-- Auto-compaction shows as OPTIMIZE with auto=true in operationParameters

Najlepsze rozwiązania dotyczące konfiguracji

Używanie właściwości tabeli w konfiguracjach sesji

Właściwości tabeli są utrwalane między sesjami i zapewniają spójne zachowanie we wszystkich zadaniach i procesach zapisu.

# Recommended: Set at table level for consistency
spark.sql("""
    CREATE TABLE schema_name.optimized_table (
        id INT,
        data STRING
    )
    TBLPROPERTIES (
        'delta.autoOptimize.optimizeWrite' = 'true',
        'delta.autoOptimize.autoCompact' = 'true',
        'delta.parquet.vorder.enabled' = 'true'
    )
""")

Konfiguracje na poziomie sesji dotyczą tylko bieżącej sesji platformy Spark i mogą powodować niespójne zapisy, jeśli różne sesje używają różnych konfiguracji.

Włączanie adaptacyjnego rozmiaru pliku docelowego

Adaptacyjny cel rozmiaru pliku automatycznie dostosowuje cele dotyczące rozmiaru pliku na podstawie rozmiaru tabeli.

spark.conf.set('spark.microsoft.delta.targetFileSize.adaptive.enabled', 'true')

Ta funkcja:

Rozpoczyna się od mniejszych plików (128 MB) dla małych tabel
Skaluje do 1 GB dla tabel powyżej 10 TB
Automatyczne ponowne ocenianie podczas OPTIMIZE operacji

Włączanie celów kompaktowania na poziomie plików

Zapobiegaj ponownemu zapisywaniu wcześniej skompaktowanych plików, gdy rozmiary docelowe się zmieniają:

spark.conf.set('spark.microsoft.delta.optimize.fileLevelTarget.enabled', 'true')

Podsumowanie zaleceń

Warstwa	Automatyczne kompaktowanie	Optymalizowanie zapisu	Porządek V	Klasteryzacja cieczy	Zaplanowane OPTYMALIZOWANIE
Brąz	Włącz (opcjonalnie)	Enable	Nie.	Nie.	Opcjonalnie
Srebro	Enable	Enable	Opcjonalnie	Tak	Aggressive
Złoto	Enable	Enable	Tak	Tak	Aggressive

W przypadku określonych scenariuszy użyj następujących zaleceń:

Spark-to-Spark: Optymalizacja rozmiaru plików; V-Order opcjonalny.
Spark-to-SQL: Włącz optymalizację zapisu i autokompaktację; docelowe pliki o rozmiarze 400 MB z 2 milionami grup wierszy.
Strumieniowe pozyskiwanie: włącz automatyczne kompaktowanie; zaplanuj dodatkowe OPTIMIZE zadania dla użytkowników SQL.
Power BI Direct Lake: Włącz V-Order; Docelowe 8+ milionów grup wierszy; uruchom OPTIMIZE VORDER.

Sprzężenie zwrotne

Czy ta strona była pomocna?

Last updated on 2026-02-13