Udostępnij za pośrednictwem

Omówienie magazynu dla modeli semantycznych usługi Direct Lake

  • Artykuł

W tym artykule przedstawiono pojęcia dotyczące magazynu w usłudze Direct Lake . Opisuje tabele delty 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 różnicowe

Tabele różnicowe istnieją w usłudze OneLake. Organizują dane oparte na plikach w wiersze i kolumny i są dostępne dla aparatów obliczeniowych usługi Microsoft Fabric, takich jak notesy, kusto i magazyn typu lakehouse. Tabele delty można wykonywać przy użyciu języka DAX (Data Analysis Expressions), Multidimensional Expressions (MDX), T-SQL (Transact-SQL), Spark SQL, a nawet Języka Python.

Uwaga

Delta —lub Delta Lake — to format magazynu typu open source. Oznacza to, że sieć szkieletowa może również wykonywać zapytania dotyczące tabel różnicowych 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. Do zewnętrznych plików Parquet można odwoływać się za pomocą skrótu OneLake, który wskazuje określoną lokalizację magazynu, taką jak Azure Data Lake Storage (ADLS) Gen2, Konta magazynu Amazon S3 lub Dataverse. W prawie wszystkich przypadkach aparaty obliczeniowe uzyskują dostęp do plików Parquet przez wykonywanie zapytań względem tabel delty. Jednak zazwyczaj modele semantyczne 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 różnicowe składają się z co najmniej jednego pliku Parquet. Te pliki są dołączane przez zestaw plików linków opartych na formacie JSON, które śledzą kolejność i charakter każdego pliku Parquet skojarzonego z tabelą delty.

Ważne jest, aby zrozumieć, że bazowe pliki Parquet mają charakter przyrostowy. W związku z tym nazwa Delta jako odwołanie do modyfikacji danych przyrostowych. Za każdym razem, gdy odbywa się operacja zapisu w tabeli delty , na przykład podczas wstawiania, aktualizowania lub usuwania danych, tworzone są nowe pliki Parquet reprezentujące modyfikacje danych jako wersję. 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 delty. Struktura delta opiera się na plikach linków, 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 delty są przechowywane w jednym pliku Parquet zawierającym wszystkie dane i istnieje pojedynczy plik linku zawierający metadane dotyczące wstawiania danych (dołączane).

  • Plik Parquet 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Plik łącza 1:
    • Zawiera sygnaturę czasową utworzenia Parquet file 1 i rekordy, które zostały dołączone.

Operacje wstawiania

Zastanów się, co się stanie po wystąpieniu operacji wstawiania: zostanie wstawiony nowy wiersz dla produktu C z wartością zapasu 4 . Ta operacja powoduje utworzenie nowego pliku Parquet i pliku linku, więc istnieją teraz dwa pliki Parquet i dwa pliki łącza.

  • Plik Parquet 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Plik Parquet 2:
    • Identyfikator produktu: D
    • StockOnHand: 4
  • Plik łącza 1:
    • Zawiera sygnaturę czasową utworzenia Parquet file 1 i rekordy, które zostały dołączone.
  • Plik łącza 2:
    • Zawiera sygnaturę czasową utworzenia Parquet file 2 i rekordy, które 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 100

Każda kolejna operacja wstawiania tworzy nowe pliki Parquet i pliki łączące. 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 po wystąpieniu operacji aktualizacji: wiersz produktu ma wartość zapasu na rękę D 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:
    • Identyfikator produktu: D
    • StockOnHand: 4
  • Plik Parquet 3:
    • ProductID: C
    • StockOnHand: 10
  • Plik łącza 1:
    • Zawiera sygnaturę czasową utworzenia Parquet file 1 i rekordy, które zostały dołączone.
  • Plik łącza 2:
    • Zawiera sygnaturę czasową utworzenia Parquet file 2 i rekordy, które zostały dołączone.
  • Plik łącza 3:
    • Zawiera sygnaturę czasową utworzenia Parquet file 3 i rekordy, które dane zostały zaktualizowane.

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

ProductID StockOnHand
A 1
B 2
C 10
D 100

Dane dotyczące produktu C istnieją teraz 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 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:
    • Identyfikator produktu: D
    • StockOnHand: 4
  • Plik Parquet 3:
    • ProductID: C
    • StockOnHand: 10
  • Plik Parquet 4:
    • ProductID: A, C, D
    • StockOnHand: 1, 10, 4
  • Plik łącza 1:
    • Zawiera sygnaturę czasową utworzenia Parquet file 1 i rekordy, które zostały dołączone.
  • Plik łącza 2:
    • Zawiera sygnaturę czasową utworzenia Parquet file 2 i rekordy, które zostały dołączone.
  • Plik łącza 3:
    • Zawiera sygnaturę czasową utworzenia Parquet file 3 i rekordy, które dane zostały zaktualizowane.
  • Plik łącza 4:
    • Zawiera sygnaturę czasową utworzenia Parquet file 4 i rekordy, które dane zostały usunięte.

Zwróć uwagę, że Parquet file 4 dane produktu nie zawierają już danych, Bale zawierają 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 100

Uwaga

Ten przykład jest prosty, ponieważ obejmuje małą tabelę, tylko kilka operacji i tylko drobne modyfikacje. Duże tabele, które mają wiele operacji zapisu i zawierają wiele wierszy danych, wygenerują więcej niż jeden plik Parquet na wersję.

Ważne

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 sieci szkieletowej ma zabezpieczenia. Jeśli liczba plików Parquet dla tabeli delty przekroczy limit dla jednostki SKU, zapytania zostaną przywrócone do trybu DirectQuery, co może spowodować spowolnienie wydajności zapytań.

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

Podróż w czasie różnicy

Pliki łączy umożliwiają wykonywanie zapytań dotyczących danych we wcześniejszym punkcie w czasie. Ta funkcja jest znana jako podróż w czasie delty. 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ż wykonać zapytanie dotyczące tabeli przy użyciu składni skróconej @ , aby określić sygnaturę czasową lub wersję w ramach nazwy tabeli. Znacznik czasu musi być w yyyyMMddHHmmssSSS formacie. Możesz określić wersję po @ , poprzedzając v element do wersji.

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

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

Ważne

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

Kadrowanie

Tworzenie ramek to operacja Direct Lake, która ustawia wersję tabeli delty, 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 tworzenia ramek oznacza sygnaturę czasową/wersję każdej tabeli delty do tabel modelu semantycznego. Od tego momentu, gdy model semantyczny musi załadować dane z tabeli delty, sygnatura czasowa/wersja skojarzona z najnowszą operacją tworzenia ramek jest używana do określania, jakie dane mają być ładowane. Wszelkie kolejne modyfikacje danych, które występują w tabeli delty od czasu ostatniej operacji tworzenia ramek, są ignorowane (do następnej operacji tworzenia ramek).

Ważne

Ponieważ model semantyczny w ramce odwołuje się do określonej wersji tabeli delty, źródło musi upewnić się, że przechowuje wersję tabeli delty do momentu ukończenia tworzenia ramek 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.

Aby uzyskać więcej informacji na temat tworzenia ramek, zobacz Omówienie usługi Direct Lake.

Partycjonowanie tabel

Tabele różnicowe 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.

Klucz partycji należy zdefiniować podczas konfigurowania partycjonowania tabel. 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 podzielonej na partycje tabeli delty jest filtrowane tylko do ostatnich trzech miesięcy danych sprzedaży, podzestaw plików Parquet i plików linków, do których należy uzyskać dostęp, można szybko zidentyfikować. 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 różnicowych w większości przypadków — chyba że operacje zapisu lub wyodrębnianie, przekształcanie i ładowanie (ETL) będą wyraźnie korzystać z nich.

Partycjonowanie korzyści wstawiania, aktualizowania i usuwania również operacji, ponieważ działanie pliku odbywa się tylko w podfolderach pasujących do klucza 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 delty używają partycji, mogą pomóc w projektowaniu optymalnych scenariuszy ETL, które zmniejszają operacje zapisu, które muszą być wykonywane podczas aktualizowania dużych tabel różnicowych. 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żne

Jeśli głównym celem tabeli delty jest służyć jako źródło danych dla modeli semantycznych (i po drugie, inne obciążenia zapytań), zwykle lepiej jest unikać partycjonowania preferencji w celu optymalizacji obciążenia kolumn do pamięci.

W przypadku modeli semantycznych usługi Direct Lake lub punktu końcowego analizy SQL najlepszym sposobem optymalizacji partycji tabeli delty jest automatyczne zarządzanie plikami Parquet dla każdej wersji tabeli delty. Pozostawienie zarządzania siecią szkieletową powinno spowodować wysoką wydajność zapytań poprzez równoległe przetwarzanie, 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 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 sieci szkieletowej ma zabezpieczenia. Jeśli liczba plików Parquet dla tabeli delty przekroczy limit dla jednostki SKU, zapytania zostaną przywrócone do trybu DirectQuery, co może spowodować spowolnienie wydajności zapytań.

Pliki Parquet

Podstawowym magazynem dla tabeli delty jest co najmniej jeden plik Parquet. Format pliku Parquet jest zwykle używany w przypadku aplikacji do zapisu jednokrotnego i wielu do odczytu. Nowe pliki Parquet są tworzone za każdym razem, gdy dane w tabeli delty są modyfikowane, niezależnie od tego, czy są wykonywane przez operację wstawiania, aktualizowania lub usuwania.

Uwaga

Dostęp do plików Parquet skojarzonych z tabelami delty 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. Formaty te 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 ProductID StockOnHand
2024-09-16 A 10
2024-09-16 B 11
2024-09-17 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 przez podstawianie kluczy słownika dla typowych wartości i stosowanie kodowania długości przebiegu (RLE). RLE dąży do skompresowania serii tych samych wartości do mniejszej reprezentacji. W poniższym przykładzie w nagłówku jest tworzone mapowanie słownika kluczy liczbowych 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ę StockOnHand kolumny 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.

Uwaga

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

Sieć szkieletowa obsługuje dodatkową optymalizację o nazwie V-Order. V-Order to optymalizacja czasu zapisu w formacie pliku Parquet. Po zastosowaniu polecenia V-Order następuje zmniejszenie i szybsze odczytywanie pliku. 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 różnicowe utworzone i załadowane przez elementy sieci szkieletowej, takie jak potoki danych, przepływy danych i notesy, automatycznie stosują kolejność wirtualną. Jednak pliki Parquet przekazane do usługi Fabric lakehouse lub przywoływane przez skrót mogą nie mieć zastosowania tej optymalizacji. Mimo że nieoptymalizowane pliki Parquet nadal mogą być odczytywane, wydajność odczytu prawdopodobnie nie będzie tak szybka, jak równoważny plik Parquet, który ma zastosowaną kolejność wirtualną.

Uwaga

Pliki Parquet, które mają zastosowaną kolejność wirtualną, są nadal zgodne z formatem pliku Parquet typu open source. W związku z tym można je odczytywać za pomocą narzędzi innych niż sieć szkieletowa.

Aby uzyskać więcej informacji, zobacz Delta Lake table optimization and V-Order (Optymalizacja tabel usługi Delta Lake) i V-Order (Kolejność maszyn wirtualnych).

Optymalizacja tabeli delty

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

Ilość danych

Chociaż tabele delty mogą rosnąć w celu przechowywania bardzo dużych ilości danych, zabezpieczenia pojemności sieci szkieletowej nakładają limity na modele semantyczne, które je wysyłają. Gdy te limity zostaną przekroczone, zapytania powrócą do trybu DirectQuery, co może spowodować spowolnienie wydajności zapytań.

W związku z tym należy rozważyć ograniczenie liczby wierszy dużej tabeli faktów przez podniesienie stopnia szczegółowości (przechowywanie podsumowanych danych), zmniejszenie wymiarowości lub przechowywanie mniejszej liczby historii.

Upewnij się również, że kolejność V-Order jest stosowana, ponieważ powoduje mniejsze, a tym samym szybsze odczytywanie pliku.

Typy danych w kolumnach

Staraj się zmniejszyć kardynalność (liczbę unikatowych wartości) w każdej kolumnie każdej tabeli delty. Dzieje się tak, ponieważ wszystkie kolumny są kompresowane i przechowywane przy użyciu kodowania skrótu. Kodowanie skrótu wymaga optymalizacji kolejności V, 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ń.

Jeśli używasz przybliżonych typów danych liczbowych (takich jak zmiennoprzecinkowe i rzeczywiste), rozważ zaokrąglanie 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 różnicowe powinny zawierać kolumny wymagane przez semantyczny model filtrowania, grupowania, sortowania i podsumowywania, a także kolumn, które obsługują 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 FirstName kolumny i LastName i potrzebujesz FullName kolumny, 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 ładowanie danych kolumn do modelu semantycznego z powodu nadmiernego 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, być może tworząc wiele kopii tych samych tabel różnicowych z różnymi konfiguracjami w celu porównania chronometrażu.

Ważne

Należy pamiętać, że każda licencja pojemności sieci szkieletowej ma zabezpieczenia. Jeśli liczba grup wierszy dla tabeli delty przekroczy limit dla jednostki SKU, zapytania powrócą do trybu DirectQuery, co może spowodować spowolnienie wydajności zapytań.

Konserwacja tabeli delty

Wraz z upływem czasu w miarę gromadzenia się operacji zapisu wersje tabel funkcji Delta. W końcu może dojść do punktu, w którym negatywny wpływ na wydajność odczytu staje się zauważalny. Co gorsza, jeśli liczba plików Parquet na tabelę lub grupy wierszy na tabelę lub wiersze na tabelę przekracza bariery ochronne dla pojemności, zapytania będą wracać do trybu DirectQuery, co może spowodować spowolnienie wydajności zapytań. Dlatego ważne jest regularne utrzymywanie tabel delty.

OPTIMIZE

Za pomocą funkcji OPTIMIZE można zoptymalizować tabelę delty, aby połączyć mniejsze pliki w większe. Można również ustawić klauzulę WHERE na docelową tylko filtrowany podzbiór wierszy, które pasują do danego predykatu partycji. Obsługiwane są tylko filtry obejmujące klucze partycji. Polecenie OPTIMIZE może również stosować polecenie V-Order w celu kompaktowania 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.

VACUUM

Za pomocą funkcji VACUUM można usuwać pliki, do których już nie odwołuje się odwołanie i/lub które są starsze niż ustawiony próg przechowywania. Zachowaj ostrożność, aby ustawić odpowiedni okres przechowywania. W przeciwnym razie możesz utracić możliwość powrotu do wersji starszej niż ramka oznaczana do tabel modelu semantycznego.

Ważne

Ponieważ model semantyczny w ramce odwołuje się do określonej wersji tabeli delty, źródło musi upewnić się, że przechowuje wersję tabeli delty do momentu ukończenia tworzenia ramek 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.

TABELA REORG

Tabelę REORG można użyć do reorganizacji tabeli delty przez ponowne zapisywanie plików w celu przeczyszczania danych usuniętych nietrwale, takich jak podczas upuszczania kolumny przy użyciu funkcji 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 typu lakehouse w portalu sieci szkieletowej, aby uprościć zarządzanie tabelami delty.

Powiązana zawartość