Direct Lake

Tryb Direct Lake to funkcja semantycznego modelu do analizowania bardzo dużych ilości danych w usłudze Power BI. Usługa Direct Lake jest oparta na ładowaniu plików w formacie parquet bezpośrednio z magazynu typu data lake bez konieczności wykonywania zapytań dotyczących punktu końcowego magazynu lub magazynu typu lakehouse i bez konieczności importowania lub duplikowania danych do modelu usługi Power BI. Usługa Direct Lake to szybka ścieżka do ładowania danych z jeziora bezpośrednio do aparatu usługi Power BI gotowego do analizy. Na poniższym diagramie przedstawiono porównanie klasycznych trybów importu i trybu DirectQuery z trybem Direct Lake.

W trybie DirectQuery aparat usługi Power BI wysyła zapytanie do danych w źródle, co może być powolne, ale nie musi kopiować danych, takich jak w trybie importu. Wszelkie zmiany w źródle danych są natychmiast odzwierciedlane w wynikach zapytania.

Z drugiej strony w trybie importu wydajność może być lepsza, ponieważ dane są buforowane i zoptymalizowane pod kątem zapytań raportów języka DAX i MDX bez konieczności tłumaczenia i przekazywania kodu SQL lub innych typów zapytań do źródła danych. Aparat usługi Power BI musi jednak najpierw skopiować nowe dane do modelu podczas odświeżania. Wszelkie zmiany w źródle są pobierane tylko przy następnym odświeżeniu modelu.

Tryb Direct Lake eliminuje wymaganie importu przez załadowanie danych bezpośrednio z usługi OneLake. W przeciwieństwie do trybu DirectQuery nie ma tłumaczenia z języka DAX lub MDX na inne języki zapytań ani wykonywania zapytań w innych systemach baz danych, co daje wydajność podobną do trybu importu. Ponieważ nie ma jawnego procesu importowania, można pobrać wszelkie zmiany w źródle danych w miarę ich występowania, łącząc zalety zarówno trybu DirectQuery, jak i trybów importowania, jednocześnie unikając ich wad. Tryb Direct Lake może być idealnym wyborem do analizowania bardzo dużych modeli i modeli z częstymi aktualizacjami w źródle danych.

Usługa Direct Lake obsługuje również zabezpieczenia na poziomie wiersza i zabezpieczenia na poziomie obiektu usługi Power BI, dzięki czemu użytkownicy widzą tylko dane, do których mają uprawnienia.

Wymagania wstępne

Usługa Direct Lake jest obsługiwana tylko w jednostkach SKU Microsoft Premium (P) i jednostkach SKU usługi Microsoft Fabric (F).

Ważne

W przypadku nowych klientów usługa Direct Lake jest obsługiwana tylko w jednostkach SKU usługi Microsoft Fabric (F). Istniejący klienci mogą nadal korzystać z usługi Direct Lake z jednostkami SKU Premium (P), ale zaleca się przejście do jednostki SKU pojemności sieci szkieletowej. Zobacz ogłoszenie licencjonowania, aby uzyskać więcej informacji na temat licencjonowania usługi Power BI Premium.

Lakehouse

Przed użyciem usługi Direct Lake należy aprowizować magazyn lakehouse (lub magazyn) z co najmniej jedną tabelą delty w obszarze roboczym hostowanym w obsługiwanej pojemności usługi Microsoft Fabric. Usługa Lakehouse jest wymagana, ponieważ zapewnia lokalizację przechowywania plików sformatowanych w formacie parquet w usłudze OneLake.

Aby dowiedzieć się, jak aprowizować jezioro, utworzyć tabelę delta w lakehouse i utworzyć podstawowy model dla lakehouse, zobacz Create a lakehouse for Direct Lake (Tworzenie jeziora dla usługi Direct Lake).

Punkt końcowy analizy SQL i magazyn danych

W ramach aprowizacji usługi Lakehouse tworzony jest punkt końcowy analizy SQL na potrzeby wykonywania zapytań SQL i aktualizowany przy użyciu wszystkich tabel dodanych do usługi Lakehouse. Tryb Direct Lake nie wysyła zapytań do punktu końcowego analizy SQL podczas ładowania danych bezpośrednio z usługi OneLake, ale jest wymagany, gdy model Direct Lake musi bezproblemowo powrócić do trybu DirectQuery, na przykład wtedy, gdy źródło danych korzysta z określonych funkcji, takich jak zabezpieczenia zaawansowane lub widoki, których nie można odczytać za pośrednictwem usługi Direct Lake, i musi korzystać z punktu końcowego analizy SQL. Tryb Direct Lake okresowo wykonuje również zapytania dotyczące punktu końcowego analizy SQL pod kątem informacji związanych ze schematem i zabezpieczeniami.

Alternatywą dla usługi Lakehouse z punktem końcowym analizy SQL można również aprowizować magazyn i dodawać tabele przy użyciu instrukcji SQL lub potoków danych. Procedura aprowizacji autonomicznego magazynu danych jest niemal identyczna z procedurą dla magazynu lakehouse.

Domyślny model semantyczny usługi Power BI

Magazyny i punkty końcowe analizy SQL tworzą również domyślny model semantyczny usługi Power BI w trybie Direct Lake. Ten domyślny model semantyczny można edytować tylko w punkcie końcowym magazynu lub analizy SQL i ma dodatkowe ograniczenia. Zapoznaj się z dokumentacją domyślnego modelu semantycznego usługi Power BI. Ta dokumentacja usługi Direct Lake dotyczy nie domyślnych modeli semantycznych usługi Power BI w trybie Direct Lake.

Tworzenie modelu semantycznego usługi Power BI w trybie Direct Lake

Semantyczne modele usługi Power BI w trybie Direct Lake są tworzone w magazynie lub lakehouse.

W usłudze Lakehouse kliknij pozycję Nowy model semantyczny usługi Power BI, aby utworzyć semantyczny model usługi Power BI w trybie Direct Lake.

W punkcie końcowym magazynu lub analizy SQL wybierz wstążkę Raportowanie , a następnie wybierz pozycję Nowy model semantyczny usługi Power BI, aby utworzyć semantyczny model usługi Power BI w trybie Direct Lake.

Następnie można dodawać relacje, miary, grupy obliczeń, ciągi formatu, zabezpieczenia na poziomie wiersza itp., a także zmieniać nazwy tabel i kolumn, edytując model semantyczny w przeglądarce. Edytuj model semantyczny później przy użyciu menu kontekstowego z obszaru roboczego, aby otworzyć model danych.

Obsługa zapisu modelu za pomocą punktu końcowego XMLA

Modele direct Lake obsługują operacje zapisu za pośrednictwem punktu końcowego XMLA przy użyciu narzędzi, takich jak SQL Server Management Studio (19.1 i nowsze), a także najnowsze wersje zewnętrznych narzędzi analizy biznesowej, takich jak Edytor tabelaryczny i studio JĘZYKA DAX. Operacje zapisu modelu za pośrednictwem obsługi punktu końcowego XMLA:

• Dostosowywanie, scalanie, wykonywanie skryptów, debugowanie i testowanie metadanych modelu usługi Direct Lake.

• Kontrola źródła i wersji, ciągła integracja i ciągłe wdrażanie (CI/CD) za pomocą usług Azure DevOps i GitHub.

• Zadania automatyzacji, takie jak odświeżanie, i stosowanie zmian w modelach usługi Direct Lake przy użyciu programu PowerShell i interfejsów API REST.

Tabele usługi Direct Lake utworzone przy użyciu aplikacji XMLA będą początkowo w stanie nieprzetworzonych, dopóki aplikacja nie uruchomi polecenia odświeżania. Nieprzetworzone tabele wracają do trybu DirectQuery. Podczas tworzenia nowego modelu semantycznego pamiętaj, aby odświeżyć model semantyczny w celu przetworzenia tabel.

Włączanie odczytu i zapisu XMLA

Przed wykonaniem operacji zapisu w modelach Direct Lake za pośrednictwem punktu końcowego XMLA należy włączyć odczyt-zapis XMLA dla pojemności.

W przypadku pojemności próbnych usługi Fabric użytkownik wersji próbnej ma uprawnienia administratora niezbędne do włączenia odczytu i zapisu XMLA.

1. W portalu administracyjnym wybierz pozycję Ustawienia pojemności.

2. Wybierz kartę Wersja próbna .

3. Wybierz pojemność z wersją próbną i nazwą użytkownika w nazwie pojemności.

4. Rozwiń węzeł Obciążenia usługi Power BI, a następnie w ustawieniu Punkt końcowy XMLA wybierz pozycję Odczytaj zapis.

   

Należy pamiętać, że ustawienie Punkt końcowy XMLA ma zastosowanie do wszystkich obszarów roboczych i modeli przypisanych do pojemności.

Metadane modelu usługi Direct Lake

Podczas nawiązywania połączenia z autonomicznym modelem usługi Direct Lake za pośrednictwem punktu końcowego XMLA metadane wyglądają jak każdy inny model. Jednak modele usługi Direct Lake pokazują następujące różnice:

• Właściwość compatibilityLevel obiektu bazy danych to 1604 lub nowsza.

• Właściwość Mode partycji Direct Lake jest ustawiona na directLakewartość .

• Partycje usługi Direct Lake używają wyrażeń udostępnionych do definiowania źródeł danych. Wyrażenie wskazuje punkt końcowy analizy SQL typu lakehouse lub warehouse. Usługa Direct Lake używa punktu końcowego analizy SQL usługi Lakehouse do odnajdywania informacji o schemacie i zabezpieczeniach, ale ładuje dane bezpośrednio z tabel delta (chyba że usługa Direct Lake musi wrócić do trybu DirectQuery z jakiegokolwiek powodu).

Oto przykładowe zapytanie XMLA w programie SSMS:

Aby dowiedzieć się więcej o obsłudze narzędzi za pośrednictwem punktu końcowego XMLA, zobacz Semantic model connectivity with the XMLA endpoint (Łączność modelu semantycznego z punktem końcowym XMLA).

Temat rezerwowy

Semantyczne modele usługi Power BI w trybie Direct Lake odczytują tabele delty bezpośrednio z usługi OneLake. Jeśli jednak zapytanie języka DAX w modelu Direct Lake przekracza limity dla jednostki SKU lub używa funkcji, które nie obsługują trybu Direct Lake, takich jak widoki SQL w magazynie, zapytanie może powrócić do trybu DirectQuery. W trybie DirectQuery zapytania używają języka SQL do pobierania wyników z magazynu lub punktu końcowego analizy SQL usługi Lakehouse, co może mieć wpływ na wydajność zapytań. Możesz wyłączyć powrót do trybu DirectQuery, jeśli chcesz przetwarzać zapytania języka DAX tylko w trybie czystej usługi Direct Lake. Wyłączenie rezerwowego jest zalecane, jeśli nie potrzebujesz powrotu do trybu DirectQuery. Przydatne może być również analizowanie przetwarzania zapytań dla modelu usługi Direct Lake w celu określenia, czy i jak często występują rezerwowe. Aby dowiedzieć się więcej na temat trybu DirectQuery, zobacz Tryby modelu semantycznego w usłudze Power BI.

Zabezpieczenia definiują limity zasobów dla trybu Direct Lake, poza którym jest niezbędny powrót do trybu DirectQuery do przetwarzania zapytań języka DAX. Aby uzyskać szczegółowe informacje na temat określania liczby plików parquet i grup wierszy dla tabeli delty, zapoznaj się z dokumentacją właściwości tabeli delty.

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. W efekcie 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ć stronicowanie i wyjście danych z danych modelu z danych onelake.

W poniższej tabeli wymieniono zarówno zabezpieczenia zasobów, jak i maksymalną pamięć:

Jednostki SKU sieci szkieletowej	Pliki Parquet na tabelę	Grupy wierszy na tabelę	Wiersze na tabelę (miliony)	Maksymalny rozmiar modelu na dysku/OneLake1 (GB)	Maksymalna ilość pamięci (GB)
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 przekroczenia maksymalny rozmiar modelu na dysku/onelake powoduje, że wszystkie zapytania modelu wracają do trybu DirectQuery, w przeciwieństwie do innych barier zabezpieczających, które są oceniane na zapytanie.

W zależności od jednostki SKU sieci szkieletowej dodatkowe jednostki pojemności i maksymalne limity pamięci na zapytanie mają zastosowanie również do modeli usługi Direct Lake. Aby dowiedzieć się więcej, zobacz Pojemności i jednostki SKU.

Zachowanie rezerwowe

Modele direct Lake obejmują właściwość DirectLakeBehavior , która ma trzy opcje:

Automatyczne — (wartość domyślna) Określa, że zapytania wracają do trybu DirectQuery , jeśli dane nie mogą być efektywnie ładowane do pamięci.

DirectLakeOnly — określa, że wszystkie zapytania używają tylko trybu Direct Lake. Powrót do trybu DirectQuery jest wyłączony. Jeśli nie można załadować danych do pamięci, zwracany jest błąd. Użyj tego ustawienia, aby określić, czy zapytania języka DAX nie mogą załadować danych do pamięci, wymuszając zwrócenie błędu.

DirectQueryOnly — określa, że wszystkie zapytania używają tylko trybu DirectQuery. To ustawienie służy do testowania wydajności rezerwowej.

Właściwość DirectLakeBehavior można skonfigurować przy użyciu modelu obiektów tabelarycznych (TOM) lub języka skryptowego modelu tabelarycznego (TMSL).

W poniższym przykładzie określono, że wszystkie zapytania używają tylko trybu Direct Lake:

// Disable fallback to DirectQuery mode.
//
database.Model.DirectLakeBehavior = DirectLakeBehavior.DirectLakeOnly = 1;
database.Model.SaveChanges();

Można to również ustawić podczas edytowania modelu semantycznego w przeglądarce we właściwościach modelu semantycznego. Wybierz pozycję Model semantyczny na karcie Model okienka Dane .

Analizowanie przetwarzania zapytań

Aby określić, czy zapytania języka DAX wizualizacji raportu do źródła danych zapewniają najlepszą wydajność przy użyciu trybu Direct Lake lub wracają do trybu DirectQuery, możesz użyć analizatora wydajności w programie Power BI Desktop, programie SQL Server Profiler lub innych narzędziach innych firm do analizowania zapytań. Aby dowiedzieć się więcej, zobacz Analizowanie przetwarzania zapytań dla modeli usługi Direct Lake.

Odśwież

Domyślnie zmiany danych w usłudze OneLake są automatycznie odzwierciedlane w modelu usługi Direct Lake. To zachowanie można zmienić, wyłączając opcję Zachowaj aktualność danych usługi Direct Lake w ustawieniach modelu.

Możesz wyłączyć, jeśli na przykład musisz zezwolić na ukończenie zadań przygotowywania danych przed udostępnieniem nowych danych konsumentom modelu. Po wyłączeniu można wywołać odświeżanie ręcznie lub przy użyciu interfejsów API odświeżania. Wywoływanie odświeżania modelu usługi Direct Lake jest operacją o niskich kosztach, w której model analizuje metadane najnowszej wersji tabeli usługi Delta Lake i jest aktualizowany w celu odwoływania się do najnowszych plików w usłudze OneLake.

Pamiętaj, że usługa Power BI może wstrzymać automatyczne aktualizacje tabel usługi Direct Lake, jeśli podczas odświeżania wystąpi błąd nieodzyskiwalny, dlatego upewnij się, że model semantyczny może zostać pomyślnie odświeżony. Usługa Power BI automatycznie wznawia aktualizacje automatyczne po zakończeniu kolejnego odświeżania wywoływanego przez użytkownika bez błędów.

Logowanie jednokrotne jest domyślnie włączone

Domyślnie modele usługi Direct Lake korzystają z usługi Microsoft Entra Single Sign-On (SSO) w celu uzyskiwania dostępu do źródeł danych usługi Fabric Lakehouse i warehouse oraz używania tożsamości użytkownika, który obecnie wchodzi w interakcję z modelem. Konfigurację można sprawdzić w ustawieniach modelu usługi Direct Lake, rozwijając sekcję Gateway and cloud connections (Połączenia bramy i chmury) pokazaną na poniższym zrzucie ekranu. Model usługi Direct Lake nie wymaga jawnego połączenia danych, ponieważ usługa Lakehouse lub Warehouse jest dostępna bezpośrednio, a logowanie jednokrotne eliminuje konieczność przechowywania poświadczeń połączenia.

Możesz również jawnie powiązać źródło danych lakehouse lub Warehouse z połączeniem chmury z możliwością udostępniania (SCC) w przypadkach, w których chcesz używać przechowywanych poświadczeń, a tym samym wyłączyć logowanie jednokrotne dla tego połączenia ze źródłem danych. Aby jawnie powiązać źródło danych, wybierz SCC z listy Mapy do: w sekcji Połączenia bramy i chmury . Możesz również utworzyć nowe połączenie, wybierając pozycję Utwórz połączenie, a następnie wykonaj kroki, aby podać nazwę połączenia. Następnie wybierz pozycję OAuth 2.0 jako metodę uwierzytelniania dla nowego połączenia, wprowadź żądane poświadczenia i wyczyść pole wyboru Logowanie jednokrotne , a następnie powiąż źródło danych lakehouse lub Warehouse z nowo utworzonym połączeniem SCC.

Konfiguracja połączenia Domyślne: logowanie jednokrotne (Entra ID) upraszcza konfigurację modelu Direct Lake, jednak jeśli masz już osobiste połączenie w chmurze (PCC) ze źródłem danych Lakehouse lub Warehouse, model Direct Lake wiąże się z pasującym pcC automatycznie, tak aby ustawienia połączenia zdefiniowane już dla źródła danych były natychmiast stosowane. Należy potwierdzić konfigurację połączenia modeli usługi Direct Lake, aby upewnić się, że modele uzyskują dostęp do źródeł danych sieci szkieletowej przy użyciu poprawnych ustawień.

Modele semantyczne mogą używać konfiguracji połączenia Default: Single Sign-On (Entra ID) dla usług Fabric Lakehouses i Warehouse w trybie Direct Lake, Import i DirectQuery. Wszystkie inne źródła danych wymagają jawnie zdefiniowanych połączeń danych.

Zabezpieczenia dostępu do danych warstwowych

Modele usługi Direct Lake utworzone na podstawie magazynów i magazynów typu lakehouse są zgodne z modelem zabezpieczeń warstwowym, który obsługuje magazyny i magazyny przez przeprowadzanie kontroli uprawnień za pośrednictwem punktu końcowego analizy SQL w celu określenia, czy tożsamość próbująca uzyskać dostęp do danych ma wymagane uprawnienia dostępu do danych. Domyślnie modele usługi Direct Lake korzystają z logowania jednokrotnego (SSO), więc obowiązujące uprawnienia użytkownika interaktywnego określają, czy użytkownik jest dozwolony, czy nie zezwala na dostęp do danych. Jeśli model usługi Direct Lake jest skonfigurowany do używania stałej tożsamości, skuteczne uprawnienie stałej tożsamości określa, czy użytkownicy korzystający z modelu semantycznego mogą uzyskiwać dostęp do danych. Punkt końcowy analizy SQL zwraca wartość Allowed or Denied do modelu Direct Lake na podstawie kombinacji zabezpieczeń usługi OneLake i uprawnień SQL.

Na przykład administrator magazynu może udzielić użytkownikowi uprawnień SELECT w tabeli, aby użytkownik mógł odczytać z tej tabeli, nawet jeśli użytkownik nie ma uprawnień zabezpieczeń usługi OneLake. Użytkownik został autoryzowany na poziomie lakehouse/warehouse. Z drugiej strony administrator magazynu może również odmówić użytkownikowi dostępu do odczytu do tabeli. Użytkownik nie będzie wówczas mógł odczytać z tej tabeli, nawet jeśli użytkownik ma uprawnienia do odczytu zabezpieczeń usługi OneLake. Instrukcja DENY unieważnia wszelkie przyznane zabezpieczenia usługi OneLake lub uprawnienia SQL. Zapoznaj się z poniższą tabelą, aby uzyskać obowiązujące uprawnienia, które użytkownik może mieć dowolną kombinację zabezpieczeń usługi OneLake i uprawnień SQL.

Uprawnienia zabezpieczeń usługi OneLake	Uprawnienia SQL	Obowiązujące uprawnienia
Zezwalaj	Brak	Zezwalaj
Brak	Zezwalaj	Zezwalaj
Zezwalaj	Zablokuj	Zablokuj
Brak	Zablokuj	Zablokuj

Znane problemy i ograniczenia

• Zgodnie z projektem tylko tabele w modelu semantycznym pochodzące z tabel w usłudze Lakehouse lub Warehouse obsługują tryb Direct Lake. Chociaż tabele w modelu mogą pochodzić z widoków SQL w usłudze Lakehouse lub Warehouse, zapytania korzystające z tych tabel będą wracać do trybu DirectQuery.

• Tabele modelu semantycznego usługi Direct Lake mogą pochodzić tylko z tabel i widoków z jednej usługi Lakehouse lub Warehouse. Pojedynczy magazyn Lakehouse może zawierać skróty dodane z innych usług Lakehouse.

• Zapytania korzystające z zabezpieczeń na poziomie wiersza względem tabel w magazynie (w tym punktu końcowego analizy SQL usługi Lakehouse) zostaną przywrócone do trybu DirectQuery.

• Tabele direct Lake nie mogą być obecnie mieszane z innymi typami tabel, takimi jak Import, DirectQuery lub Dual, w tym samym modelu. Modele złożone w semantycznych modelach usługi Power BI mogą używać modeli semantycznych usługi Power BI w trybie przechowywania usługi Direct Lake jako źródła.

• Relacje typu data/godzina nie są obsługiwane w modelach usługi Direct Lake. Relacje dat są obsługiwane.

• Kolumny obliczeniowe i tabele obliczeniowe nie są obsługiwane. Obsługiwane są grupy obliczeń i parametry pól.

• Niektóre typy danych mogą nie być obsługiwane, takie jak liczba dziesiętna o wysokiej precyzji i typy pieniędzy.

• Tabele usługi Direct Lake nie obsługują złożonych typów kolumn tabeli delty. Typy semantyczne binarne i semantyczne guid również nie są obsługiwane. Te typy danych należy przekonwertować na ciągi lub inne obsługiwane typy danych.

• Relacje tabel wymagają, aby typy danych kolumn kluczy zbiegły się w czasie. Kolumny klucza podstawowego muszą zawierać unikatowe wartości. Zapytania języka DAX kończą się niepowodzeniem, jeśli zostaną wykryte zduplikowane wartości klucza podstawowego.

• Długość wartości kolumn ciągu jest ograniczona do 32 764 znaków Unicode.

• Wartość zmiennoprzecinkowa "NaN" (Nie liczba) nie jest obsługiwana w modelach Direct Lake.

• Scenariusze usługi Power BI Embedded, które opierają się na jednostkach osadzonych, nie są jeszcze obsługiwane.

• Walidacja jest ograniczona w przypadku modeli Direct Lake. Przyjmuje się, że wybór użytkownika jest poprawny, a żadne zapytania nie weryfikują kardynalności i wyboru filtru krzyżowego dla relacji lub dla wybranej kolumny dat w tabeli dat.

• Karta Direct Lake w historii odświeżania zawiera tylko błędy odświeżania powiązane z usługą Direct Lake. Pomyślne odświeżenia są obecnie pomijane.

Rozpocznij

Najlepszym sposobem rozpoczęcia pracy z rozwiązaniem Direct Lake w organizacji jest utworzenie usługi Lakehouse, utworzenie w niej tabeli delty, a następnie utworzenie podstawowego modelu semantycznego dla usługi Lakehouse w obszarze roboczym usługi Microsoft Fabric. Aby dowiedzieć się więcej, zobacz Tworzenie magazynu lakehouse dla usługi Direct Lake.

Powiązana zawartość

• Tworzenie jeziora dla usługi Direct Lake
• Analizowanie przetwarzania zapytań dla modeli semantycznych usługi Direct Lake