Utrzymanie i optymalizacja tabel w różnych obciążeniach w Microsoft Fabric

Tabele Delta w usłudze Microsoft Fabric mogą udostępniać dane przechowywane w usłudze OneLake do użycia przez środowisko Spark, punkt końcowy analizy SQL, Power BI Direct Lake, Warehouse i inne środowiska usługi Fabric. Optymalna wydajność w zakresie różnych obciążeń zależy od dwóch czynników:

  • Obciążenie pracą, które tworzy i utrzymuje tabelę.
  • Mechanizmy, które przetwarzają tabelę.

Tabele Lakehouse są zazwyczaj zarządzane przez Spark, Fabric pipeline działanie Kopiuj lub Dataflow Gen2. Spark jest najczęściej stosowanym writerem i zapewnia najszersze kontrole układu i konserwacji. Magazyn i baza danych mirroring automatycznie zarządzają swoimi fizycznymi układami. Katalogi lustrzane zachowują układ zarządzany w systemie źródłowym. Wymagania konsumentów są zazwyczaj kompatybilne, ale Power BI Direct Lake ma dodatkowe wymagania dotyczące pamięci masowej dla optymalizacji wydajności.

Używaj jednej współdzielonej tabeli, gdy jej wymagania są zgodne. W przypadku wyjątków uzasadniających kolejną tabelę, zobacz Kiedy utworzyć kolejną tabelę.

Poznaj właściciela układu

Zacznij od określenia, które obciążenie robocze odpowiada za fizyczny układ tabeli. Kontrole w poniższej tabeli są kluczowymi elementami istotnymi dla układu i konserwacji tabel między obciążeniami, a nie wyczerpującą listą możliwości każdego silnika.

Magazyn danych Metoda zapisu lub pozyskiwania danych Układ i odpowiedzialność za utrzymanie Kluczowe kontrolki
Lakehouse Spark Zarządzane przez użytkownika Rozmiarowanie plików: adaptacyjny docelowy rozmiar pliku i cele kompaktowania na poziomie plików.
Zapis i konserwacja: wektory usuwania, automatyczna kompresja, optymalizacja zapisu, OPTIMIZE, oraz VACUUM.
Organizacja danych: klasteryzacja płynna, podziały, Z-Order i V-Order.
Lakehouse Fabric pipeline działanie Kopiuj lub Dataflow Gen2 Usługa zapisuje dane; Właściciel domu nad jeziorem utrzymuje tabelę Ustawienia zapisu dla konkretnego miejsca docelowego. Przeprowadzaj kompatybilną konserwację osobno, korzystając ze Spark, konserwacji Lakehouse lub aktywności konserwacji rurociągów.
Magazyn Magazyn danych Fabric, działanie Kopiowanie w potoku Fabric lub Dataflow Gen2 Zarządzany magazynowo Klastrowanie danych oraz ustawienie V-Order na poziomie magazynowym.
Przedmiot lustrzany Usługa lustrzanego odbicia To zależy od rodzaju lustrzanego odbicia Dublowanie bazy danych wykorzystuje układ V-Ordered Delta zarządzany przez system, bez bezpośredniej kontroli nad układem. Katalogi lustrzane zachowują strukturę plików źródłowych, którą można zoptymalizować w systemie źródłowym, jeśli system to obsługuje.

Wytyczne dla różnych obciążeń roboczych

Poniższa tabela podsumowuje zalecane podejście według producenta i konsumenta.

Producer Consumer Zalecane podejście
Lakehouse: scenarzysta Spark Spark Użyj domyślnych ustawień Fabric Spark runtime 2.0 lub nowszych i włącz automatyczną kompresję. Rozważ liquid clustering, gdy mierzone predykaty korzystają z usprawnionego pomijania plików.
Lakehouse: scenarzysta Spark Punkt końcowy analizy SQL Użyj tego samego układu zalecanego dla Sparka. Nie ustawiaj statycznego docelowego rozmiaru pliku, dowolnego limitu wierszy ani V-Order wyłącznie dla wydajności punktów końcowych SQL Analytics.
Lakehouse: scenarzysta Spark Power BI Direct Lake Użyj tego samego układu zalecanego dla Spark i dodatkowo włącz V-Order lub użyj profilu zasobówreadHeavyForPBI.
Lakehouse: Fabric pipeline lub moduł zapisujący Dataflow Gen2 Spark, punkt końcowy analityki SQL lub Power BI Direct Lake Monitoruj powstały układ plików i planuj osobne utrzymanie kompatybilnego domku nad jeziorem. Niektóre tryby docelowe, takie jak odświeżanie przyrostowe Dataflow Gen2, nakładają ograniczenia dotyczące konserwacji.
Magazyn Fabric Data Warehouse czy Iskra Korzystaj z układu zarządzanego systemem. Fabric Data Warehouse automatycznie zarządza kompakcją i innymi zadaniami konserwacyjnymi. Wykorzystaj klastrowanie danych , aby poprawić pomijanie plików dla obciążeń z cyklicznymi selektywnymi predykatami.
Magazyn Power BI Direct Lake Zachowaj domyślne ustawienie V-Order w magazynie. Korzystaj z klastrowania danych , gdy sprzyja to współdzielonym wzorcom zapytań.
Odwzorowywanie Spark, punkt końcowy analizy SQL lub Power BI Direct Lake Do mirroringu baz danych użyj systemowo zarządzanego układu V-Ordered Delta. W przypadku katalogów lustrzanych zoptymalizuj pliki bazowe w systemie źródłowym, jeśli jest to obsługiwane. Zobacz Czym jest dublowanie w usłudze Fabric?.

Optymalizacja tabel Lakehouse

Tabele Lakehouse Delta wymagają wyraźnej strategii utrzymania niezależnie od tego, czy zapisuje je Spark, Pipeline działanie Kopiuj czy Dataflow Gen2. Spark jest głównym przykładem w tej sekcji, ponieważ zapewnia najszersze możliwości układu i kontroli utrzymania w Fabric.

Ważne

Utrzymanie tabel jest kluczowe dla optymalnej wydajności zapisu i odczytu we wszystkich silnikach. Nawet obciążenia wykorzystujące wyłącznie operacje dopisywania, które początkowo działają dobrze bez działań konserwacyjnych, mogą prowadzić do nagromadzenia zbyt dużej liczby małych plików, co ma wpływ na Spark, punkt końcowy analizy SQL, Direct Lake oraz zewnętrzne czytniki danych. Zobacz Kompaktowanie tabel Delta, aby poznać metody automatycznego i ręcznego zagęszczania.

Użyj domyślnych ustawień wykonawczych Spark

Gdy Spark zapisuje tabelę, używaj domyślnych ustawień Fabric Spark runtime 2.0 lub nowszych:

W Fabric Spark runtime 1.3 dostępne są adaptacyjne rozmiary pliku docelowego, cele zagęszczania na poziomie pliku oraz wektory usuwania jako opcje do wybrania.

Gdy Pipeline działanie Kopiuj lub Dataflow Gen2 zapisuje tabelę, należy osobno obejrzeć powstały układ pliku i zaplanować konserwację. Nie zakładaj, że ci autorzy stosują domyślne ustawienia w czasie wykonywania Sparka.

  • Fabric pipelines mogą organizować działania konserwacyjne Lakehouse po zapisach.

Ważne

Miejsca docelowe lakehouse w usłudze Dataflow Gen2, które korzystają z odświeżania przyrostowego, nie obsługują ani OPTIMIZE, ani REORG TABLE. Przestrzegaj ograniczeń odświeżania przyrostowego w Dataflow Gen2.

Zapobieganie i kompaktowanie małych plików

W przypadku tabel napisanych przez Spark wolę automatyczną kompresję. Ta funkcja ocenia fragmentację tabeli po zapisie i wykonuje zagęszczanie tylko wtedy, gdy jest to konieczne. Eliminuje to potrzebę osobnej kontroli stanu tabeli przed uruchomieniem prac konserwacyjnych.

Korzystaj z następujących wskazówek dotyczących wyjątków i funkcji uzupełniających:

Scenario Zalecane podejście
Tabela zapisana iskrą Włącz automatyczne zagęszczanie jako domyślną strategię konserwacji.
Zapisy strumieniowe lub mikropartie Włącz automatyczną kompresję i zoptymalizuj zapis , aby zmniejszyć gromadzenie się małych plików.
Obciążenia z rygorystycznymi wymaganiami dotyczącymi opóźnień zapisu Planuj OPTIMIZE osobno zamiast uruchamiać synchroniczną automatyczną kompresję.
Istniejąca tabela z nagromadzonymi małymi plikami Uruchom jednorazowe OPTIMIZE, a następnie włącz automatyczne kompaktowanie w celu bieżącej konserwacji.
Tabele z częstymi aktualizacjami, usuwaniami lub scalaniami Zachowaj włączone wektory usuwania i automatyczne zagęszczanie .

OPTIMIZE kompaktuje pliki i automatycznie usuwa wektory usuwania dla pliku, gdy więcej niż 5% jego rekordów jest wskazywanych przez wektory usuwania. Używaj REORG TABLE ... APPLY (PURGE) tylko wtedy, gdy musisz fizycznie usunąć dane poniżej tego progu lub spełnić określone wymagania zgodności.

Uwaga / Notatka

Automatyczna kompakcja usuwa wektory usuwania tylko wtedy, gdy partycja spełnia także próg małych plików. Jeśli obciążenie robocze wykonuje aktualizacje lub usunięcia bez generowania małych plików, uruchamiaj okresowo OPTIMIZE, aby usuwać odpowiednie wektory usunięcia. Użyj REORG TABLE ... APPLY (PURGE), gdy musisz wymusić fizyczne czyszczenie.

Uruchom VACUUM według osobnego harmonogramu, aby usunąć pliki bez referencji po upływie okresu przechowywania. VACUUM odzyskuje miejsce przechowywania, ale nie poprawia aktywnego układu plików.

Warning

Nie skracaj VACUUM okresu utrzymania bez oceny wymagań dotyczących podróży w czasie oraz jednoczesnych czytelników lub autorów. Zbyt wczesne usuwanie plików może sprawić, że wymagane wersje tabel staną się niedostępne.

Uporządkuj dane na potrzeby pomijania plików

Używaj liquid clustering, gdy powtarzające się wzorce filtrowania lub przetwarzania zyskują dzięki ulepszonemu pomijaniu plików. Tabele z klastrowaniem płynnym wymagają OPTIMIZElub automatycznego zagęszczania, aby uporządkować nowo zapisane dane.

Unikaj domyślnego partycjonowania. Używaj tego, gdy konkretne wymaganie uzasadnia kompromisy operacyjne, na przykład w celu izolowania współbieżnych procesów zapisujących, które aktualizują, usuwają lub scalają dane w odrębnych partycjach. Więcej informacji można znaleźć w artykule Kiedy używać partycjonowania.

Dla istniejących tabel podzielonych na particje rozważmy Z-Order , gdy selektywne predykaty często filtrują te same kolumny w ramach partycji.

Optymalizacja tabel zarządzanych przez magazyn

Fabric Data Warehouse zarządza fizycznym układem tabeli Delta niezależnie od metody pobierania.

Wykorzystaj strategiczne kontrole, które udostępnia Warehouse, aby dostosować układ danych:

  • Stosuj klasteryzację danych do dużych tabel, gdy zapytania wielokrotnie używają selektywnych predykatów na tych samych kolumnach.
  • Pozostaw funkcję V-Order włączoną dla obciążeń ukierunkowanych na odczyt i mieszanych. V-Order jest domyślnie włączony.
  • Rozważ wyłączenie V-Order dla obciążeń magazynowych wymagających intensywnego zapisu.

Warning

Wyłączenie funkcji V-Order to nieodwracalna operacja wykonywana na poziomie magazynu. Sprawdź pełne obciążenie odczytu i zapisu przed wyłączeniem aplikacji.

Pełne wytyczne dotyczące magazynu można znaleźć w wytycznych dotyczących wydajności w Fabric Data Warehouse.

Optymalizacja danych lustrzanych

Twoja zdolność do ulepszenia układu fizycznego zależy od tego, czy Fabric replikuje dane, czy odwołuje się do plików źródłowych:

  • Dublowanie bazy danych: Fabric replikuje dane źródłowe do tabel Delta w usłudze OneLake oraz zarządza układem plików V-Ordered i ich konserwacją. Nie możesz bezpośrednio skonfigurować rozmiaru pliku docelowego, czyszczenia wektorów usuwania, klastrowania płynnego, partycjonowania ani V-Order na lustrzanym miejscu.
  • Katalogi lustrzane: Fabric synchronizuje metadane i używa skrótów OneLake do odniesienia się do danych źródłowych na miejscu. Fabric nie przepisuje ani nie utrzymuje tych plików. Poprawa układu fizycznego i sprzątania w systemie źródłowym, gdy obsługiwane funkcje na to pozwalają. Te zmiany są widoczne za pośrednictwem skrótów bez konieczności tworzenia kolejnej kopii w Fabric.

Dla danych lustrzanych w bazie danych:

  • Używaj selektywnych predykatów i unikaj zbędnych kolumn w zapytaniach Spark i SQL.
  • Projektuj modele semantyczne Power BI oraz miary DAX z myślą o efektywnym korzystaniu z Direct Lake.

W przypadku katalogów lustrzanych:

  • Korzystaj z obsługiwanych funkcji utrzymania i układu tabel na platformie źródłowej.
  • Oceń plik źródłowy i rozmieszczenie grup wierszy dla konsumentów Fabric, którzy wysyłają zapytania do skrótów.
  • W przypadku Direct Lake warto rozważyć utworzenie dodatkowej warstwy serwacyjnej modelowanej wymiarowo, uporządkowanej w V, gdy układ źródłowy nie spełnia wymagań wydajnościowych.

Informacje na temat pojęć, typów i obsługiwanych źródeł dublowania można znaleźć w artykułach Co to jest dublowanie w usłudze Fabric? oraz Jak działa dublowanie metadanych.

Zastosowanie optymalizacji specyficznej dla konsumenta

Spark i punkt końcowy analizy SQL dobrze działają w oparciu o tę samą adaptacyjną architekturę lakehouse. Stosuj adaptacyjny docelowy rozmiar pliku, zapobiegaj nadmiernie małym plikom i stosuj ciekłe klastry, gdy mierzone predykaty korzystają z lepszego pomijania plików. Nie włączaj V-Order wyłącznie dla wydajności punktów końcowych w Spark lub SQL Analytics. Szczegóły dotyczące konkretnego silnika można znaleźć w artykule dotyczący wydajności punktów końcowych w analizie SQL.

Power BI Direct Lake

Direct Lake korzysta z tych samych bazowych tabel Delta, ale dodaje rekomendacje dotyczące transkodowania i inkrementalnego ramowania:

Uwaga / Notatka

Direct Lake generalnie najlepiej radzi sobie z grupami rzędów od 1 do 16 milionów rzędów. Oceń dystrybucję grup wierszy i wydajność Direct Lake przed zmianą obsługiwanego ustawienia producenta.

W przypadku tabel zapisywanych przez Spark parametr spark.sql.parquet.native.writer.maxRowGroupRowCount określa maksymalną liczbę wierszy w grupie wierszy, gdy natywny silnik wykonawczy zapisuje pliki Parquet. Domyślna wartość to 0, co nie narzuca maksimum. Jeśli analiza wykaże, że rozmiarowanie grup wierszy wpływa na wydajność Direct Lake, ustal testowany limit przed zapisem lub przepisaniem tabeli. Przykład:

spark.conf.set("spark.sql.parquet.native.writer.maxRowGroupRowCount", 8_000_000)

Nie ustalaj limitu tylko po to, by osiągnąć określoną liczbę wierszy. Szerokość wiersza, kompresja, rozkład plików oraz równoległość pojemności również wpływają na wydajność. Użyj Delta Analyzer , aby ocenić powstały układ.

Szczegółowe wskazówki dotyczące ramowania, transkodowania, grup wierszy, wzorców aktualizacji i Delta Analyzer można znaleźć w artykule Opis wydajności zapytań Direct Lake.

Zastosuj wskazówki do warstw medalionów

Brąz, Srebro i Złoto opisują cel i udoskonalanie danych. Nie decydują, czy układ jest zarządzany przez użytkownika, czy systemowy, i nie wymagają osobnych kopii dla każdego konsumenta.

Warstwa Podstawowy cel Wytyczne dotyczące różnych obciążeń
Brąz (strona docelowa) Zachowanie wierności źródła i przepustowości pobierania danych Priorytetowo traktuj przepustowość zapisu, jednocześnie utrzymując tabele pisane przez Spark z automatyczną kompresją. Unikaj semantycznych modeli Power BI Direct Lake na surowych tabelach Bronze, chyba że model i kształt danych są celowo zaprojektowane do tego celu.
Srebro (kuratorowane) Dostarczaj zweryfikowane, zgodne dane do ponownego wykorzystania Ponownie wykorzystaj tabelę wśród kompatybilnych użytkowników Fabric. Dla tabel lakehouse napisanych przez Spark włącz V-Order tylko wtedy, gdy Direct Lake jest głównym konsumentem.
Złoto (porcja) Dostarczaj wymiary, fakty, agregaty i modele analityczne gotowe do zastosowań biznesowych Preferuję tę warstwę dla modeli semantycznych Direct Lake. Ponownie wykorzystaj tabelę wśród kompatybilnych konsumentów i zastosuj specyficzne dla producenta kontrole, opisane w tym artykule.

Rozwiązywanie problemów z układem i konserwacją

Stosuj działania naprawcze uwzględniające producenta. Stosuj polecenia utrzymania Spark do tabel lakehouse, gdy tryb docelowy obsługuje te operacje. Traktuj sygnały jako wskaźniki, a nie uniwersalne progi, i zweryfikowaj je względem wzorca zapisu w tabeli oraz wyników konsumenckich.

Warunek Sygnał Tabela Lakehouse Stół magazynowy
Nadmiernie małe pliki Liczba plików rośnie szybciej niż aktywny rozmiar tabeli, a pliki pozostają poniżej docelowego poziomu adaptacyjnego. W Sparku uruchom jednorazowe zagęszczanie OPTIMIZE dla istniejących zaległości, a następnie włącz automatyczne zagęszczanie. Dla Pipeline działanie Kopiuj lub zapisów Dataflow Gen2, planowanie obsługi lakehouse było obsługiwane osobno. Brak akcji. Kompaktowanie magazynu jest automatyczne.
Przestarzałe pliki o zbyt dużym rozmiarze Liczba plików pozostaje znacznie wyższa niż bieżący adaptacyjny poziom docelowy, a zbyt mała liczba plików ogranicza równoległość skanowania. Zapisz tabelę ponownie, używając opcji nadpisania lub znacznika CREATE OR REPLACE TABLE AS SELECT, z włączoną opcją adaptacyjny rozmiar pliku docelowego. Brak akcji. Magazyn automatycznie zarządza rozmiarem plików.
Nagromadzenie wektorów delecyjnych DESCRIBE HISTORY Metryki pokazują, że wektory usuwania są dodawane lub aktualizowane szybciej niż zagęszczanie je usuwa, co potencjalnie zwiększa narzut odczytu. Zachowaj włączoną automatyczną kompresję . Jeśli wektory usuwania gromadzą się bez wywoływania kompaktowania małych plików, zaplanuj OPTIMIZE. Używaj REORG TABLE ... APPLY (PURGE) tylko do wyraźnych wymagań dotyczących czyszczenia. Brak akcji. Sprzątanie jest zarządzane systemowo.
Nieprawidłowe pomijanie plików W przypadku selektywnych predykatów skanowana jest znaczna część tabeli lub ocena jakości klasteryzacji wskazuje na słabą organizację. Za pomocą Sparka konfiguruj grupowanie płynne lub użyj Z-Order dla istniejącej tabeli partycjonowanej. Konfiguruj klastrowanie danych magazynowych.
Narzut transkodowania w Direct Lake Delta Analyzer pokazuje nadmiar plików, małe grupy wierszy lub szerokie retranskodowanie po aktualizacjach. Kompaktowaj małe pliki, przeglądaj grupy wierszy i stosuj V-Order do tabel pisanych przez Spark. Opcjonalnie skonfiguruj klasterizację płynną , aby poprawić jakość kompresji w plikach Parquet. Utrzymuj włączony V-Order i analizuj klastry danych.
Wzrost pamięci plików bez referencji Pamięć masowa OneLake rośnie szybciej niż aktywny rozmiar tabeli po operacjach zmieniających dane. Uruchom VACUUM zgodnie z wymogami dotyczącymi przechowywania. Brak akcji. Sprzątanie jest zarządzane systemowo.

Dla danych lustrzanych stosuj specyficzną dla producenta remediację w Optimize mirrored data. Dublowanie bazy danych jest zarządzane przez system; w przypadku dublowanych katalogów należy przeprowadzać obsługiwane czynności konserwacyjne na platformie źródłowej.

W przypadku tabel lakehouse opcje inspekcji obsługiwane przez Spark obejmują:

  • Uruchom DESCRIBE DETAIL, aby sprawdzić liczbę plików, całkowity rozmiar oraz obliczoną właściwość delta.targetFileSize.adaptive.
  • Uruchom DESCRIBE HISTORY, aby przejrzeć schematy zapisu i historię czynności konserwacyjnych.
  • Używaj Delta Analyzer , gdy potrzebujesz szczegółowej analizy grup wierszy Direct Lake i wzorców aktualizacji.

Sprawdź średni rozmiar pliku

Użyj DESCRIBE DETAIL, aby obliczyć średni rozmiar pliku jako wstępny wskaźnik układu tabeli:

details = spark.sql("DESCRIBE DETAIL schema_name.table_name").first()

table_size_gb = details["sizeInBytes"] / (1024**3)
num_files = details["numFiles"]
avg_file_size_mb = (
    details["sizeInBytes"] / num_files / (1024**2)
    if num_files
    else 0
)

print(f"Table size: {table_size_gb:.2f} GB")
print(f"Number of files: {num_files}")
print(f"Average file size: {avg_file_size_mb:.2f} MB")

Średnia może ukrywać nierównomierność między partycjami lub między plikami skompaktowanymi niedawno a skompaktowanymi wcześniej. Jeśli średnia wskazuje na możliwy problem z układem, sprawdź poszczególne pliki Parquet lub użyj Delta Analyzer , aby ocenić rozkład przed zmianą ustawień konserwacji.

Kiedy utworzyć kolejną tabelę

Nie twórz kolejnej fizycznej tabeli tylko dlatego, że kilka silników Fabric zużywa dane.

Stwórz inną tabelę, gdy ma ona niezależny cel, na przykład:

  • Transformacja lub agregacja, która zmienia ziarno danych lub znaczenie biznesowe.
  • Różne wymagania dotyczące bezpieczeństwa, przechowywania lub jakości danych.
  • To wymóg opóźnienia lub odświeżania, którego wspólna tabela nie może spełnić.
  • Układ specyficzny dla odbiorcy, dla którego wymierne korzyści przewyższają koszty przechowywania, przetwarzania, śledzenia pochodzenia danych i zarządzania.

Treści powiązane

  • Last updated on