Projektowanie skalowalnych obliczeń

  • 7 min

Model jest ustrukturyzowany. Teraz zaprojektuj obliczenia, które zapewnią wydajność i łatwość utrzymania w miarę jak rozwija się Twoje dane i zespół. Na małą skalę model ze zduplikowanymi miarami i z niespójnym nazewnictwem nadal działa, nawet jeśli nie jest idealny. Na dużą skalę zawodzi. Model z setkami miar wymaga strukturalnych decyzji projektowych, które uniemożliwiają zduplikowaną logikę, skracają czas wykonywania zapytań na dużych zestawach danych i umożliwiają nowym członkom zespołu zrozumienie i rozszerzenie modelu bez wprowadzania błędów.

W tej jednostce omówiono trzy wzorce: grupy obliczeniowe do zmniejszania proliferacji miar, zasady czytelności języka DAX dla utrzymania zespołu oraz agregacje z myślą o wydajności zapytań w dużych tabelach faktowych.

Grupy obliczania

Grupy obliczeń to obiekty modelu, które stosują ten sam wzorzec obliczeń w wielu miarach. Zamiast tworzyć oddzielne miary dla każdej odmiany, należy zdefiniować wzorzec raz i zastosować go dynamicznie.

Problem, który rozwiązują grupy obliczeniowe

Rozważmy organizację z 50 miarami podstawowymi (takimi jak Total Sales, Total Cost, Profit i Units Sold). Każda miara wymaga obliczeń od początku roku do dnia dzisiejszego, od początku kwartału do dnia dzisiejszego i od początku miesiąca do dnia dzisiejszego. Bez grup obliczeniowych jest to 50 × 3 = 150 dodatkowych miar. Dodaj porównania z poprzednim rokiem i patrzysz na 250+ wskaźników do utrzymania.

W przypadku grup obliczeń należy utworzyć jedną grupę z elementami obliczeń dla każdego wzorca analizy czasowej. Automatycznie te elementy mają zastosowanie do dowolnej miary w modelu.

Jak działają grupy obliczeń

Grupa obliczeń zawiera elementy obliczeniowe, z których każdy definiuje wyrażenie języka DAX, które modyfikuje bieżącą miarę przy użyciu polecenia SELECTEDMEASURE(). Oto grupa obliczeń analizy czasowej:

// Year-to-Date
CALCULATE(
    SELECTEDMEASURE(),
    DATESYTD('Date'[Date])
)

// Quarter-to-Date
CALCULATE(
    SELECTEDMEASURE(),
    DATESQTD('Date'[Date])
)

// Month-to-Date
CALCULATE(
    SELECTEDMEASURE(),
    DATESMTD('Date'[Date])
)

Gdy użytkownik dodaje grupę obliczeń do wizualizacji, może przełączać się między YTD, QTD i MTD dla dowolnej miary (takiej jak Total Sales, Profit lub Units Sold) bez oddzielnych miar dla każdej kombinacji.

Ciągi formatu dynamicznego

Ciągi formatu dynamicznego zmieniają format wyświetlania na podstawie kontekstu elementu obliczania. Na przykład obliczenie procentowe powinno być wyświetlane jako wartość procentowa, podczas gdy obliczenia waluty powinny być wyświetlane jako waluta, nawet w przypadku zastosowania do tej samej miary podstawowej.

// In the format string expression for a YoY % calculation item:
"0.0%"

Ciągi formatu dynamicznego zmniejszają potrzebę oddzielnych sformatowanych miar i zachowują spójność formatowania w modelu.

Wskazówka

Dowiedz się więcej o sposobie tworzenie grup obliczeniowych w Power BI.

Kiedy należy używać grup obliczeń

Użyj grup obliczeń, gdy masz co najmniej trzy miary, które wymagają zastosowania tego samego wzorca obliczeń. Typowe przypadki użycia obejmują analizę czasową (YTD, QTD, MTD), konwersję walut i obliczenia wariancji (rzeczywiste a budżet).

Dyscyplina przejrzystości kodu DAX

Na dużą skalę wraz z zespołem, który utrzymuje ponad 200 wskaźników, czytelność jest decyzją projektową, a nie osobistą preferencją. Spójny, czytelny język DAX zmniejsza błędy konserwacji i ułatwia nowym członkom zespołu zrozumienie modelu.

Zmienne

Zmienne przechowują wyniki pośrednie, zwiększają czytelność i uniemożliwiają aparatowi wielokrotne obliczanie tego samego wyrażenia:

Profit Margin =
VAR TotalRevenue = SUM(Sales[Revenue])
VAR TotalCost = SUM(Sales[Cost])
VAR ProfitAmount = TotalRevenue - TotalCost
RETURN
    DIVIDE(ProfitAmount, TotalRevenue)

Bez zmiennych to samo SUM(Sales[Revenue]) wyrażenie może pojawiać się trzy razy w złożonej mierze. Zmienne obliczają wyrażenie raz i ponownie użyją wyniku.

Wskazówka

Dowiedz się więcej na temat używania zmiennych do ulepszania formuł języka DAX.

Konwencje nazewnictwa

Spójne nazewnictwo ma kluczowe znaczenie, gdy model ma setki miar utrzymywanych przez wiele osób. Ustanów konwencje dla:

  • Nazwy miar: użyj przejrzystych, opisowych nazw, takich jak "Total Sales" lub "YoY Revenue Growth". Unikaj skrótów, które rozumie tylko oryginalny autor.
  • Nazwy zmiennych: użyj nazw opisowych, które wyjaśniają wartość pośrednią (na przykład TotalRevenue zamiast x lub temp).
  • Elementy grupy obliczeń: nazwij elementy według ich działania, a nie sposób ich działania (np. "Od początku roku", a nie "Pakiet DATESYTD").

Znaczenie opisowego nazewnictwa dotyczy również wykorzystywania sztucznej inteligencji. Gdy Copilot lub agent danych wysyła zapytanie do modelu, używa nazw miar i opisów, aby określić, które obliczenia mają być uwzględniane. Miara o nazwie "YoY Revenue Growth" daje lepsze wyniki sztucznej inteligencji niż "Calc7_v2".

Wskazówka

Copilot w Power BI może pomóc w pisaniu i wyjaśnianiu formuł DAX. Podczas pracy nad złożonymi miarami użyj Copilot, aby zasugerować ulepszenia lub wyjaśnić istniejącą logikę.

Iteratory a funkcje agregacji

Funkcje iteracyjne (SUMX, AVERAGEX, MAXX) obliczają wyrażenie wiersz po wierszu w tabeli. Funkcje agregacji (SUM, AVERAGE, MAX) działają w jednej kolumnie. W dużych ilościach danych wybór ma znaczenie:

  • Użyj funkcji agregacji podczas podsumowywania pojedynczej kolumny. Są one szybsze, ponieważ aparat może używać wstępnie utworzonych struktur danych.
  • Użyj iteratorów, gdy obliczenie wymaga wyrażenia na poziomie wiersza (na przykład Quantity × UnitPrice na wiersz).

Uwaga / Notatka

Iteratory przetwarzają każdy wiersz, co może mieć wpływ na wydajność dużych tabel faktów.

Funkcje informacyjne dla wzorców defensywnych

Funkcje informacyjne, takie jak ISBLANK, HASONEVALUE i ISINSCOPE, tworzą wzorce obronne dla miar używanych przez wiele raportów z różnymi kontekstami filtru:

Sales per Customer =
IF(
    HASONEVALUE(Customer[CustomerID]),
    DIVIDE(SUM(Sales[Amount]), 1),
    DIVIDE(SUM(Sales[Amount]), DISTINCTCOUNT(Sales[CustomerID]))
)

Te wzorce uniemożliwiają nieoczekiwane wyniki, gdy miary są używane w kontekstach, których oryginalny autor nie przewidywał.

Aggregations

Agregacje to tabele podsumowania, które przechowują wstępnie obliczone sumy na wyższym stopniu szczegółowości niż dane szczegółowe. Zapytania trafiają najpierw do tych tabel, co zwiększa wydajność dużych tabel faktów. Gdy zapytanie jest zgodne z agregacją, aparat zwraca wyniki z mniejszej tabeli podsumowania zamiast skanować miliony wierszy szczegółów.

Agregacje jako decyzja projektowa

Podejmowanie decyzji o tym, kiedy dodać agregacje i jakie stopień szczegółowości jest decyzją projektową. Monitorowanie wydajności i dostrajanie są oddzielnymi problemami operacyjnymi, ale podczas projektowania modelu należy dokonać wyboru strukturalnego.

Rozważ agregacje, gdy:

  • Tabele faktów przekraczają miliony wierszy i często używane zapytania podsumowują dane na wyższym stopniu szczegółowości (na przykład miesięczne sumy według regionu).
  • Użytkownicy zauważają wolne czasy odpowiedzi na zapytania przy wizualizacjach na poziomie podsumowania.
  • Większość interakcji z raportami nie wymaga szczegółów na poziomie wiersza.

Jak zachowanie agregacji różni się w zależności od trybu przechowywania

W trybie importu agregacje są przechowywane jako oddzielne ukryte tabele. Aparat automatycznie kieruje pasujące zapytania do tabeli agregacji.

W trybie Direct Lake same tabele delty mogą służyć jako źródła agregacji. Ponieważ Direct Lake odczytuje kolumnowe pliki Parquet, silnik obsługuje większe wolumeny danych bez agregacji w wielu scenariuszach. Dodaj agregacje tylko wtedy, gdy wzorce zapytań potwierdzają potrzebę.

Wskazówka

Dowiedz się więcej o agregacjach definiowanych przez użytkownika w Power BI.