Udostępnij za pośrednictwem

Planowanie implementacji usługi Power BI: inspekcja na poziomie danych

  • Artykuł

Uwaga

Ten artykuł stanowi część serii artykułów dotyczących planowania implementacji usługi Power BI. Ta seria koncentruje się głównie na środowisku usługi Power BI w usłudze Microsoft Fabric. Aby zapoznać się z wprowadzeniem do serii, zobacz Planowanie implementacji usługi Power BI.

Ten artykuł dotyczący inspekcji na poziomie danych jest przeznaczony dla wielu odbiorców:

  • Twórcy danych i administratorzy obszarów roboczych: użytkownicy, którzy muszą zrozumieć użycie, wdrożenie i wydajność modeli semantycznych (wcześniej znanych jako zestawy danych), przepływy danych imarty danych, które tworzą, publikują i udostępniają.
  • Administratorzy usługi Power BI: administratorzy, którzy są odpowiedzialni za nadzorowanie usługi Power BI w organizacji. Administratorzy usługi Power BI mogą wymagać współpracy z zespołami IT, zabezpieczeniami, inspekcją wewnętrzną i innymi odpowiednimi zespołami. Administratorzy usługi Power BI mogą również wymagać współpracy z twórcami zawartości podczas rozwiązywania problemów z wydajnością.
  • Administratorzy pojemności usługi Power BI: administratorzy odpowiedzialni za nadzorowanie pojemności Premium w organizacji. Administratorzy pojemności usługi Power BI mogą wymagać współpracy z twórcami zawartości podczas rozwiązywania problemów z wydajnością.
  • Centrum doskonałości, IT i zespół ds. analizy biznesowej: zespoły, które są również odpowiedzialne za nadzorowanie usługi Power BI. Może być konieczne współpraca z administratorami usługi Power BI i innymi odpowiednimi zespołami.
  • Administratorzy systemu: zespół odpowiedzialny za tworzenie i zabezpieczanie zasobów usługi Azure Log Analytics oraz administratorów baz danych, którzy zarządzają źródłami danych.

Ważne

Czasami w tym artykule opisano usługę Power BI Premium lub jej subskrypcje pojemności (jednostki SKU P). Należy pamiętać, że firma Microsoft obecnie konsoliduje opcje zakupu i cofnie usługę Power BI Premium na jednostki SKU pojemności. Nowi i istniejący klienci powinni rozważyć zakup subskrypcji pojemności sieci szkieletowej (jednostki SKU F).

Aby uzyskać więcej informacji, zobacz Ważne aktualizacje dostępne w licencjonowaniu usługi Power BI Premium i Power BI Premium — często zadawane pytania.

Pojęcia omówione w tym artykule dotyczą głównie rozwiązań utworzonych dla trzech zakresów dostarczania zawartości, w szczególności analizy biznesowej przedsiębiorstwa, analizy biznesowej dla działów i analizy biznesowej zespołu. Twórcy rozwiązań do analizy biznesowej osobistej mogą również znaleźć informacje w tym artykule; jednak nie są one podstawowym celem.

Osiągnięcie dobrej wydajności w raportach i wizualizacjach nie jest możliwe, gdy bazowy model semantyczny i/lub źródło danych nie działa dobrze. Ten artykuł koncentruje się na inspekcji i monitorowaniu modeli semantycznych, przepływów danych imartów danych. Jest to drugi artykuł z serii inspekcji i monitorowania, ponieważ narzędzia i techniki są bardziej złożone niż opisane w artykule Dotyczącym inspekcji na poziomie raportu. Najlepiej jest utworzyć udostępnione modele semantyczne (przeznaczone do ponownego użycia między wieloma raportami), zanim użytkownicy będą tworzyć raporty. W związku z tym zalecamy przeczytanie tego artykułu wraz z artykułem Dotyczącym inspekcji na poziomie raportu.

Ponieważ semantyczne modele usługi Power BI są oparte na akompaniamencie tabelarycznym usług Analysis Services, można nawiązać połączenie z lokalnym modelem danych (w programie Power BI Desktop) lub semantycznym modelem Premium (w usługa Power BI), tak jakby była to baza danych usług Analysis Services. W związku z tym wiele funkcji inspekcji i monitorowania usług Analysis Services jest obsługiwanych w przypadku modeli semantycznych usługi Power BI Premium.

Uwaga

Aby uzyskać więcej informacji na temat modeli hostowanych w usługach Analysis Services, zobacz Omówienie monitorowania.

Pozostała część tego artykułu koncentruje się głównie na modelach opublikowanych w usługa Power BI.

Dzienniki zdarzeń modelu semantycznego

Wraz z upływem czasu twórcy danych i właściciele mogą napotkać sytuacje z modelami semantycznymi. Model semantyczny może:

Aby zapewnić użyteczność, dobrą wydajność i przyjęcie tworzonej zawartości, należy przeprowadzić inspekcję użycia i wydajności zasobów danych, którymi odpowiadasz za zarządzanie. Dzienniki zdarzeń zestawu danych umożliwiają przechwytywanie działań generowanych przez użytkownika i generowanych przez system dla modelu semantycznego. Są one również nazywane zdarzeniami śledzenia, dziennikami zestawów danych lub dziennikami aktywności zestawu danych. Administratorzy systemu często nazywają je zdarzeniami śledzenia niskiego poziomu, ponieważ są one szczegółowe.

Uwaga

Zmiana nazwy zestawu danych została wdrożona w usługa Power BI i w dokumentacji, chociaż mogą istnieć pewne wystąpienia , takie jak w przypadku operacji dziennika zdarzeń, w których zmiana jeszcze nie wystąpiła.

Należy przeanalizować zdarzenia śledzenia semantycznego modelu w celu:

  • Przeprowadź inspekcję wszystkich działań, które wystąpiły w modelu semantycznym.
  • Rozwiązywanie problemów i optymalizowanie wydajności modelu semantycznego, użycia pamięci i wydajności zapytań.
  • Zbadaj szczegóły i czas trwania odświeżania modelu semantycznego.
  • Monitoruj język formuł Power Query (zapytania M) wysyłane przez dodatek Power Query.
  • Monitorowanie formuł i wyrażeń języka DAX wysyłanych do modelu semantycznego (aparatu usług Analysis Services).
  • Sprawdź, czy wybrano prawidłowy tryb przechowywania na podstawie obciążeń, oraz konieczność zrównoważenia nowych danych i optymalnej wydajności.
  • Przeprowadź inspekcję wywoływanych ról zabezpieczeń na poziomie wiersza, dla których użytkowników i dla których modeli semantycznych.
  • Omówienie liczby równoczesnych użytkowników.
  • Zweryfikuj model semantyczny (na przykład w celu zweryfikowania jakości i wydajności danych przed wdrożeniem modelu semantycznego lub przed opublikowaniem go w produkcyjnym obszarze roboczym).

Zdarzenia generowane przez model semantyczny usługi Power BI pochodzą z istniejących dzienników diagnostycznych dostępnych dla usług Azure Analysis Services. Istnieje wiele typów zdarzeń śledzenia, które można przechwycić i przeanalizować, które opisano w poniższych sekcjach.

Dziennik analizy Azure

Azure Log Analytics jest składnikiem usługi Azure Monitor . Integracja usługi Azure Log Analytics z usługą Power BI umożliwia przechwytywanie zdarzeń modelu semantycznego ze wszystkich semantycznych modeli w obszarze roboczym usługi Power BI. Jest obsługiwana tylko w przypadku obszarów roboczych Premium. Po skonfigurowaniu integracji i włączeniu połączenia (w obszarze roboczym usługi Power BI Premium) zdarzenia modelu semantycznego są automatycznie przechwytywane i stale wysyłane do obszaru roboczego usługi Azure Log Analytics. Dzienniki modelu semantycznego są przechowywane w usłudze Azure Data Explorer, która jest bazą danych tylko do dołączania zoptymalizowaną pod kątem przechwytywania dużych ilości danych telemetrycznych niemal w czasie rzeczywistym.

Obszar roboczy usługi Power BI Premium można przypisać do obszaru roboczego usługi Log Analytics na platformie Azure. Aby włączyć ten typ rejestrowania, musisz utworzyć nowy zasób usługi Log Analytics w subskrypcji platformy Azure.

Dzienniki z co najmniej jednego obszaru roboczego usługi Power BI zostaną wysłane do docelowego obszaru roboczego usługi Log Analytics. Poniżej przedstawiono kilka sposobów organizowania danych.

  • Jeden docelowy obszar roboczy dla wszystkich danych inspekcji: przechowuj wszystkie dane w jednym obszarze roboczym usługi Log Analytics. Jest to przydatne, gdy ten sam administrator lub użytkownicy będą uzyskiwać dostęp do wszystkich danych.
  • Docelowe obszary robocze uporządkowane według obszaru tematu: organizowanie zawartości według obszaru tematu. Ta technika jest szczególnie przydatna, gdy różni administratorzy lub użytkownicy mogą uzyskiwać dostęp do danych inspekcji z usługi Azure Log Analytics. Na przykład w przypadku konieczności segregowania danych sprzedaży z danych operacyjnych.
  • Jeden docelowy obszar roboczy dla każdego obszaru roboczego usługi Power BI: skonfiguruj relację jeden do jednego między obszarem roboczym usługi Power BI a obszarem roboczym usługi Azure Log Analytics. Jest to przydatne, gdy masz szczególnie wrażliwą zawartość lub gdy dane podlegają określonym wymaganiom dotyczącym zgodności lub przepisów.

Napiwek

Dokładnie zapoznaj się z dokumentacją i często zadawanymi pytaniami dotyczącymi tej funkcji, aby wyjaśnić, co jest możliwe i czy rozumiesz wymagania techniczne. Przed udostępnieniem tej funkcji administratorom obszarów roboczych w organizacji rozważ przeprowadzenie weryfikacji technicznej koncepcji z jednym obszarem roboczym usługi Power BI.

Ważne

Chociaż nazwy są podobne, dane przechwycone przez usługę Azure Log Analytics nie są takie same jak dziennik aktywności usługi Power BI. Usługa Azure Log Analytics przechwytuje zdarzenia śledzenia na poziomie szczegółów z aparatu usług Analysis Services. Jedynym celem jest ułatwienie analizowania i rozwiązywania problemów z wydajnością modelu semantycznego. Jego zakres jest na poziomie obszaru roboczego. Z drugiej strony celem dziennika aktywności jest pomoc w zrozumieniu, jak często występują pewne działania użytkownika (takie jak edytowanie raportu, odświeżanie modelu semantycznego lub tworzenie aplikacji). Jego zakres to cała dzierżawa usługi Power BI.

Aby uzyskać więcej informacji na temat działań użytkownika, które można przeprowadzić inspekcję dla dzierżawy usługi Power BI, zobacz Inspekcja na poziomie dzierżawy.

Połączenie usługi Azure Log Analytics dla administratorówobszaru roboczego określa, które grupy użytkowników (którzy mają również niezbędną rolę administratora obszaru roboczego) mogą połączyć obszar roboczy usługi Power BI z istniejącym obszarem roboczym usługi Azure Log Analytics.

Aby można było skonfigurować integrację, należy spełnić wymagania wstępne dotyczące zabezpieczeń. W związku z tym rozważ włączenie ustawienia dzierżawy usługi Power BI tylko dla administratorów obszarów roboczych usługi Power BI, którzy mają również wymagane uprawnienia w usłudze Azure Log Analytics lub którzy mogą uzyskać te uprawnienia na żądanie.

Napiwek

Współpraca z administratorem platformy Azure na wczesnym etapie procesu planowania, szczególnie w przypadku uzyskania zatwierdzenia utworzenia nowego zasobu platformy Azure jest wyzwaniem w organizacji. Należy również zaplanować wymagania wstępne dotyczące zabezpieczeń. Zdecyduj, czy przyznać uprawnienia administratorowi obszaru roboczego usługi Power BI na platformie Azure, czy też przyznać uprawnienia administratorowi platformy Azure w usłudze Power BI.

Dzienniki modelu semantycznego przechwycone przez usługę Azure Log Analytics obejmują zapytania dotyczące modelu semantycznego, statystyki zapytań, szczegółowe działanie odświeżania, czas procesora CPU zużywany w pojemnościach Premium i nie tylko. Ponieważ są to dzienniki na poziomie szczegółowym z aparatu usług Analysis Services, dane mogą być pełne. Duże ilości danych są wspólne dla dużych obszarów roboczych, które mają duże działanie modelu semantycznego.

Aby zoptymalizować koszty podczas korzystania z usługi Azure Log Analytics w usłudze Power BI:

  • Połączenie obszarów roboczych usługi Power BI do usługi Azure Log Analytics tylko wtedy, gdy aktywnie rozwiązujesz problemy, testowanie, optymalizowanie lub badanie aktywności modelu semantycznego. Po nawiązaniu połączenia śledzenie jest uruchamiane we wszystkich semantycznych modelach w obszarze roboczym.
  • Odłącz usługę Azure Log Analytics od obszaru roboczego usługi Power BI, gdy nie musisz już aktywnie rozwiązywać problemów, testować, optymalizować lub badać działania modelu semantycznego. Rozłączając się, przerywasz działanie śledzenia we wszystkich semantycznych modelach w obszarze roboczym.
  • Upewnij się, że rozumiesz model kosztów dotyczący sposobu, w jaki usługa Azure Log Analytics rozlicza za pozyskiwanie danych, magazyn i zapytania.
  • Nie przechowuj danych w usłudze Log Analytics dłużej niż domyślny 30-dniowy okres przechowywania. Dzieje się tak, ponieważ analiza modelu semantycznego zwykle koncentruje się na natychmiastowych działaniach związanych z rozwiązywaniem problemów.

Istnieje kilka sposobów uzyskiwania dostępu do zdarzeń wysyłanych do usługi Azure Log Analytics. Możesz użyć:

  • Wstępnie utworzona aplikacja szablonu Usługi Log Analytics dla modeli semantycznych usługi Power BI.
  • Łącznik programu Power BI Desktop dla usługi Azure Data Explorer (Kusto). Użyj język zapytań Kusto (KQL), aby przeanalizować dane przechowywane w usłudze Log Analytics. Jeśli masz środowisko zapytań SQL, znajdziesz wiele podobieństw do języka KQL.
  • Środowisko zapytań internetowych w usłudze Azure Data Explorer.
  • Dowolne narzędzie zapytań, które może uruchamiać zapytania KQL.

Napiwek

Ponieważ istnieje duża liczba zdarzeń śledzenia semantycznych modeli, zalecamy opracowanie modelu DirectQuery w celu przeanalizowania danych. Model DirectQuery umożliwia wykonywanie zapytań dotyczących danych niemal w czasie rzeczywistym. Zdarzenia są zwykle dostarczane w ciągu pięciu minut.

Aby uzyskać więcej informacji, zobacz Zarządzanie połączeniami platformy Azure.

Lista kontrolna — podczas planowania korzystania z usługi Azure Log Analytics kluczowe decyzje i akcje obejmują:

  • Rozważ techniczne weryfikację koncepcji: zaplanuj mały projekt, aby zapewnić pełne zrozumienie wymagań technicznych, wymagań dotyczących zabezpieczeń, zdarzeń do przechwycenia i sposobu analizowania dzienników.
  • Zdecyduj, które obszary robocze mają być zintegrowane z usługą Log Analytics: określ, które obszary robocze w warstwie Premium zawierają modele semantyczne, które chcesz analizować.
  • Zdecyduj, czy usługa Log Analytics powinna być włączona w pełnym wymiarze czasu dla dowolnych obszarów roboczych: w celu optymalizacji kosztów określ, czy istnieją sytuacje (lub konkretne obszary robocze), w których rejestrowanie powinno być włączone trwale. Zdecyduj, czy obszary robocze powinny zostać rozłączone podczas rozwiązywania problemów.
  • Zdecyduj, jak długo zachować dane usługi Log Analytics: określ, czy istnieje potrzeba ustawienia dłuższego okresu przechowywania niż wartość domyślna 30-dniowa.
  • Wyjaśnienie procesu żądania nowego obszaru roboczego usługi Log Analytics: Współpracuj z administratorem platformy Azure, aby wyjaśnić, w jaki sposób należy przesyłać żądania dotyczące nowego zasobu usługi Log Analytics przez administratorów obszaru roboczego usługi Power BI.
  • Zdecyduj, jak będą działać zabezpieczenia: współpracuj z administratorem platformy Azure, aby zdecydować, czy administrator obszaru roboczego usługi Power BI ma otrzymać uprawnienia do obszaru roboczego usługi Azure Log Analytics, czy administrator platformy Azure, który ma otrzymać prawa do obszaru roboczego usługi Power BI. Podczas podejmowania tej decyzji dotyczącej zabezpieczeń należy wziąć pod uwagę plan regularnego łączenia i odłączania obszarów roboczych (w celu optymalizacji kosztów).
  • Zdecyduj, jak zorganizować docelowe obszary robocze usługi Log Analytics: rozważ, ile obszarów roboczych usługi Azure Log Analytics będzie odpowiednich do organizowania danych z co najmniej jednego obszaru roboczego usługi Power BI. Zrównuj tę decyzję z decyzjami dotyczącymi zabezpieczeń, którzy mogą uzyskiwać dostęp do danych dziennika.
  • Zdecyduj, którzy administratorzy obszaru roboczego mogą nawiązać połączenie: określ, które grupy administratorów obszarów roboczych mogą połączyć obszar roboczy usługi Power BI z obszarem roboczym usługi Log Analytics. Ustaw ustawienie dzierżawy usługi Azure Log Analytics dla administratorów obszarów roboczych, aby dostosować je do tej decyzji.
  • Utwórz zasób usługi Azure Log Analytics: współpraca z administratorem platformy Azure w celu utworzenia każdego obszaru roboczego usługi Log Analytics. Sprawdź i zaktualizuj uprawnienia przypisane na platformie Azure, aby upewnić się, że konfiguracja usługi Power BI może wystąpić bez żadnych problemów. Sprawdź, czy dane przechowywane na platformie Azure znajdują się w poprawnym regionie geograficznym.
  • Ustaw połączenie usługi Log Analytics dla każdego obszaru roboczego usługi Power BI: Współpracuj z administratorami obszaru roboczego usługi Power BI, aby skonfigurować połączenie z usługą Log Analytics dla każdego obszaru roboczego usługi Power BI. Sprawdź, czy dane dziennika przepływają prawidłowo do obszaru roboczego usługi Log Analytics.
  • Tworzenie zapytań do analizowania danych: skonfiguruj zapytania KQL w celu analizowania danych w usłudze Log Analytics na podstawie przypadku użycia i bieżących potrzeb.
  • Dołącz wskazówki dla administratorów obszarów roboczych usługi Power BI: podaj informacje i wymagania wstępne dla administratorów obszaru roboczego usługi Power BI, aby dowiedzieć się, jak zażądać nowego obszaru roboczego usługi Log Analytics i jak nawiązać połączenie z obszarem roboczym usługi Power BI. Ponadto wyjaśnij, kiedy należy odłączyć obszar roboczy usługi Power BI.
  • Podaj wskazówki i przykładowe zapytania dotyczące analizowania danych: Tworzenie zapytań KQL dla administratorów obszaru roboczego, aby ułatwić im rozpoczęcie analizowania przechwyconych danych.
  • Monitorowanie kosztów: współpracuj z administratorem platformy Azure w celu ciągłego monitorowania kosztów usługi Log Analytics.

SQL Server Profiler

Profiler programu SQL Server (SQL Profiler) umożliwia przechwytywanie zdarzeń modelu semantycznego usługi Power BI. Jest to składnik programu SQL Server Management Studio (SSMS). Połączenie ivity do modelu semantycznego usługi Power BI jest obsługiwana w programie SSMS, ponieważ jest oparta na architekturze usług Analysis Services pochodzącej z programu SQL Server.

Profilera SQL można używać na różnych etapach cyklu życia modelu semantycznego.

  • Podczas tworzenia modelu danych: program SQL Profiler może łączyć się z modelem danych w programie Power BI Desktop jako narzędziem zewnętrznym. Takie podejście jest przydatne w przypadku osób modelujących dane, którzy chcą zweryfikować swój model danych lub dostrajają wydajność.
  • Po opublikowaniu modelu semantycznego w usługa Power BI: program SQL Profiler może nawiązać połączenie z modelem semantycznym w obszarze roboczym Premium. Program SSMS jest jednym z wielu obsługiwanych narzędzi klienckich, które mogą używać punktu końcowego XMLA do łączności. Takie podejście jest przydatne, gdy chcesz przeprowadzać inspekcję, monitorować, weryfikować, rozwiązywać problemy lub dostroić opublikowany model semantyczny w usługa Power BI.

Można również użyć programu SQL Profiler jako narzędzia zewnętrznego w programie DAX Studio. Za pomocą programu DAX Studio można uruchomić ślad profilera, przeanalizować dane i sformatować wyniki. Modelowanie danych, którzy korzystają z programu DAX Studio, często preferują to podejście, a nie bezpośrednio przy użyciu programu SQL Profiler.

Uwaga

Użycie programu SQL Profiler to inny przypadek użycia działania profilowania danych. Dane profilujesz w Edytor Power Query, aby lepiej zrozumieć jej cechy. Profilowanie danych jest ważnym działaniem dla osób modelujących dane, ale nie znajduje się w zakresie tego artykułu.

Rozważ użycie narzędzia SQL Profiler zamiast usługi Azure Log Analytics, gdy:

  • Twoja organizacja nie zezwala na używanie ani tworzenie zasobów usługi Azure Log Analytics na platformie Azure.
  • Chcesz przechwycić zdarzenia dla modelu danych w programie Power BI Desktop (który nie został opublikowany w obszarze roboczym Premium w usługa Power BI).
  • Chcesz przechwycić zdarzenia dla jednego semantycznego modelu przez krótki czas (zamiast wszystkich modeli semantycznych w obszarze roboczym Premium).
  • Chcesz przechwycić określone zdarzenia tylko podczas śledzenia (na przykład tylko zdarzenie koniec zapytania).
  • Chcesz często uruchamiać i zatrzymywać ślady (na przykład w przypadku konieczności przechwytywania zdarzeń modelu semantycznego, które występują teraz).

Podobnie jak w przypadku usługi Azure Log Analytics (opisanej wcześniej w tym artykule), zdarzenia modelu semantycznego przechwycone przez program SQL Profiler pochodzą z istniejących dzienników diagnostycznych dostępnych dla usług Azure Analysis Services. Istnieją jednak pewne różnice w dostępnych zdarzeniach.

Napiwek

Korzystanie z programu SQL Profiler do monitorowania usług Analysis Services jest omówione w wielu książkach, artykułach i wpisach w blogu. Większość tych informacji jest istotna w przypadku monitorowania modelu semantycznego usługi Power BI.

Ważne

Możesz również użyć programu SQL Profiler do monitorowania zapytań wysyłanych z usługa Power BI do bazowych źródeł danych (na przykład do relacyjnej bazy danych programu SQL Server). Jednak możliwość śledzenia relacyjnej bazy danych jest przestarzała. Połączenie do aparatu usług Analysis Services jest obsługiwany i nie jest przestarzały. Jeśli znasz zdarzenia rozszerzone usług Analysis Services i wolisz ich używać, łączność z programu SSMS jest możliwa dla modelu danych w programie Power BI Desktop. Nie jest to jednak obsługiwane w przypadku usługi Power BI Premium. W związku z tym ta sekcja koncentruje się tylko na standardowej łączności programu SQL Profiler.

Ustawienie dzierżawy Zezwalaj na punkty końcowe XMLA i analizowanie w programie Excel z lokalnymi modelami semantycznymi steruje grupami użytkowników (którzy są również przypisani do roli Współautor, Członek lub Administracja obszaru roboczego albo uprawnienie do tworzenia dla pojedynczego modelu semantycznego) może używać punktu końcowego XMLA do wykonywania zapytań i/lub obsługi modeli semantycznych w usługa Power BI. Aby uzyskać więcej informacji na temat korzystania z punktu końcowego XMLA, zobacz zaawansowany scenariusz użycia zarządzania modelami danych.

Uwaga

Możesz również użyć programu SQL Profiler, aby ułatwić debugowanie i rozwiązywanie problemów z określonymi wyrażeniami języka DAX. Program SQL Profiler można połączyć z programem Power BI Desktop jako narzędziem zewnętrznym. Poszukaj klasy zdarzeń dziennika oceny języka DAX, aby wyświetlić pośrednie wyniki wyrażenia języka DAX. To zdarzenie jest generowane podczas korzystania z funkcji EVALUATEANDLOG języka DAX w obliczeniu modelu.

Ta funkcja jest przeznaczona tylko do celów programistycznych i testowych. Przed opublikowaniem modelu danych w obszarze roboczym produkcyjnym należy go usunąć z obliczeń modelu danych.

Lista kontrolna — podczas planowania korzystania z profilera SQL kluczowe decyzje i akcje obejmują:

  • Zdecyduj, kto może mieć zainstalowany program SSMS lub DAX Studio: określ, czy zezwolisz wszystkim twórcom zawartości usługi Power BI w organizacji na zainstalowanie programu SSMS i/lub programu DAX Studio, aby mogli korzystać z programu SQL Profiler. Zdecyduj, czy te narzędzia pomocnicze są instalowane na żądanie, czy też część standardowego zestawu oprogramowania zainstalowanego dla zatwierdzonych twórców danych w organizacji.
  • Dodaj program SQL Profiler do menu Narzędzia zewnętrzne w programie Power BI Desktop: jeśli twórcy danych będą często używać profilera SQL, poproś dział IT o automatyczne dodanie go do menu Narzędzia zewnętrzne w programie Power BI Desktop dla tych użytkowników.
  • Zdecyduj, kto może używać punktu końcowego XMLA: określ, czy wszyscy użytkownicy mogą łączyć się z opublikowanymi modelami semantycznymi przy użyciu punktu końcowego XMLA, czy tylko do zatwierdzonych twórców danych. Ustaw ustawienie Zezwalaj na punkty końcowe XMLA i Analizuj w programie Excel przy użyciu ustawień dzierżawy modeli semantycznych lokalnych, aby dopasować je do tej decyzji.
  • Podaj wskazówki i przykładowe zapytania dotyczące analizowania danych: utwórz dokumentację dla twórców danych, aby zrozumieć zalecany sposób przeprowadzania inspekcji i monitorowania modeli semantycznych. Podaj wskazówki dotyczące typowych przypadków użycia, aby ułatwić im rozpoczęcie zbierania i analizowania danych śledzenia.

Metadane modelu danych

Ponieważ semantyczne modele usługi Power BI są oparte na akomponemencie usług Analysis Services, masz dostęp do narzędzi, które mogą wykonywać zapytania dotyczące metadanych modelu danych. Metadane obejmują wszystkie elementy dotyczące modelu danych, w tym nazwy tabel, nazwy kolumn i wyrażenia miary.

Dynamiczne widoki zarządzania

Dynamiczne widoki zarządzania usług Analysis Services (DMV) mogą wykonywać zapytania dotyczące metadanych modelu danych. Dynamiczne widoki zarządzania umożliwiają przeprowadzanie inspekcji, dokumentowania i optymalizowania modeli danych w danym momencie.

W szczególności można wykonywać następujące czynności:

  • Przeprowadź inspekcję źródeł danych używanych przez model.
  • Odkryj, które obiekty zużywają najwięcej pamięci w modelu.
  • Określ, jak wydajnie można skompresować dane kolumn.
  • Znajdź kolumny w modelu, który nie jest używany.
  • Przeprowadź inspekcję aktywnych sesji i połączeń użytkowników.
  • Sprawdź strukturę modelu.
  • Przejrzyj wyrażenia języka DAX używane przez tabele obliczeniowe, kolumny obliczeniowe, miary i reguły zabezpieczeń na poziomie wiersza.
  • Identyfikowanie zależności między obiektami i miarami.

Napiwek

Dynamiczne widoki zarządzania pobierają informacje o bieżącym stanie modelu semantycznego. Pomyśl o danych zwracanych przez dynamiczne widoki zarządzania jako migawkę tego, co dzieje się w danym momencie w czasie. Z drugiej strony dzienniki zdarzeń modelu semantycznego (opisane wcześniej w tym artykule) pobierają informacje o tym, jakie działania wystąpiły dla modelu semantycznego, gdy połączenie śledzenia było aktywne.

Program SSMS to narzędzie często używane do uruchamiania zapytań DMV. Możesz również użyć polecenia cmdlet Invoke-ASCmd programu PowerShell, aby utworzyć i wykonać skrypty XMLA, które wysyłają zapytania do widoków DMV.

Narzędzia innych firm i narzędzia zewnętrzne są również popularne w społeczności usługi Power BI. Te narzędzia używają publicznie udokumentowanych widoków DMV, aby uprościć dostęp i pracować z danymi zwracanymi przez dynamiczne widoki zarządzania. Jednym z przykładów jest daX Studio, który zawiera jawne funkcje umożliwiające dostęp do widoków DMV. Program DAX Studio zawiera również wbudowaną funkcję Metryk widoku, która jest powszechnie znana jako analizator Vertipaq. Analizator Vertipaq ma interfejs użytkownika do analizowania struktury i rozmiaru tabel, kolumn, relacji i partycji w modelu danych. Możesz również wyeksportować (lub zaimportować) metadane modelu danych do pliku vpax. Wyeksportowany plik zawiera tylko metadane dotyczące struktury i rozmiaru modelu danych bez przechowywania danych modelu.

Napiwek

Rozważ udostępnienie pliku vpax komuś, kto potrzebuje pomocy w modelu danych. Dzięki temu nie udostępnisz danych modelu tej osobie.

Zapytania DMV można używać na różnych etapach cyklu życia modelu semantycznego.

  • Podczas tworzenia modelu danych: Wybrane narzędzie może łączyć się z modelem danych w programie Power BI Desktop jako narzędziem zewnętrznym. Takie podejście jest przydatne w przypadku osób modelujących dane, którzy chcą zweryfikować swój model danych lub dostrajają wydajność.
  • Po opublikowaniu modelu semantycznego w usługa Power BI: Wybrane narzędzie może połączyć się z modelem semantycznym w obszarze roboczym Premium. Program SSMS jest jednym z wielu obsługiwanych narzędzi klienckich, które używają punktu końcowego XMLA do łączności. Takie podejście jest przydatne, gdy chcesz przeprowadzić inspekcję lub zweryfikować opublikowany model semantyczny w usługa Power BI.

Napiwek

Jeśli zdecydujesz się na pisanie własnych zapytań DMV (na przykład w programie SSMS), pamiętaj, że dynamiczne widoki zarządzania nie obsługują wszystkich operacji SQL. Ponadto niektóre dynamiczne widoki zarządzania nie są obsługiwane w usłudze Power BI (ponieważ wymagają one uprawnień administratora serwera usług Analysis Services, które nie są obsługiwane przez usługę Power BI).

Ustawienie dzierżawy Zezwalaj na punkty końcowe XMLA i analizowanie w programie Excel z lokalnymi modelami semantycznymi steruje grupami użytkowników (którzy są również przypisani do roli Współautor, Członek lub Administracja obszaru roboczego albo uprawnienie do tworzenia dla pojedynczego modelu semantycznego) może używać punktu końcowego XMLA do wykonywania zapytań i/lub obsługi modeli semantycznych w usługa Power BI.

Aby uzyskać więcej informacji na temat korzystania z punktu końcowego XMLA, narzędzi innych firm i narzędzi zewnętrznych, zobacz zaawansowany scenariusz użycia zarządzania modelami danych.

Analizator najlepszych rozwiązań

Analizator najlepszych rozwiązań (BPA) to funkcja edytora tabelarycznego, która jest narzędziem innej firmy, które osiągnęło powszechne wdrożenie przez społeczność usługi Power BI. Narzędzie BPA zawiera zestaw dostosowywalnych reguł, które mogą pomóc w inspekcji jakości, spójności i wydajności modelu danych.

Napiwek

Aby skonfigurować narzędzie BPA, pobierz zestaw reguł najlepszych rozwiązań udostępnianych przez firmę Microsoft w witrynie GitHub.

Przede wszystkim narzędzie BPA może pomóc zwiększyć spójność modeli, wykrywając nieoptymalne decyzje projektowe, które mogą zmniejszyć problemy z wydajnością. Przydaje się, gdy masz samoobsługowe modele danych dystrybuowane w różnych obszarach organizacji.

Narzędzie BPA może również ułatwić przeprowadzanie inspekcji modeli danych i zarządzanie nimi. Możesz na przykład sprawdzić, czy model danych zawiera dowolne role zabezpieczeń na poziomie wiersza. Możesz też sprawdzić, czy wszystkie obiekty modelu mają opis. Jest to przydatne, gdy na przykład twoim celem jest zapewnienie, że model danych zawiera słownik danych.

BPA może uwidocznić problemy projektowe, które mogą pomóc Centrum Doskonałości określić, czy konieczne jest więcej szkoleń lub dokumentacji. Może podjąć działania w celu informowania twórców danych o najlepszych rozwiązaniach i wytycznych organizacji.

Napiwek

Należy pamiętać, że narzędzie BPA może wykryć istnienie cech (takich jak zabezpieczenia na poziomie wiersza). Jednak ustalenie, czy konfiguracja jest poprawna, może być trudna. Z tego powodu ekspert w tej dziedzinie może wymagać przeprowadzenia przeglądu . Z drugiej strony, brak istnienia konkretnej charakterystyki nie musi oznaczać złego projektu; modeler danych może mieć dobry powód do utworzenia określonego projektu.

Lista kontrolna — podczas planowania dostępu do metadanych dla modeli danych kluczowe decyzje i akcje obejmują:

  • Zdecyduj, kto może mieć zainstalowany program SSMS: określ, czy zezwolisz wszystkim twórcom zawartości usługi Power BI w organizacji na zainstalowanie programu SSMS, aby umożliwić im łączenie się z opublikowanymi modelami semantycznymi. Zdecyduj, czy jest on zainstalowany na żądanie, czy w ramach standardowego zestawu oprogramowania zainstalowanego dla zatwierdzonych twórców danych w organizacji.
  • Zdecyduj, kto może mieć zainstalowane narzędzia innych firm: określ, czy zezwolisz wszystkim twórcom zawartości usługi Power BI w organizacji na instalowanie narzędzi innych firm (takich jak DAX Studio i Tabular Editor), aby umożliwić monitorowanie lokalnych modeli danych i/lub opublikowanych modeli semantycznych. Zdecyduj, czy są instalowane na żądanie, czy w ramach standardowego zestawu oprogramowania zainstalowanego dla zatwierdzonych twórców danych w organizacji.
  • Konfigurowanie reguł najlepszych rozwiązań: zdecyduj, które reguły analizatora najlepszych rozwiązań mogą skanować modele danych w organizacji.
  • Zdecyduj, kto może używać punktu końcowego XMLA: określ, czy wszyscy użytkownicy mogą łączyć się z modelami semantycznymi przy użyciu punktu końcowego XMLA, czy tylko do zatwierdzonych twórców danych. Ustaw ustawienie Zezwalaj na punkty końcowe XMLA i Analizuj w programie Excel przy użyciu ustawień dzierżawy modeli semantycznych lokalnych, aby dopasować je do tej decyzji.
  • Zapewnianie wskazówek dla twórców zawartości: tworzenie dokumentacji dla twórców danych w celu zrozumienia zalecanych sposobów analizowania modeli semantycznych. Podaj wskazówki dotyczące typowych przypadków użycia, aby ułatwić im rozpoczęcie zbierania i analizowania wyników dmV i/lub przy użyciu analizatora najlepszych rozwiązań.

Model danych i wydajność zapytań

Program Power BI Desktop zawiera kilka narzędzi , które ułatwiają twórcom danych rozwiązywanie problemów i badanie modeli danych. Te możliwości są przeznaczone dla osób modelujących dane, którzy chcą zweryfikować swój model danych i dostrajać wydajność przed opublikowaniem w usługa Power BI.

Performance Analyzer

Użyj Analizator wydajności, który jest dostępny w programie Power BI Desktop, aby przeprowadzić inspekcję i zbadać wydajność modelu danych. Analizator wydajności pomaga twórcom raportów mierzyć wydajność poszczególnych elementów raportu. Często jednak główną przyczyną problemów z wydajnością jest projekt modelu danych. Z tego powodu twórca semantycznego modelu może również korzystać z Analizator wydajności. Jeśli istnieją różne twórcy zawartości odpowiedzialni za tworzenie raportów i modeli semantycznych, prawdopodobnie będą musieli współpracować podczas rozwiązywania problemów z wydajnością.

Napiwek

Program DAX Studio umożliwia importowanie i analizowanie plików dziennika wygenerowanych przez Analizator wydajności.

Aby uzyskać więcej informacji na temat Analizator wydajności, zobacz Inspekcja na poziomie raportu.

Diagnostyka zapytań

Użyj diagnostyki zapytań, która jest dostępna w programie Power BI Desktop, aby zbadać wydajność dodatku Power Query. Są one przydatne do rozwiązywania problemów i gdy trzeba zrozumieć, co robi aparat Power Query.

Informacje, które można uzyskać z diagnostyki zapytań, obejmują:

  • Dodatkowe szczegóły związane z komunikatami o błędach (gdy wystąpi wyjątek).
  • Zapytania wysyłane do źródła danych.
  • Niezależnie od tego, czy składanie zapytań jest czy nie występuje.
  • Liczba wierszy zwracanych przez zapytanie.
  • Potencjalne spowolnienie podczas operacji odświeżania danych.
  • Zdarzenia w tle i zapytania generowane przez system.

W zależności od tego, czego szukasz, możesz włączyć jeden lub wszystkie dzienniki: zagregowane, szczegółowe, liczniki wydajności i partycje prywatności danych.

Diagnostykę sesji można uruchomić w Edytor Power Query. Po włączeniu operacje zapytań i odświeżania są zbierane do momentu zatrzymania śledzenia diagnostycznego. Dane są wypełniane bezpośrednio w edytorze zapytań zaraz po zatrzymaniu diagnostyki. Dodatek Power Query tworzy grupę diagnostyki (folder) i dodaje do niej kilka zapytań. Następnie możesz użyć standardowych funkcji dodatku Power Query do wyświetlania i analizowania danych diagnostycznych.

Alternatywnie możesz włączyć śledzenie w programie Power BI Desktop w sekcji Diagnostyka okna Opcje. Pliki dziennika są zapisywane w folderze na komputerze lokalnym. Te pliki dziennika są wypełniane danymi po zamknięciu programu Power BI Desktop, w którym dane śledzenia zostaną zatrzymane. Po zamknięciu programu Power BI Desktop możesz otworzyć pliki dziennika za pomocą preferowanego programu (takiego jak edytor tekstów), aby je wyświetlić.

Ocena i składanie zapytań

Dodatek Power Query obsługuje różne możliwości ułatwiające zrozumienie oceny zapytań, w tym planu zapytania. Może również pomóc w ustaleniu, czy składanie zapytań występuje dla całego zapytania, czy też dla podzbioru kroków w zapytaniu. Składanie zapytań jest jednym z najważniejszych aspektów dostrajania wydajności. Warto również przejrzeć zapytania natywne wysyłane przez dodatek Power Query podczas monitorowania źródła danych, które opisano w dalszej części tego artykułu.

Aplikacja metryk Premium

Podczas rozwiązywania problemów warto współpracować z administratorem pojemności usługi Power BI Premium. Administrator pojemności ma dostęp do aplikacji użycia i metryk usługi Power BI Premium. Ta aplikacja może udostępniać wiele informacji o działaniach, które występują w pojemności. Te informacje mogą pomóc w rozwiązywaniu problemów z modelem semantycznym.

Napiwek

Administrator pojemności Premium może udzielić dostępu do dodatkowych użytkowników (administratorów innych niż pojemności), aby umożliwić im dostęp do aplikacji metryk Premium.

Aplikacja metryk Premium składa się z wewnętrznego modelu semantycznego i początkowego zestawu raportów. Ułatwia ona monitorowanie pojemności usługi Power BI Premium (P) lub pojemności jednostki SKU usługi Power BI Embedded (A) w czasie zbliżonym do rzeczywistego. Zawiera dane z ostatnich dwóch do czterech tygodni (w zależności od metryki).

Użyj aplikacji metryki Premium, aby rozwiązywać problemy i optymalizować modele semantyczne. Można na przykład zidentyfikować modele semantyczne, które mają duże zużycie pamięci lub które mają rutynowe wysokie użycie procesora CPU. Jest to również przydatne narzędzie do znajdowania modeli semantycznych, które zbliżają się do limitu rozmiaru pojemności.

Lista kontrolna — biorąc pod uwagę podejścia do monitorowania modelu danych i wydajności zapytań, kluczowe decyzje i akcje obejmują:

  • Zidentyfikuj cele wydajności zapytań modelu semantycznego: upewnij się, że dobrze rozumiesz, co oznacza dobra wydajność modelu semantycznego. Określ, kiedy będą wymagane określone cele wydajności zapytań (na przykład zapytania do obsługi raportów muszą być renderowane w ciągu pięciu sekund). Jeśli tak, upewnij się, że obiekty docelowe są przekazywane twórcom danych w organizacji.
  • Zidentyfikuj cele wydajności odświeżania modelu semantycznego: określ, kiedy będą wymagane określone cele odświeżania danych (na przykład ukończenie operacji odświeżania danych w ciągu 15 minut i przed godziną 5:00). Jeśli tak, upewnij się, że obiekty docelowe są przekazywane twórcom danych w organizacji.
  • Poinformuj zespół pomocy technicznej: upewnij się, że wewnętrzny zespół pomocy technicznej użytkowników zna możliwości diagnostyczne, dzięki czemu są gotowi do obsługi użytkowników usługi Power BI, gdy potrzebują pomocy.
  • Połączenie zespół pomocy technicznej i administratorzy baz danych: Upewnij się, że zespół pomocy technicznej wie, jak skontaktować się z odpowiednimi administratorami dla każdego źródła danych (na przykład podczas rozwiązywania problemów z składaniem zapytań).
  • Współpraca z administratorem pojemności Premium: skontaktuj się z administratorem pojemności, aby rozwiązać problemy z modelami semantycznymi, które znajdują się w obszarze roboczym przypisanym do pojemności Premium lub pojemności usługi Power BI Embedded. W razie potrzeby zażądaj dostępu do aplikacji metryk Premium.
  • Podaj wskazówki dla twórców zawartości: utwórz dokumentację dla twórców danych, aby zrozumieć, jakie działania należy wykonać podczas rozwiązywania problemów.
  • Dołącz do materiałów szkoleniowych: podaj wskazówki dla twórców danych dotyczące tworzenia dobrze wydajnych modeli danych. Pomóż im wcześnie przyjąć dobre nawyki projektowe. Skoncentruj się na nauczaniu twórców danych, jak podejmować dobre decyzje projektowe.

Monitorowanie źródła danych

Czasami konieczne jest bezpośrednie monitorowanie określonego źródła danych, z którymi łączy się usługa Power BI. Na przykład może istnieć magazyn danych, w którym występuje zwiększone obciążenie, a użytkownicy zgłaszają spadek wydajności. Zazwyczaj administrator bazy danych lub administrator systemu monitoruje źródła danych.

Źródło danych można monitorować w celu:

  • Przeprowadź inspekcję, którzy użytkownicy wysyłają zapytania do źródła danych.
  • Przeprowadź inspekcję, które aplikacje (takie jak usługa Power BI) wysyłają zapytania do źródła danych.
  • Sprawdź, jakie instrukcje zapytania są wysyłane do źródła danych, kiedy i według których użytkowników.
  • Określ, jak długo trwa uruchamianie zapytania.
  • Przeprowadź inspekcję wywoływanego przez system źródłowy zabezpieczeń na poziomie wiersza, gdy jest używany logowanie jednokrotne.

Istnieje wiele akcji, które twórca zawartości usługi Power BI może wykonać po przeanalizowaniu wyników monitorowania. Mogą:

  • Dostraj i uściślij zapytania wysyłane do źródła danych, aby były tak wydajne, jak to możliwe.
  • Zweryfikuj i dostosuj zapytania natywne wysyłane do źródła danych.
  • Zmniejsz liczbę kolumn importowanych do modelu danych.
  • Usuń kolumny o wysokiej precyzji i wysokiej kardynalności, które są importowane do modelu danych.
  • Zmniejsz ilość danych historycznych importowanych do modelu danych.
  • Dostosuj czas odświeżania danych usługi Power BI, aby ułatwić rozłożenie zapotrzebowania na źródło danych.
  • Użyj odświeżania danych przyrostowych, aby zmniejszyć obciążenie źródła danych.
  • Zmniejsz liczbę odświeżeń danych usługi Power BI, konsolidując wiele modeli semantycznych w udostępniony model semantyczny.
  • Dostosuj ustawienia automatycznego odświeżania strony, aby zwiększyć częstotliwość odświeżania, a tym samym zmniejszyć obciążenie źródła danych.
  • Uproszczenie obliczeń w celu zmniejszenia złożoności zapytań wysyłanych do źródła danych.
  • Zmień tryb przechowywania danych (na przykład w celu zaimportowania trybu zamiast trybu DirectQuery), aby zmniejszyć spójne obciążenie zapytania w źródle danych.
  • Użyj technik redukcji zapytań, aby zmniejszyć liczbę zapytań wysyłanych do źródła danych.

Administratorzy systemu mogą podejmować inne działania. Mogą:

  • Wprowadzenie pośredniej warstwy danych, takiej jak przepływy danych usługi Power BI (gdy magazyn danych nie jest odpowiednią opcją). Twórcy zawartości usługi Power BI mogą używać przepływów danych jako źródła danych zamiast łączyć się bezpośrednio ze źródłami danych. Pośrednia warstwa danych może zmniejszyć obciążenie systemu źródłowego. Ma również dodatkową zaletę scentralizowanej logiki przygotowywania danych. Aby uzyskać więcej informacji, zobacz scenariusz użycia samoobsługowego przygotowywania danych.
  • Zmień lokalizację źródła danych, aby zmniejszyć wpływ opóźnienia sieci (na przykład użyj tego samego regionu danych dla usługa Power BI, źródeł danych i bram).
  • Zoptymalizuj źródło danych, aby wydajniej pobierać dane dla usługi Power BI. Kilka typowych technik obejmuje tworzenie indeksów tabel, tworzenie indeksowanych widoków, tworzenie utrwanych kolumn obliczeniowych, utrzymywanie statystyk, używanie tabel w pamięci lub magazynu kolumn oraz tworzenie zmaterializowanych widoków.
  • Umożliwianie użytkownikom używania repliki tylko do odczytu źródła danych, a nie oryginalnej produkcyjnej bazy danych. Replika może być dostępna w ramach strategii bazy danych wysokiej dostępności (HA). Jedną z zalet repliki tylko do odczytu jest zmniejszenie rywalizacji w systemie źródłowym.

Narzędzia i techniki, których można użyć do monitorowania źródeł danych, zależą od platformy technologicznej. Na przykład administrator bazy danych może używać zdarzeń rozszerzonych lub magazynu zapytań do monitorowania baz danych usługi Azure SQL Database i programu SQL Server.

Czasami usługa Power BI uzyskuje dostęp do źródła danych za pośrednictwem bramy danych. Bramy obsługują łączność z usługa Power BI do niektórych typów źródeł danych. Jednak nie tylko łączą się z danymi. Brama zawiera aparat mashupu, który wykonuje przetwarzanie i przekształcenia danych na maszynie. Ponadto kompresuje i szyfruje dane, aby można je było wydajnie i bezpiecznie przesyłać do usługa Power BI. W związku z tym niezarządzany lub nieoptymizowany brama może przyczynić się do wąskich gardeł wydajności. Zalecamy skontaktowanie się z administratorem bramy, aby uzyskać pomoc dotyczącą monitorowania bram.

Napiwek

Administrator usługi Power BI może skompilować pełny spis dzierżawy (obejmujący pochodzenie) i uzyskać dostęp do działań użytkowników w dzienniku aktywności. Dzięki korelowaniu pochodzenia i działań użytkowników administratorzy mogą identyfikować najczęściej używane źródła danych i bramy.

Aby uzyskać więcej informacji na temat spisu dzierżawy i dziennika aktywności, zobacz Inspekcja na poziomie dzierżawy.

Lista kontrolna — podczas planowania monitorowania źródła danych kluczowe decyzje i akcje obejmują:

  • Określanie określonych celów: podczas monitorowania źródła danych uzyskaj jasność co dokładnie do tego, co należy osiągnąć, i cele dotyczące rozwiązywania problemów.
  • Współpracuj z administratorami baz danych: współpracuj z administratorami bazy danych lub administratorami systemu, aby uzyskać pomoc podczas monitorowania określonego źródła danych.
  • Współpraca z administratorami bramy: w przypadku źródeł danych łączących się za pośrednictwem bramy danych skontaktuj się z administratorem bramy podczas rozwiązywania problemów.
  • Połączenie zespół pomocy technicznej i administratorzy baz danych: Upewnij się, że zespół pomocy technicznej wie, jak skontaktować się z odpowiednimi administratorami dla każdego źródła danych (na przykład podczas rozwiązywania problemów z składaniem zapytań).
  • Aktualizowanie szkoleń i wskazówek: dołącz kluczowe informacje i porady dla twórców danych dotyczące pracy ze źródłami danych organizacji. Dołącz informacje o tym, co zrobić, gdy coś pójdzie nie tak.

Monitorowanie odświeżania danych

Operacja odświeżania danych obejmuje importowanie danych ze źródłowych źródeł danych do semantycznego modelu, przepływu danych lub schematu danych usługi Power BI. Możesz zaplanować operację odświeżania danych lub uruchomić ją na żądanie.

Umowa dotycząca poziomu usług

W celu udokumentowania oczekiwań dotyczących zasobów danych często używane są umowy dotyczące poziomu usług (SLA). W przypadku usługi Power BI rozważ użycie umowy SLA dla zawartości krytycznej lub zawartości na poziomie przedsiębiorstwa. Często obejmuje to, kiedy użytkownicy mogą oczekiwać, że zaktualizowane dane w modelu semantycznym będą dostępne. Na przykład możesz mieć umowę SLA, którą wszystkie operacje odświeżania danych muszą być wykonywane codziennie o 7:00.

Dzienniki modelu semantycznego

Dzienniki zdarzeń modelu semantycznego z usługi Azure Log Analytics lub SQL Profiler (opisane wcześniej w tym artykule) zawierają szczegółowe informacje o tym, co dzieje się w modelu semantycznym. Przechwycone zdarzenia obejmują działanie odświeżania modelu semantycznego. Dzienniki zdarzeń są szczególnie przydatne, gdy konieczne jest rozwiązywanie problemów i badanie odświeżeń modelu semantycznego.

Modele semantyczne pojemności Premium

Jeśli masz zawartość hostowaną w pojemności usługi Power BI Premium, masz więcej możliwości monitorowania operacji odświeżania danych.

  • Strona podsumowań odświeżania usługi Power BI w portalu administracyjnym zawiera podsumowanie historii odświeżania. To podsumowanie zawiera informacje o czasie trwania odświeżania i komunikatach o błędach.
  • Aplikacja wykorzystania i metryk usługi Power BI Premium zawiera również przydatne informacje o odświeżaniu. Jest to przydatne, gdy musisz zbadać działanie odświeżania dla pojemności Usługi Power BI Premium (JEDNOSTKA SKU P) lub pojemności jednostki SKU usługi Power BI Embedded (A).

Rozszerzone odświeżanie modelu semantycznego

Twórcy zawartości mogą programowo inicjować odświeżanie modelu semantycznego przy użyciu rozszerzonego odświeżania za pomocą interfejsu API REST Odświeżanie zestawu danych w grupie. W przypadku korzystania z rozszerzonego odświeżania można monitorować historyczne, bieżące i oczekujące operacje odświeżania.

Monitorowanie harmonogramu odświeżania danych

Administratorzy usługi Power BI mogą monitorować harmonogramy odświeżania danych w dzierżawie, aby określić, czy istnieje wiele operacji odświeżania zaplanowanych jednocześnie w określonym przedziale czasu (na przykład między 5:00 a 7:00, co może być szczególnie zajętym czasem odświeżania danych). Administracja istratory mają uprawnienia dostępu do metadanych harmonogramu odświeżania modelu semantycznego z interfejsów API skanowania metadanych, które są nazywane interfejsami API skanera.

Interfejsy API REST usługi Power BI

W przypadku krytycznych modeli semantycznych nie należy polegać wyłącznie na powiadomieniach e-mail dotyczących monitorowania problemów z odświeżaniem danych. Rozważ skompilowanie historii odświeżania danych w scentralizowanym magazynie, w którym można monitorować, analizować i wykonywać na nim działania.

Historię odświeżania danych można pobrać przy użyciu:

Napiwek

Zdecydowanie zalecamy monitorowanie historii odświeżania modeli semantycznych, aby upewnić się, że bieżące dane są dostępne dla raportów i pulpitów nawigacyjnych. Pomaga również wiedzieć, czy umowy SLA są spełnione.

Lista kontrolna — podczas planowania monitorowania odświeżania danych kluczowe decyzje i akcje obejmują:

  • Określanie określonych celów: Podczas monitorowania odświeżania danych uzyskaj jasność dokładnie tego, co należy osiągnąć i jaki zakres monitorowania powinien być (na przykład modele semantyczne produkcji, certyfikowane modele semantyczne i inne).
  • Rozważ skonfigurowanie umowy SLA: określ, czy umowa SLA byłaby przydatna do określania oczekiwań dotyczących dostępności danych i czasu uruchamiania harmonogramów odświeżania danych.
  • Współpraca z administratorami bazy danych i bramy: współpracuj z administratorami bazy danych lub systemu oraz administratorami bramy, aby monitorować lub rozwiązywać problemy z odświeżaniem danych.
  • Transfer wiedzy dla zespołu pomocy technicznej: upewnij się, że zespół pomocy technicznej wie, jak pomóc twórcom zawartości w przypadku wystąpienia problemów z odświeżaniem danych.
  • Aktualizowanie szkoleń i wskazówek: dołącz kluczowe informacje i porady dla twórców danych dotyczące odświeżania danych ze źródeł danych organizacji i typowych źródeł danych. Uwzględnij najlepsze rozwiązania i preferencje organizacji dotyczące zarządzania odświeżaniem danych.
  • Użyj adresu e-mail pomocy technicznej dla powiadomień: w przypadku zawartości krytycznej skonfiguruj powiadomienia odświeżania, aby używać adresu e-mail pomocy technicznej.
  • Konfigurowanie scentralizowanego monitorowania odświeżania: użyj interfejsów API REST usługi Power BI do kompilowania historii odświeżania danych.

Monitorowanie przepływu danych

Przepływ danych usługi Power BI można utworzyć za pomocą usługi Power Query Online. Wiele funkcji wydajności zapytań i diagnostyka dodatku Power Query, które zostały opisane wcześniej, mają zastosowanie.

Opcjonalnie można ustawić obszary robocze, aby używać usługi Azure Data Lake Storage Gen2 na potrzeby magazynu przepływów danych (znanego jako bring-your-own-storage), a nie magazynu wewnętrznego. W przypadku korzystania z magazynu bring-your-own-storage rozważ włączenie telemetrii , aby można było monitorować metryki dla konta magazynu. Aby uzyskać więcej informacji, zobacz scenariusz użycia samoobsługowego przygotowywania danych i zaawansowany scenariusz użycia przygotowywania danych.

Interfejsy API REST usługi Power BI umożliwiają monitorowanie transakcji przepływu danych. Na przykład użyj interfejsu API pobierania transakcji przepływu danych, aby sprawdzić stan odświeżeń przepływu danych.

Możesz śledzić działania użytkowników dla przepływów danych usługi Power BI za pomocą dziennika aktywności usługi Power BI. Aby uzyskać więcej informacji, zobacz Inspekcja na poziomie dzierżawy.

Napiwek

Istnieje wiele najlepszych rozwiązań, które można zastosować, aby zoptymalizować projekty przepływów danych. Aby uzyskać więcej informacji, zobacz Najlepsze rozwiązania dotyczące przepływów danych.

Monitorowanie narzędzia Datamart

Schemat danych usługi Power BI zawiera kilka zintegrowanych składników, w tym przepływ danych, zarządzaną bazę danych i model semantyczny. Zapoznaj się z poprzednimi sekcjami tego artykułu, aby dowiedzieć się więcej o inspekcji i monitorowaniu poszczególnych składników.

Możesz śledzić działania użytkowników dlamartów danych usługi Power BI przy użyciu dziennika aktywności usługi Power BI. Aby uzyskać więcej informacji, zobacz Inspekcja na poziomie dzierżawy.

Powiązana zawartość

W następnym artykule z tej serii dowiesz się więcej o inspekcji na poziomie dzierżawy.