Przewodnik optymalizacji dla usługi Power BI

  • Artykuł

Ten artykuł zawiera wskazówki, które umożliwiają deweloperom i administratorom tworzenie i konserwowanie zoptymalizowanych rozwiązań usługi Power BI. Rozwiązanie można zoptymalizować w różnych warstwach architektury. Warstwy obejmują:

  • Źródła danych
  • Model danych
  • Wizualizacje, w tym pulpity nawigacyjne, raporty usługi Power BI i raporty podzielone na strony usługi Power BI
  • Środowisko, w tym pojemności, bramy danych i sieć

Optymalizowanie modelu danych

Model danych obsługuje całe środowisko wizualizacji. Modele danych są hostowane w ekosystemie usługi Power BI lub zewnętrznie (przy użyciu trybu DirectQuery lub live Połączenie ion), a w usłudze Power BI są nazywane modelami semantycznymi — wcześniej nazywanymi zestawami danych. Ważne jest, aby zrozumieć opcje i wybrać odpowiedni typ modelu semantycznego dla rozwiązania. Istnieją trzy tryby semantyczne modelu: Import, DirectQuery i Composite. Aby uzyskać więcej informacji, zobacz Semantyczne modele w trybach usługa Power BI i Semantycznych w usługa Power BI.

Aby uzyskać wskazówki dotyczące określonego trybu semantycznego modelu, zobacz:

Optymalizowanie wizualizacji

Wizualizacje usługi Power BI mogą być pulpitami nawigacyjnymi, raportami usługi Power BI lub raportami podzielonymi na strony w usłudze Power BI. Każda z nich ma różne architektury, a więc każda z nich ma własne wskazówki.

Pulpity nawigacyjne

Ważne jest, aby zrozumieć, że usługa Power BI utrzymuje pamięć podręczną dla kafelków pulpitu nawigacyjnego — z wyjątkiem dynamicznych kafelków raportu i kafelków przesyłania strumieniowego. Jeśli model semantyczny wymusza dynamiczne zabezpieczenia na poziomie wiersza, pamiętaj, aby zrozumieć wpływ na wydajność, ponieważ kafelki będą buforowane na podstawie poszczególnych użytkowników.

Po przypięciu dynamicznych kafelków raportu do pulpitu nawigacyjnego nie są one obsługiwane z pamięci podręcznej zapytań. Zamiast tego zachowują się jak raporty i wysyłają zapytania do rdzeni wirtualnych na bieżąco.

Jak sugeruje nazwa, pobieranie danych z pamięci podręcznej zapewnia lepszą i spójniejszą wydajność niż poleganie na źródle danych. Jednym ze sposobów korzystania z tej funkcji jest posiadanie pulpitów nawigacyjnych jako pierwszej strony docelowej dla użytkowników. Przypinanie często używanych i wysoce żądanych wizualizacji do pulpitów nawigacyjnych. W ten sposób pulpity nawigacyjne stają się cenną "pierwszą linią obrony", która zapewnia spójną wydajność z mniejszym obciążeniem pojemności. Użytkownicy mogą nadal klikać do raportu, aby analizować szczegóły.

W przypadku modeli semantycznych trybu DirectQuery i połączeń na żywo pamięć podręczna jest okresowo aktualizowana przez wykonywanie zapytań względem źródła danych. Domyślnie odbywa się to co godzinę, ale można skonfigurować inną częstotliwość w ustawieniach modelu semantycznego. Każda aktualizacja pamięci podręcznej będzie wysyłać zapytania do bazowego źródła danych w celu zaktualizowania pamięci podręcznej. Liczba zapytań generowanych zależy od liczby wizualizacji przypiętych do pulpitów nawigacyjnych, które opierają się na źródle danych. Zwróć uwagę, że jeśli włączono zabezpieczenia na poziomie wiersza, zapytania są generowane dla każdego innego kontekstu zabezpieczeń. Rozważmy na przykład dwie różne role, które kategoryzują użytkowników i mają dwa różne widoki danych. Podczas odświeżania pamięci podręcznej zapytań usługa Power BI generuje dwa zestawy zapytań.

Raporty Power BI

Istnieje kilka zaleceń dotyczących optymalizowania projektów raportów usługi Power BI.

Uwaga

Jeśli raporty są oparte na semantycznym modelu DirectQuery, aby uzyskać dodatkowe optymalizacje projektu raportu, zobacz Wskazówki dotyczące modelu DirectQuery w programie Power BI Desktop (Optymalizowanie projektów raportów).

Stosowanie najbardziej restrykcyjnych filtrów

Tym więcej danych, które wizualizacja musi wyświetlać, tym wolniej jest ładowana wizualizacja. Chociaż ta zasada wydaje się oczywista, łatwo zapomnieć. Załóżmy na przykład, że masz duży model semantyczny. Na podstawie tego semantycznego modelu utworzysz raport z tabelą. Użytkownicy końcowi używają fragmentatorów na stronie, aby uzyskać żądane wiersze — zazwyczaj interesuje ich tylko kilkadziesiąt wierszy.

Typowym błędem jest pozostawienie domyślnego widoku tabeli bez filtrowania — czyli wszystkich wierszy o rozmiarze 100 mln+. Dane dla tych wierszy są ładowane do pamięci i są nieskompresowane przy każdym odświeżeniu. To przetwarzanie powoduje ogromne zapotrzebowanie na pamięć. Rozwiązanie: użyj filtru "Top N", aby zmniejszyć maksymalną liczbę elementów wyświetlanych w tabeli. Możesz ustawić maksymalny element na większy niż potrzebny użytkownikom, na przykład 10 000. Wynikiem jest to, że środowisko użytkownika końcowego nie zmienia się, ale użycie pamięci znacznie spada. A co najważniejsze, wydajność się poprawia.

Podobne podejście projektowe do powyższego jest sugerowane dla każdej wizualizacji w raporcie. Zadaj sobie pytanie, czy wszystkie dane w tej wizualizacji są potrzebne? Czy istnieją sposoby filtrowania ilości danych wyświetlanych w wizualizacji przy minimalnym wpływie na środowisko użytkownika końcowego? Pamiętaj, że tabele w szczególności mogą być kosztowne.

Ograniczanie wizualizacji na stronach raportu

Powyższe zasady dotyczą jednakowo liczby wizualizacji dodanych do strony raportu. Zdecydowanie zaleca się ograniczenie liczby wizualizacji na określonej stronie raportu tylko do tego, co jest konieczne. Strony przeglądania szczegółowego i etykietki narzędzi strony raportu to doskonałe sposoby dostarczania dodatkowych szczegółów bez zacinania większej liczby wizualizacji na stronie.

Ocena wydajności wizualizacji niestandardowej

Pamiętaj, aby umieścić każdą wizualizację niestandardową w swoich tempach, aby zapewnić wysoką wydajność. Źle zoptymalizowane wizualizacje usługi Power BI mogą negatywnie wpłynąć na wydajność całego raportu.

Raporty podzielone na strony w usłudze Power BI

Projekty raportów podzielonych na strony usługi Power BI można zoptymalizować, stosując projekt najlepszych rozwiązań do pobierania danych raportu. Aby uzyskać więcej informacji, zobacz Wskazówki dotyczące pobierania danych dla raportów podzielonych na strony.

Upewnij się również, że pojemność ma wystarczającą ilość pamięci przydzielonej do obciążenia raportów podzielonych na strony.

Optymalizowanie środowiska

Środowisko usługi Power BI można zoptymalizować, konfigurując ustawienia pojemności, ustalanie rozmiaru bram danych i zmniejszając opóźnienie sieci.

Ustawienia pojemności

W przypadku korzystania z pojemności — dostępnych w przypadku jednostek SKU usługi Power BI Premium (P), licencji Premium na użytkownika (PPU) lub usługi Power BI Embedded (jednostki SKU A, A4–A6) — można zarządzać ustawieniami pojemności. Aby uzyskać więcej informacji, zobacz Licencje pojemności usługi Microsoft Fabric i Zarządzanie pojemnościami Premium.

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.

Ustalanie rozmiaru bramy

Brama jest wymagana za każdym razem, gdy usługa Power BI musi uzyskiwać dostęp do danych, które nie są dostępne bezpośrednio przez Internet. Lokalną bramę danych można zainstalować na serwerze lokalnym lub hostowanej na maszynie wirtualnej infrastruktury jako usługi (IaaS).

Aby zrozumieć obciążenia bramy i zalecenia dotyczące określania rozmiaru, zobacz Ustalanie rozmiaru lokalnej bramy danych.

Opóźnienie sieci

Opóźnienie sieci może mieć wpływ na wydajność raportu przez zwiększenie czasu wymaganego dla żądań dotarcia do usługa Power BI i dostarczenia odpowiedzi. Dzierżawy w usłudze Power BI są przypisywane do określonego regionu.

Napiwek

Aby określić lokalizację dzierżawy, zobacz Gdzie znajduje się moja dzierżawa usługi Power BI?

Gdy użytkownicy z dzierżawy uzyskują dostęp do usługa Power BI, ich żądania są zawsze kierowane do tego regionu. Gdy żądania docierają do usługa Power BI, usługa może wysyłać dodatkowe żądania — na przykład do bazowego źródła danych lub bramy danych — które również podlegają opóźnieniom sieci.

Narzędzia takie jak Azure Speed Test zapewniają wskazanie opóźnienia sieci między klientem a regionem świadczenia usługi Azure. Ogólnie rzecz biorąc, aby zminimalizować wpływ opóźnienia sieci, staraj się zachować źródła danych, bramy i pojemność usługi Power BI tak blisko, jak to możliwe. Najlepiej, że znajdują się w tym samym regionie. Jeśli opóźnienie sieci jest problemem, spróbuj zlokalizować bramy i źródła danych bliżej pojemności usługi Power BI, umieszczając je na maszynach wirtualnych hostowanych w chmurze.

Monitorowanie wydajności

Wydajność można monitorować, aby zidentyfikować wąskie gardła. Powolne zapytania — lub wizualizacje raportów — powinny być centralnym punktem ciągłej optymalizacji. Monitorowanie można wykonywać w czasie projektowania w programie Power BI Desktop lub na obciążeniach produkcyjnych w pojemnościach usługi Power BI Premium. Aby uzyskać więcej informacji, zobacz Monitorowanie wydajności raportów w usłudze Power BI.

Powiązana zawartość

Aby uzyskać więcej informacji na temat tego artykułu, zapoznaj się z następującymi zasobami: