Design skalerbare beregninger

Din model er struktureret. Design nu de beregninger, der holder det effektivt og vedligeholdelsesvenligt, efterhånden som dine data og dit team vokser. I lille skala fungerer en model med duplikerede målinger og inkonsekvent navngivning stadig, selvom det ikke er ideelt. I stor skala går den i stykker. En model med hundredvis af målinger kræver strukturelle designbeslutninger, der forhindrer duplikeret logik, reducerer forespørgselstiden på store datasæt og gør det muligt for nye teammedlemmer at forstå og udvide modellen uden at introducere fejl.

Denne enhed dækker tre mønstre: beregningsgrupper til reduktion af målspredning, DAX-læsbarhedsdisciplin for teamvedligeholdelse og aggregeringer for forespørgselspræstation på store faktatabeller.

Beregningsgrupper

Beregningsgrupper er modelobjekter, der anvender det samme beregningsmønster på tværs af flere mål. I stedet for at skabe separate mål for hver variation, definerer du mønsteret én gang og anvender det dynamisk.

Problemberegningsgrupperne løser

Overvej en organisation med 50 basismål (såsom Samlet Salg, Samlet Omkostning, Fortjeneste og Solgte Enheder). Hver måling kræver beregninger for år til dato, kvartal til dato og måned til dato. Uden beregningsgrupper er det 50 × 3 = 150 ekstra mål. Læg tidligere års sammenligninger til, og du skal have 250+ målinger at vedligeholde.

Med beregningsgrupper opretter du én gruppe med beregningselementer for hvert tidsintelligensmønster. Disse elementer gælder automatisk for ethvert mål i modellen.

Hvordan beregningsgrupper fungerer

En beregningsgruppe indeholder beregningselementer, hvor hver definerer et DAX-udtryk, der ændrer det aktuelle mål ved hjælp af SELECTEDMEASURE(). Her er en gruppe for tidsintelligens-beregninger:

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

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

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

Når en bruger tilføjer beregningsgruppen til et visuelt program, kan de skifte mellem YTD, QTD og MTD for enhver måling (såsom samlet salg, overskud eller solgte enheder) uden separate mål for hver kombination.

Strenge i dynamisk format

Dynamiske formatstrenge ændrer visningsformatet baseret på beregningsobjektets kontekst. For eksempel bør en procentberegning vises som en procent, mens valutaberegninger skal vises som valuta, selv når de anvendes på det samme basismål.

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

Dynamiske formatstrenge reducerer behovet for separate formaterede målinger og holder formateringen ensartet på tværs af modellen.

Hvornår skal man bruge beregningsgrupper

Brug beregningsgrupper, når du har tre eller flere mål, der kræver samme beregningsmønster. Almindelige anvendelsestilfælde inkluderer tidsintelligens (YTD, QTD, MTD), valutakonvertering og variansberegninger (faktisk vs. budget).

DAX læsbarhedsdisciplin

I stor skala med et team, der opretholder 200+ målinger, er læsbarhed et designvalg, ikke en personlig præference. Konsistent, læsbar DAX reducerer vedligeholdelsesfejl og gør det lettere for nye teammedlemmer at forstå modellen.

Variabler

Variabler gemmer mellemliggende resultater, forbedrer læsbarheden og forhindrer motoren i at evaluere det samme udtryk flere gange:

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

Uden variable kan det samme SUM(Sales[Revenue]) udtryk forekomme tre gange i en kompleks måling. Variabler evaluerer udtrykket én gang og genbruger resultatet.

Navngivningskonventioner

Ensartet navngivning er afgørende, når din model har hundredvis af målinger, der vedligeholdes af flere personer. Etabler konventioner for:

• Mål navne: Brug klare, beskrivende navne som "Samlet salg" eller "Årlig omsætningsvækst." Undgå forkortelser, som kun den oprindelige forfatter forstår.
• Variabelnavne: Brug beskrivende navne, der forklarer mellemværdien (såsom TotalRevenue i stedet for x eller temp).
• Beregningsgruppeelementer: Navngiv elementer efter, hvad de gør, ikke hvordan de fungerer (såsom "Year-to-Date" i stedet for "DATESYTD Wrapper").

Beskrivende navngivning har også betydning for AI-forbruget. Når Copilot eller en dataagent forespørger din model, bruger den målnavne og beskrivelser til at bestemme, hvilke beregninger der skal inkluderes. Et mål kaldet "YoY Revenue Growth" giver bedre AI-resultater end "Calc7_v2."

Iteratorer vs. aggregeringsfunktioner

Iteratorfunktioner (SUMX, AVERAGEX, ) MAXXevaluerer et række-for-række-udtryk over en tabel. Aggregeringsfunktioner (SUM, AVERAGE, ) MAXopererer på en enkelt kolonne. Ved store datamængder er valget vigtigt:

• Brug aggregeringsfunktioner, når du opsummerer en enkelt kolonne. De er hurtigere, fordi motoren kan bruge forudbyggede datastrukturer.
• Brug iteratorer, når beregningen kræver et rækkeniveau-udtryk (for eksempel Quantity × UnitPrice per række).

Informationsfunktioner for defensive mønstre

Informationsfunktioner som ISBLANK, HASONEVALUE, og ISINSCOPE skaber forsvarsmønstre for målinger, der forbruges af flere rapporter med forskellige filterkontekster:

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

Disse mønstre forhindrer uventede resultater, når målinger anvendes i sammenhænge, som den oprindelige forfatter ikke havde forudset.

Sammenlægninger

Aggregeringer er oversigtstabeller, der gemmer forudberegnede totaler med en højere korn end detaljedataene. Forespørgsler rammer disse tabeller først, hvilket forbedrer ydeevnen på store faktatabeller. Når en forespørgsel matcher en aggregering, returnerer motoren resultater fra den mindre oversigtstabel i stedet for at scanne millioner af detaljerækker.

Aggregeringer som designbeslutning

At beslutte, hvornår man skal tilføje aggregeringer, og med hvilken granularitet, er en designbeslutning. Ydelsesovervågning og tuning er separate operationelle bekymringer, men du træffer det strukturelle valg under modeldesignet.

Overvej aggregeringer, når:

• Faktatabeller overstiger millioner af rækker, og almindeligt anvendte forespørgsler opsummerer data med højere korn (såsom månedlige totaler efter region).
• Brugere oplever langsomme svartider på forespørgselsniveau-visualiseringer.
• De fleste rapportinteraktioner behøver ikke række-niveau detaljer.

Hvordan aggregeringsadfærd adskiller sig efter lagringstilstand

I importtilstand gemmes aggregeringer som separate skjulte tabeller. Motoren videresender automatisk matchende forespørgsler til aggregeringstabellen.

I Direct Lake-tilstand kan Delta-tabellerne selv fungere som aggregationskilder. Fordi Direct Lake læser kolonneformede Parquet-filer, kan motoren håndtere større datamængder uden aggregationer i mange scenarier. Tilføj kun aggregeringer, når forespørgselsmønstre bekræfter behovet.