Oszacowanie jednostki SKU usługi Power BI Embedded: ostateczny przewodnik na rok 2025

Dekonstrukcja pojemności usługi Power BI

Proces wyboru właściwej jednostki magazynowej (SKU) dla rozwiązania Power BI Embedded to kluczowa decyzja dotycząca architektury i finansów. W tej sekcji przedstawiono dekonstrukcję krajobrazu pojemności usługi Power BI, przedstawiając podstawową analizę dostępnych rodzin jednostek SKU.

1.1. Podstawowa zasada: dedykowana vs. na użytkownika

Licencjonowanie na użytkownika (Pro)

Idealny do wewnętrznego BI, gdzie zdefiniowany zbiór licencjonowanych użytkowników tworzy i wykorzystuje raporty w ramach usługi Power BI.

Pojemność dedykowana (wbudowana)

Obowiązkowe w przypadku scenariuszy „aplikacja jest właścicielem danych”, zapewniająca zarezerwowaną pulę zasobów do udostępniania analiz nielicencjonowanym użytkownikom aplikacji.

Podstawowym przypadkiem użycia usługi Power BI Embedded jest scenariusz „aplikacja jest właścicielem danych”. Aby ten model mógł funkcjonować w produkcji, wymagana jest dedykowana pojemność. Pojemność to pula zarezerwowanych zasobów obliczeniowych — rdzeni wirtualnych i pamięci — przydzielonych wyłącznie do przetwarzania obciążeń.

1.2. Interaktywne porównanie SKU

Użyj poniższych filtrów, aby porównać rodziny SKU według różnych atrybutów. Pozwala to na bezpośrednie porównanie modeli wydajnościowych i zakupowych.

Wszystkie jednostki SKU
Płatność zgodnie z rzeczywistym użyciem
Zobowiązanie
Wstrzymaj/Wznów
Aplikacja jest właścicielem danych
Zalecane do nowych projektów

Anatomia obciążenia pracą

Oszacowanie wymaganej pojemności SKU nie jest prostą sprawą zliczenia użytkowników. „Obciążenie pracą” to złożona interakcja wielu czynników, z których każdy składa się na zapotrzebowanie na zasoby zdolności produkcyjnej.

Kluczowe czynniki wpływające na zapotrzebowanie na pojemność

Szczytowe obciążenie jednoczesne

Jednocześnie aktywni użytkownicy, a nie wszyscy użytkownicy.

Zgłoś złożoność

Liczba wizualizacji i interakcji na stronę.

Model danych

Rozmiar, tryb łączności i złożoność języka DAX.

Odświeżanie danych

Obciążenie w tle z aktualizacji zestawu danych.

2.1. Dekonstrukcja „renderowania strony”

„Renderowanie strony” to jednostka miary interaktywnego obciążenia pracą. Jest on liczony za każdym razem, gdy ładowane lub odświeżane są elementy wizualne, włączając w to widok początkowy, filtrowanie, wycinanie lub drążenie szczegółów. Każda akcja wysyła zapytania do wydajności zaplecza, zużywając cykle procesora. Obciążenie jest bezpośrednią funkcją złożoności raportu.

2.2. Analiza modelu danych: silnik pod maską

Projekt podstawowego modelu danych usługi Power BI (model semantyczny) jest krytycznym czynnikiem wpływającym zarówno na wymagania dotyczące pamięci, jak i procesora. Obejmuje to jego rozmiar, tryb łączności i złożoność obliczeń.

Tryb importu

Dane są ładowane do pojemności usługi Power BI. Zapewnia to bardzo dużą wydajność zapytań, ale zużywa pamięć i procesor w przypadku wszystkich zapytań i odświeżeń. Jest ograniczony przez limity pamięci jednostki SKU.

Tryb bezpośredniego zapytania

Power BI wysyła zapytania do źródłowej bazy danych w czasie rzeczywistym. Jest to idealne rozwiązanie w przypadku bardzo dużych zbiorów danych i zmniejsza obciążenie pamięci, ale przenosi zależność wydajności od zewnętrznego źródła danych.

Źle napisane obliczenia w języku DAX (Data Analysis Expressions) mogą również być „cichym zabójcą” wydajności, zużywając nieproporcjonalnie dużo procesora. Optymalizacja języka DAX to kluczowy krok przed testowaniem obciążenia.

2.3. Strategia odświeżania danych: obciążenie w tle

Odświeżanie dużych zestawów danych może wymagać dużych zasobów. Jeśli odświeżenia mają miejsce w godzinach szczytu, konkurują z zapytaniami użytkowników, co prowadzi do ograniczania przepustowości. Najlepszą praktyką jest planowanie odświeżań poza godzinami szczytu i stosowanie odświeżania przyrostowego, które aktualizuje tylko zmienione dane, radykalnie zmniejszając obciążenie tła.

Odśwież porównanie strategii

Pełne odświeżenie

Ponownie ładuje cały zestaw danych. Wysokie zużycie zasobów. Długi czas trwania.

→

Odświeżanie przyrostowe

Ładuje ponownie tylko nowe lub zmienione dane. Niskie zużycie zasobów. Krótki czas trwania.

2.4. Lista kontrolna ilościowego obciążenia pracą

Skorzystaj z tej listy kontrolnej, aby określić ilościowo profil obciążenia aplikacji i wstępnie oszacować jednostkę SKU.

Maksymalna liczba jednoczesnych użytkowników

Spełnia wymagania rdzeni wirtualnych.

Śr. Interakcje / Użytkownik / Godziny szczytu

Szacuje łączną liczbę „renderowań stron” w godzinach szczytu.

Największy rozmiar zbioru danych (GB)

Określa minimalną pamięć RAM jednostki SKU.

Podstawowy tryb łączności

Import
Zapytanie bezpośrednie
Mieszany

Określa, gdzie znajduje się obciążenie zapytania.

Złożoność języka DAX

Niski
Średni
Wysoki

Wysoka złożoność zwiększa wykorzystanie procesora.

Czy zastosowano odświeżanie przyrostowe?

Tak
NIE

„Tak” radykalnie zmniejsza obciążenie tła.

Zestaw narzędzi do szacowania

Oszacowanie teoretyczne stanowi punkt wyjścia, ale weryfikacja empiryczna nie podlega negocjacjom. Microsoft udostępnia w tym celu pakiet narzędzi, umożliwiający cykl przewidywania, pomiaru i działania.

3.1. Faza 1: Przedprodukcyjna symulacja obciążenia

Narzędzie do oceny obciążenia wydajności usługi Power BI to specjalnie zaprojektowane narzędzie do automatyzowania testów obciążenia w oparciu o pojemność. Jest to główny sposób sprawdzenia wyboru SKU przed rozpoczęciem produkcji. Narzędzie to, skrypt PowerShell o otwartym kodzie źródłowym, symuluje jednoczesnych użytkowników i stosuje filtry w celu wygenerowania realistycznego obciążenia zapytaniami, unikając wyników przechowywanych w pamięci podręcznej.

# Example: Running the load assessment tool
.Run-PBITests.ps1 -pbiUsername "[email protected]" -pbiPassword "your_password" `
-pbiWorkspaceName "MyTestWorkspace" -pbiReportName "ComplexSalesReport" `
-tenantId "your_tenant_id" -appId "your_app_id" -appSecret "your_app_secret" `
-concurrency 50

Najlepiej testować iteracyjnie, zaczynając od małej liczby użytkowników i ekstrapolując wyniki.

3.2. Faza 2: Monitorowanie produkcji

Po uruchomieniu aplikacja Microsoft Fabric Performance Metrics staje się niezbędnym narzędziem do monitorowania. Zapewnia szczegółowy widok wydajności pojemności. Strona „Obliczenia” przedstawia wykres szeregów czasowych zużycia jednostek wydajności (CU), podkreślając okresy przeciążenia. Klikając punkt czasowy prawym przyciskiem myszy, możesz przeglądać szczegółowo każdą operację, użytkownika, który ją zainicjował, i dokładny koszt zasobów.

3.3. Faza 3: Proaktywne zarządzanie i automatyzacja

Dojrzała strategia obejmuje proaktywną, zautomatyzowaną kontrolę przy użyciu interfejsów API Azure Monitor i Power BI. Tworzy to kompletną, zautomatyzowaną pętlę sprzężenia zwrotnego na potrzeby skalowania.

Pętla sprzężenia zwrotnego autoskalowania

1. Wykryto wysoki procesor

Azure Monitor śledzi procesor > 95%

→

2. Alarm wyzwala działanie

Wywoływany jest element Runbook automatyzacji

→

3. Nawiązano połączenie API

Skrypt wywołuje punkt końcowy aktualizacji wydajności

→

4. Zwiększa się pojemność

SKU zostało zaktualizowane (np. F16 do F32)

Ta praktyka, znana jako automatyczne skalowanie, jest najskuteczniejszym sposobem radzenia sobie z nieprzewidywalnymi obciążeniami, zapewniając płynną obsługę użytkownika w godzinach szczytu i minimalizując koszty w okresach przerw.

Strategiczne ramy wyboru SKU

Efektywne zarządzanie wydajnością nie jest jednorazową decyzją, ale ciągłym cyklem życia obejmującym szacowanie, walidację, monitorowanie i optymalizację. Ten czteroetapowy schemat kieruje procesem.

Krok 1:Wykształcone domysły

Zacznij od wybrania najmniejszej jednostki SKU, która Twoim zdaniem może w sposób wiarygodny obsłużyć dane obciążenie pracą, w oparciu o dane z listy kontrolnej. Jeśli największy zbiór danych wynosi 12 GB, minimalnym punktem wyjścia będzie F64 (limit 25 GB). Łatwiej uzasadnić zwiększanie skali niż obrona zbyt dużej początkowej pojemności.

Krok 2:Kontrola rzeczywistości

Rygorystycznie przetestuj swój początkowy wybór SKU za pomocą narzędzia do oceny obciążenia. Jeśli procesor wzrasta do 100% i ogranicza użytkowników, jednostka SKU jest za mała. Powtórz test, zwiększając rozmiar o kolejny rozmiar. Jeśli wygodnie radzi sobie z obciążeniem (np. szczytowe obciążenie procesora 60-70%), masz empiryczne dowody na swój wybór.

Krok 3:Uruchomienie i linia bazowa

Wdróż w środowisku produkcyjnym i wykorzystaj pierwsze kilka tygodni na ustalenie bazowej wydajności w świecie rzeczywistym dzięki aplikacji Fabric Pojemność Metrics. Te dane obserwacyjne dotyczące rzeczywistych zachowań użytkowników stanowią podstawę wszelkich przyszłych optymalizacji.

Krok 4:Ciągła optymalizacja

Pojemność nie polega na tym, że „ustaw i zapomnij”. Użyj ciągłego cyklu optymalizacji. Wdrażaj dynamiczne skalowanie (zaplanowane skrypty lub automatyczne skalowanie), aby obsługiwać szczyty i wstrzymywać wydajność w okresach przestoju, aby obniżyć koszty o ponad 70%.

4.1. Interaktywna analiza kosztów i korzyści

Po ustabilizowaniu się obciążenia pracą można przeprowadzić ostateczną optymalizację finansową. Wystąpienie zarezerwowane na 1 rok oferuje znaczną zniżkę w przypadku przewidywalnych, stałych obciążeń.

Skorzystaj z poniższego wykresu, aby zwizualizować kompromis pomiędzy elastycznym rozliczeniem według rzeczywistego użycia a oszczędnościami wynikającymi ze zobowiązania. Wybierz SKU, aby zobaczyć porównanie kosztów.

Wybierz SKU do analizy:

F32/A2 (4 rdzenie typu V)
F64 / A4 (8 rdzeni V)
F128 / A5 (16 rdzeni typu V)
F256 / A6 (32 rdzenie typu V)

Kluczowe zalecenia

• Domyślne jednostki SKU Fabric „F”:W przypadku wszystkich nowych projektów zacznij od nowoczesnej, przyszłościowej rodziny SKU „F”.
• Najpierw zoptymalizuj, kup później:Strojenie wydajności jest bezpośrednią dźwignią optymalizacji kosztów.
• Wykorzystaj pętlę „Przewiduj – Zmierz – Działaj”:Stale korzystaj z narzędzi do iteracji i dostosowywania rozmiaru wydajności.
• Dopasuj koszty do zużycia:Wstrzymuj wydajność w czasie bezczynności i korzystaj z automatycznego skalowania w celu obsługi szczytów.
• Rezerwa na stabilność:Zatwierdź wystąpienie zarezerwowane dopiero po ustabilizowaniu się obciążenia.

Typowe pułapki, których należy unikać

• Szacowanie na podstawie całkowitej liczby użytkowników:Planuj dla największej liczby jednoczesnych użytkowników, a nie dla wszystkich zarejestrowanych użytkowników.
• Pomijanie testów obciążenia:Walidacja empiryczna nie jest opcjonalna.
• Używanie pojemności jako kuli:Nie używaj większego SKU, aby zrekompensować niezoptymalizowane raporty.
• Nastawienie „ustaw i zapomnij”:Stale monitoruj i dostosowuj wydajność.
• Zbyt wczesne dokonanie rezerwacji:Eliminuje to elastyczność i może skutkować wysokimi kosztami.