Dziś wracamy do tematu Power BI i powiemy sobie parę słów o przesyłaniu danych w czasie rzeczywistym tworząc tak zwany stream dataset. Zapraszam serdecznie do lektury!
Power BI wyposażony jest w kilka scenariuszy przesyłu danych do usługi inicjowanych od strony aplikacji klienckiej takich jak:
- Push dataset
- Streaming dataset
- PubNub streaming dataset
W ramach niniejszego artykułu skupimy się głównie na Streaming dataset. Jest to nic innego jak “wpychanie” danych do serwisu Power BI gdzie są one tymczasowo przechowywane i wizualizowane w locie. Wybierając Streaming dataset już na samym początku warto zwrócić uwagę, że tworząc tego zestaw danych nie będziemy mogli stworzyć raportu ponieważ pod spodem nie ma żadnej bazy z której tego typu funkcjonalność mogła by skorzystać. Push data set umożliwia stworzenie raportu ale nie umożliwia stworzenia animowanych kafelków tak jak w poprzednim wypadku. Ogólnie rzecz biorąc każde z podejść dosyć znacznie się od siebie różni, zestaw różnic można znaleźć w dokumentacji, które zbiorczo zostały umieszczone w poniżej tabeli:
Na szczęście mamy możliwość wykorzystania zalet metod Push oraz Streaming tworząc podejście hybrydowe o którym powiemy sobie w dalszej części artykułu.
Przechodząc dalej możemy zadać sobie pytanie jak więc wizualizować tego typu dane? Odpowiedź jest prosta – przede wszystkim możemy wykorzystać obiekt typu Dashboard i odpowiednio skonfigurowany kafelek (Tile). Dane możemy wepchnąć wykorzystując jeden z trzech sposobów:
- Power BI REST API
- Streaming Dataset UI
- Azure Stream Analytics
W naszym scenariuszu testowym korzystając z kreatora zestawu danych wyślemy do Power BI dane wizualizujące wskaźniki SQL Server o nazwie Batch Requests per Second oraz Lock Requests per Second. Pierwszy wskaźnik zobrazuje nam ilość operacji jakie są wykonywane przez moją lokalną instancję bazy danych, drugi z kolei przedstawi ilość żądań założenia blokady. Przejdźmy zatem do praktyki! Pierwszym krokiem jest stworzenie Streaming dataset czyli standardowo będąc w przestrzeni roboczej klikamy przycisk Create w prawym górnym rogu i z listy rozwijanej wybieramy Streaming dataset:
W kolejnym kroku musimy wskazać źródło, którego chcemy wykorzystać dla naszego zbioru danych. Tak jak wspominałem jest ich trzy, my w tym miejscu wykorzystamy API:
Po kliknięciu Next będziemy musieli zdefiniować strukturę w jakiej dane będą trafiały do serwisu. W rzeczywistości sprowadza się to do zdefiniowania pól oraz ich typów danych:
W dolnej części okna widzimy JSONa z podglądem wartości. Dlaczego widzimy akurat ten format? Ponieważ właśnie w takiej formie będziemy musieli wysłać dane do usługi Power BI. W dolnej części ekranu możemy dostrzec również przycisk Historic data analysis:
Domyślnie opcja ta jest wyłączona i oznacza, że żadne dane przez nas przesłane nie będą przechowywane (tzn. będą przechowywane przez krótki okres aby można było stworzyć wizualizacje). Włączenie tej opcji pozwala przechowywać dane i ich analizę historyczną. Tak jak wspomniałem wcześniej włączenie tej opcji powoduje, że nasz zestaw danych będzie typu Hybrid (bez tej opcji otrzymamy zestaw typu Streaming):
Dlaczego zestaw nazywa się Hybrid? Ponieważ jest on połączeniem trybu Streaming (pokazującego bieżące dane) oraz trybu Push (przechowującego dane historyczne).
Po stworzeniu zestawu danych możemy kliknąć opcję API Info:
Naszym oczom powinno ukazać się okno z tzw. Push URL czyli z adresem endpointa na który powinniśmy pchać nasze dane. Mamy w tym oknie m.in. przykładowy kod w Powershell który możemy wykorzystać aby przesłać dane w formacie JSON:
Po kliknięciu Done nasz stream dataset jest gotowy. Teraz wystarczy napisać w Powershellu kod który odczyta wspomniane przeze mnie wskaźniki związane z SQL Server i wyśle je do Power BI. Udało mi się stworzyć coś takiego i cały kod wygląda następująco:
$sleepDuration = 1 $eventsToSend = 500 $endpoint = "https://api.powerbi.com/beta/..." $payload = @{Min=0;Max=0;DateTime = '' ; BatchRequestsPerSecond = 0;LockRequestsPerSecond=0; EventSource = ''} $index = 1 do { $Counter = (Get-Counter -counter "\\seequality-lapt\SQLServer:SQL Statistics\Batch Requests/sec”).CounterSamples.CookedValue $Counter2= (Get-Counter -counter "\\seequality-lapt\SQLServer:Locks(Key)\Lock Requests/sec”).CounterSamples.CookedValue $payload.DateTime = Get-Date -format s $payload.EventSource ='adrian-laptop' $payload.BatchRequestsPerSecond = $Counter $payload.LockRequestsPerSecond = $Counter2 $payload.Min=0 $payload.Max=1000 Invoke-RestMethod -Method Post -Uri "$endpoint" -Body (ConvertTo-Json @($payload)) "`nEvent {0}" -f $index $payload # 1 second sleep Start-Sleep $sleepDuration #next iteration $index++ } While ($index -le $eventsToSend) "`n{0} Events Sent" -f $eventsToSend
Pokrótce powyższy kod zawiera następujące zmienne:
- sleepDuration – zmienna przechowująca wartość w sekundach co ile dane powinny być wysyłane do usługi,
- eventsToSend – ile pakietów chcemy wysłać (jest to sztuczne ograniczenie pętli aby nie działała ona w nieskończoność)
- endpoint – zmienna przechowująca Push URL, który znaleźliśmy w oknie API Info,
- payload – zmienna przechowująca JSON, który będziemy chcieli wysyłać składający się z następujących elementów:
- Min – wartość minimalna do wykorzystania na warstwie wizualizacji,
- Max – wartość maksymalna do wykorzystania na warstwie wizualizacji,
- BatchRequestsPerSecond – wartość wskaźnika Batch Requests per Second z mojej lokalnej instancji SQL Server,
- LockRequestsPerSecond – wartość wskaźnika Lock Requests per Second z mojej lokalnej instancji SQL Server,
- DateTime – czas pobrania powyższych wskaźników,
- EventSource – źródło pobrania wskaźników (w tym wypadku mój laptop).
- index – licznik pętli
Mając ten zestaw zmiennych w pętli odczytujemy wskaźniki z perfmona (monitora wydajności) i co sekundę wysyłamy je w postaci predefiniowanego JSONa do Power BI. Liczniki nie będą pokazywać sensownych danych bez odpowiedniego obciążenia na bazie danych. Generować obciążenie tego typu na lokalnej instancji możemy na wiele sposobów – ja wykorzystałem narzędzie ostress, które świetnie sprawdza się do tego typu zastosowań.
Przejdźmy do Power BI i tam na podstawie naszego zbioru danych stwórzmy Dashboard:
W pierwszym kroku musimy nadać nazwę naszego kokpitu:
Do pustego kokpitu możemy dodać nowy kafelek (tile):
W oknie dodawania kafelka musimy wybrać typ kafelka, którym w tym przypadku będzie Custom Streaming Data:
Po kliknięciu Next musimy wybrać stworzony przez nas wcześniej zestaw danych:
W ostatnim oknie kreatora możemy wybrać typ wizualizacji jaki nas interesuje. Na moment pisania niniejszego artykułu mamy do dyspozycji następujące wizualizacje:
Na nasze potrzeby wybierzemy sobie Gauge i skonfigurujemy ją w następujący sposób:
Po stworzeniu tego obiektu możemy uruchomić nasze skrypty generujące ruch oraz skrypt Powershell wysyłający dane do Power BI. Jeśli wszystko wykonaliśmy poprawnie powinniśmy zobaczyć interaktywny obiekt typu Gauge zmieniający się na bieżąco:
Obiekt tego typu nie umożliwia analizy danych historycznych tylko pokazuje bieżący stan. Wcześniej przy tworzeniu zestawu danych zaznaczyliśmy opcję Historic Data Analysis tak więc powinniśmy mieć możliwość porównania bieżących danych z tymi z przeszłości. Taką analizę umożliwia nam chociażby wykres liniowy:
Powyżej możemy zobaczyć wykres który na bieżąco jest rysowany i mamy przy tym pewne porównanie do wartości historycznych. Jeśli stworzylibyśmy zestaw typu Push mielibyśmy możliwość przypięcia wizualizacji z raportu jednakże “nie rysowałyby się” w locie tak jak ma to miejsce powyżej.
Jak możecie zauważyć praca ze Stream datasets nie jest niczym strasznym i pozwala bardzo szybko osiągnąć ciekawe efekty. Oczywiście API możemy używać na przeróżne sposoby – w przyszłości postaram się przedstawić jak to zrobić z poziomu Microsoft Flow. Połączenie świetnego narzędzia jakim jest Microsoft Flow oraz Power BI pozwala na tworzenie bardzo fajnych przepływów bez napisania nawet jednej linii kodu co powinno być szczególnie użyteczne dla użytkowników biznesowych. Na ten moment to by było na tyle, mam nadzieję, że ten krótki tutorial nieco przybliżył wam tą technologię i będziecie mogli ją wykorzystać w swoich projektach.
- Avoiding Issues: Monitoring Query Pushdowns in Databricks Federated Queries - October 27, 2024
- Microsoft Fabric: Using Workspace Identity for Authentication - September 25, 2024
- Executing SQL queries from Azure DevOps using Service Connection credentials - August 28, 2024
Last comments