Blog JSystems - uwalniamy wiedzę!

Szukaj

Power BI - Potoki wdrażania, Fabric, Copilot i telefon

Direct Lake przełącza się na DirectQuery - przyczyny trybu zapasowego

W skrócie

  • Model Direct Lake na punkcie końcowym SQL przełącza zapytania na DirectQuery (ang. fallback, tryb zapasowy), gdy nie może czytać tabel Delta wprost. Raport działa dalej, ale wolniej, a w historii odświeżania pojawia się ostrzeżenie.
  • Według dokumentacji Microsoft przyczyny to tabele oparte na widokach SQL, zabezpieczenia RLS, OLS albo maskowanie danych w punkcie końcowym SQL, tabele ponad limitami pojemności i tabele nieodświeżone po zmianie.
  • Wariant modelu sprawdzasz w widoku TMDL, powód powrotu zapytaniem TABLETRAITS, a skutek w Analizatorze wydajności. Potem usuwasz przyczynę i ustawiasz Zachowanie trybu Direct Lake. Wariant Direct Lake na OneLake w ogóle nie przechodzi na DirectQuery.

Przełączenie modelu Direct Lake na DirectQuery dzieje się po cichu: raport na lakehouse albo magazynie danych po prostu zwalnia, choć model miał czytać tabele Delta prosto z OneLake. Tak działa tryb zapasowy Direct Lake w modelu semantycznym Microsoft Fabric.Pokazujemy, w którym wariancie Direct Lake to występuje, jakie są przyczyny według dokumentacji Microsoft, jak sprawdzić powód dla każdej tabeli i jak ustawić zachowanie modelu.

Jak to wygląda w praktyce

Pierwszy objaw to wolniejsze wizualizacje bez komunikatu. W Power BI Desktop pokazuje to Analizator wydajności: przy wizualizacji pojawia się wiersz Zapytanie bezpośrednie, czyli czas zapytania wysłanego do źródła. Według dokumentacji Microsoft przy zapytaniu obsłużonym w trybie Direct Lake tego wiersza nie ma. Drugie miejsce to historia odświeżania modelu w usłudze. Odświeżenie kończy się powodzeniem, ale z ostrzeżeniem, na przykład „Zauważyliśmy, że co najmniej jedna tabela w modelu jest oparta na widokach opartych na języku T-SQL wymagających od zapytań powrotu do trybu DirectQuery.” Podobne ostrzeżenia usługa ma dla zabezpieczeń RLS w źródle i dla tabel Delta, które przekraczają limity zasobów pojemności.

Gdy powrót do DirectQuery jest wyłączony, zamiast spowolnienia widzisz błąd wizualizacji: „Nie możemy przetworzyć żądania, ponieważ żądanie wymagałoby powrotu do trybu DirectQuery, ale dla tego zestawu danych wyłączono powrót.” (w angielskiej wersji: „We cannot process the request because the request would require a fallback to DirectQuery mode, but fallback is disabled for this dataset.”). Przy tabeli nieodświeżonej po zmianie silnik pisze „Nie można przetworzyć żądania, ponieważ tabela «faktsprzedaz» nie została odświeżona, a powrót do trybu DirectQuery jest wyłączony dla tego modelu semantycznego.” (w angielskiej wersji: „We cannot process the request because table 'faktsprzedaz' is not refreshed and fallback to DirectQuery is disabled for this semantic model.”).

Dlaczego tak się dzieje

Direct Lake ma dwa warianty. Direct Lake na punkcie końcowym SQL, czyli na warstwie SQL lakehouse albo magazynu danych, korzysta z tego punktu do odczytu schematu i sprawdzania uprawnień, a dane wczytuje z OneLake. Według dokumentacji Microsoft taki model zostaje w trybie Direct Lake tylko wtedy, gdy żadna tabela nie ma zabezpieczeń na poziomie wiersza (RLS), obiektów (OLS) ani dynamicznego maskowania danych zdefiniowanych w punkcie końcowym SQL, żadna nie jest oparta na niezmaterializowanym widoku SQL, model odświeżono po zmianie tabel Delta i żadna tabela nie przekracza limitów pojemności. Jedna tabela ponad limitem wyłącza tryb Direct Lake dla całego modelu. Dla najmniejszej pojemności F2 dokumentacja podaje 1000 plików Parquet i 1000 grup wierszy na tabelę, 300 milionów wierszy na tabelę i 10 GB rozmiaru modelu. Dokumentacja Microsoft wymienia jako powód także brak pamięci pojemności przy wielu równoległych obciążeniach.

Drugi wariant, Direct Lake na OneLake, według dokumentacji nigdy nie przechodzi na DirectQuery: po przekroczeniu limitów odświeżenie się nie udaje, a zapytania kończą się błędem. W kursie model Nordvella Direct Lake zakładaliśmy w lakehouse NordvellaLakehouse przyciskiem Nowy model semantyczny, a okno tworzenia modelu przypominało: „Widoków SQL nie można wybrać dla usługi Direct Lake na OneLake, ale tabele oparte na widokach SQL można później dodać do modelu semantycznego, korzystając z innych trybów magazynu.” Tryby przechowywania i różnice między nimi opisujemy w poście o wyborze między Importem a DirectQuery.

Okno Nowy model semantyczny w lakehouse: model Nordvella Direct Lake z czterema tabelami i uwagą o widokach SQL
Nowy model w trybie Direct Lake. Okno przypomina, że widoków SQL nie wybierzesz dla Direct Lake na OneLake.

Co zrobić krok po kroku

  1. Sprawdź wariant modelu. Otwórz model w Power BI Desktop, otwórz Widok TMDL i przeciągnij do edytora z panelu Dane węzeł z wyrażeniami modelu. Według dokumentacji Microsoft Direct Lake na OneLake korzysta z łącznika Azure Data Lake Storage, a Direct Lake na punkcie końcowym SQL z łącznika SQL Server albo OneLake.SqlAnalytics(). Przyczyn powrotu do DirectQuery szukasz tylko w drugim przypadku.
  2. Ustal powód dla każdej tabeli. Na modelu opublikowanym w usłudze uruchom w widoku zapytań w języku DAX zapytanie poniżej. Według dokumentacji Microsoft kolumna [DirectLakeFallbackInfo] podaje przyczynę powrotu, a wartość None oznacza, że tabela działa w trybie Direct Lake. Funkcja wymaga uprawnień administratora modelu, inaczej silnik odpowiada „Funkcja TABLETRAITS może być wykonywana tylko przez użytkownika z uprawnieniami administratora w bazie danych.” (w angielskiej wersji: „TABLETRAITS function can be executed only by the user with administrator permissions on the database.”). Na modelu Nordvelli w trybie Import, otwartym w Power BI Desktop, to samo zapytanie zwróciło „Funkcja TABLETRAITS może być wykonywana tylko w wersji PBI-Premium.” (w angielskiej wersji: „TABLETRAITS function may only be executed in Power BI Premium.”), więc diagnozę robisz na modelu w usłudze.
    EVALUATE TABLETRAITS()
  3. Potwierdź to na raporcie. W Desktopie połączonym z modelem kliknij na karcie Widok przycisk Analizator wydajności, potem Rozpocznij nagrywanie i Odśwież wizualizacje. Rozwiń wiersz wizualizacji: pozycja Zapytanie bezpośrednie oznacza, że zapytanie poszło do punktu końcowego SQL. Pracę z analizatorem opisujemy w poście o szukaniu wizualizacji, która spowalnia raport.
  4. Usuń przyczynę. Tabelę opartą na widoku SQL zmaterializuj jako tabelę Delta albo zaakceptuj DirectQuery dla tej tabeli. Zabezpieczenia RLS i OLS przenieś z punktu końcowego SQL do modelu semantycznego, tak jak role w lekcji o zabezpieczeniach na poziomie wiersza. Tabelę Delta ponad limitem skompaktuj poleceniami OPTIMIZE i VACUUM, a gdy to nie wystarczy, potrzebna jest większa pojemność. Tabelę nieodświeżoną po zmianie naprawia odświeżenie modelu.
  5. Ustaw zachowanie modelu. W widoku modelu otwórz Właściwości modelu semantycznego i znajdź Zachowanie trybu Direct Lake. Wartość domyślna (w dokumentacji Automatic) po cichu przechodzi na DirectQuery, Tylko tryb Direct Lake zamienia każdy powrót w błąd, a Tylko tryb DirectQuery zawsze wysyła zapytania do punktu końcowego SQL. Dokumentacja Microsoft zaleca Tylko tryb Direct Lake na czas tworzenia modelu, żeby problemy wyszły od razu, a Automatic na produkcji.
  6. Przy nowym modelu rozważ wariant Direct Lake na OneLake, który dokumentacja Microsoft zaleca dla nowych modeli. Nie przechodzi on na DirectQuery, a tabele oparte na widokach SQL dodasz w trybie Import albo DirectQuery jako model złożony.

Jak sprawdzić, że problem zniknął

Naprawione, gdy TABLETRAITS() pokazuje None dla wszystkich tabel, w Analizatorze wydajności nie ma wiersza Zapytanie bezpośrednie, a historia odświeżania nie ma ostrzeżenia. Sprawdź też liczby: w kursie model Direct Lake dał 467 775 009,17 zł Łącznej sprzedaży, 222 818 294,93 zł dla Warszawy i 108 675 wierszy FaktSprzedaz, tyle samo co model Import. Gdy powrót do DirectQuery jest akceptowany, sprawdź, jak szybko odpowiada punkt końcowy SQL, bo raport działa wtedy jak model DirectQuery, o czym piszemy w poście o wolnym trybie DirectQuery.

Żeby tryb zapasowy nie wracał, odświeżaj model po każdej zmianie tabel Delta, regularnie kompaktuj duże tabele i przed dużym przyrostem danych porównaj liczbę wierszy największej tabeli z limitem swojej pojemności.

Źródła i sposób sprawdzenia

  • Microsoft Learn: How Direct Lake works (DirectQuery fallback, DirectLakeBehavior, TABLETRAITS) (źródło)
  • Microsoft Learn: Direct Lake overview (warianty, limity pojemności) (źródło)
  • Microsoft Learn: Develop Direct Lake semantic models (rozpoznanie wariantu po łączniku) (źródło)
  • Microsoft Learn: Analyze query processing for Direct Lake semantic models (Performance analyzer) (źródło)
  • Kurs Power BI, lekcja 27: lakehouse NordvellaLakehouse, model Nordvella Direct Lake, te same liczby co w modelu Import

Zachowanie programu sprawdziliśmy w Power BI Desktop 2.157 (wydanie z sierpnia 2026 r.) z polskim interfejsem, a przykłady na modelu sieci Nordvella z bezpłatnego kursu Power BI. Microsoft wydaje nową wersję Power BI Desktop co miesiąc, więc nazwy przycisków i limity usługi mogą się zmieniać. Aktualne wartości podaje dokumentacja Microsoft Learn.

Wróć do listy: 131 najczęstszych pytań i problemów związanych z Power BI

Najczęściej zadawane pytania

Dlaczego Direct Lake przełącza się na DirectQuery?
Według dokumentacji Microsoft model Direct Lake na punkcie końcowym SQL przechodzi na DirectQuery, gdy tabela jest oparta na widoku SQL, gdy w punkcie końcowym SQL zdefiniowano RLS, OLS albo maskowanie danych, gdy tabela przekracza limity pojemności albo nie została odświeżona po zmianie. Raport działa dalej, ale zapytania są wolniejsze.
Jak sprawdzić, czy model Direct Lake używa DirectQuery?
Uruchom zapytanie DAX EVALUATE TABLETRAITS() na modelu w usłudze: kolumna DirectLakeFallbackInfo podaje przyczynę dla każdej tabeli, a wartość None oznacza tryb Direct Lake. W Analizatorze wydajności Power BI Desktop powrót widać jako wiersz Zapytanie bezpośrednie przy wizualizacji.
Jak wyłączyć fallback do DirectQuery w Direct Lake?
We właściwościach modelu semantycznego ustaw Zachowanie trybu Direct Lake na Tylko tryb Direct Lake. Zapytania, które wymagałyby DirectQuery, kończą się wtedy błędem zamiast spowolnienia. Dokumentacja Microsoft zaleca to ustawienie podczas tworzenia modelu, a na produkcji wartość domyślną Automatic.
Czy Direct Lake na OneLake przechodzi na DirectQuery?
Nie. Według dokumentacji Microsoft Direct Lake na OneLake działa wyłącznie w trybie Direct Lake. Po przekroczeniu limitów pojemności odświeżenie się nie udaje, a zapytania zwracają błąd, więc tabele trzeba zoptymalizować albo zwiększyć pojemność.

Komentarze (0)

Musisz być zalogowany by móc dodać komentarz. Zaloguj się przez Google

Brak komentarzy...