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 sieci szkieletowej służy do tworzenia modelu semantycznego usługi Direct Lake w obszarze roboczym. Jest to prosty proces, który polega na wybraniu tabel z pojedynczego magazynu typu lakehouse lub warehouse w celu dodania ich do modelu semantycznego.

Następnie możesz użyć środowiska modelowania internetowego do 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ć zabezpieczenia na poziomie wiersza modelu, definiując role i reguły, a także dodając do tych ról członków (konta użytkowników lub grupy zabezpieczeń firmy Microsoft Entra).

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 z punktem końcowym XMLA w dalszej części tego artykułu.

Napiwek

Aby dowiedzieć się, jak utworzyć usługę Lakehouse, tabelę delty i podstawowy model semantyczny usługi Direct Lake, wykonaj czynności z tego samouczka.

Tabele modelu

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 wracają 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ę, jak wybrać tabele do uwzględnienia w modelu semantycznym usługi Direct Lake, zobacz 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 Omówienie magazynu dla modeli semantycznych usługi 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 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 użytkowników zawartości, twórców i użytkowników, którzy będą zarządzać modelem semantycznym (i powiązanymi elementami sieci szkieletowej). 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. Możesz na przykład użyć usługi OLS, aby ograniczyć użytkowników, którzy mogą uzyskać dostęp do Salary kolumny z Employee tabeli.

W przypadku punktu końcowego analizy SQL można skonfigurować usługę OLS w celu kontrolowania dostępu do obiektów punktu końcowego, takich jak tabele lub widoki, oraz zabezpieczenia na poziomie kolumn (CLS) w celu kontrolowania dostępu do kolumn tabeli punktów końcowych.

W przypadku modelu semantycznego można skonfigurować usługę OLS w celu kontrolowania dostępu 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

Zabezpieczenia na poziomie wiersza obejmują ograniczenie dostępu do podzestawów danych w tabelach. Na przykład możesz użyć zabezpieczeń na poziomie wiersza, aby upewnić się, że sprzedawcy mogą uzyskiwać dostęp tylko do danych sprzedaży dla klientów w ich regionie sprzedaży.

W przypadku punktu końcowego analizy SQL można skonfigurować zabezpieczenia na poziomie wiersza w celu kontrolowania dostępu do wierszy w tabeli punktów końcowych.

Ważne

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

W przypadku modelu semantycznego można skonfigurować zabezpieczenia na poziomie wiersza w celu kontrolowania dostępu do wierszy w tabelach modelu. Zabezpieczenia na poziomie wiersza można skonfigurować w środowisku modelowania internetowego lub za pomocą narzędzia innej firmy.

Jak są oceniane zapytania

Powodem opracowywania modeli semantycznych usługi Direct Lake jest osiągnięcie zapytań o wysoką wydajność w przypadku dużych ilości danych w usłudze 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 logowania jednokrotnego (ustawienie domyślne), clS jest określany przez poziom dostępu użytkownika 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 analizy SQL, która wymusza zabezpieczenia na poziomie wiersza lub widok, zapytanie powraca do trybu DirectQuery.
    1. Jeśli połączenie w chmurze używa logowania jednokrotnego (ustawienie domyślne), zabezpieczenia na poziomie wiersza są określane przez poziom dostępu użytkownika raportu.
    2. Jeśli połączenie w chmurze używa stałej tożsamości, zabezpieczenia na poziomie wiersza są określane przez poziom dostępu stałej tożsamości.
  4. Jeśli zapytanie przekracza bariery ochronne pojemności, powraca do trybu DirectQuery.
  5. W przeciwnym razie zapytanie jest zadowalające z pamięci podręcznej w pamięci. Dane kolumn są ładowane do pamięci jako i wtedy, gdy są wymagane.

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 Odczyt i OdczytData w elemencie źródłowym (lakehouse lub warehouse). Uprawnienia do elementu mogą być dziedziczone z ról obszaru roboczego lub przypisane jawnie dla elementu zgodnie z opisem w tym artykule.

Zakładając, że to wymaganie jest spełnione, sieć szkieletowa udziela niezbędnego dostępu do modelu semantycznego w celu odczytania tabel delty i skojarzonych plików Parquet (w celu załadowania danych kolumny do pamięci) i można zastosować reguły dostępu do danych.

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 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żne

Uprawnienia elementu modelu semantycznego można ustawić jawnie za pośrednictwem aplikacji usługi Power BI lub uzyskać 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 do zapisu w modelu semantycznym. Z drugiej strony reguły dostępu do danych mają zastosowanie do użytkowników przypisanych do roli obszaru roboczego Osoba przeglądająca . Jednak użytkownicy przypisani do roli obszaru roboczego Administrator, Członek lub Współautor niejawnie mają uprawnienia do zapisu w modelu semantycznym, dlatego reguły dostępu do danych nie są wymuszane. 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 z chmurą modelu semantycznego korzysta z logowania jednokrotnego. 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 do pamięci w celu uzyskania zapytań o wysoką wydajność.

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 zamiast logowania jednokrotnego.

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

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

Stosowanie reguł dostępu do danych do Komentarz
Tylko model semantyczny Użyj tej opcji, jeśli użytkownicy nie otrzymują uprawnień do elementu w celu wykonywania zapytań dotyczących magazynu lub lakehouse. Skonfiguruj połączenie w chmurze, aby używać stałej tożsamości. Wysoką wydajność zapytań można osiągnąć z pamięci podręcznej w pamięci.
Tylko punkt końcowy 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 logowanie jednokrotne jest włączone dla połączenia w chmurze. Wydajność zapytań może być niska.
Lakehouse lub magazyn i semantyczny model 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, wymuszanie zabezpieczeń na poziomie wiersza tylko w warstwie modelu semantycznego. Dzięki temu użytkownicy będą korzystać z zapytań o wysoką wydajność w pamięci. W takim przypadku zdecydowanie zaleca się, aby połączenie z chmurą używało stałej tożsamości zamiast logowania jednokrotnego.
  • Jeśli to możliwe, unikaj wymuszania olS i CLS w obu warstwach, 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ędzia społeczności typu open source.

Napiwek

Aby uzyskać więcej informacji na temat używania narzędzi innych firm do tworzenia modeli semantycznych, zarządzania nimi lub optymalizowania, zobacz zaawansowany scenariusz użycia zarządzania modelami danych.

Aby można było wykonywać operacje zapisu, dla pojemności musi być włączona opcja odczytu i zapisu XMLA. Aby uzyskać więcej informacji, zobacz Włączanie odczytu i zapisu XMLA.

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ć kolekcję ChangedProperties i PBI_RemovedChildren , aby zmieniony obiekt zawierał 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.

Obsługiwane modele zmiany modelu semantycznego przy użyciu xmlA są następujące:

  • Nazwa tabeli/kolumny (ChangeProperty = name)
  • Usuń tabelę (dodaj tabelę do adnotacji PBI_RemovedChildren w wyrażeniu zapytania)

Ważne

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 Semantic model connectivity with the XMLA endpoint (Łą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 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 w magazynie typu 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 z jakiegokolwiek powodu powróci do trybu DirectQuery ).

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 przechowywania usługi Direct Lake
  • Kolumny obliczeniowe odwołujące się do tabel lub kolumn w trybie przechowywania usługi Direct Lake
  • Tabele hybrydowe
  • Agregacje zdefiniowane przez użytkownika
  • Modele złożone, w tym przypadku nie można połączyć tabel trybu przechowywania Direct Lake z tabelami trybu przechowywania DirectQuery lub Podwójne w tym samym modelu. Można jednak użyć programu Power BI Desktop, aby utworzyć połączenie na żywo z modelem semantycznym usługi Direct Lake, a następnie rozszerzyć go na nowe miary, a następnie kliknąć opcję, aby wprowadzić zmiany w tym modelu, aby dodać nowe tabele (przy użyciu trybu Importuj, DirectQuery lub Podwójny). Ta akcja tworzy połączenie DirectQuery z modelem semantycznym w trybie Direct Lake, więc tabele są wyświetlane jako tryb przechowywania DirectQuery, ale ten tryb przechowywania nie wskazuje powrotu do trybu DirectQuery. Tylko połączenie między tym nowym modelem a modelem Direct Lake to DirectQuery, a zapytania nadal używają usługi Direct Lake do pobierania danych z usługi OneLake. Aby uzyskać więcej informacji, zobacz Tworzenie modelu złożonego na modelu semantycznym.
  • Kolumny oparte na kolumnach punktów końcowych analizy SQL, które stosują dynamiczne maskowanie danych.

Powiązana zawartość