Udostępnij za pośrednictwem

Opracowywanie modeli semantycznych usługi Direct Lake

  • Artykuł

W tym artykule opisano tematy projektowe związane z opracowywaniem modeli semantycznych usługi Direct Lake.

Tworzenie modelu

Portal Fabric służy do tworzenia modelu semantycznego Direct Lake w przestrzeni roboczej. Jest to prosty proces, który polega na wyborze tabel z jednego lakehouse'a lub magazynu, aby dodać je do modelu semantycznego.

Następnie możesz użyć środowiska modelowania internetowego w celu dalszego opracowywania modelu semantycznego. To środowisko umożliwia tworzenie relacji między tabelami, tworzenie miar i grup obliczeniowych, oznaczanie tabel dat i ustawianie właściwości modelu i jego obiektów (takich jak formaty kolumn). Można również skonfigurować model zabezpieczenia na poziomie wiersza (RLS), definiując role i reguły, a także dodając członków (kont użytkowników Microsoft Entra lub grup zabezpieczeń) do tych ról.

Alternatywnie możesz kontynuować opracowywanie modelu przy użyciu narzędzia zgodnego ze standardem XMLA, takiego jak SQL Server Management Studio (SSMS) (wersja 19.1 lub nowsza) lub narzędzia społeczności typu open source. Aby uzyskać więcej informacji, zobacz obsługa zapisu modelu przy użyciu punktu końcowego XMLA w dalszej części tego artykułu.

Napiwek

Możesz dowiedzieć się, jak utworzyć usługę Lakehouse, tabelę delta i podstawowy model semantyczny usługi Direct Lake, wykonując czynności tego samouczka.

Tablice modelowe

Tabele modelu są oparte na tabeli lub widoku punktu końcowego analizy SQL. Należy jednak unikać używania widoków, jeśli jest to możliwe. Wynika to z faktu, że zapytania do tabeli modelu oparte na widoku zawsze powrócić do trybu DirectQuery, co może spowodować spowolnienie wydajności zapytań.

Tabele powinny zawierać kolumny do filtrowania, grupowania, sortowania i podsumowywania oprócz kolumn obsługujących relacje modelu. Chociaż niepotrzebne kolumny nie wpływają na wydajność zapytań semantycznych modelu (ponieważ nie zostaną załadowane do pamięci), powodują one większy rozmiar magazynu w usłudze OneLake i wymagają większej ilości zasobów obliczeniowych do załadowania i konserwacji.

Ostrzeżenie

Używanie kolumn stosujących dynamiczne maskowanie danych (DDM) w modelach semantycznych usługi Direct Lake nie jest obsługiwane.

Aby dowiedzieć się, które tabele mają być uwzględniane w modelu semantycznym usługi Direct Lake, zobacz Edit tables for Direct Lake semantic models (Edytowanie tabel dla modeli semantycznych usługi Direct Lake).

Aby uzyskać więcej informacji na temat kolumn do uwzględnienia w tabelach modelu semantycznego, zobacz Zrozumienie przechowywania dla modeli semantycznych Direct Lake.

Wymuszanie reguł dostępu do danych

Jeśli masz wymagania dotyczące dostarczania podzbiorów danych modelu różnym użytkownikom, możesz wymusić reguły dostępu do danych. Reguły są wymuszane przez skonfigurowanie zabezpieczeń na poziomie obiektu (OLS) i/lub zabezpieczeń na poziomie wiersza (RLS) w punkcie końcowym analizy SQL lub w modelu semantycznym.

Uwaga

Temat wymuszania reguł dostępu do danych jest inny, ale związany z ustawianiem uprawnień dla osób zarządzających zawartością, twórców i użytkowników, którzy będą zarządzać modelem semantycznym (i powiązanymi elementami Fabric). Aby uzyskać więcej informacji na temat ustawiania uprawnień, zobacz Zarządzanie modelami semantycznymi usługi Direct Lake.

Zabezpieczenia na poziomie obiektu (OLS)

Usługa OLS obejmuje ograniczenie dostępu do odnajdywania obiektów lub kolumn oraz wykonywania zapytań o nie. Na przykład można użyć usługi OLS, aby ograniczyć użytkowników, którzy mogą uzyskiwać dostęp do kolumny Salary z tabeli Employee.

W przypadku punktu końcowego analizy SQL można skonfigurować OLS, aby kontrolować dostęp do obiektów punktu końcowego, takich jak tabele lub widoki, oraz zabezpieczenie na poziomie kolumn (CLS), aby kontrolować dostęp do kolumn tablic punktu końcowego.

W przypadku modelu semantycznego można skonfigurować usługę OLS, aby kontrolować dostęp do tabel lub kolumn modelu. Aby skonfigurować usługę OLS, musisz użyć narzędzi społeczności typu open source, takich jak Tabular Editor.

Zabezpieczenia na poziomie wiersza

RLS polega na ograniczaniu dostępu do podzbiorów danych w tabelach. Na przykład możesz użyć Zabezpieczeń na Poziomie Rekordów (RLS), aby upewnić się, że sprzedawcy mogą uzyskiwać dostęp tylko do danych sprzedaży dotyczących klientów w ich regionie sprzedaży.

W przypadku punktu końcowego analizy SQL można skonfigurować zabezpieczenia na poziomie wiersza, aby kontrolować dostęp do wierszy w tabeli punktów końcowych.

Ważny

Gdy zapytanie używa dowolnej tabeli z zabezpieczeniami na poziomie wiersza (RLS) w punkcie końcowym analizy SQL (endpoint), powróci do trybu DirectQuery. Wydajność zapytań może być niższa.

W przypadku modelu semantycznego można skonfigurować zabezpieczenia na poziomie wiersza, aby kontrolować dostęp do wierszy w tabelach modelu. Zabezpieczenia na poziomie wiersza można skonfigurować w webowym środowisku modelowania lub za pomocą narzędzia innej firmy.

Jak są oceniane zapytania

Najważniejszym powodem tworzenia modeli semantycznych Direct Lake jest osiągnięcie wysokiej wydajności zapytań dla dużych wolumenów danych w OneLake. W związku z tym należy dążyć do projektowania rozwiązania, które maksymalizuje szanse na wykonywanie zapytań w pamięci.

Poniższe kroki przybliżają sposób oceniania zapytań (i tego, czy kończą się niepowodzeniem). Korzyści wynikające z trybu przechowywania w usłudze Direct Lake są możliwe tylko w przypadku osiągnięcia piątego kroku.

  1. Jeśli zapytanie zawiera dowolną tabelę lub kolumnę, która jest ograniczona przez semantyczny model OLS, zwracany jest wynik błędu (wizualizacja raportu nie będzie renderowana).
  2. Jeśli zapytanie zawiera dowolną kolumnę, która jest ograniczona przez interfejs CLS punktu końcowego analizy SQL (lub tabela zostanie odrzucona), zostanie zwrócony wynik błędu (wizualizacja raportu zakończy się niepowodzeniem renderowania).
    1. Jeśli połączenie w chmurze używa SSO (ustawienie domyślne), CLS jest określany przez poziom dostępu odbiorcy raportu.
    2. Jeśli połączenie w chmurze używa stałej tożsamości, clS jest określany przez poziom dostępu stałej tożsamości.
  3. Jeśli zapytanie zawiera dowolną tabelę w punkcie końcowym analitycznym SQL, która wymusza RLS lub używany jest widok, zapytanie zostaje przełączone na tryb DirectQuery.
    1. Jeśli połączenie w chmurze używa logowania jednokrotnego (ustawienie domyślne), RLS jest określane przez poziom dostępu konsumenta raportu.
    2. Jeśli połączenie w chmurze używa stałej tożsamości, zabezpieczenia na poziomie wiersza (RLS) są określane przez poziom dostępu stałej tożsamości.
  4. Jeśli zapytanie przekracza ograniczenia zasobów, powraca do trybu DirectQuery.
  5. W przeciwnym razie zapytanie jest obsługiwane z pamięci podręcznej w pamięci operacyjnej. Dane kolumny są ładowane do pamięci w razie potrzeby.

Uprawnienia elementu źródłowego

Konto używane do uzyskiwania dostępu do danych jest jednym z następujących elementów.

  • Jeśli połączenie w chmurze używa logowania jednokrotnego (ustawienie domyślne), jest to użytkownik raportu.
  • Jeśli połączenie w chmurze używa stałej tożsamości, jest to stała tożsamość.

Konto musi mieć co najmniej uprawnienia odczytu i ReadData na elemencie źródłowym (lakehouse lub warehouse). Uprawnienia do elementu można dziedziczyć z ról obszaru roboczego lub przypisać jawnie dla elementu zgodnie z opisem w tym artykule.

Zakładając, że to wymaganie jest spełnione, Fabric udostępnia niezbędny dostęp do modelu semantycznego, aby odczytać tabele Delta i powiązane pliki Parquet (w celu ładowania danych kolumnowych do pamięci), a reguły dostępu do danych mogą być zastosowane.

Opcje reguły dostępu do danych

Reguły dostępu do danych można skonfigurować w:

  • Tylko semantyczny model.
  • Tylko punkt końcowy analizy SQL.
  • Zarówno w modelu semantycznym, jak i w punkcie końcowym analizy SQL.

Reguły w modelu semantycznym

Jeśli musisz wymusić reguły dostępu do danych, należy to zrobić w modelu semantycznym zawsze, gdy jest to możliwe. Wynika to z faktu, że zabezpieczenia na poziomie wiersza wymuszane przez model semantyczny są osiągane przez filtrowanie pamięci podręcznej danych w pamięci w celu uzyskania zapytań o wysoką wydajność.

Jest to również odpowiednie podejście, gdy użytkownicy raportów nie otrzymują uprawnień do wykonywania zapytań dotyczących magazynu lub jeziora.

W obu przypadkach zdecydowanie zaleca się, aby połączenie z chmurą używało stałej tożsamości zamiast SSO (logowania jednokrotnego). Logowanie jednokrotne oznaczałoby, że użytkownicy końcowi mogą uzyskiwać bezpośredni dostęp do punktu końcowego analizy SQL i w związku z tym mogą pomijać reguły zabezpieczeń w modelu semantycznym.

Ważny

Uprawnienia elementu modelu semantycznego można jawnie ustawić za pośrednictwem aplikacji usługi Power BIlub uzyskiwanych niejawnie za pośrednictwem ról obszaru roboczego.

W szczególności reguły dostępu do danych modelu semantycznego nie są wymuszane dla użytkowników, którzy mają uprawnienia zapisu w modelu semantycznym. Z kolei reguły dostępu do danych dotyczą użytkowników przypisanych do roli Viewer w obszarze roboczym. Jednak użytkownicy przypisani do roli obszaru roboczego Administratora, Członkalub Współautora niejawnie mają uprawnienia Zapisu w modelu semantycznym, więc reguły dostępu do danych nie są egzekwowane. Aby uzyskać więcej informacji, zobacz Role w obszarach roboczych .

Reguły w punkcie końcowym analizy SQL

Należy wymusić reguły dostępu do danych w punkcie końcowym analizy SQL, gdy połączenie w chmurze modelu semantycznego używa logowania jednokrotnego (SSO) . Dzieje się tak, ponieważ tożsamość użytkownika jest delegowana do wykonywania zapytań dotyczących punktu końcowego analizy SQL, zapewniając, że zapytania zwracają tylko dane, do których użytkownik może uzyskać dostęp. Należy również wymusić reguły dostępu do danych na tym poziomie, gdy użytkownicy będą wysyłać zapytania do punktu końcowego analizy SQL bezpośrednio dla innych obciążeń (na przykład w celu utworzenia raportu podzielonego na strony usługi Power BI lub wyeksportowania danych).

Szczególnie jednak zapytanie semantyczne modelu powróci do trybu DirectQuery, jeśli zawiera tabelę wymuszającą zabezpieczenia na poziomie wiersza w punkcie końcowym analizy SQL. W związku z tym model semantyczny może nigdy nie buforować danych w pamięci, aby umożliwić wysokowydajne zapytania.

Reguły w obu warstwach

Reguły dostępu do danych można wymuszać w obu warstwach. Jednak takie podejście obejmuje dodatkową złożoność i nakład pracy związany z zarządzaniem. W takim przypadku zdecydowanie zaleca się, aby połączenie z chmurą używało stałej tożsamości użytkownika zamiast uwierzytelniania jednokrotnego.

Porównanie opcji reguły dostępu do danych

W poniższej tabeli porównaliśmy opcje konfiguracji dostępu do danych.

Zastosowanie reguł dostępu do danych Komentarz
Tylko model semantyczny Użyj tej opcji, gdy użytkownikom nie nadano uprawnień do korzystania z lakehouse lub magazynu. Skonfiguruj połączenie w chmurze, aby używać stałej tożsamości. Wysoką wydajność zapytań można osiągnąć dzięki pamięci podręcznej.
Tylko punkt końcowy dla analizy SQL Użyj tej opcji, gdy użytkownicy muszą uzyskiwać dostęp do danych z magazynu lub modelu semantycznego oraz z spójnymi regułami dostępu do danych. Upewnij się, że SSO (jednokrotne logowanie) jest włączone dla połączenia w chmurze. Wydajność zapytań może być niska.
Model semantyczny lakehouse lub warehouse i Ta opcja obejmuje dodatkowe nakłady pracy związane z zarządzaniem. Skonfiguruj połączenie w chmurze, aby używać stałej tożsamości.

Poniżej przedstawiono zalecane rozwiązania związane z wymuszaniem reguł dostępu do danych:

  • Jeśli różni użytkownicy muszą być ograniczeni do podzbiorów danych, zawsze gdy jest to możliwe, wymuszaj RLS tylko w warstwie modelu semantycznego. Dzięki temu użytkownicy będą korzystać z zapytań w pamięci o wysokiej wydajności. W takim przypadku zdecydowanie zaleca się, aby połączenie z chmurą korzystało ze stałej tożsamości zamiast uwierzytelniania jednokrotnego.
  • Jeśli to możliwe, unikaj wymuszania OLS i CLS na którymkolwiek z poziomów, ponieważ powoduje to błędy w wizualizacjach raportu. Błędy mogą prowadzić do nieporozumień lub obaw użytkowników. W przypadku kolumn z możliwością podsumowania rozważ utworzenie miar, które zwracają wartość BLANK w określonych warunkach zamiast CLS (jeśli to możliwe).

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

Modele semantyczne usługi Direct Lake obsługują operacje zapisu z punktem końcowym XMLA przy użyciu narzędzi takich jak SSMS (19.1 lub nowsza) oraz narzędzi open source rozwijanych przez społeczność.

Napiwek

Aby uzyskać więcej informacji na temat opracowywania i optymalizowania modeli semantycznych za pomocą narzędzi innych firm, zobacz zaawansowane zarządzanie modelami danych scenariusz użycia.

Zanim będzie można wykonywać operacje zapisu, dla pojemności musi być włączona opcja odczytu i zapisu XMLA. Aby uzyskać więcej informacji, zobacz Włącz XMLA z dostępem do odczytu i zapisu.

Operacje zapisu modelu z obsługą 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. Aby uzyskać więcej informacji, zobacz Zarządzanie cyklem życia zawartości.
  • Zadania automatyzacji, takie jak odświeżanie modelu semantycznego, i stosowanie zmian w modelach semantycznych usługi Direct Lake przy użyciu programu PowerShell i interfejsów API REST.

Podczas zmieniania modelu semantycznego przy użyciu XMLA należy zaktualizować kolekcje ChangedProperties i PBI_RemovedChildren dla zmienionego obiektu, aby zawierały wszelkie zmodyfikowane lub usunięte właściwości. Jeśli nie wykonasz tej aktualizacji, narzędzia do modelowania usługi Power BI mogą zastąpić wszelkie zmiany przy następnej synchronizacji schematu z usługą Lakehouse.

Dowiedz się więcej o tagach genealogii obiektów modelu semantycznego w artykule dotyczącym tagów genealogii dla modeli semantycznych usługi Power BI.

Ważny

Tabele usługi Direct Lake utworzone przy użyciu aplikacji XMLA będą początkowo w stanie nieprzetworzone, dopóki aplikacja nie wyśle polecenia odświeżania. Zapytania obejmujące nieprzetworzone tabele zawsze wracają do trybu DirectQuery. Dlatego podczas tworzenia nowego modelu semantycznego pamiętaj, aby odświeżyć model, aby przetworzyć jego tabele.

Aby uzyskać więcej informacji, zobacz łączność modelu semantycznego z punktem końcowym XMLA .

Metadane modelu usługi Direct Lake

Po nawiązaniu połączenia z semantycznym modelem usługi Direct Lake za pomocą punktu końcowego XMLA metadane wyglądają tak jak w przypadku dowolnego innego modelu. Jednak modele usługi Direct Lake pokazują następujące różnice:

  • Właściwość compatibilityLevel obiektu bazy danych to 1604 (lub wyższa).
  • Właściwość mode partycji Direct Lake jest ustawiona na wartość directLake.
  • Partycje usługi Direct Lake używają wyrażeń udostępnionych do definiowania źródeł danych. Wyrażenie wskazuje punkt końcowy analityczny SQL lakehouse lub warehouse. Usługa Direct Lake używa punktu końcowego analizy SQL do odnajdywania informacji o schemacie i zabezpieczeniach, ale ładuje dane bezpośrednio z usługi OneLake (chyba że powrócić do trybu DirectQuery z jakiegokolwiek powodu).

Zadania po publikacji

Po opublikowaniu modelu semantycznego usługi Direct Lake należy wykonać niektóre zadania konfiguracji. Aby uzyskać więcej informacji, zobacz Zarządzanie modelami semantycznymi usługi Direct Lake.

Nieobsługiwane funkcje

Następujące funkcje modelu nie są obsługiwane przez semantyczne modele usługi Direct Lake:

  • Tabele obliczeniowe odwołujące się do tabel lub kolumn w trybie magazynowania Direct Lake
  • Kolumny obliczeniowe odwołujące się do tabel lub kolumn w trybie przechowywania Direct Lake
  • Tabele hybrydowe
  • Agregacje zdefiniowane przez użytkownika
  • Modele złożone, w których nie można połączyć tabel trybu przechowywania Direct Lake z tabelami trybu przechowywania DirectQuery lub Dual storage mode w tym samym modelu. Można jednak użyć programu Power BI Desktop do utworzenia połączenia na żywo z modelem semantycznym usługi Direct Lake, a następnie rozszerzyć go o nowe miary, a następnie kliknąć opcję , aby wprowadzić zmiany w tym modelu dodać nowe tabele (przy użyciu trybu importu, trybu DirectQuery lub podwójnego magazynu). Ta akcja tworzy połączenie DirectQuery z modelem semantycznym w trybie Direct Lake, przez co tabele są wyświetlane w trybie przechowywania DirectQuery, jednak ten tryb nie wskazuje na powrót do DirectQuery. Połączenie między tym nowym modelem a modelem Direct Lake odbywa się wyłącznie za pomocą DirectQuery, a zapytania nadal korzystają z modelu Direct Lake do pobierania danych z OneLake. Aby uzyskać więcej informacji, zobacz Tworzenie modelu złożonego w modelu semantycznym.
  • Kolumny oparte na kolumnach punktów końcowych analizy SQL, które stosują dynamiczne maskowanie danych.

Powiązana zawartość