Udostępnij za pośrednictwem

Zarządzanie modelami semantycznymi usługi Direct Lake

  • Artykuł

W tym artykule opisano tematy projektowe związane z zarządzaniem modelami semantycznymi usługi Direct Lake.

Zadania po publikacji

Po pierwszym opublikowaniu modelu semantycznego usługi Direct Lake gotowym do raportowania należy natychmiast wykonać niektóre zadania po opublikowaniu. Te zadania można również dostosować w dowolnym momencie w cyklu życia modelu semantycznego.

Opcjonalnie możesz również skonfigurować odnajdywanie danych, aby umożliwić twórcom raportów odczytywanie metadanych, pomagając im odnajdywać dane w centrum danych OneLake i żądać dostępu do niego. Możesz również zatwierdzić (certyfikowany lub promowany) model semantyczny, aby poinformować, że reprezentuje dane dotyczące jakości do użycia.

Konfigurowanie połączenia w chmurze

Model semantyczny usługi Direct Lake używa połączenia w chmurze w celu nawiązania połączenia z punktem końcowym analizy SQL. Umożliwia ona dostęp do danych źródłowych, czyli plików Parquet w trybie magazynowania OneLake (tryb przechowywania Direct Lake, który obejmuje ładowanie danych kolumn do pamięci) lub punkt końcowy analizy SQL (gdy zapytania wracają do trybu DirectQuery).

Domyślne połączenie w chmurze

Podczas tworzenia modelu semantycznego usługi Direct Lake jest używane domyślne połączenie w chmurze. Korzysta z logowania jednokrotnego (SSO), co oznacza, że tożsamość, która wysyła zapytanie do modelu semantycznego (często użytkownika raportu) jest używana do wykonywania zapytań dotyczących danych punktu końcowego analizy SQL.

Połączenie z chmurą z możliwością udostępniania

Opcjonalnie można utworzyć połączenie chmury z możliwością udostępniania (SCC), aby można było nawiązać połączenia ze źródłem danych przy użyciu stałej tożsamości. Może to pomóc klientom korporacyjnym chronić swoje magazyny danych organizacji. Dział IT może zarządzać poświadczeniami, tworzyć scCs i udostępniać je twórcom przeznaczonym do scentralizowanego zarządzania dostępem.

Aby skonfigurować stałą tożsamość, zobacz Określanie stałej tożsamości dla modelu semantycznego usługi Direct Lake.

Uwierzytelnianie

Stała tożsamość może uwierzytelniać się przy użyciu protokołu OAuth 2.0 lub jednostki usługi.

Uwaga

Obsługiwane jest tylko uwierzytelnianie entra firmy Microsoft. W związku z tym uwierzytelnianie podstawowe nie jest obsługiwane w przypadku modeli semantycznych usługi Direct Lake.

OAuth 2.0

W przypadku korzystania z protokołu OAuth 2.0 można uwierzytelnić się przy użyciu konta użytkownika Microsoft Entra. Konto użytkownika musi mieć uprawnienia do wykonywania zapytań dotyczących tabel i widoków punktów końcowych analizy SQL oraz metadanych schematu.

Korzystanie z określonego konta użytkownika nie jest zalecaną praktyką. Wynika to z faktu, że zapytania modelu semantycznego kończą się niepowodzeniem w przypadku zmiany hasła lub usunięcia konta użytkownika (na przykład po opuszczeniu organizacji przez pracownika).

Jednostka usługi

Uwierzytelnianie za pomocą jednostki usługi jest zalecaną praktyką, ponieważ nie zależy od określonego konta użytkownika. Podmiot zabezpieczeń musi mieć uprawnienia do wykonywania zapytań dotyczących tabel i widoków punktów końcowych analizy SQL oraz metadanych schematu.

W celu zapewnienia ciągłości poświadczenia jednostki usługi mogą być zarządzane przez rotację wpisów tajnych/certyfikatów.

Uwaga

Ustawienia dzierżawy sieci szkieletowej muszą zezwalać na jednostki usługi, a jednostka usługi musi należeć do zadeklarowanej grupy zabezpieczeń.

Logowanie jednokrotne

Podczas tworzenia połączenia z chmurą z możliwością udostępniania pole wyboru Logowanie jednokrotne jest domyślnie niezaznaczone. Jest to prawidłowa konfiguracja w przypadku korzystania z stałej tożsamości.

Możesz włączyć logowanie jednokrotne, jeśli chcesz, aby tożsamość, która wysyła zapytanie do modelu semantycznego, również wysyłać zapytania do punktu końcowego analizy SQL. W tej konfiguracji model semantyczny usługi Direct Lake będzie używać stałej tożsamości do odświeżania modelu i tożsamości użytkownika w celu wykonywania zapytań dotyczących danych.

W przypadku używania stałej tożsamości często zdarza się wyłączyć logowanie jednokrotne, tak aby stała tożsamość była używana zarówno na potrzeby odświeżeń, jak i zapytań, ale nie ma potrzeby technicznego.

Poniżej przedstawiono zalecane rozwiązania związane z połączeniami w chmurze:

  • Gdy wszyscy użytkownicy mogą uzyskiwać dostęp do danych (i mają do tego uprawnienia), nie ma potrzeby tworzenia udostępnionego połączenia w chmurze. Zamiast tego można użyć domyślnych ustawień połączenia w chmurze. W takim przypadku tożsamość użytkownika, który wykonuje zapytania dotyczące modelu, powinna wrócić do trybu DirectQuery.
  • Utwórz połączenie w chmurze udostępnionej, jeśli chcesz użyć stałej tożsamości do wykonywania zapytań dotyczących danych źródłowych. Może to być spowodowane tym, że użytkownicy, którzy wysyłają zapytania do modelu semantycznego, nie mają uprawnień do odczytu magazynu lub magazynu typu lakehouse. Takie podejście jest szczególnie istotne, gdy model semantyczny wymusza zabezpieczenia na poziomie wiersza.
  • Jeśli używasz stałej tożsamości, użyj opcji Jednostka usługi , ponieważ jest ona bezpieczniejsza i niezawodna. Dzieje się tak, ponieważ nie polega na jednym koncie użytkownika ani jego uprawnieniach i nie będzie wymagać konserwacji (i zakłóceń) w przypadku zmiany hasła ani opuszczenia organizacji.
  • Jeśli różni użytkownicy muszą mieć ograniczony dostęp tylko do podzestawów danych, jeśli są to możliwe, wymusić zabezpieczenia na poziomie wiersza tylko w warstwie modelu semantycznego. Dzięki temu użytkownicy będą korzystać z zapytań o wysoką wydajność w pamięci.
  • Jeśli to możliwe, unikaj olS i CLS, ponieważ powoduje błędy w wizualizacjach raportu. Błędy mogą powodować zamieszanie lub obawy 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).

Zarządzanie członkostwem roli zabezpieczeń

Jeśli model semantyczny usługi Direct Lake wymusza zabezpieczenia na poziomie wiersza, może być konieczne zarządzanie członkami przypisanymi do ról zabezpieczeń. Aby uzyskać więcej informacji, zobacz Zarządzanie zabezpieczeniami w modelu.

Ustawianie uprawnień elementu sieci szkieletowej

Modele semantyczne usługi Direct Lake są zgodne z modelem zabezpieczeń warstwowych. Wykonują kontrole uprawnień za pośrednictwem punktu końcowego analizy SQL, aby określić, czy tożsamość próbująca uzyskać dostęp do danych ma niezbędne uprawnienia dostępu do danych.

Musisz udzielić użytkownikom uprawnień, aby mogli używać modelu semantycznego usługi Direct Lake lub zarządzać nim. Krótko mówiąc, użytkownicy raportów potrzebują uprawnień do odczytu , a twórcy raportów potrzebują uprawnień do tworzenia . Uprawnienia modelu semantycznego można przypisać bezpośrednio lub uzyskać niejawnie za pośrednictwem 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.

W zależności od konfiguracji połączenia w chmurze oraz tego, czy użytkownicy muszą wykonywać zapytania dotyczące usługi Lakehouse, czy punktu końcowego analizy SQL magazynu, może być konieczne przyznanie innych uprawnień (opisanych w tabeli w tej sekcji).

Uwaga

W szczególności użytkownicy nie wymagają uprawnień do odczytu danych w usłudze OneLake. Dzieje się tak dlatego, że sieć szkieletowa udziela niezbędnych uprawnień do modelu semantycznego w celu odczytania tabel delty i skojarzonych 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ść).

Weź pod uwagę następujące scenariusze i wymagania dotyczące uprawnień.

Scenariusz Wymagane uprawnienia Komentarze
Użytkownicy mogą wyświetlać raporty • Udziel uprawnień do odczytu dla raportów i uprawnienia Odczyt dla modelu semantycznego.
• Jeśli połączenie z chmurą korzysta z logowania jednokrotnego, przyznaj co najmniej uprawnienie do odczytu dla magazynu lub lakehouse.		 Raporty nie muszą należeć do tego samego obszaru roboczego co model semantyczny. Aby uzyskać więcej informacji, zobacz Strategia dla użytkowników tylko do odczytu.
Użytkownicy mogą tworzyć raporty • Udziel uprawnień do tworzenia dla modelu semantycznego.
• Jeśli połączenie z chmurą korzysta z logowania jednokrotnego, przyznaj co najmniej uprawnienie do odczytu dla magazynu lub lakehouse.		 Aby uzyskać więcej informacji, zobacz Strategia dla twórców zawartości.
Użytkownicy mogą wykonywać zapytania dotyczące modelu semantycznego, ale odrzucają wykonywanie zapytań dotyczących punktu końcowego analizy typu lakehouse lub SQL • Nie udzielaj żadnych uprawnień do jeziora ani magazynu. Odpowiednie tylko wtedy, gdy połączenie w chmurze używa stałej tożsamości.
Użytkownicy mogą wykonywać zapytania dotyczące modelu semantycznego i punktu końcowego analizy SQL, ale odrzucają wykonywanie zapytań względem usługi Lakehouse • Przyznaj uprawnienia Odczyt i OdczytData dla magazynu lub lakehouse. Ważne: Zapytania wysyłane do punktu końcowego analizy SQL pomijają uprawnienia dostępu do danych wymuszane przez model semantyczny.
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żne

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).

Odświeżanie modeli semantycznych usługi Direct Lake

Odświeżanie modelu semantycznego usługi Direct Lake powoduje operację tworzenia ramek . Można wyzwolić operację odświeżania:

Automatyczne aktualizacje

Istnieje semantyczne ustawienie na poziomie modelu o nazwie Zachowaj aktualność danych usługi Direct Lake, które wykonuje automatyczne aktualizacje tabel usługi Direct Lake. Jest domyślnie włączony. Dzięki temu zmiany danych w usłudze OneLake zostaną automatycznie odzwierciedlone w modelu semantycznym usługi Direct Lake. Ustawienie jest dostępne w portalu sieci szkieletowej w sekcji Odświeżanie ustawień modelu semantycznego.

Po włączeniu ustawienia semantyczny model wykonuje operację tworzenia ramek za każdym razem, gdy zostaną wykryte modyfikacje danych w bazowych tabelach delty. Operacja tworzenia ramek jest zawsze specyficzna tylko dla tych tabel, w których wykryto modyfikacje danych.

Zalecamy pozostawienie ustawienia włączonego, szczególnie w przypadku modelu semantycznego o małych lub średnich rozmiarach. Jest to szczególnie przydatne, gdy wymagania dotyczące raportowania o małych opóźnieniach i tabele delty są regularnie modyfikowane.

W niektórych sytuacjach możesz wyłączyć aktualizacje automatyczne. Na przykład może być konieczne zezwolenie na ukończenie zadań przygotowywania danych lub procesu ETL przed udostępnieniem nowych danych konsumentom modelu semantycznego. Po wyłączeniu można wyzwolić odświeżanie przy użyciu metody programowej (opisanej wcześniej).

Uwaga

Usługa Power BI zawiesza aktualizacje automatyczne, gdy podczas odświeżania wystąpi błąd niemożliwy do odzyskania. Może wystąpić błąd niemożliwy do odzyskania, na przykład w przypadku niepowodzenia odświeżania po kilku próbach. Upewnij się więc, ż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 na żądanie bez błędów.

Rozgrzej pamięć podręczną

Operacja odświeżania modelu semantycznego usługi Direct Lake może wykluczyć wszystkie kolumny rezydentne z pamięci. Oznacza to, że pierwsze zapytania po odświeżeniu modelu semantycznego usługi Direct Lake mogą mieć pewne opóźnienie, ponieważ kolumny są ładowane do pamięci. Opóźnienia mogą być zauważalne tylko wtedy, gdy masz bardzo duże ilości danych.

Aby uniknąć takich opóźnień, rozważ rozgrzewanie pamięci podręcznej przez programowe wysyłanie zapytania do modelu semantycznego. Wygodnym sposobem wysyłania zapytania jest użycie linku semantycznego. Ta operacja powinna być wykonywana natychmiast po zakończeniu operacji odświeżania.

Ważne

Ocieplenie pamięci podręcznej może mieć sens tylko wtedy, gdy opóźnienia są niedopuszczalne. Nie należy niepotrzebnie ładować danych do pamięci, które mogą wywierać presję na inne obciążenia pojemności, powodując ograniczenie przepustowości lub przestarzałe.

Ustawianie właściwości zachowania usługi Direct Lake

Rezerwowe modele semantyczne usługi Direct Lake można kontrolować, ustawiając jej DirectLakeBehavior właściwość. Można go ustawić na:

  • Automatyczne: (domyślne) Zapytania wracają do trybu DirectQuery, jeśli wymagane dane nie mogą być efektywnie ładowane do pamięci.
  • DirectLakeOnly: wszystkie zapytania używają tylko trybu przechowywania 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.
  • DirectQueryOnly: wszystkie zapytania używają tylko trybu DirectQuery. To ustawienie służy do testowania wydajności rezerwowej, gdzie na przykład można obserwować wydajność zapytań w połączonych raportach.

Właściwość można ustawić w środowisku modelowania internetowego lub za pomocą tabelarycznego modelu obiektów (TOM) lub języka TMSL (Tabular Model Scripting Language).

Napiwek

Rozważ wyłączenie rezerwowego trybu DirectQuery, jeśli chcesz przetwarzać zapytania tylko w trybie przechowywania w usłudze Direct Lake. Zalecamy wyłączenie rezerwowego, gdy nie chcesz wracać do trybu DirectQuery. Przydatne może być również analizowanie przetwarzania zapytań dla modelu semantycznego usługi Direct Lake w celu określenia, czy i jak często występuje rezerwowy.

Monitorowanie modeli semantycznych usługi Direct Lake

Można monitorować model semantyczny usługi Direct Lake, aby określić wydajność zapytań języka DAX wizualizacji raportu lub określić, kiedy wraca do trybu DirectQuery.

Możesz użyć Analizator wydajności, programu SQL Server Profiler, usługi Azure Log Analytics lub narzędzia społeczności typu open source, takiego jak DAX Studio.

Performance Analyzer

Możesz użyć Analizator wydajności w programie Power BI Desktop, aby zarejestrować czas przetwarzania wymagany do zaktualizowania elementów raportu zainicjowanych w wyniku dowolnej interakcji użytkownika, która powoduje uruchomienie zapytania. Jeśli wyniki monitorowania pokazują metrykę Zapytania bezpośrednie, oznacza to, że zapytania języka DAX zostały przetworzone w trybie DirectQuery. W przypadku braku tej metryki zapytania języka DAX zostały przetworzone w trybie Direct Lake.

Aby uzyskać więcej informacji, zobacz Analizowanie przy użyciu Analizator wydajności.

SQL Server Profiler

Program SQL Server Profiler umożliwia pobieranie szczegółowych informacji o wydajności zapytań przez śledzenie zdarzeń zapytań. Jest on instalowany przy użyciu programu SQL Server Management Studio (SSMS). Przed rozpoczęciem upewnij się, że masz zainstalowaną najnowszą wersję programu SSMS.

Aby uzyskać więcej informacji, zobacz Analizowanie przy użyciu programu SQL Server Profiler.

Ważne

Ogólnie rzecz biorąc, tryb przechowywania w usłudze Direct Lake zapewnia szybką wydajność zapytań, chyba że konieczne jest powrót do trybu DirectQuery. Ponieważ powrót do trybu DirectQuery może mieć wpływ na wydajność zapytań, ważne jest analizowanie przetwarzania zapytań dla modelu semantycznego usługi Direct Lake w celu określenia, czy, jak często i dlaczego występują rezerwowe.

Dziennik analizy Azure

Usługi Azure Log Analytics można używać do zbierania, analizowania i działania na danych telemetrycznych skojarzonych z modelem semantycznym usługi Direct Lake. Jest to usługa w usłudze Azure Monitor, której usługa Power BI używa do zapisywania dzienników aktywności.

Aby uzyskać więcej informacji, zobacz Korzystanie z usługi Azure Log Analytics w usłudze Power BI.

Powiązana zawartość