Direct Lake vs Import w Power BI. Który tryb wybrać dla dużych modeli danych

Direct Lake to tryb przechowywania danych w Power BI, który odczytuje dane bezpośrednio z OneLake, bez importowania ich do modelu, zachowując przy tym wydajność zapytań porównywalną z trybem Import. Największa różnica ujawnia się przy dużych modelach: Direct Lake eliminuje czasochłonne odświeżenia i wielokrotnie obniża zużycie jednostek obliczeniowych, czyli capacity units. Pytanie o porównanie obu trybów dla modelu z ponad trzydziestoma milionami wierszy padło na naszym webinarze o hurtowni danych 2.0 i ten artykuł jest rozwiniętą odpowiedzią.

‍

Trzy tryby przechowywania danych w Power BI

Power BI oferuje trzy sposoby pracy z danymi, a wybór między nimi to jedna z ważniejszych decyzji architektonicznych w projekcie analitycznym.

Import ładuje dane do pamięci modelu. To klasyczny, najstarszy tryb i przez lata domyślny wybór dla większości wdrożeń.

DirectQuery nie przechowuje danych w modelu w ogóle: każda interakcja z raportem generuje zapytanie do źródła. Zapewnia dane zawsze aktualne, ale wydajność zależy w całości od źródła i przy złożonych raportach bywa bolesna.

Direct Lake to tryb dostępny w Microsoft Fabric, który łączy zalety obu podejść: dane nie są importowane do modelu, a mimo to zapytania działają z szybkością znaną z trybu Import. Jak to możliwe, wyjaśniamy poniżej.

‍

Jak działa tryb Import

W trybie Import dane są ładowane do pamięci modelu i kompresowane przez silnik VertiPaq: kolumnowy silnik analityczny, który stoi za szybkością Power BI. Gdy dane są już w pamięci, odpytywanie jest błyskawiczne: filtry, przekroje i kalkulacje na milionach wierszy liczą się w ułamkach sekund.

Cena tej szybkości ujawnia się przy odświeżaniu. Każde odświeżenie oznacza ponowne załadowanie danych ze źródła do modelu, a przy tabeli faktów liczącej dziesiątki milionów wierszy to proces zajmujący sporo czasu. I nie dotyczy to tylko pierwszego ładowania: każde kolejne odświeżenie wykonuje tę samą ciężką pracę.

Z perspektywy platformy Fabric ma to jeszcze jeden wymiar: zużycie capacity units. Pełne odświeżenie dużego modelu w trybie Import intensywnie konsumuje jednostki obliczeniowe wykupionej pojemności. Przy częstych odświeżeniach dużych modeli to właśnie one potrafią stać się głównym kosztem środowiska.

‍

Jak działa Direct Lake

Direct Lake korzysta z tego samego silnika VertiPaq, ale zmienia ścieżkę danych: zamiast importować dane do modelu, odczytuje pliki bezpośrednio z OneLake. Jest to możliwe, ponieważ dane w OneLake są składowane w otwartym formacie Delta Parquet, czyli w układzie kolumnowym, który VertiPaq potrafi czytać natywnie, bez wcześniejszej konwersji i ładowania.

W praktyce oznacza to, że etap odświeżania modelu w zasadzie znika. Dane zaktualizowane w Lakehouse, na przykład przez transformację Dataflow, są dostępne dla raportów bez przeładowywania czegokolwiek do pamięci modelu.

Jedno zjawisko trzeba znać: cold start. Pierwsze zapytanie do danej porcji danych bywa wolniejsze, ponieważ silnik dopiero ładuje potrzebne kolumny do pamięci. Każde kolejne zapytanie do tych samych danych działa już z pełną szybkością. W codziennym użytkowaniu raportu efekt jest odczuwalny co najwyżej przy pierwszym otwarciu po dłuższej przerwie.

‍

Porównanie na dużym modelu: ponad 30 milionów wierszy w tabeli faktów

Właśnie przy takiej skali, o którą pytano na webinarze, różnice między trybami przestają być teoretyczne.

Czas odświeżenia. W trybie Import każde odświeżenie modelu z tabelą faktów tej wielkości to długi, ciężki proces, który trzeba mieścić w oknach czasowych i którego awarie trzeba obsługiwać. W Direct Lake odświeżenia modelu w klasycznym sensie nie ma: aktualizują się dane w Lakehouse, a model czyta je na bieżąco.

Wydajność zapytań. Po rozgrzaniu, czyli po załadowaniu kolumn do pamięci przy pierwszych zapytaniach, oba tryby oferują porównywalną szybkość, bo pracuje ten sam silnik. Import ma minimalną przewagę braku cold startu, Direct Lake nadrabia ją brakiem opóźnienia między aktualizacją danych a ich widocznością w raporcie.

Zużycie capacity units. Tu różnica jest największa i najbardziej odczuwalna finansowo. Import przy każdym odświeżeniu konsumuje jednostki na przeładowanie całego modelu. Direct Lake tej pracy nie wykonuje wcale, więc jego zużycie jednostek jest znacznie niższe. Przy dużych modelach odświeżanych codziennie lub częściej to argument, który potrafi samodzielnie rozstrzygnąć wybór trybu, a w skrajnych przypadkach zdecydować o tym, czy obecna pojemność w ogóle wystarcza.

‍

‍

Kiedy Import nadal ma sens

Direct Lake jest naturalnym wyborem dla modeli zbudowanych na Lakehouse w Fabric, ale Import nie odchodzi do historii.

Źródła spoza OneLake. Direct Lake wymaga danych w OneLake w formacie Delta. Jeśli model ma łączyć dane z hurtowni z małym słownikiem utrzymywanym gdzie indziej, ten fragment może wymagać importu.

Rozbudowana logika w samym modelu. Modele, które intensywnie korzystają z kolumn wyliczanych i przekształceń wykonywanych na poziomie modelu, mogą wymagać trybu Import, bo Direct Lake zakłada, że transformacje dzieją się wcześniej, w warstwie danych. To zresztą dobra praktyka niezależnie od trybu: logika transformacyjna powinna żyć w Dataflow, nie w modelu.

Fallback do DirectQuery. Warto wiedzieć, że w określonych sytuacjach, na przykład przy przekroczeniu limitów pojemności dla trybu Direct Lake, silnik może przełączyć zapytania na tryb DirectQuery, co odbija się na wydajności. Dobrze zaprojektowany model i właściwie dobrana pojemność minimalizują ryzyko takiego przełączenia, a zachowanie fallbacku można kontrolować w ustawieniach modelu.

‍

Rekomendacje architektoniczne

Prosta macierz decyzyjna na start:

‍

Reguła kciuka: jeśli budujesz hurtownię w Fabric zgodnie z podejściem, które opisujemy w artykule o budowie hurtowni krok po kroku, Direct Lake jest domyślnym wyborem, a Import traktuj jako uzasadniony wyjątek.

Dobór trybów przechowywania to element szerszego projektu architektury: układu tabel, modelu semantycznego i pojemności środowiska. Zespół Power Center w ANEGIS przeprowadza audyty wydajności istniejących środowisk Power BI i Fabric: sprawdzamy, gdzie ucieka czas odświeżeń i capacity units, i projektujemy układ docelowy. Jeśli Wasze modele rosną szybciej niż pojemność, zapraszamy do kontaktu.

‍