Udostępnij za pośrednictwem

Wskazówki dotyczące pobierania danych dla raportów podzielonych na strony

  • Artykuł

Ten artykuł jest przeznaczony dla Ciebie jako autor raportu projektowania raportów podzielonych na strony w usłudze Power BI. Zawiera on zalecenia ułatwiające zaprojektowanie efektywnego i wydajnego pobierania danych.

Typy źródeł danych

Raporty podzielone na strony natywnie obsługują zarówno relacyjne, jak i analityczne źródła danych. Te źródła są dalej kategoryzowane jako oparte na chmurze lub lokalne. Lokalne źródła danych — zarówno hostowane lokalnie, jak i na maszynie wirtualnej — wymagają bramy danych, aby usługa Power BI mogła nawiązać połączenie. Chmura oznacza, że usługa Power BI może łączyć się bezpośrednio przy użyciu połączenia internetowego.

Jeśli możesz wybrać typ źródła danych (prawdopodobnie w nowym projekcie), zalecamy użycie źródeł danych opartych na chmurze. Raporty podzielone na strony mogą łączyć się z mniejszym opóźnieniem sieci, zwłaszcza gdy źródła danych znajdują się w tym samym regionie co dzierżawa usługi Power BI. Ponadto można nawiązać połączenie z tymi źródłami przy użyciu logowania jednokrotnego (SSO). Oznacza to, że tożsamość użytkownika raportu może przepływać do źródła danych, co umożliwia wymuszanie uprawnień na poziomie wiersza poszczególnych użytkowników. Obecnie logowanie jednokrotne jest obsługiwane tylko w przypadku lokalnych źródeł danych SQL Server i Oracle (zobacz Obsługiwane źródła danych dla raportów podzielonych na strony usługi Power BI).

Uwaga

Chociaż obecnie nie można nawiązać połączenia z lokalnymi bazami danych przy użyciu logowania jednokrotnego, nadal można wymusić uprawnienia na poziomie wiersza. Odbywa się to przez przekazanie wbudowanego pola UserID do parametru zapytania zestawu danych. Źródło danych będzie musiało przechowywać wartości głównej nazwy użytkownika (UPN) w sposób umożliwiający poprawne filtrowanie wyników zapytania.

Rozważmy na przykład, że każdy sprzedawca jest przechowywany jako wiersz w tabeli Salesperson . Tabela zawiera kolumny dla nazwy UPN, a także region sprzedaży sprzedawcy. W czasie zapytania tabela jest filtrowana według nazwy UPN użytkownika raportu i jest również związana z faktami sprzedaży przy użyciu sprzężenia wewnętrznego. Dzięki temu zapytanie skutecznie filtruje wiersze faktów sprzedaży do wierszy z regionu sprzedaży użytkownika raportu.

Relacyjne źródła danych

Ogólnie rzecz biorąc, źródła danych relacyjnych są dobrze dostosowane do raportów w stylu operacyjnym, takich jak faktury sprzedaży. Są one również odpowiednie dla raportów, które muszą pobierać bardzo duże zestawy danych (ponad 10 000 wierszy). Relacyjne źródła danych mogą również definiować procedury składowane, które mogą być wykonywane przez zestawy danych raportu. Procedury składowane zapewniają kilka korzyści:

  • Parametryzacja
  • Hermetyzacja logiki programowania, umożliwiając bardziej złożone przygotowywanie danych (na przykład tabele tymczasowe, kursory lub funkcje zdefiniowane przez użytkownika skalarne)
  • Ulepszona łatwość konserwacji, umożliwiając łatwe aktualizowanie logiki procedury składowanej. W niektórych przypadkach można to zrobić bez konieczności modyfikowania i ponownego publikowania raportów podzielonych na strony (dostarczanie nazw kolumn i typów danych pozostaje niezmienione).
  • Lepsza wydajność, ponieważ ich plany wykonywania są buforowane do ponownego użycia
  • Ponowne używanie procedur składowanych w wielu raportach

W programie Power BI Report Builder możesz użyć projektanta zapytań relacyjnych do graficznego konstruowania instrukcji zapytania , ale tylko dla źródeł danych firmy Microsoft.

Analityczne źródła danych

Analityczne źródła danych , znane również jako modele danych lub po prostu modele, są dobrze dopasowane zarówno do raportów operacyjnych, jak i analitycznych, i mogą dostarczać szybkie podsumowane wyniki zapytań nawet w przypadku bardzo dużych ilości danych. Miary modelu i kluczowe wskaźniki wydajności mogą hermetyzować złożone reguły biznesowe w celu uzyskania podsumowania danych. Te źródła danych nie są jednak odpowiednie dla raportów, które muszą pobierać bardzo duże ilości danych (ponad 10 000 wierszy).

W programie Power BI Report Builder możesz wybrać dwóch projektantów zapytań: Projektant zapytań języka DAX usług Analysis Services i projektant zapytań MDX usług Analysis Services. Te projektanci mogą służyć do semantycznego modelu usługi Power BI (wcześniej znanego jako zestaw danych) źródeł danych lub dowolnego modelu usług SQL Server Analysis Services lub Azure Analysis Services — tabelarycznego lub wielowymiarowego.

Zalecamy korzystanie z projektanta zapytań języka DAX , który zapewnia, że jest całkowicie zgodny z potrzebami twojego zapytania. Jeśli model nie definiuje potrzebnych miar, musisz przełączyć się do trybu zapytania. W tym trybie możesz dostosować instrukcję zapytania, dodając wyrażenia (w celu uzyskania podsumowania).

Projektant zapytań MDX wymaga, aby model zawierał miary. Projektant ma dwie możliwości, które nie są obsługiwane przez projektanta zapytań języka DAX. W szczególności umożliwia:

  • Zdefiniuj elementy obliczeniowe na poziomie zapytania (w rozwiązaniu MDX).
  • Skonfiguruj regiony danych, aby żądać agregacji serwerów w grupach innych niż szczegółowe. Jeśli raport musi przedstawiać podsumowania miar częściowych lub nie addytywnych (takich jak obliczenia analizy czasowej lub różne liczby), prawdopodobnie bardziej wydajne będzie użycie agregacji serwera niż pobieranie wierszy szczegółów niskiego poziomu i podsumowanie obliczeń raportu.

Rozmiar wyniku zapytania

Ogólnie rzecz biorąc, najlepszym rozwiązaniem jest pobranie tylko danych wymaganych przez raport. Dlatego nie pobieraj kolumn ani wierszy, które nie są wymagane przez raport.

Aby ograniczyć wiersze, zawsze należy zastosować najbardziej restrykcyjne filtry i zdefiniować zapytania agregujące. Grupowanie zapytań i podsumowywanie danych źródłowych w celu pobrania wyników o wyższym stopniu szczegółowość. Rozważmy na przykład, że raport musi przedstawić podsumowanie sprzedaży sprzedawcy. Zamiast pobierać wszystkie wiersze zamówień sprzedaży, utwórz zapytanie zestawu danych, które grupuje według sprzedawcy i podsumowuje sprzedaż dla każdej grupy.

Pola oparte na wyrażeniach

Istnieje możliwość rozszerzenia zestawu danych raportu z polami na podstawie wyrażeń. Jeśli na przykład twoje zestawy danych źródła danych zawierają imię i nazwisko klienta, może być potrzebne pole, które łączy te dwa pola w celu utworzenia pełnej nazwy klienta. Aby osiągnąć to obliczenie, masz dwie opcje. Masz następujące możliwości:

  • Utwórz pole obliczeniowe, które jest polem zestawu danych na podstawie wyrażenia.
  • Wstrzykiwanie wyrażenia bezpośrednio do zapytania zestawu danych (przy użyciu natywnego języka źródła danych), co powoduje regularne pole zestawu danych.

Zalecamy tę drugą opcję, jeśli jest to możliwe. Istnieją dwa dobre powody, dla których wstrzykiwanie wyrażeń bezpośrednio do zapytania zestawu danych jest lepsze:

  • Możliwe, że źródło danych jest zoptymalizowane pod kątem oceny wyrażenia wydajniej niż usługa Power BI (szczególnie w przypadku relacyjnych baz danych).
  • Wydajność raportów została ulepszona, ponieważ nie ma potrzeby, aby usługa Power BI zmaterializować pola obliczeniowe przed renderowaniem raportu. Pola obliczeniowe mogą znacznie wydłużyć czas renderowania raportu, gdy zestawy danych pobierają dużą liczbę wierszy.

Nazwy pól

Podczas tworzenia zestawu danych jego pola są automatycznie nazwane po kolumnach zapytania. Możliwe, że te nazwy nie są przyjazne ani intuicyjne. Istnieje również możliwość, że nazwy kolumn zapytań źródłowych zawierają znaki zabronione w identyfikatorach obiektów języka RDL (np. spacje i symbole). W tym przypadku niedozwolone znaki są zastępowane znakiem podkreślenia (_).

Zalecamy najpierw sprawdzenie, czy wszystkie nazwy pól są przyjazne, zwięzłe, ale nadal zrozumiałe. Jeśli nie, zalecamy ich zmianę nazwy przed rozpoczęciem układu raportu. Wynika to z faktu, że zmienione pola nie zmieniają się w sposób pływowy do wyrażeń używanych w układzie raportu. Jeśli zdecydujesz się zmienić nazwy pól po rozpoczęciu układu raportu, musisz znaleźć i zaktualizować wszystkie uszkodzone wyrażenia.

Filtr a parametr

Prawdopodobnie projekty raportów podzielonych na strony będą miały parametry raportu. Parametry raportu są często używane do monitowania użytkownika raportu o filtrowanie raportu. Jako autor raportu podzielonego na strony masz dwa sposoby na osiągnięcie filtrowania raportów. Parametr raportu można mapować na:

  • Filtr zestawu danych, w którym przypadku wartości parametrów raportu są używane do filtrowania danych już pobranych przez zestaw danych.
  • Parametr zestawu danych, w którym przypadku wartości parametrów raportu są wstrzykiwane do zapytania natywnego wysyłanego do źródła danych.

Uwaga

Wszystkie zestawy danych raportów są buforowane na podstawie sesji przez maksymalnie 10 minut poza ich ostatnim użyciem. Zestaw danych można ponownie użyć podczas przesyłania nowych wartości parametrów (filtrowania), renderowania raportu w innym formacie lub interakcji z projektem raportu w jakiś sposób, na przykład przełączania widoczności lub sortowania.

Rozważmy następnie przykład raportu sprzedaży z pojedynczym parametrem raportu w celu filtrowania raportu według jednego roku. Zestaw danych pobiera sprzedaż przez wszystkie lata. Dzieje się tak, ponieważ parametr raportu jest mapowy na filtry zestawu danych. Raport wyświetla dane dla żądanego roku, który jest podzbiorem danych zestawu danych. Gdy użytkownik raportu zmieni parametr raportu na inny rok, a następnie wyświetli raport, usługa Power BI nie musi pobierać żadnych danych źródłowych. Zamiast tego stosuje inny filtr do już buforowanego zestawu danych. Po buforowaniu zestawu danych filtrowanie może być bardzo szybkie.

Teraz rozważ inny projekt raportu. Tym razem projekt raportu mapuje parametr raportu roku sprzedaży na parametr zestawu danych. W ten sposób usługa Power BI wprowadza wartość roku do zapytania natywnego, a zestaw danych pobiera dane tylko w tym roku. Za każdym razem, gdy użytkownik raportu zmienia wartość parametru raportu roku, a następnie wyświetla raport, zestaw danych pobiera nowy wynik zapytania tylko w tym roku.

Oba podejścia projektowe mogą filtrować dane raportu, a oba projekty mogą dobrze pracować dla projektów raportów. Zoptymalizowany projekt będzie jednak zależeć od przewidywanych ilości danych, zmienności danych i przewidywanych zachowań użytkowników raportu.

Zalecamy filtrowanie zestawów danych, jeśli przewidujesz, że inny podzbiór wierszy zestawu danych będzie ponownie używany wiele razy (co pozwala zaoszczędzić czas renderowania, ponieważ nie trzeba pobierać nowych danych). W tym scenariuszu można rozpoznać, że koszt pobierania większego zestawu danych może zostać wyprzedżony w stosunku do liczby przypadków ponownego użycia. Dlatego przydatne jest generowanie zapytań, które są czasochłonne. Należy jednak zachować ostrożność — buforowanie dużych zestawów danych na podstawie poszczególnych użytkowników może negatywnie wpłynąć na wydajność i przepływność pojemności.

Zalecamy parametryzacja zestawu danych, jeśli przewidujesz, że jest mało prawdopodobne, aby zażądano innego podzestawu wierszy zestawu danych lub, gdy liczba wierszy zestawu danych do przefiltrowania może być bardzo duża (i nieefektywna w pamięci podręcznej). Takie podejście projektowe również działa dobrze, gdy magazyn danych jest niestabilny. W takim przypadku każda zmiana wartości parametru raportu spowoduje pobranie aktualnych danych.

Źródła danych inne niż natywne

Jeśli musisz tworzyć raporty podzielone na strony na podstawie źródeł danych, które nie są natywnie obsługiwane przez raporty podzielone na strony, należy najpierw opracować model danych w programie Power BI Desktop. Dzięki temu możesz łączyć się z setkami źródeł danych obsługiwanych przez usługę Power BI. Po opublikowaniu w usługa Power BI można utworzyć raport podzielony na strony, który łączy się z semantycznym modelem usługi Power BI.

Integracja danych

Jeśli musisz połączyć dane z wielu źródeł danych, masz dwie opcje:

  • Łączenie zestawów danych raportów: jeśli źródła danych są natywnie obsługiwane przez raporty podzielone na strony, możesz rozważyć utworzenie pól obliczeniowych korzystających z funkcji Lookup lub LookupSet Report Builder.
  • Opracowywanie modelu programu Power BI Desktop: prawdopodobnie bardziej wydajne jest jednak opracowanie modelu danych w programie Power BI Desktop. Za pomocą dodatku Power Query można łączyć zapytania na podstawie dowolnego obsługiwanego źródła danych. Po opublikowaniu w usługa Power BI można utworzyć raport podzielony na strony, który łączy się z semantycznym modelem usługi Power BI.

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

Złożone typy danych programu SQL Server

Ponieważ program SQL Server jest lokalnym źródłem danych, usługa Power BI musi nawiązać połączenie za pośrednictwem bramy. Brama nie obsługuje jednak pobierania danych dla złożonych typów danych. Złożone typy danych obejmują wbudowane typy, takie jak GEOMETRY i GEOGRAPHY, oraz hierarchyid. Mogą również obejmować typy zdefiniowane przez użytkownika zaimplementowane za pomocą klasy zestawu w środowisku uruchomieniowym języka wspólnego platformy Microsoft.NET Framework (CLR).

Wykreślenie danych przestrzennych i analiz w wizualizacji mapy wymaga danych przestrzennych programu SQL Server. W związku z tym nie można pracować z wizualizacją mapy, gdy program SQL Server jest źródłem danych. Aby było jasne, będzie działać, jeśli źródłem danych jest usługa Azure SQL Database, ponieważ usługa Power BI nie łączy się za pośrednictwem bramy.

Obrazy mogą służyć do dodawania logo lub obrazów do układu raportu. Gdy obrazy odnoszą się do wierszy pobranych przez zestaw danych raportu, dostępne są dwie opcje:

  • Możliwe, że dane obrazu można również pobrać ze źródła danych (jeśli są już przechowywane w tabeli).
  • Gdy obrazy są przechowywane na serwerze internetowym, możesz użyć wyrażenia dynamicznego, aby utworzyć ścieżkę adresu URL obrazu.

Aby uzyskać więcej informacji i sugestii, zobacz Wskazówki dotyczące obrazów dla raportów podzielonych na strony.

Pobieranie nadmiarowych danych

Raport może pobierać nadmiarowe dane. Może się to zdarzyć, gdy usuniesz pola zapytania zestawu danych lub raport ma nieużywane zestawy danych. Unikaj tych sytuacji, ponieważ powodują one niepotrzebne obciążenie źródeł danych, sieci i zasobów pojemności usługi Power BI.

Usunięte pola zapytania

Na stronie Pola okna Właściwości zestawu danych można usunąć pola zapytania zestawu danych (pola zapytania są mapowane na kolumny pobrane przez zapytanie zestawu danych). Jednak program Report Builder nie usuwa odpowiednich kolumn z zapytania zestawu danych.

Jeśli musisz usunąć pola zapytania z zestawu danych, zalecamy usunięcie odpowiednich kolumn z zapytania zestawu danych. Program Report Builder automatycznie usunie wszystkie nadmiarowe pola zapytań. Jeśli zdarzy ci się usunąć pola zapytania, pamiętaj również o zmodyfikowaniu instrukcji zapytania zestawu danych, aby usunąć kolumny.

Nieużywane zestawy danych

Po uruchomieniu raportu wszystkie zestawy danych są oceniane — nawet jeśli nie są powiązane z obiektami raportu. Z tego powodu przed opublikowaniem raportu pamiętaj o usunięciu wszystkich zestawów danych testowych lub programistycznych.

Powiązana zawartość

Aby uzyskać więcej informacji związanych z tym artykułem, zapoznaj się z następującymi zasobami: