Notatka
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 modelu Power BI semantyczna dostępna w Microsoft Fabric. Jest ona zoptymalizowana pod kątem szybkiego ładowania dużych ilości danych do pamięci z tabel delty dostępnych w usłudze OneLake — pojedynczego magazynu 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 do modeli semantycznych łączących się z dużymi domami danych (lakehouses) Fabric, hurtowniami danych 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 Import jest niepraktyczne lub niemożliwe. Zapytania Direct Lake i Import są przetwarzane przez aparat zapytań VertiPaq, podczas gdy zapytania federacyjne DirectQuery są kierowane do bazowego źródła danych. Zapytania Direct Lake i Import zwykle przewyższają wyniki zapytań DirectQuery podczas ładowania 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 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 jest operacją o niskich kosztach, która analizuje metadane najnowszej wersji tabel delty i aktualizuje odwołania do najnowszych plików w usłudze OneLake. Z kolei odświeżanie importu 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). Usługa Direct Lake przenosi przygotowywanie danych do usługi OneLake, a w tym celu używa pełnego zakresu technologii Fabric na potrzeby przygotowywania danych, w tym zadań platformy 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 obciążenia związanego z zarządzaniem cyklami odświeżania danych w celu załadowania całego woluminu danych.
- Korzysta z istniejących inwestycji w Fabric dzięki bezproblemowej integracji z dużymi lakehouse'ami, hurtowniami danych i innymi źródłami Fabric opartymi na tabelach 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.
Napiwek
Wydajność usługi Direct Lake zależy od dobrze zoptymalizowanych tabel Delta. Aby uzyskać kompleksowe wskazówki dotyczące optymalizacji tabel pod kątem konsumpcji w Direct Lake, w tym zalecenia dotyczące V-Order i grup wierszy, zobacz Zarządzanie i optymalizacja tabel dla różnych obciążeń.
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 importu i trybu DirectQuery w modelach semantycznych są nadal istotne w Fabric i są właściwym wyborem modelu semantycznego 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.
Semantyczny model z tabelami Import i tabelami Direct Lake oferuje wymaganą skalę i elastyczność w wielu scenariuszach BI.
Ponadto integracja OneLake automatycznie zapisuje dane dla tabel w trybie importowania trybu przechowywania do Delta tables w OneLake bez jakiegokolwiek wysiłku związanego z migracją, co pozwala zrealizować wiele zalet Fabric dostępnych dla wszystkich użytkowników modelu semantycznego, takich jak integracja z Lakehouse za pomocą skrótów, zapytań SQL, notatek i innych. Zalecamy tę opcję jako szybki sposób czerpania korzyści z 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 Fabric lakehouses, instrukcje języka T-SQL DML dla magazynów Fabric, przepływów danych, potoków i innych, co pomaga zapewnić, że logika przygotowywania danych jest wykonywana nadrzędnie w architekturze w celu zmaksymalizowania możliwości 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 magazynie typu lakehouse zarządzanym przez IT, to rozszerzenie modelu za pomocą tabel w trybie importu danych może być dobrym wyborem, ponieważ tryb importu obsługuje przygotowywanie danych za pomocą Power Query, które jest definiowane jako część modelu semantycznego.
Pamiętaj, aby wziąć pod uwagę bieżącą licencję pojemności Fabric oraz ograniczenia pojemności Fabric, gdy rozważasz 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 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 przechowywania Import i Direct Lake używają silnika VertiPaq do przetwarzania zapytań DAX i zwracania wyników do raportu oraz do użytkownika 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, zapoznaj się z trybami modelu semantycznego w usłudze Power BI.
Tryb przechowywania tabel w usłudze Direct Lake ma dwie opcje:
Direct Lake w usłudze OneLake mogą 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 usługą Direct Lake w tabelach OneLake mogą również zawierać tabele importu dodane z innych źródeł danych.
Direct Lake w usłudze SQL może używać danych z jednego źródła danych Fabric z tabelami delty. Punkt końcowy analizy SQL jest używany do odnajdywania tabel Delta oraz odnajdywania widoków SQL i sprawdzania uprawnień. Direct Lake w punktach końcowych analizy SQL przechodzi w tryb magazynowania tabeli DirectQuery, gdy nie może załadować danych bezpośrednio z tabeli Delta, na przykład gdy źródłem danych jest widok SQL lub gdy magazyn korzysta ze szczegółowej kontroli dostępu opartej na SQL. Właściwość semantycznego modelu, zachowanie Direct Lake, steruje zachowaniem awaryjnym.
Porównanie trybów przechowywania
Użyj poniższych porównań, aby zrozumieć źródła danych i możliwości obsługiwane przez każdy tryb przechowywania.
Obsługiwane źródła danych Fabric
Obsługa silnika: W przypadku rozwiązania Direct Lake w usłudze OneLake silnik Analysis Services obsługuje dowolny element w usłudze Fabric, którego magazyn danych OneLake odwołuje się do prawidłowych tabel Delta, zarówno natywnie, jak i za pomocą skrótów. Możesz programowo tworzyć modele dla innych kompatybilnych elementów, korzystając z narzędzia zgodnego z XMLA lub notatnika Fabric. Więcej informacji można znaleźć w artykule Utwórz model.
Obsługa środowiska tworzenia: Poniższa tabela przedstawia kompleksową obsługę w tych środowiskach dla każdej opcji Direct Lake.
| Źródło danych Fabric | Usługa Direct Lake w usłudze OneLake | Direct Lake na SQL |
|---|---|---|
| Lakehouse | Wsparte | Wsparte |
| Warehouse | Wsparte | Wsparte |
| Baza danych SQL na platformie Fabric | Wsparte | Wsparte |
| Dublowana baza danych | Wsparte | Wsparte |
| Odwzorowany katalog Azure Databricks | Wsparte | Wsparte |
| Baza danych snowflake | Wsparte | Wsparte |
| Cosmos DB w Fabric | Wsparte | Niewspierane |
| Baza danych KQL 1 | Wsparte | Niewspierane |
| Podgląd magazynu | Niewspierane | Niewspierane |
| Interfejs API dla języka GraphQL | Niewspierane | Niewspierane |
1 W przypadku bazy danych KQL włącz funkcję Dostępność w usłudze OneLake, aby jej dane były dostępne w formacie Delta Lake.
Migawki magazynowe i API dla GraphQL nie udostępniają tabel Delty w OneLake jako tabel źródłowych dla Direct Lake.
Porównaj możliwości trybu przechowywania danych
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 | Direct Lake w punktach końcowych analizy SQL | Importowanie | DirectQuery |
|---|---|---|---|---|
| Licencjonowania | tylko abonament na pojemność Fabric (jednostki SKU) | tylko abonament na pojemność Fabric (jednostki SKU) | Dowolna licencja Fabric lub Power BI (w tym licencja Microsoft Fabric Bezpłatna) | Dowolna licencja Fabric lub Power BI (w tym licencja Microsoft Fabric Bezpłatna) |
| Źródło danych | Co najmniej jeden element Fabric, którego magazyn OneLake wskazuje na prawidłowe tabele Delta — natywnie lub za pomocą skrótów | Jedno obsługiwane źródło danych Fabric z punktem końcowym analizy SQL, jak podano w Obsługiwanych źródłach danych Fabric | 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żna łączyć tabele w trybie przechowywania danych importowanych w modelowaniu w wersji internetowej Power BI z tabelami DirectQuery za pomocą 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 importu, Dual i trybem przechowywania Direct Lake. |
| Logowanie jednokrotne (SSO) | Tak | Tak | Nie dotyczy | Tak |
| Tabele obliczeniowe | Tak (wersja zapoznawcza) — tabele obliczeniowe są obsługiwane dla funkcji Direct Lake w usłudze OneLake; zobacz uwagi i ograniczenia. | 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 - Tylko kontekst użytkownika (wersja zapoznawcza) | 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 Podczas używania Direct Lake na endpointach analityki SQL nie można łączyć tabel trybów przechowywania Direct Lake z tabelami trybów DirectQuery lub Dual storage w tym samym modelu semantycznym. Można jednak użyć Power BI Desktop, aby utworzyć model złożony w modelu semantycznym usługi Direct Lake, a następnie rozszerzyć go na nowe tabele (przy użyciu importu, trybu DirectQuery lub trybu przechowywania podwójnego) 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.
Aby uzyskać szczegółowe informacje na temat sposobu działania usługi Direct Lake, w tym ładowania kolumn (transkodowania), tworzenia ram, aktualizacji automatycznych i rezerwowego trybu DirectQuery, zobacz Jak działa usługa Direct Lake.
Aby uzyskać szczegółowe informacje na temat uprawnień, uwierzytelniania, zabezpieczeń OLS/RLS i reguł dostępu do danych, zobacz Integrowanie zabezpieczeń usługi Direct Lake.
wymagania dotyczące pojemności Fabric
Modele semantyczne usługi Direct Lake wymagają licencji na pojemność Fabric. Istnieją również zabezpieczenia pojemności i ograniczenia dotyczące subskrypcji pojemności (SKU) Fabric, jak przedstawiono w poniższej tabeli.
Ważny
Pierwsza kolumna w poniższej tabeli zawiera również subskrypcje pojemności Power BI Premium (jednostki SKU P). Jednostki SKU usługi Power BI Premium dla pojemności są wycofywane. Nowe wdrożenia powinny korzystać z subskrypcji Fabric capacity (F SKU).
Więcej informacji można znaleźć w przeglądzie migracji z Power BI Premium na Microsoft Fabric.
| Jednostka SKU dla 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 |
| F4096 | 10 000 | 10 000 | 24,000 | Nieograniczony | 400 |
| F8192 | 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 zabezpieczenie; może jednak wpłynąć na wydajność, jeśli ilość danych jest wystarczająco duża, aby spowodować nadmierne stronicowanie w i ze danych modelu z OneLake.
Jeśli zabezpieczenia zostaną przekroczone, zachowanie zależy od trybu przechowywania tabel:
- Usługa Direct Lake w usłudze OneLake: podobnie jak tryb importu, odświeżanie kończy się niepowodzeniem i nie można wykonywać zapytań dotyczących modelu, dopóki tabele delty nie zostaną zoptymalizowane pod kątem mieścinia się w granicach bariery ochronnej.
- Direct Lake w SQL: przejście z powrotem do trybu DirectQuery, jeśli włączono tryb awaryjny. Odświeżanie kończy się pomyślnie z ostrzeżeniem, a zapytania nadal zwracają wyniki, ale z wolniejszym działaniem.
Maksymalny rozmiar modelu na dysku lub w OneLake jest oceniany na poziomie modelu i dotyczy wszystkich zapytań. Wszystkie inne zabezpieczenia przedstawione w tabeli są oceniane dla każdego zapytania. Dlatego ważne jest, aby optymalizować swoje tabele Delta oraz semantyczny model Direct Lake, aby uniknąć niepotrzebnego skalowania do wyższej jednostki SKU w platformie 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 mają 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 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 usłudze OneLake wymaga, aby użytkownik miał dostęp do plików w usłudze OneLake, co nie stosuje zabezpieczeń na poziomie wiersza opartym 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. W tym przypadku Direct Lake w punktach końcowych analizy SQL przejdzie w tryb DirectQuery. 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 należy użyć innego trybu przechowywania, takiego jak Import lub Direct Lake 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 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. | Tak – Kolumny wyliczone są tylko w kontekście użytkownika | 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 inteligencja daty/godziny w programie Power BI Desktop służy do tworzenia relacji za pomocą 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 sieci Web z Power BI jest obsługiwane tylko przy użyciu jednostki usługi, jeśli korzysta się z ustalonej 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 zawiera listę błędów odświeżania związanych z usługą 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 |
| Jednostka SKU Fabric określa maksymalną ilość dostępnej pamięci na model semantyczny usługi Direct Lake w ramach zasobów. 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 znaleźć region, w którym się znajdujesz, zobacz znajdowanie macierzystego regionu Fabric. | Tak | Tak Obejściem jest utworzenie magazynu typu lakehouse w obszarze roboczym innego regionu oraz utworzenie skrótu do tabel przed stworzeniem modelu semantycznego. |
| Osadzanie raportów wymaga tokenu w wersji 2 do osadzania. | Tak | Tak |
| Profile jednostki usługi na potrzeby uwierzytelniania. | Niewspierane | Niewspierane |
| Power BI modele semantyczne Direct Lake można tworzyć i wykonywać zapytania przez jednostki usługi, a członkostwo w roli Osoba przeglądająca z jednostkami usługi jest obsługiwane, ale domyślne modele semantyczne Direct Lake dla 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. | Wsparte | 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. | Niewspierane | Wsparte |
| Dodawanie wielu tabel z tej samej tabeli źródła danych. | Nieobsługiwane w Power BI Desktop ani podczas modelowania w sieci Web. 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żywanie tabel Edit w narzędziach Power BI i refresh powoduje błąd z wieloma tabelami z tej samej tabeli źródła danych w modelu semantycznym. | Nieobsługiwane w Power BI Desktop ani podczas modelowania w sieci Web. 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żywanie tabel Edit w narzędziach Power BI i refresh powoduje błąd z wieloma tabelami z tej samej tabeli źródła danych w modelu semantycznym. |
| Tabele usługi Direct Lake utworzone przy użyciu aplikacji XMLA są początkowo w stanie nieprzetworzone, dopóki aplikacja nie wyśle polecenia odświeżania. Pamiętaj, aby odświeżyć model w celu przetworzenia jego tabel, gdy tworzysz nowy model semantyczny. | Zapytania obejmujące nieprzetworzone tabele zwracają błąd. | Zapytania obejmujące nieprzetworzone tabele wracają do trybu DirectQuery, chyba że powrót jest wyłączony, w którym przypadku zapytania kończą się niepowodzeniem. |
Narzędzia zgodne ze standardem XMLA muszą obsługiwać wersję compatibilityLevel 1604 lub wyższą, aby współpracować z modelami semantycznymi usługi Direct Lake i uwidaczniać metadane specyficzne dla Direct Lake. |
Tak | Tak |
| Odświeżanie modeli semantycznych usługi Direct Lake przy użyciu dowolnej bramy (lokalnej lub wirtualnej) | Niewspierane. Usługa Direct Lake w usłudze OneLake obsługuje tylko połączenia w chmurze i nie może działać za pośrednictwem żadnej bramy. | Niewspierane. Usługa Direct Lake w usłudze SQL (punkt końcowy analizy) obsługuje tylko połączenia w chmurze i nie może działać za pośrednictwem żadnej bramy. |
Analiza w tabelach przestawnych Excel (i innych klientach MDX) ma takie same ograniczenia jak tryb DirectQuery dla tabel 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 w tabelach importu jest obsługiwane nawet w przypadku tabel Direct Lake w modelu semantycznym.
Power BI Desktop może na żywo edytować model semantyczny przy użyciu tabel direct lake i tabel importu. 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 Power BI może otwierać dowolne modele semantyczne, w tym tabele Direct Lake wraz z innymi tabelami w różnych trybach przechowywania.
Widok zapytań DAX podczas edytowania na żywo lub przy nawiązaniu połączenia na żywo, a także pisania zapytań DAX w Internecie, jest obsługiwany dla Direct Lake na SQL, Direct Lake na OneLake oraz prawdziwie złożonych (Direct Lake na OneLake + Importowanie 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 uprawnienia do kompilacji.
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 używać operacji Edit tables i refresh w Power BI Desktop i modelowaniu w Power BI w Internecie. 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.