Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
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 przechowywanych w usłudze OneLake — pojedynczy magazyn dla wszystkich danych analitycznych. Po załadowaniu do pamięci semantyczny model umożliwia interaktywną analizę o wysokiej wydajności.
Usługa Direct Lake jest idealna w przypadku modeli semantycznych łączących się z dużymi jeziorkami danych, magazynami i innymi źródłami z tabelami Delta, szczególnie gdy replikowanie całego woluminu danych do modelu importu jest trudne lub niemożliwe. Zapytania Direct Lake są, podobnie jak w trybie importu, przetwarzane przez aparat zapytań VertiPaq, podczas gdy DirectQuery kieruje zapytania do bazowego źródła danych. Oznacza to, że zapytania Direct Lake, takie jak tryb importu, zwykle przewyższają zapytanie bezpośrednie.
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
Modele semantyczne Import i DirectQuery są nadal istotne w Fabric i są właściwym wyborem 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 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 wchodzą w interakcje z wizualizacjami w raportach usługi Power BI, które generują zapytania języka DAX do modelu semantycznego.
-
Tryb przechowywania: model semantyczny przetwarza zapytania języka DAX inaczej w zależności od zastosowanego trybu przechowywania. 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.
- Z drugiej strony zapytanie bezpośrednie tłumaczy zapytania języka DAX na składnię zapytania źródła danych (zazwyczaj formę języka SQL) i sfederuje je z bazową bazą danych. Źródłowe procesory zapytań bazy danych często nie są dostosowane do stylu analizy biznesowej, zagregowanych zapytań i w związku z tym powodują spowolnienie wydajności i zmniejszenie interakcyjności użytkowników 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 Direct Lake może używać dwóch różnych metod dostępu:
- Direct Lake na OneLake nie zależy od punktów końcowych SQL i może używać danych z dowolnego źródła danych Fabric z tabelami Delta. Usługa Direct Lake w usłudze OneLake nie wraca do trybu DirectQuery.
Notatka
Usługa Direct Lake w usłudze OneLake jest obecnie dostępna w publicznej wersji zapoznawczej.
- Usługa Direct Lake w punktach końcowych SQL używa punktu końcowego SQL usługi Fabric lakehouse lub magazynu na potrzeby odnajdywania i sprawdzania uprawnień tabeli delty. Usługa Direct Lake w punktach końcowych SQL może powrócić do trybu DirectQuery, gdy nie może załadować danych bezpośrednio z tabeli delty, na przykład wtedy, gdy źródło danych jest widokiem SQL lub gdy usługa Warehouse korzysta z zabezpieczeń na poziomie wiersza (RLS) opartych na języku SQL. Usługa Direct Lake w punktach końcowych SQL jest ogólnie dostępna i w pełni obsługiwana w środowisku produkcyjnym.
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 | Zapytanie bezpośrednie |
|---|---|---|---|---|
| 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 | Nr 1 | Nr 1 | Tak — może łączyć się z tabelami trybu przechowywania DirectQuery lub trybu Dual | Tak — może łączyć się z tabelami w trybie importu lub trybu podwójnego przechowywania. |
| 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 | Tak — ale obliczenia nie mogą odwoływać się do kolumn tabel w trybie Direct Lake. | 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 Ochronne ograniczenia i ograniczenia zdolności Fabric 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 usługi Direct Lake są odpytywane w celu zwrócenia danych na podstawie stanu tabeli delty w momencie najnowszej operacji ramki. 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.
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 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
Modele semantyczne usługi Direct Lake są zgodne z modelem zabezpieczeń warstwowych. Wykonują kontrole uprawnień w celu określenia, czy tożsamość próbująca uzyskać dostęp do danych ma niezbędne uprawnienia dostępu do danych w elemencie danych źródłowych i modelu semantycznym. Uprawnienia można przypisać bezpośrednio lub uzyskać niejawnie przy użyciu ról obszaru roboczego w usłudze Microsoft Fabric.
Ważne jest, aby wiedzieć, że Direct Lake w OneLake i Direct Lake na punktach końcowych SQL wykonują kontrole uprawnień w różny sposób.
- Usługa Direct Lake w usłudze OneLake wymaga uprawnień Odczyt i OdczytWszystkie w usłudze Lakehouse/warehouse w celu uzyskania dostępu do tabel delty.
- Usługa Direct Lake w punktach końcowych SQL wymaga uprawnień Odczyt i OdczytData w usłudze Lakehouse/warehouse w celu uzyskania dostępu do danych z punktu końcowego analizy SQL.
Notatka
Usługa Direct Lake w OneLake wymaga, aby użytkownicy mieli uprawnienia do odczytywania tabel Delta w OneLake, a niekoniecznie do punktu końcowego SQL. Wymusza to scentralizowany projekt zabezpieczeń, w którym OneLake jest jednym źródłem kontroli dostępu.
Z drugiej strony, Direct Lake w kontekście punktów końcowych SQL wymaga, aby użytkownicy mieli dostęp do odczytu do punktu końcowego SQL i niekoniecznie do tabel Delta w OneLake. Dzieje się tak dlatego, że Fabric udziela niezbędnych uprawnień modelowi semantycznemu do odczytywania tabel Delta i powiązanych plików Parquet (w celu załadowania danych kolumn do pamięci). Model semantyczny ma również uprawnienia niezbędne do okresowego odczytywania punktu końcowego analizy SQL w celu przeprowadzania kontroli uprawnień w celu określenia, do jakich danych może uzyskiwać dostęp użytkownik zapytań (lub stała tożsamość).
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ń
Weź pod uwagę następujące scenariusze i wymagania dotyczące uprawnień.
| Scenariusz | Wymagane uprawnienia | Komentarze |
|---|---|---|
| Użytkownicy mogą wyświetlać raporty | Udziel uprawnienia Odczyt dla raportów i uprawnienia Odczyt dla modelu semantycznego. Jeśli model semantyczny korzysta z Direct Lake na punktach końcowych SQL, a połączenie w chmurze korzysta z logowania jednokrotnego, przyznaj co najmniej uprawnienia Odczyt i OdczytData dla lakehouse lub magazynu. Jeśli model semantyczny używa usługi Direct Lake w usłudze OneLake, a połączenie w chmurze używa SSO, przyznaj co najmniej uprawnienie Odczyt i OdczytAll dla tabel Delta w usłudze OneLake. |
Raporty nie muszą należeć do tego samego obszaru roboczego co model semantyczny. Aby uzyskać więcej informacji, zobacz Strategia dla użytkowników w trybie tylko do odczytu. |
| Użytkownicy mogą tworzyć raporty | Udziel uprawnień do tworzenia dla modelu semantycznego. Jeśli model semantyczny używa Direct Lake w punktach końcowych SQL, a połączenie w chmurze korzysta z logowania jednokrotnego, przyznaj co najmniej uprawnienia Odczyt oraz OdczytData dla lakehouse lub magazynu. Jeśli model semantyczny używa funkcji Direct Lake w OneLake, a połączenie z chmurą używa logowania jednokrotnego, przyznaj co najmniej uprawnienia Odczyt i OdczytWszystko dla tabel Delta w OneLake. |
Aby uzyskać więcej informacji, zobacz Strategia dla twórców zawartości. |
| Użytkownicy mogą wyświetlać raporty, ale odmówiono im możliwości wykonywania zapytań względem usługi Lakehouse, punktu końcowego analizy SQL lub tabel Delta w usłudze OneLake. | Udziel uprawnienia Odczyt dla raportów i uprawnienia Odczyt dla modelu semantycznego. Nie udzielaj użytkownikom żadnych uprawnień do tabel lakehouse, warehouse ani Delta. |
Odpowiednie tylko wtedy, gdy model Direct Lake używa stałej identyfikacji przez połączenie w chmurze z wyłączonym SSO (logowaniem jednokrotnym). |
| Zarządzanie modelem semantycznym, w tym ustawieniami odświeżania | Wymaga własności modelu semantycznego. | Aby uzyskać więcej informacji, zobacz Semantic model ownership (Własność modelu semantycznego). |
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ń.
| Uwaga/ograniczenie | Usługa Direct Lake w usłudze OneLake | Usługa Direct Lake w punktach końcowych SQL |
|---|---|---|
| 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 przełączy się na tryb 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 takim przypadku zapytania nie powiodą się. |
| Modelowanie złożone nie jest obecnie obsługiwane, co oznacza, ż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). | Niewspierane | Niewspierane |
| Kolumny obliczeniowe i tabele obliczeniowe odwołujące się do kolumn lub tabel w trybie przechowywania 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. | 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 |
| 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. | Tak | Tak |
| 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 | Niewspierane |
| Usługa Direct Lake nie obsługuje profilów głównej usługi na potrzeby uwierzytelniania. | Niewspierane | Tak |
| 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 | |
| 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 | Tak |