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 ona zoptymalizowana pod kątem dużych ilości danych, które można szybko załadować do pamięci z tabel delty, które przechowują dane w plikach Parquet w usłudze OneLake — pojedynczy 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 usługi Direct Lake umożliwia łączenie się z tabelami lub widokami pojedynczego magazynu typu lakehouse lub fabric. Oba te elementy sieci szkieletowej i modele semantyczne usługi Direct Lake wymagają licencji pojemności sieci szkieletowej.
Pod pewnymi względami model semantyczny usługi Direct Lake jest podobny do modelu semantycznego Importuj. 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 przypadku rezerwowego trybu 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. W przypadku modelu semantycznego usługi Direct Lake odświeżanie obejmuje operację tworzenia ramek (opisaną w dalszej części tego artykułu), która 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).
Uwaga
Odświeżanie przyrostowe dla modelu semantycznego importu może pomóc skrócić czas odświeżania i wykorzystanie zasobów pojemności.
Kiedy należy używać trybu przechowywania w usłudze Direct Lake?
Podstawowy przypadek użycia trybu przechowywania usługi Direct Lake jest zwykle przeznaczony dla projektów analitycznych opartych na itach, które wykorzystują architektury skoncentrowane na usłudze Lake. 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.
Uwaga
Modele semantyczne importu i trybu DirectQuery są nadal istotne w sieci szkieletowej i są właściwym wyborem modelu semantycznego w niektórych scenariuszach. Na przykład tryb przechowywania importu często dobrze sprawdza się dla analityka samoobsługi, który potrzebuje swobody i elastyczności, aby działać szybko i bez zależności od IT w celu dodania nowych elementów danych.
Ponadto integracja z usługą OneLake automatycznie zapisuje dane dla tabel w trybie importowania magazynu do tabel różnicowych w usłudze OneLake bez konieczności angażowania wysiłku związanego z migracją. 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 już wykonano przygotowywanie danych w usłudze Data Lake), możesz zależeć od automatycznych aktualizacji , aby zmienić ramkę w odpowiedzi na te modyfikacje. W takim przypadku zapytania wysyłane do modelu semantycznego będą zwracać najnowsze dane. Ta funkcja działa dobrze we współpracy z funkcją automatycznego odświeżania stron raportów usługi Power BI.
Należy pamiętać, że usługa Direct Lake zależy od przygotowania danych w usłudze 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 jak najniższa w architekturze w celu zmaksymalizowania możliwości ponownego wykorzystania. Jeśli jednak autor modelu semantycznego nie ma możliwości modyfikowania elementu źródłowego, na przykład w przypadku analityka samoobsługi, który może nie mieć uprawnień do zapisu w usłudze Lakehouse zarządzanej przez it, tryb importowania magazynu 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 sieci szkieletowej i zabezpieczenia pojemności sieci szkieletowej, jeśli rozważysz tryb przechowywania usługi Direct Lake. Ponadto należy uwzględnić zagadnienia i ograniczenia 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 delty jest co najmniej jeden plik Parquet w usłudze 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 magazynu typu 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 rezerwowe mogą spowodować spowolnienie wydajności 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.
| Produkt | opis |
|---|---|
 |
OneLake to usługa Data Lake, która przechowuje dane analityczne w formacie Parquet. Ten format pliku jest zoptymalizowany pod kątem przechowywania danych dla modeli semantycznych usługi Direct Lake. |
 |
Magazyn lakehouse usługi Fabric lub Sieć szkieletowa istnieje w obszarze roboczym, który znajduje się w pojemności sieci Szkieletowej. 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ń względem tabel delta w usłudze OneLake przy użyciu języka Transact-SQL (T-SQL). |
 |
Model semantyczny usługi Direct Lake istnieje w obszarze roboczym sieć szkieletowa. Łą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, co jest 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 bariery ochronne pojemności, zapytania semantyczne modelu automatycznie wracają do trybu 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 usługi Direct Lake, w tym ładowanie kolumn, tworzenie ram, automatyczne aktualizacje i rezerwowanie zapytania bezpośredniego.
Ładowanie kolumn (transkodowanie)
Modele semantyczne usługi Direct Lake ładują dane tylko z usługi OneLake jako i po pierwszym wysłaniu zapytań do kolumn. 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. Potrzebne kolumny obejmują wszystkie kolumny, które są bezpośrednio używane 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.
Po zrozumieniu, 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 zazwyczaj bardzo 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 rezydentami 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ła odświeżona (zobacz Framing w następnej sekcji).
- Żadne zapytanie nie używało kolumny przez jakiś czas.
- Inne przyczyny zarządzania pamięcią, w tym wykorzystanie pamięci w pojemności z powodu innych, współbieżnych operacji.
Wybór jednostki SKU sieci szkieletowej określa maksymalną ilość dostępnej pamięci dla każdego modelu semantycznego usługi Direct Lake w pojemności. Aby uzyskać więcej informacji o zabezpieczeniach zasobów i maksymalnych limitach pamięci, zobacz Zabezpieczenia i ograniczenia 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. Tworzenie ramek to operacja usługi Direct Lake, która jest wyzwalana przez odświeżenie modelu semantycznego, a w większości przypadków ukończenie operacji 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.
W przypadku tworzenia ramek kolumny rezydentne mogą być eksmitowane z pamięci, a punkt w czasie odświeżania staje się nowym punktem odniesienia dla wszystkich przyszłych zdarzeń transkodowania. Od tego momentu zapytania usługi Direct Lake uwzględniają tylko dane w tabelach delty od czasu ostatniej operacji tworzenia ramek. Z tego powodu tabele usługi Direct Lake są odpytywane w celu zwrócenia danych na podstawie stanu tabeli delty w punkcie najnowszej operacji tworzenia ramek. Ten czas nie musi być najnowszym stanem tabel delty.
Na poniższym diagramie pokazano, jak działają operacje tworzenia ram w usłudze Direct Lake.
Diagram przedstawia następujące procesy i funkcje.
| Produkt | opis |
|---|---|
|
Model semantyczny istnieje w obszarze roboczym Sieć szkieletowa. |
|
Operacje tworzenia ramek są okresowo wykonywane i ustawiają punkt odniesienia dla wszystkich przyszłych zdarzeń transkodowania . Operacje tworzenia ramek mogą odbywać się automatycznie, ręcznie, zgodnie z harmonogramem lub programowo. |
|
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 ostatnią operacją tworzenia ramek. |
|
Późniejsza operacja tworzenia ramek obejmuje pliki Parquet dodane po ostatniej operacji tworzenia ramek. |
|
Kolumny rezydentne w modelu semantycznym usługi Direct Lake mogą zostać wykluczone z pamięci, a punkt w czasie odświeżania staje się nowym punktem odniesienia dla wszystkich przyszłych zdarzeń transkodowania. |
|
Kolejne modyfikacje danych reprezentowane przez nowe pliki Parquet nie są widoczne, dopóki nie nastąpi kolejna operacja tworzenia ramek. |
Nie zawsze pożądane jest, aby dane reprezentujące najnowszy stan dowolnej tabeli delty, gdy odbywa się operacja 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.
Aby uzyskać więcej informacji na temat przechowywania wersji i tworzenia ram tabeli delty, zobacz Understand storage for Direct Lake semantic models (Omówienie magazynu dla modeli semantycznych usługi Direct Lake).
Automatyczne aktualizacje
Istnieje semantyczne ustawienie na poziomie modelu umożliwiające automatyczne aktualizowanie tabel usługi Direct Lake. Jest domyślnie włączony. Dzięki temu zmiany danych w usłudze OneLake zostaną automatycznie odzwierciedlone w modelu semantycznym usługi Direct Lake. Należy wyłączyć aktualizacje automatyczne, gdy chcesz kontrolować zmiany danych przez tworzenie ramek, 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).
Powrót zapytania bezpośredniego
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 punktu w czasie ostatniej operacji tworzenia ramek.
Zapytanie zawsze spada, gdy semantyczny model wykonuje zapytanie o widok w punkcie końcowym analizy SQL lub tabelę w punkcie końcowym analizy SQL, który wymusza zabezpieczenia na poziomie wiersza.
Ponadto zapytanie może wrócić, gdy model semantyczny przekracza bariery ochronne pojemności.
Ważne
Jeśli to możliwe, zawsze należy zaprojektować rozwiązanie (lub rozmiar pojemności), aby uniknąć powrotu zapytania bezpośredniego. Wynika to z faktu, że może to spowodować spowolnienie wydajności zapytań.
Rezerwowe modele semantyczne usługi Direct Lake można kontrolować, ustawiając jej właściwość DirectLakeBehavior . Aby uzyskać więcej informacji, zobacz Ustawianie właściwości zachowania usługi Direct Lake.
Zabezpieczenia pojemności sieci szkieletowej i ograniczenia
Modele semantyczne usługi Direct Lake wymagają licencji pojemności sieci szkieletowej. Ponadto istnieją zabezpieczenia pojemności i ograniczenia, które mają zastosowanie do subskrypcji pojemności sieci szkieletowej (SKU), jak przedstawiono w poniższej tabeli.
Ważne
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 cofnie usługę Power BI Premium na jednostki SKU pojemności. Nowi i istniejący klienci powinni rozważyć zakup subskrypcji pojemności sieci szkieletowej (jednostki SKU F).
Aby uzyskać więcej informacji, zobacz Ważne aktualizacje dostępne w licencjonowaniu usługi Power BI Premium i usłudze Power BI Premium.
| Jednostka SKU sieci szkieletowej | Pliki Parquet na tabelę | Grupy wierszy na 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 | 1500 | 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, w których można stronicować dane. 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.
W przypadku przekroczenia maksymalny rozmiar modelu na dysku/oneLake spowoduje powrót do trybu DirectQuery wszystkich zapytań do modelu semantycznego. Wszystkie inne zabezpieczenia przedstawione w tabeli są oceniane na zapytanie. Dlatego ważne jest, aby zoptymalizować tabele delty i model semantyczny usługi Direct Lake, aby uniknąć niepotrzebnego skalowania w górę do wyższej jednostki SKU sieci szkieletowej (co powoduje zwiększenie kosztów).
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.
Rozważania i ograniczenia
Modele semantyczne usługi Direct Lake przedstawiają pewne zagadnienia i ograniczenia.
Uwaga
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 usługi Direct Lake łączy się z tabelą w punkcie końcowym analizy SQL, który wymusza zabezpieczenia na poziomie wiersza, zapytania obejmujące tabelę modelu zawsze wracają do trybu 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 usługi Direct Lake nie 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).
- Kolumny obliczeniowe i tabele obliczeniowe odwołujące się do kolumn lub tabel w trybie przechowywania usługi Direct Lake nie są obsługiwane. Obsługiwane są 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.
- Tabele trybu przechowywania usługi Direct Lake nie obsługują złożonych typów kolumn tabeli delty. Typy semantyczne binarne i semantyczne identyfikatora GUID są również 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 zostaną wykryte zduplikowane wartości.
- Funkcja automatycznego analizy danych/czasu w programie Power BI Desktop nie jest obsługiwana. Oznaczanie własnej tabeli dat jako tabeli dat jest obsługiwane.
- 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.
- Scenariusze osadzania, które używają scenariusza użycia dla klienta , nie są obsługiwane.
- Publikowanie w Internecie z usługi Power BI jest obsługiwane tylko w przypadku używania stałej tożsamości dla modelu semantycznego usługi Direct Lake.
- 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.
- W portalu sieci szkieletowej karta Direct Lake w historii odświeżania zawiera tylko błędy odświeżania powiązane z usługą Direct Lake. Operacje pomyślnego odświeżania (tworzenia ramek) nie są wyświetlane.
- Jednostka SKU sieci szkieletowej określa maksymalną ilość dostępnej pamięci na model semantyczny usługi Direct Lake dla pojemności. Po przekroczeniu limitu zapytania do modelu semantycznego mogą być wolniejsze z powodu nadmiernego stronicowania i z 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. Jeśli na przykład usługa Lakehouse znajduje się w regionie Zachodnio-środkowe stany USA, można tworzyć tylko modele semantyczne z tego magazynu Lakehouse w tym samym regionie. Obejściem jest utworzenie usługi Lakehouse w obszarze roboczym innego regionu i skrót do tabel przed utworzeniem modelu semantycznego. Aby znaleźć region, w którym się znajdujesz, zobacz Znajdowanie regionu macierzystego sieci szkieletowej.
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.
| Możliwość | Direct Lake | Importuj | DirectQuery |
|---|---|---|---|
| Licencjonowanie | Tylko subskrypcja pojemności sieci szkieletowej (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 lakehouse lub warehouse (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 | Nie1 | Tak — może łączyć się z tabelami trybu przechowywania DirectQuery lub Podwójne | Tak — może łączyć się z tabelami importu lub dwóch trybów przechowywania |
| Logowanie jednokrotne | Tak | Nie dotyczy | Tak |
| tabele obliczeniowe, | 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 importu, nawet jeśli odwołują się do innych tabel w trybie DirectQuery |
| Kolumny obliczeniowe | Nie. | Tak | Tak |
| Tabele hybrydowe | Nie. | Tak | Tak |
| Partycje tabeli modelu | 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. | 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 obiektu semantycznego modelu | 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 zabezpieczeniami na poziomie wiersza modelu semantycznego | Tak |
| Zabezpieczenia na poziomie wiersza (RLS) modelu semantycznego | 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 |
| Duże woluminy danych bez wymagania dotyczącego odświeżania | Tak | Mniej odpowiednie — do wykonywania zapytań i odświeżania może być wymagany większy rozmiar pojemności | Tak |
| Zmniejszanie opóźnienia danych | Tak — w przypadku włączenia aktualizacji automatycznych lub programowego reframowania, jednak najpierw należy wykonać przygotowywanie danych nadrzędnych | Nie. | Tak |
1 Tabele trybu przechowywania Direct Lake nie można połączyć z tabelami trybu przechowywania DirectQuery lub Podwójne 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.