Udostępnij za pośrednictwem

Zrozumienie magazynowania dla modeli semantycznych Direct Lake

  • Artykuł

W tym artykule przedstawiono pojęcia dotyczące magazynu Direct Lake. Opisuje tabele Delta i pliki Parquet. W tym artykule opisano również, jak można zoptymalizować tabele delty dla modeli semantycznych usługi Direct Lake oraz jak można je obsługiwać, aby ułatwić zapewnienie niezawodnej, szybkiej wydajności zapytań.

Tabele Delta

Tabele Delta istnieją w usłudze OneLake. Organizują one dane oparte na plikach w wiersze i kolumny i są dostępne dla silników obliczeniowych usługi Microsoft Fabric, takich jak notesy , Kusto, lakehouse oraz warehouse. Można pytać tabele Delta za pomocą języka DAX (Data Analysis Expressions), Multidimensional Expressions (MDX), T-SQL (Transact-SQL), Spark SQL, a nawet Pythona.

Notatka

Delta — lub Delta Lake— jest formatem magazynowania typu open source. Oznacza to, że Fabric może również wykonywać zapytania dotyczące tabel Delta utworzonych przez inne narzędzia i dostawców.

Tabele delty przechowują swoje dane w plikach Parquet, które są zwykle przechowywane w usłudze lakehouse używanej przez model semantyczny usługi Direct Lake do ładowania danych. Jednak pliki Parquet mogą być również przechowywane zewnętrznie. Można się odwoływać do zewnętrznych plików Parquet, używając skrótu OneLake, który wskazuje na konkretną lokalizację przechowywania, na przykład Azure Data Lake Storage (ADLS) Gen2, konta przechowywania Amazon S3 czy Dataverse. W prawie wszystkich przypadkach aparaty obliczeniowe uzyskują dostęp do plików Parquet przez wykonywanie zapytań względem tabel delty. Jednak zazwyczaj semantyczne modele usługi Direct Lake ładują dane kolumn bezpośrednio z zoptymalizowanych plików Parquet w usłudze OneLake przy użyciu procesu znanego jako transkodowanie .

Przechowywanie wersji danych

Tabele Delta składają się z co najmniej jednego pliku Parquet. Te pliki są towarzyszone przez zestaw plików powiązanych opartych na formacie JSON, które śledzą kolejność i charakter każdego pliku Parquet skojarzonego z tabelą Delta.

Ważne jest, aby zrozumieć, że bazowe pliki Parquet mają charakter przyrostowy. W związku z tym nazwa Delta jako odniesienie do przyrostowych modyfikacji danych. Za każdym razem, gdy odbywa się operacja zapisu w Tabeli Delty, takich jak wstawianie, aktualizowanie lub usuwanie danych, tworzone są nowe pliki Parquet reprezentujące modyfikacje danych jako wersja . Pliki Parquet są zatem niezmienne, co oznacza, że nigdy nie są modyfikowane. W związku z tym dane mogą być duplikowane wiele razy w zestawie plików Parquet dla tabeli Delta. Struktura Delta opiera się na plikach powiązań, aby określić, które fizyczne pliki Parquet są wymagane do wygenerowania poprawnego wyniku zapytania.

Rozważmy prosty przykład tabeli delty używanej w tym artykule do wyjaśnienia różnych operacji modyfikacji danych. Tabela zawiera dwie kolumny i przechowuje trzy wiersze.

ProductID StockOnHand
A 1
B 2
C 3

Dane tabeli Delta są przechowywane w jednym pliku Parquet, który zawiera wszystkie dane, a istnieje pojedynczy plik powiązany zawierający metadane dotyczące czasu dodawania danych.

  • Plik Parquet 1:
    • productID: A, B, C
    • StockOnHand: 1, 2, 3
  • Plik łącza 1:
    • Zawiera sygnaturę czasową utworzenia Parquet file 1 oraz zapis, że dane zostały dołączone.

Operacje wstawiania

Zastanów się, co się stanie, gdy wystąpi operacja wstawiania: zostanie wstawiony nowy wiersz dla produktu C z wartością stanu magazynowego 4. Ta operacja powoduje utworzenie nowego pliku Parquet i pliku z odnośnikiem, więc istnieją teraz dwa pliki Parquet i dwa pliki z odnośnikami.

  • Plik Parquet 1:
    • productID: A, B, C
    • StockOnHand: 1, 2, 3
  • Plik Parquet 2
    • IDProduktu: D
    • StockOnHand: 4
  • Plik łącza 1:
    • Zawiera sygnaturę czasową utworzenia Parquet file 1 oraz zapis o dołączeniu danych.
  • Plik łącza 2:
    • Zawiera sygnaturę czasową utworzenia Parquet file 2 i zapisuje informację, że dane zostały dołączone.

W tym momencie zapytanie tabeli delta zwraca następujący wynik. Nie ma znaczenia, że wynik pochodzi z wielu plików Parquet.

ProductID StockOnHand
A 1
B 2
C 3
D 4

Każda kolejna operacja wstawiania tworzy nowe pliki Parquet i pliki powiązane. Oznacza to, że liczba plików Parquet i plików linków rośnie wraz z każdą operacją wstawiania.

Operacje aktualizacji

Teraz zastanów się, co się stanie, gdy nastąpi operacja aktualizacji: wiersz dla produktu D ma wartość stanu magazynowego zmienioną na 10. Te operacje prowadzą do utworzenia nowego pliku Parquet i pliku linku, więc istnieją teraz trzy pliki Parquet i trzy pliki linków.

  • Plik Parquet 1:
    • productID: A, B, C
    • StockOnHand: 1, 2, 3
  • Plik Parquet 2:
    • ProductID: D
    • StockOnHand: 4
  • Plik Parquet 3:
    • ProductID: C
    • StockOnHand: 10
  • Plik łącza 1:
    • Zawiera znacznik czasu utworzenia Parquet file 1 oraz zapisuje, że dane zostały dołączone.
  • Plik linku 2:
    • Zawiera sygnaturę czasową utworzenia Parquet file 2 oraz informacje, że dane zostały dodane.
  • Plik łącza 3:
    • Zawiera sygnaturę czasową utworzenia Parquet file 3 oraz informację, że dane zostały zaktualizowane.

W tym momencie zapytanie tabeli delta zwraca następujący wynik.

ProductID StockOnHand
A 1
B 2
C 10
D 4

Dane dla produktu C teraz istnieją w wielu plikach Parquet. Jednak zapytania do tabeli delty łączą pliki linków, aby określić, które dane powinny być używane w celu zapewnienia poprawnego wyniku.

Operacje usuwania

Teraz zastanów się, co się stanie po wystąpieniu operacji usuwania: wiersz dla produktu B zostanie usunięty. Ta operacja powoduje utworzenie nowego pliku Parquet i pliku łącza, więc istnieją teraz cztery pliki Parquet i cztery pliki linków.

  • Plik Parquet 1:
    • productID: A, B, C
    • StockOnHand: 1, 2, 3
  • Plik Parquet 2:
    • ProductID: D
    • StockOnHand: 4
  • Plik Parquet 3:
    • ProductID: C
    • StockOnHand: 10
  • Plik Parquet 4:
    • productID: A, C, D
    • StockOnHand: 1, 10, 4
  • Plik z linkiem 1:
    • Zawiera sygnaturę czasową utworzenia Parquet file 1 oraz zapis, że dane zostały dołączone.
  • Plik łącza 2:
    • Zawiera sygnaturę czasową utworzenia Parquet file 2 oraz zapisuje, że dane zostały dołączone.
  • Plik linku 3:
    • Zawiera sygnaturę czasową utworzenia Parquet file 3 oraz zapis, że dane zostały zaktualizowane.
  • Plik łącza 4:
    • Zawiera sygnaturę czasową utworzenia Parquet file 4 oraz zapis, że dane zostały usunięte.

Zwróć uwagę, że Parquet file 4 nie zawiera już danych dotyczących Bproduktu, ale zawiera dane dla wszystkich innych wierszy w tabeli.

W tym momencie zapytanie tabeli delta zwraca następujący wynik.

ProductID StockOnHand
A 1
C 10
D 4

Notatka

Ten przykład jest prosty, ponieważ obejmuje małą tabelę, tylko kilka operacji i tylko drobne modyfikacje. W przypadku dużych tabel, w których często wykonywane są operacje zapisu i które zawierają wiele wierszy danych, wygenerowany zostanie więcej niż jeden plik Parquet na wersję.

Ważny

W zależności od sposobu definiowania tabel delty i częstotliwości operacji modyfikacji danych może to spowodować powstanie wielu plików Parquet. Należy pamiętać, że każda licencja pojemności Fabric ma ograniczenia. Jeśli liczba plików Parquet dla tabeli Delta przekroczy limit dla jednostki SKU, zapytania przełączyć się na DirectQuery, co może spowodować spowolnienie wydajności zapytań.

Aby zarządzać liczbą plików Parquet, zobacz utrzymanie tabeli Delta w dalszej części tego artykułu.

Podróż w czasie delta

Pliki łączy umożliwiają wykonywanie zapytań dotyczących danych z wcześniejszego punktu w czasie. Ta funkcja jest znana jako podróżowanie w czasie Delta. Wcześniejszy punkt w czasie może być znacznikiem czasu lub wersją.

Rozważmy następujące przykłady zapytań.

SELECT * FROM Inventory TIMESTAMP AS OF '2024-04-28T09:15:00.000Z';
SELECT * FROM Inventory AS OF VERSION 2;

Napiwek

Możesz również zapytanie tabeli wykonać przy użyciu tzw. skróconej składni @ do określenia czasu lub wersji jako części nazwy tabeli. Znacznik czasu musi być w formacie yyyyMMddHHmmssSSS. Wersję można określić po @, dodając v przed wersją.

Poniżej przedstawiono poprzednie przykłady zapytań przepisane z skróconą składnią.

SELECT * FROM Inventory@20240428091500000;
SELECT * FROM Inventory@v2;

Ważny

Wersje tabel dostępne dzięki podróży w czasie są określane przez kombinację progu retencji dla plików dziennika transakcji oraz częstotliwości i określonego przechowywania dla operacji VACUUM (opisanych w dalszej części sekcji konserwacji tabel Delta). W przypadku codziennego uruchamiania funkcji VACUUM z wartościami domyślnymi siedem dni danych będzie dostępnych na potrzeby podróży czasowej.

Kadrowanie

Framing to operacja Direct Lake, która ustawia wersję tabeli Delta, która powinna służyć do ładowania danych do kolumny modelu semantycznego. Równie ważne jest, że wersja określa również, co należy wykluczyć po załadowaniu danych.

Operacja ramkowania oznacza znaczniki czasowe lub wersję każdej tabeli Delta w tabelach modelu semantycznego. Od tego momentu, gdy model semantyczny musi załadować dane z tabeli Delta, znacznik czasu lub wersja skojarzona z najnowszą operacją ustalania ram jest używana do określenia, jakie dane mają być ładowane. Wszelkie kolejne modyfikacje danych, które występują w tabeli Delta od czasu ostatniej operacji ramkowania, są ignorowane (do następnej operacji ramkowania).

Ważny

Ponieważ model semantyczny w ramce odwołuje się do określonej wersji tabeli Delta, źródło musi upewnić się, że przechowuje tę wersję tabeli Delta do momentu stworzenia nowej wersji. W przeciwnym razie użytkownicy napotkają błędy, gdy pliki tabeli Delta, do których model musi mieć dostęp, zostaną opróżnione lub w inny sposób usunięte przez obciążenie związane z procesami produkcyjnymi.

Aby uzyskać więcej informacji na temat tworzenia ramek, zobacz Direct Lake overview.

Partycjonowanie tabel

Tabele Delta można partycjonować, aby podzbiór wierszy był przechowywany razem w jednym zestawie plików Parquet. Partycje mogą przyspieszać zapytania, a także operacje zapisu.

Rozważ tabelę delty zawierającą miliard wierszy danych sprzedaży w okresie dwóch lat. Chociaż można przechowywać wszystkie dane w jednym zestawie plików Parquet, w przypadku tego woluminu danych nie jest optymalny dla operacji odczytu i zapisu. Zamiast tego wydajność można poprawić, rozkładając miliard wierszy danych na wiele serii plików Parquet.

Podczas konfigurowania partycjonowania tabel należy zdefiniować klucz partycji . Klucz partycji określa, które wiersze mają być przechowywane w której serii. W przypadku tabel delty klucz partycji można zdefiniować na podstawie odrębnych wartości określonej kolumny (lub kolumn), takich jak kolumna miesiąca/roku tabeli dat. W takim przypadku dwa lata danych będą dystrybuowane na 24 partycje (2 lata x 12 miesięcy).

Aparaty obliczeniowe sieci szkieletowej nie wiedzą o partycjach tabeli. Podczas wstawiania nowych wartości klucza partycji nowe partycje są tworzone automatycznie. W usłudze OneLake znajdziesz jeden podfolder dla każdej unikatowej wartości klucza partycji, a każdy podfolder przechowuje własny zestaw plików Parquet i pliki linków. Musi istnieć co najmniej jeden plik Parquet i jeden plik łącza, ale rzeczywista liczba plików w każdym podfolderze może się różnić. W miarę wykonywania operacji modyfikacji danych każda partycja utrzymuje własny zestaw plików Parquet i łączy pliki, aby śledzić, co należy zwrócić dla danego znacznika czasu lub wersji.

Jeśli zapytanie dotyczące tabeli Delta podzielonej na partycje jest ograniczone tylko do danych sprzedaży z ostatnich trzech miesięcy, można szybko zidentyfikować podzestaw plików Parquet i powiązanych plików, do których należy uzyskać dostęp. Umożliwia to całkowite pomijanie wielu plików Parquet, co skutkuje lepszą wydajnością odczytu.

Jednak zapytania, które nie filtrują klucza partycji, mogą nie zawsze działać lepiej. Może to być przypadek, gdy tabela delty przechowuje wszystkie dane w jednym dużym zestawie plików Parquet i istnieje fragmentacja pliku lub grupy wierszy. Chociaż istnieje możliwość równoległego pobierania danych z wielu plików Parquet w wielu węzłach klastra, wiele małych plików Parquet może niekorzystnie wpłynąć na operacje we/wy pliku i w związku z tym wydajność zapytań. Z tego powodu najlepiej jest unikać partycjonowania tabel Delta w większości przypadków — chyba że operacje zapisu lub procesy ETL (wyodrębnianie, przekształcanie i ładowanie) będą z tego wyraźnie korzystać.

Partycjonowanie przynosi korzyści również operacjom wstawiania, aktualizacji i usuwania, ponieważ operacje na plikach odbywają się tylko w podfolderach odpowiadających kluczowi partycji zmodyfikowanych lub usuniętych wierszy. Jeśli na przykład partia danych zostanie wstawiona do partycjonowanej tabeli delty, dane są oceniane w celu określenia, jakie wartości klucza partycji istnieją w partii. Dane są następnie kierowane tylko do odpowiednich folderów dla partycji.

Zrozumienie, w jaki sposób tabele Delta używają partycji, może pomóc w projektowaniu optymalnych scenariuszy ETL, zmniejszając operacje zapisu, które muszą być wykonywane podczas aktualizowania dużych tabel Delta. Wydajność zapisu poprawia się, zmniejszając liczbę i rozmiar nowych plików Parquet, które należy utworzyć. W przypadku dużej tabeli delty partycjonowanej według miesiąca/roku, zgodnie z opisem w poprzednim przykładzie, nowe dane dodają tylko nowe pliki Parquet do najnowszej partycji. Podfoldery poprzednich miesięcy kalendarzowych pozostają nienaruszone. Jeśli jakiekolwiek dane z poprzednich miesięcy kalendarzowych muszą zostać zmodyfikowane, tylko odpowiednie foldery partycji otrzymają nowe pliki partycji i łącza.

Ważny

Jeśli głównym celem tabeli Delta jest służyć jako źródło danych dla modeli semantycznych (a dopiero potem, dla innych obciążeń zapytań), zwykle lepiej jest unikać partycjonowania na rzecz optymalizacji obciążenia kolumn w pamięci.

W przypadku modeli semantycznych Direct Lake lub punktu końcowego analizy SQL najlepszym sposobem na optymalizację partycji tabeli Delta jest pozwolenie, aby Fabric automatycznie zarządzał plikami Parquet dla każdej wersji tabeli Delta. Pozostawienie zarządzania systemem Fabric powinno skutkować wysoką wydajnością zapytań dzięki równoległości, jednak może niekoniecznie zapewnić najlepszą wydajność zapisu.

Jeśli musisz zoptymalizować operacje zapisu, rozważ użycie partycji w celu zoptymalizowania operacji zapisu w tabelach delty na podstawie klucza partycji. Należy jednak pamiętać, że nadmierne partycjonowanie tabeli delty może negatywnie wpłynąć na wydajność odczytu. Z tego powodu zalecamy dokładne przetestowanie wydajności odczytu i zapisu, na przykład przez utworzenie wielu kopii tej samej tabeli delty z różnymi konfiguracjami w celu porównania chronometrażu.

Ostrzeżenie

W przypadku partycjonowania w kolumnie o wysokiej kardynalności może to spowodować nadmierną liczbę plików Parquet. Należy pamiętać, że każda licencja pojemności Fabric ma ograniczenia. Jeśli liczba plików Parquet dla tabeli Delta przekroczy limit dla jednostki SKU, zapytania przełączą się na tryb DirectQuery, co może spowodować spowolnienie wydajności zapytań.

Pliki Parquet

Podstawowym magazynem danych dla tabeli Delta jest jeden lub więcej plików Parquet. Format pliku Parquet jest zwykle używany do jednokrotnego zapisu i wielu aplikacji. Nowe pliki Parquet są tworzone za każdym razem, gdy dane w tabeli Delta są modyfikowane, czy to w wyniku operacji wstawiania, aktualizacji, czy usuwania.

Notatka

Dostęp do plików Parquet skojarzonych z Tabelami Delta można uzyskać za pomocą narzędzia, takiego jak Eksplorator plików OneLake. Pliki można pobierać, kopiować lub przenosić do innych miejsc docelowych tak łatwo, jak przenosić inne pliki. Jest to jednak kombinacja plików Parquet i plików linków opartych na formacie JSON, które umożliwiają aparatom obliczeniowym wystawianie zapytań względem plików jako tabeli delty.

Format pliku Parquet

Format wewnętrzny pliku Parquet różni się od innych typowych formatów magazynu danych, takich jak CSV, TSV, XMLA i JSON. Te formaty porządkują dane według wierszy, podczas gdy Parquet organizuje dane według kolumn. Ponadto format pliku Parquet różni się od tych formatów, ponieważ organizuje wiersze danych w co najmniej jedną grupę wierszy.

Wewnętrzna struktura danych semantycznego modelu usługi Power BI jest oparta na kolumnach, co oznacza, że pliki Parquet mają wiele wspólnego z usługą Power BI. To podobieństwo oznacza, że model semantyczny usługi Direct Lake może wydajnie ładować dane z plików Parquet bezpośrednio do pamięci. W rzeczywistości bardzo duże ilości danych można załadować w sekundach. Porównaj tę funkcję z odświeżaniem modelu semantycznego Importuj, który musi pobierać bloki lub dane źródłowe, a następnie przetwarzać, kodować, przechowywać, a następnie ładować je do pamięci. Operacja odświeżania modelu semantycznego importu może również zużywać znaczne ilości zasobów obliczeniowych (pamięci i procesora CPU) i zająć dużo czasu. Jednak w przypadku tabel delty większość starań, aby przygotować dane odpowiednie do bezpośredniego ładowania do modelu semantycznego odbywa się podczas generowania pliku Parquet.

Jak pliki Parquet przechowują dane

Rozważmy następujący przykładowy zestaw danych.

Data IdentyfikatorProduktu StockOnHand
2024-09-16 A 10
2024-09-16 B 11
17.09.2024 A 13
…

W przypadku przechowywania w formacie pliku Parquet koncepcyjnie ten zestaw danych może wyglądać podobnie do następującego tekstu.

Header:
RowGroup1:
    Date: 2024-09-16, 2024-09-16, 2024-09-17…
    ProductID: A, B, A…
    StockOnHand: 10, 11, 13…
RowGroup2:
    …
Footer:

Dane są kompresowane poprzez podmianę kluczy słownika dla typowych wartości oraz zastosowanie kodowania długości serii (RLE). RLE dąży do skompresowania serii tych samych wartości do mniejszej reprezentacji. W poniższym przykładzie w nagłówku tworzony jest słownik, który mapuje numeryczne klucze na wartości, a mniejsze wartości klucza są używane zamiast wartości danych.

Header:
    Dictionary: [
        (1, 2024-09-16), (2, 2024-09-17),
        (3, A), (4, B),
        (5, 10), (6, 11), (7, 13)
        …
    ]
RowGroup1:
    Date: 1, 1, 2…
    ProductID: 3, 4, 3…
    StockOnHand: 5, 6, 7…
Footer:

Gdy model semantyczny usługi Direct Lake wymaga danych, aby obliczyć sumę kolumny StockOnHand pogrupowanej według ProductID, wymagany jest tylko słownik i dane skojarzone z dwiema kolumnami. W dużych plikach zawierających wiele kolumn można pominąć znaczną część pliku Parquet, aby przyspieszyć proces odczytu.

Notatka

Zawartość pliku Parquet nie jest czytelna dla człowieka i dlatego nie nadaje się do otwierania w edytorze tekstów. Dostępnych jest jednak wiele narzędzi typu open source, które mogą otwierać i ujawniać zawartość pliku Parquet. Te narzędzia umożliwiają również inspekcję metadanych, takich jak liczba wierszy i grup wierszy zawartych w pliku.

Kolejność V

Struktura obsługuje dodatkową optymalizację o nazwie V-Order. V-Order to optymalizacja czasu zapisu w formacie pliku Parquet. Po zastosowaniu V-Order plik staje się mniejszy, co umożliwia jego szybsze odczytywanie. Ta optymalizacja jest szczególnie istotna w przypadku modelu semantycznego usługi Direct Lake, ponieważ przygotowuje dane do szybkiego ładowania do pamięci, dzięki czemu zmniejsza zapotrzebowanie na zasoby pojemności. Skutkuje to również szybszą wydajnością zapytań, ponieważ należy skanować mniej pamięci.

Tabele Delta utworzone i załadowane przez elementy Fabric, takie jak potoki danych , przepływy danych i notebooks automatycznie stosują V-Order. Jednak pliki Parquet przesłane do Fabric lakehouse lub przywoływane przez skrót mogą nie mieć tej optymalizacji zastosowanej. Mimo że nieoptymalizowane pliki Parquet nadal mogą być odczytywane, szybkość odczytu prawdopodobnie nie będzie tak szybka jak równoważny plik Parquet z zastosowaną kolejnością V.

Notatka

Pliki Parquet, które mają zastosowany V-Order, są nadal zgodne z formatem pliku Parquet open source. Dlatego mogą być odczytywane przez narzędzia inne niż Fabric.

Aby uzyskać więcej informacji, zobacz optymalizację tabeli Delta Lake oraz V-Order.

Optymalizacja tabeli delty

W tej sekcji opisano różne tematy dotyczące optymalizacji tabel Delta dla modeli semantycznych.

Wolumin danych

Podczas gdy tabele Delta mogą zwiększać swoją pojemność, aby przechowywać niezwykle duże ilości danych, ograniczenia pojemności Fabryki narzucają limity na modele semantyczne, które je odpytują. Po przekroczeniu tych limitów zapytania powrócą do zapytania bezpośredniego, co może spowodować wolniejszą wydajność zapytań.

W związku z tym należy rozważyć ograniczenie liczby wierszy dużej tabeli faktów przez zwiększenie jej ogólności (przechowując podsumowane dane), zmniejszenie wymiarowości lub przechowywanie krótszej historii.

Upewnij się również, że zamówienie wirtualne jest stosowane, ponieważ powoduje mniejszy plik, który jest szybszy do odczytu.

Typ danych kolumny

Staraj się zmniejszyć kardynalność (liczbę unikatowych wartości) w każdej kolumnie każdej tabeli delty. Dzieje się tak dlatego, że wszystkie kolumny są kompresowane i przechowywane przy użyciu kodowania skrótów . Kodowanie haszu wymaga optymalizacji kolejności V-Order, aby przypisać identyfikator liczbowy do każdej unikatowej wartości zawartej w kolumnie. Jest to następnie identyfikator liczbowy, który jest przechowywany i wymaga wyszukiwania skrótu podczas przechowywania i wykonywania zapytań.

W przypadku używania przybliżonych typów danych liczbowych (takich jak zmiennoprzecinkowych i rzeczywistych), rozważ zaokrąglenie wartości i użycie mniejszej dokładności.

Niepotrzebne kolumny

Podobnie jak w przypadku dowolnej tabeli danych, tabele delty powinny przechowywać tylko wymagane kolumny. W kontekście tego artykułu oznacza to, że jest to wymagane przez model semantyczny, chociaż mogą istnieć inne obciążenia analityczne, które wysyłają zapytania do tabel delty.

Tabele Delta powinny zawierać kolumny wymagane przez model semantyczny do filtrowania, grupowania, sortowania i podsumowywania, a także kolumny obsługujące relacje modelu. Chociaż niepotrzebne kolumny nie wpływają na wydajność zapytań semantycznych modelu (ponieważ nie zostaną załadowane do pamięci), powodują one większy rozmiar magazynu i wymagają większej ilości zasobów obliczeniowych do załadowania i konserwacji.

Ponieważ modele semantyczne usługi Direct Lake nie obsługują kolumn obliczeniowych, należy zmaterializować takie kolumny w tabelach delty. Należy pamiętać, że takie podejście projektowe jest antywzorem dla modeli semantycznych Import i DirectQuery. Jeśli na przykład masz kolumny FirstName i LastName i potrzebujesz kolumny FullName, zmaterializuj wartości tej kolumny podczas wstawiania wierszy do tabeli delty.

Należy wziąć pod uwagę, że niektóre podsumowania modelu semantycznego mogą zależeć od więcej niż jednej kolumny. Na przykład aby obliczyć sprzedaż, miara w modelu sumuje produkt dwóch kolumn: Quantity i Price. Jeśli żadna z tych kolumn nie jest używana niezależnie, bardziej wydajne byłoby zmaterializowanie obliczeń sprzedaży jako jednej kolumny niż przechowywanie wartości składników w osobnych kolumnach.

Rozmiar grupy wierszy

Wewnętrznie plik Parquet organizuje wiersze danych w wielu grupach wierszy w każdym pliku. Na przykład plik Parquet zawierający 30 000 wierszy może podzielić je na trzy grupy wierszy, z których każdy ma 10 000 wierszy.

Liczba wierszy w grupie wierszy wpływa na szybkość odczytywania danych w usłudze Direct Lake. Większa liczba grup wierszy z mniejszą liczbą wierszy może negatywnie wpłynąć na wczytywanie danych kolumnowych do modelu semantycznego z powodu nadmiernych operacji we/wy.

Ogólnie rzecz biorąc, nie zalecamy zmiany domyślnego rozmiaru grupy wierszy. Można jednak rozważyć zmianę rozmiaru grupy wierszy dla dużych tabel delty. Pamiętaj, aby dokładnie przetestować wydajność odczytu i zapisu, tworząc być może wiele kopii tych samych tabel Delta z różnymi konfiguracjami w celu porównania czasów.

Ważny

Należy pamiętać, że każda licencja pojemności Fabric ma zabezpieczenia. Jeśli liczba grup wierszy w tabeli Delta przekroczy limit dla SKU, zapytania przejdą na DirectQuery, co może spowodować wolniejsze działanie zapytań.

Konserwacja tabeli delty

Z czasem, w miarę wykonywania operacji zapisu, wersje tabeli Delta się kumulują. W końcu może dojść do punktu, w którym negatywny wpływ na wydajność odczytu staje się zauważalny. Co gorsze, jeśli liczba plików Parquet na tabelę, grup wierszy na tabelę lub wierszy na tabelę przekracza ograniczenia dla pojemności, zapytania powrócą do trybu DirectQuery, co może skutkować wolniejszym działaniem zapytań. Dlatego ważne jest regularne utrzymywanie tabel delty.

OPTYMALIZOWAĆ

Można użyć OPTIMIZE, aby zoptymalizować tabelę Delta w celu łączenia mniejszych plików w większe. Można również ustawić klauzulę WHERE tak, aby dotyczyła tylko filtrowanego podzestawu wierszy pasujących do danego predykatu partycji. Obsługiwane są tylko filtry obejmujące klucze partycji. Polecenie OPTIMIZE może również zastosować metodę V-Order do kompresowania i ponownego zapisywania plików Parquet.

Zalecamy regularne uruchamianie tego polecenia na dużych, często aktualizowanych tabelach delty, być może codziennie po zakończeniu procesu ETL. Zrównoważ kompromis między lepszą wydajnością zapytań a kosztem użycia zasobów wymaganych do zoptymalizowania tabeli.

PRÓŻNIA

Można użyć VACUUM, aby usunąć pliki, które nie są już referencowane i/lub które są starsze niż ustalony próg zachowywania. Należy zachować ostrożność, aby ustawić odpowiedni okres przechowywania. W przeciwnym razie możesz utracić możliwość podróży w czasie do wersji starszej niż ramka wstawiona do tabel modelu semantycznego.

Ważny

Ponieważ model semantyczny w ramce odnosi się do określonej wersji tabeli Delta, źródło musi upewnić się, że zachowuje tę wersję do zakończenia tworzenia nowej wersji. W przeciwnym razie użytkownicy napotkają błędy, gdy pliki tabeli delty muszą być dostępne przez model i zostały opróżnione lub usunięte przez obciążenie producenta.

REORGANIZACJA TABELI

Możesz użyć REORG TABLE, aby zreorganizować tabelę Delta, ponownie zapisując pliki w celu usunięcia danych usuniętych miękko, na przykład podczas usuwania kolumny za pomocą ALTER TABLE DROP COLUMN.

Automatyzowanie konserwacji tabel

Aby zautomatyzować operacje konserwacji tabel, możesz użyć interfejsu API usługi Lakehouse. Aby uzyskać więcej informacji, zobacz Manage the Lakehouse with Microsoft Fabric REST API (Zarządzanie usługą Lakehouse przy użyciu interfejsu API REST usługi Microsoft Fabric).

Napiwek

Możesz również użyć funkcji konserwacji tabel lakehouse w portalu Fabric, aby uprościć zarządzanie tabelami Delta.

Powiązana zawartość