Udostępnij przez

Omówienie usługi Direct Lake

Direct Lake to opcja trybu przechowywania tabel semantycznego modelu Power BI dostępna w Microsoft Fabric. Jest zoptymalizowany pod kątem szybkiego ładowania dużych wolumenów danych do pamięci z delta tables dostępnych w OneLake — jednego magazynu na wszystkie dane analityczne. Po załadowaniu do pamięci semantyczny model umożliwia interaktywną analizę o wysokiej wydajności.

Diagram przedstawia semantyczny model usługi Direct Lake i sposób nawiązywania połączenia z tabelami delty w usłudze OneLake zgodnie z opisem w poprzednich akapitach.

Direct Lake jest idealny dla modeli semantycznych łączących się z dużymi lakehousami Fabric, magazynami Fabric i innymi źródłami danych Fabric z tabelami delta. Usługa Direct Lake jest szczególnie przydatna, gdy replikowanie całego woluminu danych do tabeli importu jest trudne lub niemożliwe. Zapytania Direct Lake oraz import są przetwarzane przez aparat zapytań VertiPaq, podczas gdy zapytania DirectQuery są przekazywane do bazowego źródła danych. Zapytania Direct Lake i import są zwykle wydajniejsze od zapytań DirectQuery podczas wczytywania i interakcji z wizualizacjami w raportach.

Jednak usługa Direct Lake różni się od trybu importu w ważny sposób: operacja odświeżania modelu semantycznego usługi Direct Lake różni się koncepcyjnie od operacji odświeżania dla modelu semantycznego importu. Tryb importu replikuje dane i tworzy całą buforowaną kopię danych dla modelu semantycznego, natomiast odświeżanie Direct Lake kopiuje tylko metadane (znane jako framing, opisane w dalszej części tego artykułu), co może potrwać kilka sekund. Odświeżanie usługi Direct Lake to ekonomiczna operacja, która analizuje metadane najnowszej wersji tabel Delta i aktualizuje odwołania do najnowszych plików w usłudze OneLake. Natomiast w przypadku odświeżania importu, generuje się kopię danych, co może zająć dużo czasu i zużywać znaczne zasoby źródeł danych i pojemności systemowej (pamięć i procesor CPU). Usługa Direct Lake przenosi przygotowywanie danych do usługi OneLake i w ten sposób używa pełnego zakresu technologii Fabric do przygotowywania danych, w tym zadań Spark, instrukcji DML języka T-SQL, przepływów danych, potoków i nie tylko.

Tryb przechowywania w usłudze Direct Lake oferuje następujące kluczowe korzyści:

  • Podobnie jak w trybie importu, zapytania Direct Lake są przetwarzane przez aparat VertiPaq, a tym samym zapewniają wydajność zapytań porównywalną z trybem importu bez nakładu pracy związanego z zarządzaniem cyklami odświeżania danych w celu załadowania całego woluminu danych.
  • Wykorzystuje istniejące inwestycje w Fabric przez bezproblemową integrację z dużymi jeziorami danych, magazynami danych i innymi źródłami Fabric z tabelami Delta. Na przykład usługa Direct Lake jest idealnym wyborem dla złotej warstwy analitycznej w architekturze medallion lakehouse.
  • Maksymalizuje zwrot z inwestycji (ROI), ponieważ przeanalizowane woluminy danych mogą przekraczać maksymalne limity pamięci pojemności, ponieważ tylko dane potrzebne do udzielenia odpowiedzi na zapytanie są ładowane do pamięci.
  • Minimalizuje opóźnienia danych dzięki szybkiemu i automatycznemu synchronizowaniu modelu semantycznego ze źródłami, dzięki czemu nowe dane są dostępne dla użytkowników biznesowych bez harmonogramów odświeżania.

Kiedy należy używać trybu przechowywania w usłudze Direct Lake?

Podstawowy przypadek użycia trybu przechowywania Direct Lake jest zwykle przeznaczony dla projektów analitycznych prowadzonych przez IT, które korzystają z architektur skoncentrowanych na jeziorach. W takich scenariuszach masz lub spodziewasz się gromadzić duże ilości danych w usłudze OneLake. Szybkie ładowanie tych danych do pamięci, częste i szybkie operacje odświeżania, wydajne wykorzystanie zasobów pojemności i wydajność szybkiego wykonywania zapytań są ważne w tym przypadku użycia.

Notatka

Tabele Import i DirectQuery w modelach semantycznych są nadal istotne w Fabric i są właściwym wyborem dla modelu semantycznego w określonych scenariuszach. Na przykład tryb importu przechowywania często dobrze sprawdza się dla analityka korzystającego z samoobsługi, który potrzebuje swobody i elastyczności, aby działać szybko i bez konieczności polegania na IT przy dodawaniu nowych elementów danych.

Semantyczny model z tabelami importu i tabelami usługi Direct Lake zapewnia elastyczność w zakresie skalowania wymaganego również w przypadku wielu scenariuszy analizy biznesowej.

Ponadto integracja z OneLake automatycznie zapisuje dane z tabel w trybie magazynu "Import" do tabel Delta w OneLake bez potrzeby przeprowadzania migracji, co pozwala na wykorzystanie wielu zalet usługi Fabric, które są dostępne dla użytkowników semantycznych modeli importu, takich jak integracja z lakehouse przez skróty, zapytania SQL, notatniki i inne funkcje. Zalecamy tę opcję jako szybki sposób na czerpanie korzyści z usługi Fabric bez konieczności lub natychmiastowego przeprojektowania istniejącego magazynu danych i/lub systemu analitycznego.

Usługa Direct Lake zależy od przygotowywania danych w usłudze Data Lake. Przygotowywanie danych można wykonać przy użyciu różnych narzędzi, takich jak zadania platformy Spark dla lakehouse'ów usługi Fabric, instrukcje DML języka T-SQL dla hurtowni Fabric, przepływy danych, potoki i inne, co pomaga w zapewnieniu, że logika przygotowywania danych jest realizowana na wcześniejszych etapach w architekturze w celu zmaksymalizowania ponownego użycia. Jeśli jednak autor modelu semantycznego nie ma możliwości modyfikowania elementu źródłowego, na przykład gdy analityk samoobsługowy nie ma uprawnień do zapisu w lakehouse zarządzanym przez dział IT, rozszerzenie modelu poprzez tabele pamięci trybu Importu może być dobrym wyborem, ponieważ tryb Importu wspiera przygotowywanie danych za pomocą narzędzia Power Query, które jest określane jako część modelu semantycznego.

Pamiętaj, aby wziąć pod uwagę bieżącą licencję pojemności Fabric i zabezpieczenia pojemności Fabric, rozważając tryb przechowywania Direct Lake. Ponadto należy wziąć pod uwagę zagadnienia i ograniczenia , które zostały opisane w dalszej części tego artykułu.

Napiwek

Zalecamy utworzenie prototypu —lub weryfikacji koncepcji (POC) — w celu określenia, czy model semantyczny usługi Direct Lake jest właściwym rozwiązaniem, oraz aby ograniczyć ryzyko.

Kluczowe pojęcia i terminologia

W tym artykule przyjęto założenie znajomości następujących pojęć:

  • Użytkownicy ładują wizualizacje i wchodzą w interakcje z nimi w raportach usługi Power BI generujących zapytania języka DAX do modelu semantycznego.
  • Tryb przechowywania: semantyczny model przetwarza zapytania języka DAX inaczej w zależności od używanego trybu przechowywania tabel. Przykład:
    • Tryby magazynowania Import i Direct Lake używają aparatu VertiPaq do przetwarzania zapytań języka DAX i zwracania wyników do raportu i użytkownika usługi Power BI.
    • DirectQuery tłumaczy zapytania języka DAX na składnię zapytań źródła danych, taką jak zapytanie SQL, i uruchamia je w bazowej bazie danych. Te źródłowe bazy danych nie są zwykle zoptymalizowane pod kątem dużego obciążenia zapytań pochodzącego z raportów i zagregowanych zapytań wymaganych przez wizualizacje i mogą powodować niższą wydajność w porównaniu z trybami Importuj i Direct Lake.

Tryb przechowywania jest właściwością tabeli w modelu semantycznym. Gdy model semantyczny zawiera tabele z różnymi trybami przechowywania, jest określany jako model złożony. Aby uzyskać więcej informacji na temat trybów przechowywania, zobacz Tryby modelu semantycznego w usłudze Power BI.

Tryb przechowywania tabel w usłudze Direct Lake ma dwie opcje:

  • Usługa Direct Lake w usłudze OneLake może używać danych z co najmniej jednego źródła danych Fabric z tabelami delta. Usługa Direct Lake w usłudze OneLake nie wraca do trybu DirectQuery za pośrednictwem punktu końcowego analizy SQL źródła danych. Modele semantyczne z funkcją Direct Lake w tabelach OneLake mogą również mieć tabele do importu zaimportowane z innych źródeł danych.

Notatka

Usługa Direct Lake w usłudze OneLake jest obecnie dostępna w publicznej wersji zapoznawczej. Włącz ustawienie dzierżawy Użytkownik może utworzyć Direct Lake w modelach semantycznych OneLake (wersja zapoznawcza) w portalu administracyjnym, aby tworzyć modele semantyczne z użyciem tego trybu przechowywania tabel. Ustawienie dzierżawy nie wpływa na wcześniej utworzone modele semantyczne.

  • Usługa Direct Lake w usłudze SQL może używać danych z pojedynczego źródła danych Fabric z tabelami delta. Punkt końcowy analityki SQL jest używany do odnajdywania tabel delta i widoku SQL oraz sprawdzania uprawnień. Usługa Direct Lake w punktach końcowych SQL powraca do trybu przechowywania tabel DirectQuery, gdy nie może załadować danych bezpośrednio z tabeli różnicowej, na przykład gdy źródło danych jest widokiem SQL lub gdy usługa Warehouse korzysta z szczegółowej kontroli dostępu opartej na języku SQL. Właściwość semantycznego modelu, zachowanie Direct Lake, kontroluje mechanizm powrotu.

Porównanie trybów przechowywania

W poniższej tabeli porównaliśmy tryb przechowywania usługi Direct Lake z trybami przechowywania Import i DirectQuery.

Zdolność Usługa Direct Lake w usłudze OneLake Usługa Direct Lake w punktach końcowych SQL Importowanie DirectQuery
Ustawienie dzierżawy Włącz ustawienie dzierżawy Użytkownik może utworzyć usługę Direct Lake w semantycznych modelach OneLake (wersja zapoznawcza) w portalu administracyjnym. Włączone dla wszystkich dzierżaw. Włączone dla wszystkich dzierżaw. Włączone dla wszystkich dzierżaw.
Licencjonowania Tylko subskrypcja pojemności fabric (SKU) Tylko subskrypcja pojemności fabric (SKU) Dowolna licencja usługi Fabric lub Power BI (w tym bezpłatna licencja usługi Microsoft Fabric) Dowolna licencja usługi Fabric lub Power BI (w tym bezpłatna licencja usługi Microsoft Fabric)
Źródło danych Tabele dowolnego źródła danych Fabric wspierane przez tabele Delta Tylko tabele jeziorowe lub magazynowe (lub widoki) Dowolny łącznik Dowolny łącznik obsługujący tryb DirectQuery
Łączenie z widokami punktów końcowych analizy SQL Nie Tak — ale automatycznie powróci do trybu DirectQuery Tak Tak
Modele złożone Tak – może łączyć tabele w trybie przechowywania importu w modelowaniu online usługi Power BI z tabelami DirectQuery przy użyciu narzędzi XMLA. Nr 1 Tak — może łączyć się z tabelami trybu przechowywania DirectQuery, Dual i Direct Lake Tak — może łączyć się z tabelami trybów magazynowania Import, Dual i Direct Lake
Logowanie jednokrotne (SSO) Tak Tak Nie dotyczy Tak
Tabele obliczeniowe Tak — ale obliczenia nie mogą odwoływać się do kolumn tabel w trybie Direct Lake. Nie — z wyjątkiem grup obliczeń, parametrów warunkowych i parametrów pól, które niejawnie tworzą tabele obliczeniowe Tak Nie — tabele obliczeniowe używają trybu przechowywania Import, nawet jeśli odwołują się do innych tabel w trybie DirectQuery.
Kolumny obliczeniowe Nie Nie Tak Tak
Tabele hybrydowe Nie Nie Tak Tak
Partycje tabeli modelowej Nie — jednak partycjonowanie można wykonać na poziomie tabeli delty Nie — jednak partycjonowanie można wykonać na poziomie tabeli delty Tak — automatycznie utworzone przez odświeżanie przyrostowe lub utworzone ręcznie przy użyciu punktu końcowego XMLA Nie
Agregacje zdefiniowane przez użytkownika Nie Nie Tak – importowanie tabel agregacji w tabelach trybu DirectQuery jest wspierane Tak
Zabezpieczenia na poziomie obiektu lub kolumny dla punktu końcowego analizy SQL Nie Tak — ale może powodować błędy w przypadku odmowy uprawnień Tak — ale musi duplikować uprawnienia związane z zabezpieczeniami modelu semantycznego na poziomie obiektowym Tak — ale zapytania mogą powodować błędy w przypadku odmowy uprawnień
Zabezpieczenia na poziomie wiersza (RLS) punktu końcowego analizy SQL Nie Tak — ale zapytania wracają do trybu DirectQuery Tak — ale musi duplikować uprawnienia z modelem semantycznym RLS Tak
Zabezpieczenia modelu semantycznego na poziomie wiersza (RLS) Tak — ale zdecydowanie zaleca się użycie połączenia z chmurą o stałej tożsamości Tak — ale zdecydowanie zaleca się użycie połączenia z chmurą o stałej tożsamości Tak Tak
Zabezpieczenia na poziomie obiektu modelu semantycznego (OLS) Tak Tak Tak Tak
Duże woluminy danych bez wymagania dotyczącego odświeżania Tak Tak Nie Tak
Zmniejszanie opóźnienia danych Tak — gdy aktualizacje automatyczne są włączone lub programowe reframowanie Tak — gdy aktualizacje automatyczne są włączone lub programowe reframowanie Nie Tak
Power BI Embedded Tak 2 Tak 2 Tak Tak

1 W przypadku korzystania z usługi Direct Lake w punktach końcowych SQL nie można połączyć tabel trybu przechowywania direct lake z tabelami trybu directQuery lub podwójnego trybu przechowywania w tym samym modelu semantycznym. Można jednak użyć programu Power BI Desktop do utworzenia modelu złożonego w modelu semantycznym usługi Direct Lake, a następnie rozszerzyć go na nowe tabele (przy użyciu trybu importu, trybu DirectQuery lub podwójnego magazynu) lub obliczeń. Aby uzyskać więcej informacji, zobacz Tworzenie modelu złożonego na modelu semantycznym.

2 Wymaga tokenu osadzania w wersji 2. Jeśli używasz konta usługi, musisz użyć połączenia w chmurze z użyciem stałej tożsamości.

Jak działa usługa Direct Lake

Zazwyczaj zapytania wysyłane do modelu semantycznego Direct Lake są obsługiwane z pamięci podręcznej kolumn pochodzących z tabel delty. Podstawowym magazynem dla tabeli Delta w OneLake jest jeden lub więcej plików Parquet. Pliki Parquet organizują dane według kolumn zamiast wierszy. Modele semantyczne ładują całe kolumny z tabel delty do pamięci, ponieważ są one wymagane przez zapytania.

Usługa Direct Lake w usłudze OneLake nie jest połączona z punktem końcowym SQL, oferując ściślejszą integrację z funkcjami usługi OneLake, takimi jak zabezpieczenia usługi OneLake i bardziej wydajne plany zapytań języka DAX, ponieważ na przykład sprawdzanie bezpieczeństwa opartego na języku SQL nie jest wymagane. Rezerwowy tryb DirectQuery nie jest obsługiwany przez usługę Direct Lake w usłudze OneLake.

W przypadku usługi Direct Lake w punktach końcowych SQL zapytanie języka DAX może używać trybu rezerwowego DirectQuery, co obejmuje bezproblemowe przełączenie się do trybu DirectQuery. Rezerwowy tryb DirectQuery pobiera dane bezpośrednio z punktu końcowego analityki SQL lakehouse lub hurtowni. Na przykład przełączenie awaryjne występuje po wykryciu zabezpieczeń opartych na SQL w punkcie końcowym SQL. W takim przypadku operacja DirectQuery wysyła zapytanie do punktu końcowego analizy SQL. Operacje zapasowe mogą spowodować wolniejsze działanie zapytań.

W poniższych sekcjach opisano pojęcia i funkcje Direct Lake, w tym ładowanie kolumn, ramowanie, automatyczne aktualizacje i powrót do DirectQuery.

Ładowanie kolumn (transkodowanie)

Modele semantyczne Direct Lake ładują dane tylko z OneLake, gdy kolumny są zapytawane po raz pierwszy. Proces ładowania danych na żądanie z usługi OneLake jest znany jako transkodowanie.

Gdy model semantyczny odbiera zapytanie języka DAX (lub wyrażenia wielowymiarowe — MDX), najpierw określa, jakie kolumny są potrzebne do wygenerowania wyniku zapytania. Wymagana jest dowolna kolumna używana bezpośrednio przez zapytanie, a także kolumny wymagane przez relacje i miary. Zazwyczaj liczba kolumn potrzebnych do wygenerowania wyniku zapytania jest znacznie mniejsza niż liczba kolumn zdefiniowanych w modelu semantycznym.

Gdy zrozumie, które kolumny są potrzebne, semantyczny model określa, które kolumny są już w pamięci. Jeśli jakiekolwiek kolumny potrzebne do zapytania nie są w pamięci, semantyczny model ładuje wszystkie dane dla tych kolumn z usługi OneLake. Ładowanie danych kolumny jest zwykle szybką operacją, jednak może zależeć od czynników, takich jak kardynalność danych przechowywanych w kolumnach.

Kolumny załadowane do pamięci są następnie rezydujące w pamięci. Przyszłe zapytania obejmujące tylko kolumny rezydentne nie muszą ładować więcej kolumn do pamięci.

Kolumna pozostaje rezydentem, dopóki nie zostanie usunięta (eksmitowana) z pamięci. Przyczyny usunięcia kolumn:

  • Model lub tabela został odświeżony po aktualizacji tabeli Delta w źródle (zobacz Ramowanie w następnej sekcji).
  • Żadne zapytanie nie używało kolumny przez jakiś czas.
  • Inne przyczyny zarządzania pamięcią, w tym obciążenie pamięci ze względu na pojemność spowodowane równoczesnymi operacjami.

Wybór SKU Fabric określa maksymalną ilość dostępnej pamięci dla każdego semantycznego modelu Direct Lake na danej pojemności. Aby uzyskać więcej informacji o zabezpieczeniach zasobów i maksymalnych limitach pamięci, zobacz Wymagania dotyczące pojemności sieci szkieletowej w dalszej części tego artykułu.

Kadrowanie

Framing zapewnia właścicielom modelu kontrolę nad tym, jakie dane są ładowane do modelu semantycznego. Operacja Direct Lake, zwana ramowaniem, jest inicjowana przez odświeżenie modelu semantycznego i zazwyczaj zajmuje tylko kilka sekund. Dzieje się tak dlatego, że jest to operacja o niskich kosztach, w której semantyczny model analizuje metadane najnowszej wersji tabel usługi Delta Lake i jest aktualizowany w celu odwołania się do najnowszych plików Parquet w usłudze OneLake.

Podczas tworzenia ram, segmenty kolumn rezydentnej tabeli i słowniki mogą zostać wyrzucone z pamięci, jeśli bazowe dane uległy zmianie, a moment odświeżenia staje się nowym wyznacznikiem dla wszystkich przyszłych zdarzeń transkodowania. Od tego momentu zapytania Direct Lake uwzględniają tylko dane w tabelach Delta od momentu ostatniej operacji ramowania. Z tego powodu tabele direct Lake są odpytywane w celu zwrócenia danych na podstawie stanu tabeli delty w punkcie najnowszej pomyślnej operacji tworzenia ramek. Ten czas niekoniecznie jest najnowszym stanem tabel Delty.

Model semantyczny analizuje log Delta każdej tabeli Delta podczas typowania ramki, aby usunąć tylko segmenty kolumn dotknięte problemem i aby ponownie załadować nowo dodane dane w trakcie transkodowania. Ważną optymalizacją jest to, że słowniki na ogół nie są usuwane, gdy tworzenie ramek odbywa się w trybie przyrostowym, a nowe wartości dodawane są do istniejących słowników. To podejście do stopniowego tworzenia ramek pomaga zmniejszyć obciążenie związane z ponownym ładowaniem i korzystnie wpływa na wydajność zapytań. W idealnym przypadku, gdy tabela Delta nie otrzymała aktualizacji, nie ma potrzeby ponownego ładowania kolumn, które są już obecne w pamięci, a zapytania wykazują znacznie mniejszy wpływ na wydajność po wprowadzeniu ramowania, ponieważ przyrostowe ramowanie zasadniczo umożliwia modelowi semantycznemu aktualizowanie znacznych części istniejących danych bezpośrednio w pamięci.

Notatka

Tworzenie ram może zakończyć się niepowodzeniem, jeśli tabela delty przekracza zabezpieczenia pojemności sieci szkieletowej, na przykład gdy tabela delty ma więcej niż 10 000 plików parquet. Aby uzyskać więcej informacji o zabezpieczeniach zasobów, zobacz Wymagania dotyczące pojemności sieci szkieletowej w dalszej części tego artykułu.

Na poniższym diagramie pokazano, jak działają operacje tworzenia ram w usłudze Direct Lake.

Diagram pokazuje, jak działają operacje tworzenia ram w usłudze Direct Lake.

Diagram przedstawia następujące procesy i funkcje.

Przedmiot Opis
Model semantyczny istnieje w obszarze roboczym Fabric.
Operacje ramkowania są wykonywane okresowo i ustawiają punkt odniesienia dla wszystkich przyszłych zdarzeń transkodowania. Operacje tworzenia ramek mogą odbywać się automatycznie, ręcznie, zgodnie z harmonogramem lub za pomocą programowania.
Usługa OneLake przechowuje metadane i pliki Parquet, które są reprezentowane jako tabele delty.
Ostatnia operacja ramowania obejmuje pliki Parquet powiązane z tabelami Delta, a w szczególności pliki Parquet, które zostały dodane przed ostatnią operacją ramowania.
Późniejsza operacja ramowania obejmuje pliki Parquet dodane po ostatniej operacji ramowania .
Kolumny rezydentne w modelu semantycznym Direct Lake mogą zostać usunięte z pamięci, a moment, w którym następuje odświeżenie, staje się nową bazą dla wszystkich przyszłych zdarzeń transkodowania.
Kolejne modyfikacje danych reprezentowane przez nowe pliki Parquet nie są widoczne, dopóki nie nastąpi kolejna operacja ramowania.

Nie zawsze jest pożądane, aby dane reprezentowały najnowszy stan dowolnej tabeli Delta podczas wykonywania operacji transkodowania. Należy wziąć pod uwagę, że tworzenie ramek może pomóc w zapewnieniu spójnych wyników zapytań w środowiskach, w których dane w tabelach delty są przejściowe. Dane mogą być przejściowe z kilku powodów, takich jak w przypadku długotrwałych procesów wyodrębniania, przekształcania i ładowania (ETL).

Odświeżanie modelu semantycznego usługi Direct Lake można wykonać ręcznie, automatycznie lub programowo. Aby uzyskać więcej informacji, zobacz Odświeżanie modeli semantycznych usługi Direct Lake.

Aktualizacje automatyczne

Istnieje semantyczne ustawienie na poziomie modelu umożliwiające automatyczne aktualizowanie tabel usługi Direct Lake. Jest ona domyślnie włączona. Dzięki temu zmiany danych w usłudze OneLake zostaną automatycznie odzwierciedlone w modelu semantycznym usługi Direct Lake. Należy wyłączyć automatyczne aktualizacje, gdy chcesz kontrolować zmiany danych przez ramowanie, co zostało wyjaśnione w poprzedniej sekcji. Aby uzyskać więcej informacji, zobacz Zarządzanie modelami semantycznymi usługi Direct Lake.

Napiwek

Automatyczne odświeżanie stron można skonfigurować w raportach usługi Power BI. Jest to funkcja, która automatycznie odświeża określoną stronę raportu, zapewniając, że raport łączy się z modelem semantycznym usługi Direct Lake (lub innymi typami modelu semantycznego).

Fallback DirectQuery

W przypadku korzystania z usługi Direct Lake w punktach końcowych SQL zapytanie wysyłane do modelu semantycznego usługi Direct Lake może wrócić do trybu DirectQuery , w którym to przypadku tabela nie działa już w trybie Direct Lake. Pobiera dane bezpośrednio z punktu końcowego analizy SQL w magazynie danych lub domu jeziornego. Takie zapytania zawsze zwracają najnowsze dane, ponieważ nie są ograniczone do momentu w czasie ostatniej operacji ramowania.

Po przełączeniu na tryb awaryjny DirectQuery zapytanie nie korzysta już z trybu Direct Lake. Zapytanie nie może korzystać z trybu Direct Lake, gdy model semantyczny wysyła zapytanie do widoku lub tabeli w punkcie końcowym analityki SQL, która wymusza zabezpieczenia na poziomie wiersza (RLS). Ponadto zapytanie nie może korzystać z trybu Direct Lake, gdy tabela delta przekracza bariery ochronne pojemności.

Ważny

Jeśli to możliwe, zawsze należy zaprojektować swoje rozwiązanie lub dostosować pojemność, aby unikać korzystania z zapytania DirectQuery jako zapasowej opcji. Wynika to z faktu, że może to spowodować spowolnienie wydajności zapytań.

Możesz kontrolować zachowanie rezerwowe swoich semantycznych modeli Direct Lake, ustawiając ich właściwość DirectLakeBehavior. To ustawienie dotyczy tylko usługi Direct Lake w punktach końcowych SQL. Usługa Direct Lake w usłudze OneLake nie obsługuje trybu awaryjnego DirectQuery. Aby uzyskać więcej informacji, zobacz Ustawianie właściwości zachowania usługi Direct Lake.

Zabezpieczenia danych i uprawnienia dostępu

Domyślnie usługa Direct Lake używa logowania jednokrotnego (SSO), co oznacza, że tożsamość, która wysyła zapytanie do modelu semantycznego (często użytkownika raportu), musi być autoryzowana do uzyskiwania dostępu do danych. Alternatywnie można powiązać model Direct Lake z udostępnianym połączeniem w chmurze (SCC), aby przypisać stałą tożsamość i wyłączyć jednokrotne logowanie się (SSO). W takim przypadku tylko przypisana tożsamość wymaga dostępu do odczytu danych w źródle.

Uprawnienia elementu tkaniny

Usługa Direct Lake wymusza model zabezpieczeń warstwowych. Efektywna autoryzacja dla każdego zapytania zależy od uprawnień pozycji w Fabric (dostępu do obszaru roboczego i semantycznego modelu) oraz uprawnień na poziomie źródła, a także od sposobu konfigurowania modelu na potrzeby uwierzytelniania — logowanie jednokrotne (SSO) lub stała tożsamość SCC (Secure Client Communication).

Wskazówki operacyjne:

  • Tryb uwierzytelniania określa, czy zapytania są wykonywane przy użyciu tożsamości poszczególnych użytkowników (SSO) lub jednej tożsamości usługi (SCC).
    • Użyj logowania jednokrotnego w scenariuszach interaktywnych, w których wymagana jest autoryzacja poszczególnych użytkowników.
    • Użyj protokołu SCC o stałej tożsamości w scenariuszach dla użytkowników osadzonych lub tylko do odczytu, w których zakres dostępu na poziomie źródła jest określony dla pojedynczego konta usługi.
  • Zastosuj zasady najniższych uprawnień zarówno na poziomach źródła, jak i obszaru roboczego.
  • Przetestuj i zweryfikuj zachowanie obu trybów uwierzytelniania — szczególnie dla zabezpieczeń na poziomie wiersza opartych na SQL oraz we wszystkich przypadkach, które mogą wyzwalać tryb awaryjny DirectQuery — przed wdrożeniem produkcyjnym.

Aby uzyskać więcej informacji, zobacz Integrowanie zabezpieczeń usługi Direct Lake.

Uprawnienia modelu semantycznego

Oprócz uprawnień dotyczących elementów Fabric, należy również udzielić użytkownikom uprawnień, aby mogli używać modelu semantycznego Direct Lake i zarządzać nim. Krótko mówiąc, użytkownicy raportów potrzebują uprawnień do odczytu , a twórcy raportów potrzebują dodatkowych uprawnień do tworzenia . Uprawnienia modelu semantycznego można przypisać bezpośrednio lub uzyskać niejawnie przy użyciu ról obszaru roboczego. Aby zarządzać ustawieniami modelu semantycznego (w przypadku odświeżania i innych konfiguracji), musisz być właścicielem modelu semantycznego.

Wymagania dotyczące uprawnień

Aby zapoznać się ze scenariuszami i wymaganiami dotyczącymi uprawnień, zobacz Użytkownicy usługi Direct Lake.

Ważny

Przed udostępnieniem modelu semantycznego i raportów do środowiska produkcyjnego należy zawsze dokładnie przetestować uprawnienia.

Aby uzyskać więcej informacji, zobacz Semantic model permissions (Uprawnienia modelu semantycznego).

Wymagania dotyczące pojemności sieci szkieletowej

Modele semantyczne Direct Lake wymagają licencji pojemnościowej Fabric . Ponadto istnieją zabezpieczenia i ograniczenia dotyczące pojemności Fabric w ramach subskrypcji (SKU), jak przedstawiono w poniższej tabeli.

Ważny

Pierwsza kolumna w poniższej tabeli zawiera również subskrypcje pojemności usługi Power BI Premium (jednostki SKU P). Firma Microsoft konsoliduje opcje zakupu i wycofuje SKU Power BI Premium w modelu per capacity. Nowi i istniejący klienci powinni rozważyć zakup subskrypcji pojemności Fabric (F SKUs).

Aby uzyskać więcej informacji, zobacz Ważne aktualizacje dostępne w licencjonowaniu usługi Power BI Premium i usłudze Power BI Premium.

SKU tkaniny Pliki Parquet na tabelę Grupy wierszy w tabeli Wiersze na tabelę (miliony) Maksymalny rozmiar modelu na dysku/OneLake (GB) Maksymalna ilość pamięci (GB) 1
F2 1 000 1 000 300 10 3
F4 1 000 1 000 300 10 3
F8 1 000 1 000 300 10 3
F16 1 000 1 000 300 20 5
F32 1 000 1 000 300 40 10
F64/FT1/P1 5,000 5,000 1,500 Nieograniczony 25
F128/P2 5,000 5,000 3000 Nieograniczony 50
F256/P3 5,000 5,000 6000 Nieograniczony 100
F512/P4 10 000 10 000 12 000 Nieograniczony 200
F1024/P5 10 000 10 000 24,000 Nieograniczony 400
F2048 10 000 10 000 24,000 Nieograniczony 400

1 W przypadku modeli semantycznych usługi Direct Lake, Maksymalna pamięć reprezentuje górny limit zasobów pamięci dla ilości danych, które można załadować do pamięci. Z tego powodu nie jest to poręcz ochronna, ponieważ jej przekroczenie nie powoduje powrotu do trybu DirectQuery; jednak może to mieć wpływ na wydajność, jeśli ilość danych jest wystarczająco duża, aby spowodować nadmierne stronicowanie danych do i z modelu danych w OneLake.

W przypadku przekroczenia maksymalny rozmiar modelu na dysku/oneLake powoduje powrót do trybu DirectQuery wszystkich zapytań do modelu semantycznego. Wszystkie inne zabezpieczenia przedstawione w tabeli są oceniane dla każdego zapytania. Dlatego ważne jest , aby zoptymalizować tabele Delta i model semantyczny Direct Lake, aby uniknąć niepotrzebnego skalowania w górę do wyższego indeksu SKU Fabric.

Ponadto limity jednostek pojemności i maksymalnej pamięci na zapytanie mają zastosowanie do modeli semantycznych usługi Direct Lake. Aby uzyskać więcej informacji, zobacz Pojemności i jednostki SKU.

Zagadnienia i ograniczenia

Modele semantyczne usługi Direct Lake przedstawiają pewne zagadnienia i ograniczenia.

Notatka

Możliwości i funkcje modeli semantycznych usługi Direct Lake szybko ewoluują. Pamiętaj, aby okresowo przeglądać najnowszą listę zagadnień i ograniczeń.

Tryb przechowywania tabel Direct Lake w OneLake jest w publicznej wersji próbnej. Włącz ustawienie dzierżawy Użytkownik może tworzyć modele semantyczne Direct Lake w OneLake (wersja zapoznawcza) w portalu administracyjnym, aby tworzyć modele semantyczne z wykorzystaniem tabel Direct Lake w OneLake.

Uwaga/ograniczenie Usługa Direct Lake w usłudze OneLake Usługa Direct Lake w usłudze SQL (punkt końcowy analizy)
Gdy punkt końcowy analizy SQL wymusza zabezpieczenia na poziomie wiersza, zapytania języka DAX są przetwarzane inaczej w zależności od typu zastosowanego trybu Direct Lake.

Gdy usługa Direct Lake w usłudze OneLake jest stosowana, zapytania zostaną pomyślnie wykonane, a restrykcje na poziomie wiersza oparte na języku SQL nie zostaną zastosowane. Usługa Direct Lake w OneLake wymaga, aby użytkownik miał dostęp do plików w OneLake, co nie obsługuje zabezpieczeń na poziomie wiersza opartych na SQL.		 Zapytania powiodą się. Tak, chyba że mechanizm rezerwowy jest wyłączony, w którym przypadku zapytania kończą się niepowodzeniem.
Jeśli tabela w modelu semantycznym jest oparta na widoku SQL (niezmaterializowanym), zapytania języka DAX są przetwarzane inaczej w zależności od typu zastosowanego trybu Direct Lake.

Usługa Direct Lake w punktach końcowych SQL powróci do trybu DirectQuery w tym przypadku.

Nie jest obsługiwane tworzenie funkcji Direct Lake w tabeli OneLake na podstawie niematerializowanego widoku SQL. Zamiast tego można użyć zmaterializowanego widoku Lakehouse, ponieważ tabele Delta już istnieją. Alternatywnie użyj innego trybu przechowywania, takiego jak Import lub DirectLake, dla tabel opartych na niezmaterializowanych widokach SQL.		 Nie dotyczy Tak, chyba że mechanizm rezerwowy jest wyłączony, w którym przypadku zapytania kończą się niepowodzeniem.
Modelowanie złożone, co oznacza, że tabele modelu semantycznego usługi Direct Lake mogą być mieszane z tabelami w innych trybach przechowywania, takich jak Import, DirectQuery lub Dual (z wyjątkiem przypadków specjalnych, w tym grup obliczeniowych, parametrów warunkowych i parametrów pól). Wsparte Niewspierane
Kolumny obliczeniowe i tabele obliczeniowe odwołujące się do kolumn lub tabel w trybie przechowywania usługi Direct Lake. Grupy obliczeń, parametry warunkowe i parametry pola, które niejawnie tworzą tabele obliczeniowe i tabele obliczeniowe, które nie odwołują się do kolumn lub tabel usługi Direct Lake, są obsługiwane we wszystkich scenariuszach. Niewspierane Niewspierane
Tabele trybu przechowywania usługi Direct Lake nie obsługują złożonych typów kolumn tabeli delty. Typy semantyczne binarne i GUID są także nieobsługiwane. Te typy danych należy przekonwertować na ciągi lub inne obsługiwane typy danych. Niewspierane Niewspierane
Relacje tabel wymagają dopasowania typów danych powiązanych kolumn. Tak Tak
Jednostronne kolumny relacji muszą zawierać unikatowe wartości. Zapytania kończą się niepowodzeniem, jeśli w kolumnie jednostronnej wykryto zduplikowane wartości. Tak Tak
Automatyczna analiza daty/godziny w programie Power BI Desktop w celu tworzenia relacji przy użyciu tylko części daty w kolumnie data/godzina. Uwaga: oznaczanie własnej tabeli dat jako tabeli dat i tworzenie relacji przy użyciu kolumn dat jest obsługiwane. Wsparte Niewspierane
Długość wartości kolumn ciągu jest ograniczona do 32 764 znaków Unicode. Tak Tak
Nieliczbowe wartości zmiennoprzecinkowe, takie jak NaN (nie liczba), nie są obsługiwane. Tak Tak
Publikowanie w Internecie z Power BI przy użyciu jednostki usługi jest obsługiwane tylko w przypadku używania stałej tożsamości dla semantycznego modelu Direct Lake. Tak Tak
W środowisku modelowania internetowego walidacja jest ograniczona w przypadku modeli semantycznych usługi Direct Lake. Przyjmuje się, że wybór użytkownika jest poprawny, a żadne zapytania nie są wystawiane w celu weryfikowania kardynalności lub wyboru filtru krzyżowego dla relacji lub wybranej kolumny dat w oznaczonej tabeli dat. Tak Tak
W portalu Fabric karta Direct Lake w historii odświeżania pokazuje błędy odświeżania dotyczące Direct Lake. Operacje pomyślnego odświeżania nie są zazwyczaj wyświetlane, chyba że stan odświeżania ulegnie zmianie, na przykład z braku wcześniejszego uruchomienia lub niepowodzenia odświeżania na pomyślne odświeżenie lub pomyślne odświeżenie z ostrzeżeniem. Tak Tak
SKU usługi Fabric określa maksymalną dostępną pamięć dla modelu semantycznego Direct Lake w ramach pojemności. Po przekroczeniu limitu zapytania do modelu semantycznego mogą być wolniejsze z powodu nadmiernego przeładowywania danych modelu. Tak Tak
Tworzenie modelu semantycznego usługi Direct Lake w obszarze roboczym, który znajduje się w innym regionie obszaru roboczego źródła danych, nie jest obsługiwane. Na przykład, jeśli Lakehouse znajduje się w regionie Zachodnio-Centralnym USA, można tworzyć modele semantyczne z tego samego Lakehouse tylko w tym regionie. Aby obejść ten problem, można utworzyć Lakehouse w obszarze roboczym innego regionu, tworząc skróty do tabel przed utworzeniem modelu semantycznego. Aby znaleźć region, w którym się znajdujesz, zobacz znajdź swój region macierzysty Fabric. Tak Tak
Osadzanie raportów wymaga tokenu w wersji 2 do osadzania. Tak Tak
Profile jednostki usługi na potrzeby uwierzytelniania. Niewspierane Niewspierane
Modele semantyczne Power BI Direct Lake mogą być tworzone i odpytywane przez główne jednostki usługi, a wsparcie dla członkostwa w roli Osoba przeglądająca z głównymi jednostkami usługi jest obsługiwane, ale domyślne modele semantyczne Power BI Direct Lake w ramach Lakehouse/warehouse nie obsługują tego scenariusza. Tak Tak
Skróty w usłudze Lakehouse mogą służyć jako źródła danych dla tabel modelu semantycznego. Nieobsługiwane podczas publicznej wersji zapoznawczej Wsparte
Tworzenie modeli Direct Lake w osobistych obszarach roboczych (Mój obszar roboczy). Niewspierane Niewspierane
Reguły potoku wdrażania w celu ponownego powiązania źródła danych. Nieobsługiwane bezpośrednio — może utworzyć wyrażenie parametru do użycia w parametrach połączenia. Wsparte
Dodawanie wielu tabel z tej samej tabeli źródła danych. Nieobsługiwane w programie Power BI Desktop lub modelowaniu webowym. Istnieje możliwość dodania wielu tabel z tej samej tabeli źródła danych przy użyciu narzędzi zewnętrznych opartych na języku XMLA. Użycie funkcji Edytowanie tabel w narzędziu usługi Power BI i odświeżanie powoduje błąd z wieloma tabelami z tej samej tabeli źródła danych w modelu semantycznym. Nieobsługiwane w programie Power BI Desktop lub modelowaniu webowym. Istnieje możliwość dodania wielu tabel z tej samej tabeli źródła danych przy użyciu narzędzi zewnętrznych opartych na języku XMLA. Użycie funkcji Edytowanie tabel w narzędziu usługi Power BI i odświeżanie powoduje błąd z wieloma tabelami z tej samej tabeli źródła danych w modelu semantycznym.

  • Funkcja Analizuj w tabelach przestawnych programu Excel (i innych klientach MDX) ma takie same ograniczenia jak DirectQuery z tabelami Direct Lake w modelu semantycznym. Instrukcje MDX o zakresie sesji, takie jak nazwane zestawy, elementy członkowskie zdefiniowane przez użytkownika, elementy członkowskie domyślne itp., nie są obsługiwane. Obsługiwane są instrukcje MDX o zakresie zapytań, takie jak klauzula "WITH". Hierarchie zdefiniowane przez użytkownika tabeli Direct Lake nie są obsługiwane. Importowanie hierarchii zdefiniowanych przez użytkownika tabeli jest obsługiwane nawet w przypadku tabel Direct Lake w modelu semantycznym.

  • Program Power BI Desktop umożliwia edycję na żywo modelu semantycznego przy użyciu tabel Direct Lake oraz importowanie tabel. Grupy obliczeń, parametry warunkowe i parametry pola, które niejawnie tworzą tabele obliczeniowe i tabele obliczeniowe, które nie odwołują się do kolumn lub tabel usługi Direct Lake, mogą być również uwzględniane.

  • Modelowanie internetowe usługi Power BI może otwierać dowolny model semantyczny, w tym tabele usługi Direct Lake z innymi tabelami trybu przechowywania.

  • Widok zapytań języka DAX podczas edytowania na żywo lub nawiązywania połączenia na żywo oraz zapisywania zapytań języka DAX w Internecie są obsługiwane w przypadku usług Direct Lake w usługach SQL, Direct Lake w usłudze OneLake i prawdziwego złożonego (Direct Lake w usłudze OneLake i importowania z dowolnego źródła danych) modeli semantycznych.

  • Widok TMDL jest obsługiwany podczas edycji na żywo w programie Power BI Desktop.

  • Tworzenie raportów z połączeniem na żywo jest obsługiwane dla wszystkich modeli semantycznych, gdy autor raportu ma co najmniej dostęp do kompilacji.

  • Funkcja Direct Lake w wyrażeniu połączenia SQL w modelu semantycznym musi odwoływać się do punktu końcowego analizy SQL według identyfikatora GUID, a nie według przyjaznej nazwy, aby móc używać operacji Edytuj tabele i odśwież w programie Power BI Desktop oraz w modelowaniu internetowym w usłudze Power BI. Wyrażenie połączenia można zaktualizować w widoku TMDL lub narzędziach zewnętrznych opartych na języku XMLA. Identyfikator GUID jest dostępny w adresie URL podczas wyświetlania punktu końcowego analizy SQL w przeglądarce.

Powiązana zawartość

  • Last updated on