Omówienie usługi Direct Lake

Direct Lake to opcja trybu przechowywania tabel w semantycznym modelu usługi Power BI przechowywanym w obszarze roboczym usługi Microsoft Fabric. Jest zoptymalizowany pod kątem dużych ilości danych, które można szybko załadować do pamięci z tabel Delta, które przechowują swoje dane w plikach Parquet w OneLake— jednolity magazyn dla wszystkich danych analitycznych. Po załadowaniu do pamięci model semantyczny umożliwia wykonywanie zapytań o wysokiej wydajności. Usługa Direct Lake eliminuje powolne i kosztowne importowanie danych do modelu.

Tryb przechowywania Direct Lake umożliwia łączenie się z tabelami lub widokami pojedynczego lakehouse Fabric lub magazynu Fabric warehouse . Oba te elementy Fabric oraz modele semantyczne Direct Lake wymagają licencji pojemnościowej Fabric .

Pod pewnymi względami semantyczny model Direct Lake jest podobny do modelu semantycznego Import. Wynika to z faktu, że dane modelu są ładowane do pamięci przez aparat VertiPaq w celu zapewnienia szybkiej wydajności zapytań (z wyjątkiem przypadków rezerwowego DirectQuery, co zostało wyjaśnione w dalszej części tego artykułu).

Jednak model semantyczny usługi Direct Lake różni się od modelu semantycznego importu w ważny sposób. Dzieje się tak, ponieważ operacja odświeżania modelu semantycznego usługi Direct Lake różni się koncepcyjnie od operacji odświeżania modelu semantycznego Importuj. Dla modelu semantycznego Direct Lake odświeżenie obejmuje operację ramowania (opisaną w dalszej części tego artykułu), co może potrwać kilka sekund. Jest to operacja o niskich kosztach, w której model semantyczny analizuje metadane najnowszej wersji tabel delty i jest aktualizowany w celu odwołania się do najnowszych plików w usłudze OneLake. Natomiast w przypadku modelu semantycznego Importuj odświeżanie generuje kopię danych, co może zająć dużo czasu i zużywać znaczne źródło danych i zasoby pojemności (pamięć i procesor CPU).

Notatka

Odświeżanie przyrostowe dla importowanego modelu semantycznego może pomóc skrócić czas odświeżania i wykorzystanie zasobów pojemnościowych.

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

Podstawowym zastosowaniem trybu przechowywania Direct Lake jest realizacja projektów analitycznych prowadzonych przez działy IT, wykorzystujących architektury skoncentrowane na jeziorach danych. W tym scenariuszu masz (lub spodziewasz się gromadzenia) dużych 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

Modele semantyczne importu i DirectQuery są nadal istotne w Fabric i stanowią właściwy wybór w niektórych 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.

Ponadto integracja OneLake automatycznie zapisuje dane dla tabel w trybie magazynowania importowanego do tabel różnicowych w usłudze OneLake bez konieczności podejmowania żadnych działań migracyjnych. Korzystając z tej opcji, można zrealizować wiele zalet usługi Fabric, które są udostępniane użytkownikom modelu semantycznego importu, takich jak integracja z usługami lakehouse za pomocą skrótów, zapytań SQL, notesów i nie tylko. Zalecamy, aby rozważyć tę opcję jako szybki sposób na czerpanie korzyści z usługi Fabric bez konieczności lub natychmiastowego ponownego projektowania istniejącego magazynu danych i/lub systemu analitycznego.

Tryb przechowywania w usłudze Direct Lake jest również odpowiedni do minimalizowania opóźnienia danych w celu szybkiego udostępniania danych użytkownikom biznesowym. Jeśli tabele Delty są modyfikowane sporadycznie (i przy założeniu, że dane zostały już przygotowane w jeziorze danych), możesz polegać na automatycznych aktualizacjach, aby się dostosować w odpowiedzi na te modyfikacje. W takim przypadku zapytania wysyłane do modelu semantycznego zwracają najnowsze dane. Ta funkcja dobrze współpracuje z automatycznym odświeżaniem stron funkcji raportów usługi Power BI.

Należy pamiętać, że Direct Lake opiera się na przygotowaniu danych w Data Lake. Przygotowywanie danych można wykonać przy użyciu różnych narzędzi, takich jak zadania platformy Spark dla magazynów typu lakehouse usługi Fabric, instrukcje DML języka T-SQL dla magazynów sieci szkieletowej, przepływów danych, potoków i innych. Takie podejście pomaga zapewnić, że logika przygotowywania danych jest realizowana na możliwie najniższym poziomie w architekturze, aby zmaksymalizować możliwość ponownego użycia. Jeśli jednak autor modelu semantycznego nie ma możliwości modyfikowania elementu źródłowego, na przykład jeśli analityk samoobsługi nie ma uprawnień do zapisu w usłudze Lakehouse zarządzanej przez IT, tryb przechowywania importu może być lepszym wyborem. Dzieje się tak, ponieważ obsługuje przygotowywanie danych przy użyciu dodatku Power Query, który jest definiowany jako część modelu semantycznego.

Pamiętaj, aby uwzględnić bieżącą licencję pojemności systemu Fabric oraz ograniczenia pojemności systemu Fabric podczas rozważania trybu przechowywania w usłudze 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.

Jak działa usługa Direct Lake

Zazwyczaj zapytania wysyłane do modelu semantycznego usługi Direct Lake są obsługiwane z pamięci podręcznej kolumn źródłowych z tabel delty. Podstawowym magazynem dla tabeli Delta jest co najmniej jeden plik Parquet w OneLake. Pliki Parquet organizują dane według kolumn, a nie wierszy. Modele semantyczne ładują całe kolumny z tabel delty do pamięci, ponieważ są one wymagane przez zapytania.

Model semantyczny usługi Direct Lake może również używać rezerwowego trybu DirectQuery, który obejmuje bezproblemowe przełączanie do trybu DirectQuery. Rezerwowy tryb DirectQuery pobiera dane bezpośrednio z punktu końcowego analizy SQL lakehouse lub magazynu. Na przykład rezerwowa może wystąpić, gdy tabela delty zawiera więcej wierszy danych niż obsługiwane przez pojemność sieci szkieletowej (opisane w dalszej części tego artykułu). W takim przypadku operacja DirectQuery wysyła zapytanie do punktu końcowego analizy SQL. Operacje zapasowe mogą spowodować wolniejsze działanie zapytań.

Na poniższym diagramie przedstawiono sposób działania usługi Direct Lake przy użyciu scenariusza użytkownika, który otwiera raport usługi Power BI.

Diagram przedstawia następujące akcje użytkownika, procesy i funkcje.

Przedmiot	Opis
	OneLake to jezioro danych, które przechowuje dane analityczne w formacie Parquet. Ten format pliku jest optymalizowany do przechowywania danych dla semantycznych modeli Direct Lake.
	Lakehouse usługi Fabric lub magazyn usługi Fabric istnieje w obszarze roboczym, który znajduje się na pojemności Fabric. Usługa Lakehouse ma punkt końcowy analizy SQL, który zapewnia środowisko oparte na języku SQL na potrzeby wykonywania zapytań. Tabele (lub widoki) umożliwiają wykonywanie zapytań dotyczących tabel delta w usłudze OneLake przy użyciu Transact-SQL (T-SQL).
	Model semantyczny Direct Lake istnieje w obszarze roboczym Fabric. Łączy się z tabelami lub widokami w magazynie lub lakehouse.
	Użytkownik otwiera raport usługi Power BI.
	Raport usługi Power BI wysyła zapytania języka DAX (Data Analysis Expressions) do modelu semantycznego usługi Direct Lake.
	Jeśli to możliwe (i konieczne), semantyczny model ładuje kolumny do pamięci bezpośrednio z plików Parquet przechowywanych w usłudze OneLake. Zapytania osiągają wydajność w pamięci, dzięki czemu są bardzo szybkie.
	Model semantyczny zwraca wyniki zapytania.
	Raport usługi Power BI renderuje wizualizacje.
	W pewnych okolicznościach, na przykład gdy model semantyczny przekracza ograniczenia pojemności, zapytania modelu semantycznego automatycznie przechodzą na tryb DirectQuery. W tym trybie zapytania są wysyłane do punktu końcowego analizy SQL w magazynie typu lakehouse lub warehouse.
	Zapytania DirectQuery wysyłane do punktu końcowego analizy SQL z kolei wysyłają zapytania do tabel delta w usłudze OneLake. Z tego powodu wydajność zapytań może być niższa niż w przypadku zapytań w pamięci.

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 ładowane do pamięci stają się następnie rezydentne 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 czy tabela została odświeżona po aktualizacji tabeli Delta w źródle (zobacz Framing 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 w związku z pojemnością z powodu równoległych operacji.

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

Kadrowanie

Framing zapewnia właścicielom modelu chwilową kontrolę nad danymi ładowanymi 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 struktur, segmenty kolumn tabeli rezydentnej i słowniki mogą zostać usunięte z pamięci, jeśli bazowe dane uległy zmianie, a moment odświeżenia staje się nowym punktem odniesienia 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 Delta w momencie najnowszej operacji ramkowania. Ten moment nie musi być najnowszym stanem tabel Delty.

Należy pamiętać, że model semantyczny analizuje dziennik Delta każdej tabeli Delta podczas ramowania, aby usunąć tylko dotknięte segmenty kolumn i ponownie załadować nowo dodane dane podczas 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 ramek, ponieważ tworzenie przyrostowe zasadniczo umożliwia modelowi semantycznemu aktualizowanie znacznych części istniejących danych w pamięci.

Na poniższym diagramie pokazano, 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 tworzenia ramek są wykonywane okresowo i ustawiają punkt odniesienia dla wszystkich przyszłych transkodowania zdarzeń. 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 tworzenia ramek obejmuje pliki Parquet powiązane z tabelami delty, a w szczególności pliki Parquet, które zostały dodane przed operacją ostatniej framingu.
	Późniejsza operacja tworzenia ramek obejmuje pliki Parquet dodane po ostatniej operacji tworzenia ramek .
	Kolumny rezydencyjne w modelu semantycznym Direct Lake mogą zostać usunięte z pamięci, a moment odświeżenia 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 Direct Lake.

Aby uzyskać więcej informacji na temat wersjonowania i ramowania tabeli delty, zobacz Omówienie magazynowania dla 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

Możesz skonfigurować automatyczne odświeżanie strony 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

Zapytanie wysyłane do modelu semantycznego usługi Direct Lake może wrócić do trybu DirectQuery . W takim przypadku pobiera dane bezpośrednio z punktu końcowego analizy SQL magazynu typu lakehouse lub warehouse. Takie zapytania zawsze zwracają najnowsze dane, ponieważ nie są ograniczone do momentu w czasie ostatniej operacji ramowania.

Zapytanie zawsze spada, gdy semantyczny model wykonuje zapytanie dotyczące widoku w punkcie końcowym analizy SQL lub tabeli w punkcie końcowym analizy SQL, który wymusza zabezpieczenia na poziomie wiersza.

Ponadto, zapytanie może się cofnąć, gdy model semantyczny przekracza granice 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ć mechanizm zapasowy dla swoich semantycznych modeli Direct Lake poprzez ustawienie właściwości DirectLakeBehavior. Aby uzyskać więcej informacji, zobacz Ustaw właściwość zachowania Direct Lake.

Zabezpieczenia pojemności sieci szkieletowej i ograniczenia

Modele semantyczne Direct Lake wymagają licencji pojemnościowej Fabric . Ponadto istnieją ograniczenia i zabezpieczenia dotyczące pojemności Fabric dla 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). Należy pamiętać, że firma Microsoft konsoliduje opcje zakupu i wycofuje usługi Power BI Premium według pojemności SKU. Nowi i istniejący klienci powinni rozważyć zakup subskrypcji pojemności Fabric (F SKU).

Aby uzyskać więcej informacji, zobacz Ważna aktualizacja wchodząca w licencjonowanie usługi Power BI Premium i Power BI Premium.

Jednostka SKU tkaniny	Pliki Parquet na tabelę	Grupy wierszy na każdą tabelę	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	3,000	Nieograniczony	50
F256/P3	5,000	5,000	6,000	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

¹ dla modeli semantycznych usługi Direct Lake maksymalna ilość pamięci reprezentuje górny limit zasobów pamięci dla ilości danych, w których można stronicować. Z tego powodu nie jest to bariera chroniąca, 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 i wyjście z danych modelu z danych OneLake.

Jeśli zostanie przekroczony maksymalny rozmiar modelu na dysku/OneLake, wszystkie zapytania do modelu semantycznego przejdą na tryb DirectQuery. Wszystkie inne zabezpieczenia przedstawione w tabeli są oceniane na zapytanie. Dlatego ważne jest, aby zoptymalizować tabele delty i modelu semantycznego usługi Direct Lake, aby uniknąć konieczności niepotrzebnego skalowania w górę do wyższej jednostki SKU sieci szkieletowej (co powoduje zwiększenie kosztów).

Ponadto jednostka pojemności i maksymalny limit 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 zmieniają się. Pamiętaj, aby okresowo przeglądać najnowszą listę zagadnień i ograniczeń.

• Gdy tabela modelu semantycznego Direct Lake łączy się z tabelą w punkcie końcowym usługi analizy SQL, która wymusza zabezpieczenia na poziomie wiersza (RLS), zapytania dotyczące tej tabeli modelu zawsze będą wykonywane w trybie DirectQuery. Wydajność zapytań może być niższa.
• Gdy tabela modelu semantycznego usługi Direct Lake łączy się z widokiem w punkcie końcowym analizy SQL, zapytania obejmujące tabelę modelu zawsze wracają do trybu DirectQuery. Wydajność zapytań może być niższa.
• Modelowanie złożone nie jest obsługiwane. Oznacza to, że tabele modelu semantycznego Direct Lake nie mogą być mieszane z tabelami w innych trybach przechowywania, takich jak Import, DirectQuery lub Dual (z wyjątkiem przypadków specjalnych, do których należą grupy obliczeniowe , parametry analizy warunkowej , oraz parametry pól ).
• Kolumny obliczeniowe i tabele obliczeniowe odwołujące się do kolumn lub tabel w trybie przechowywania Direct Lake nie są obsługiwane. grupy obliczeń, parametry 'co-jeśli'i parametry pól, które niejawnie tworzą tabele obliczeniowe, oraz tabele obliczeniowe, które nie odwołują się do kolumn lub tabel usługi Direct Lake, są obsługiwane.
• 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.
• Relacje tabel wymagają dopasowania typów danych powiązanych kolumn.
• Jednostronne kolumny relacji muszą zawierać unikatowe wartości. Zapytania kończą się niepowodzeniem, jeśli w kolumnie jednostronnej wykryto zduplikowane wartości.
• funkcja automatycznego analizy danych/czasu w programie Power BI Desktop nie jest obsługiwana. Oznaczenie własnej tabeli dat jako tabeli dat jest wspierane.
• Długość wartości kolumn ciągu jest ograniczona do 32 764 znaków Unicode.
• Wartość zmiennoprzecinkowa NaN (a nie liczba) nie jest obsługiwana.
• Publikowanie w Internecie z usługi Power BI przy użyciu jednostki usługi jest obsługiwane tylko w przypadku używania stałej tożsamości dla modelu semantycznego usługi Direct Lake.
• W środowisku modelowania internetowegoweryfikacja jest ograniczona dla semantycznych modeli 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.
• W portalu Fabric karta Direct Lake w historii odświeżania zawiera tylko błędy odświeżania związane z Direct Lake. Operacje pomyślnego odświeżania (tworzenia ramek) nie są wyświetlane.
• SKU usługi Fabric określa maksymalną dostępną pamięć na model semantyczny Direct Lake dla danej pojemności. Po przekroczeniu limitu zapytania do modelu semantycznego mogą być wolniejsze z powodu nadmiernego przeładowywania danych modelu.
• 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. Można obejść ten problem, tworząc Lakehouse w obszarze roboczym innego regionu i utworzenie skrótów do tabel przed utworzeniem modelu semantycznego. Aby znaleźć region, w którym się znajdujesz, zobacz , aby znaleźć domowy region usługi Fabric.
• Można utworzyć i wyświetlić niestandardowy model semantyczny usługi Direct Lake przy użyciu tożsamości jednostki usługi, ale domyślny model semantyczny usługi Direct Lake nie obsługuje jednostek usługi. Upewnij się, że w twojej dzierżawie włączono uwierzytelnianie jednostki usługi dla Fabric REST API i przyznaj jednostce usługi uprawnienia Kontrybutora lub wyższe do obszaru roboczego semantycznego modelu Direct Lake.
• Osadzanie raportów wymaga tokenu osadzania w wersji 2.
• Usługa Direct Lake nie obsługuje profilów aplikacyjnych na potrzeby uwierzytelniania.
• Niestandardowe modele semantyczne usługi Direct Lake utworzone przez jednostkę usługi i przeglądarkę z jednostką usługi są obsługiwane, ale domyślne modele semantyczne usługi Direct Lake nie są obsługiwane.
• Profil jednostki usługi nie jest obsługiwany.

Porównanie z innymi trybami przechowywania

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

Zdolność	Direct Lake	Import	DirectQuery
Licencjonowania	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	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	Tak — ale automatycznie powróci do trybu DirectQuery	Tak	Tak
Modele złożone	Brak 1	Tak — może łączyć się z tabelami trybu przechowywania DirectQuery lub trybu podwójnego	Tak — może łączyć się z tabelami w trybie importu lub trybu podwójnego przechowywania.
Logowanie jednokrotne (SSO)	Tak	Nie dotyczy	Tak
Tabele obliczeniowe	Nie — z wyjątkiem grup obliczeń , parametrów warunkowychi 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	Tak	Tak
Tabele hybrydowe	Nie	Tak	Tak
Partycje tabeli modelowej	Nie — jednak partycjonowanie można wykonać na poziomie tabeli delty	Tak — automatycznie utworzone przez odświeżanie przyrostowe lub ręcznie utworzone przy użyciu punktu końcowego XMLA	Nie
Agregacje zdefiniowane przez użytkownika	Nie	Tak	Tak
Zabezpieczenia na poziomie obiektu lub zabezpieczenia na poziomie kolumny punktu końcowego analizy SQL	Tak — ale zapytania powrócą do trybu DirectQuery i mogą powodować błędy w przypadku odmowy uprawnień	Tak — ale musi duplikować uprawnienia z zabezpieczeniami na poziomie obiektowym modelu semantycznego	Tak — ale zapytania mogą powodować błędy w przypadku odmowy uprawnień
Zabezpieczenia na poziomie wiersza (RLS) punktu końcowego analizy SQL	Tak — ale zapytania wracają do trybu DirectQuery	Tak — ale musi duplikować uprawnienia z modelem semantycznym RLS (zabezpieczenia na poziomie wiersza)	Tak
Zabezpieczenia modelu semantycznego na poziomie wiersza (RLS)	Tak — ale zdecydowanie zaleca się użycie stałego połączenia tożsamościowego w chmurze	Tak	Tak
Zabezpieczenia na poziomie obiektu modelu semantycznego (OLS)	Tak	Tak	Tak
Duże woluminy danych bez wymagania dotyczącego odświeżania	Tak	Mniej odpowiednie — do wykonywania zapytań i odświeżania może być wymagana większa pojemność	Tak
Zmniejszanie opóźnienia danych	Tak — w przypadku włączenia automatycznych aktualizacji lub programowego reframowania; należy jednak najpierw wykonać przygotowania danych	Nie	Tak
Power BI Embedded	Tak 2	Tak	Tak

¹ Nie można połączyć tabel w trybie przechowywania Direct Lake z tabelami korzystającymi z trybu DirectQuery ani trybu Dual 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 w modelu semantycznym.

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

Powiązana zawartość

• opracowywanie modeli semantycznych usługi Direct Lake
• zarządzanie semantycznymi modelami usługi Direct Lake
• Zrozum magazynowanie dla modeli semantycznych Direct Lake
• Utwórz lakehouse dla usługi Direct Lake
• Analizowanie przetwarzania zapytań dla modeli semantycznych usługi Direct Lake