Bruk av aggregasjoner i Power BI DesktopUse aggregations in Power BI Desktop

Aggregasjoner i Power BI gjør det mulig for deg å redusere tabellstørrelser slik at du kan fokusere på viktige data og forbedre ytelsen til spørringer.Aggregations in Power BI let you reduce table sizes so you can focus on important data and improve query performance. Aggregasjoner muliggjør interaktiv analyse fra stordata på måter som ellers ikke er mulig, og reduserer kostnaden betydelig ved å tilgjengeliggjøre informasjon fra store datasett så du kan foreta informerte beslutninger.Aggregations enable interactive analysis over big data in ways that aren't possible otherwise, and can dramatically reduce the cost of unlocking large datasets for decision making.

Her er noen fordeler ved å bruke aggregasjoner:Some advantages of using aggregations include:

  • Bedre ytelse på spørring av stordata.Better query performance over big data. Hver interaksjon med Power BI-visualobjekter sender DAX-spørringer til datasettet.Every interaction with Power BI visuals submits DAX queries to the dataset. Bufrede aggregasjonsdata bruker en brøkdel av ressursene som kreves for detaljerte data, slik at du får tilgang til informasjon fra stordata som ellers ville vært utilgjengelig.Cached aggregated data uses a fraction of the resources required for detail data, so you can unlock big data that would otherwise be inaccessible.
  • Optimalisert dataoppdatering.Optimized data refresh. Mindre bufferstørrelser reduserer oppdateringstidene, noe som gjør at brukerne får data raskere.Smaller cache sizes reduce refresh times, so data gets to users faster.
  • Balanserte arkitekturer.Balanced architectures. Minneintern buffer i Power BI kan håndtere aggregerte spørringer og dermed begrense spørringer i DirectQuery-modus. Dette hjelper deg med å operere innenfor samtidighetsgrensene.The Power BI in-memory cache can handle aggregated queries, limiting queries sent in DirectQuery mode and helping you meet concurrency limits. Andre detaljerte spørringer pleier å være filtrerte spørringer på transaksjonsnivå, noe som datalagre og stordatasystemer vanligvis håndterer uten problem.The remaining detail-level queries tend to be filtered, transactional-level queries, which data warehouses and big-data systems normally handle well.

Aggregasjoner i Microsoft Power BI Desktop

Dimensjonale datakilder, blant annet datalagre og datatorg, kan bruke relasjonsbaserte aggregasjoner.Dimensional data sources, like data warehouses and data marts, can use relationship-based aggregations. Hadoop-baserte stordatakilder baserer ofte aggregasjoner på GroupBy-kolonner.Hadoop-based big-data sources often base aggregations on GroupBy columns. Denne artikkelen beskriver vanlige modelleringsforskjeller i Power BI for hver type datakilde.This article describes typical Power BI modeling differences for each type of data source.

Oppretting av en aggregert tabellCreate an aggregated table

Slik oppretter du en aggregert tabell:To create an aggregated table:

  1. Opprett en ny tabell med feltene du vil ha i henhold til datakilde og modell.Set up a new table with the fields you want, depending on your data source and model.
  2. Definer aggregasjoner i dialogboksen Administrere aggregasjoner.Define the aggregations by using the Manage aggregations dialog.
  3. Hvis det er aktuelt, kan du endre lagringsmodus for den aggregerte tabellen.If applicable, change the storage mode for the aggregated table.

Administrer aggregasjonerManage aggregations

Når du har opprettet den nye tabellen med feltene du vil ha, høyreklikker du på tabellen i feltruten i en Power BI Desktop-visning, og velger Administrere aggregasjoner.After you create the new table that has the fields you want, in the Fields pane of any Power BI Desktop view, right-click the table, and select Manage aggregations.

Velg Administrere aggregasjoner

Dialogboksen Administrere aggregasjoner viser en rad for hver kolonne i tabellen, og der kan du angi funksjonen for aggregasjonen.The Manage aggregations dialog shows a row for each column in the table, where you can specify the aggregation behavior. I følgende eksempel er spørringer til detaljtabellen Sales (Salg) omdirigert internt til aggregasjonstabellen Sales Agg (Aggregerte salg).In the following example, queries to the Sales detail table are internally redirected to the Sales Agg aggregation table.

I rullegardinmenyen til Oppsummering i dialogboksen Administrere aggregasjoner vises følgende verdier:The Summarization drop-down in the Manage aggregations dialog offers the following values:

  • CountCount
  • GroupByGroupBy
  • MaxMax
  • MinMin
  • SumSum
  • Antall tabellraderCount table rows

Skjermbilde viser dialogboksen Behandle aggregasjoner.

I dette eksempelet på relasjonsbasert aggregasjon er GroupBy-oppføringene valgfrie.In this relationship-based aggregation example, the GroupBy entries are optional. Unntak er DISTINCTCOUNT ettersom den ikke påvirker aggregasjonen og er hovedsakelig for å gi lesbarhet.Except for DISTINCTCOUNT, they don't affect aggregation behavior, and are primarily for readability. Uten GroupBy-oppføringene ville aggregasjonene fremdeles få treff, basert på relasjonene.Without the GroupBy entries, the aggregations would still get hit, based on the relationships. Dette er i motsetning til stordataeksempelet senere i artikkelen, der GroupBy-oppføringer er nødvendige.This is different from the big data example later in this article, where the GroupBy entries are required.

Når du har definert aggregasjonene du vil bruke, velger du Bruk alle.After defining the aggregations you want, select Apply All.

ValideringerValidations

Dialogboksen Administrere aggregasjoner setter i gang følgende valideringer som du bør merke deg:The Manage aggregations dialog enforces the following notable validations:

  • Detaljkolonnen må ha samme datatype som aggregasjonskolonnen, bortsett fra oppsummeringsfunksjonene Antall og Antall tabellrader.The Detail Column must have the same datatype as the Aggregation Column, except for the Count and Count table rows Summarization functions. Antall og Antall tabellrader er bare tilgjengelig for aggregasjonskolonner med heltall, og krever ikke en samsvarende datatype.Count and Count table rows are only available for integer aggregation columns, and don't require a matching datatype.
  • Kjedede aggregasjoner som dekker tre eller flere tabeller er ikke tillatt.Chained aggregations covering three or more tables aren't allowed. Aggregasjoner i tabell A kan for eksempel ikke referere til en tabell B med aggregasjoner som refererer til en tabell C.For example, aggregations on Table A can't refer to a Table B that has aggregations referring to a Table C.
  • Dupliserte aggregasjoner der to oppføringer bruker samme oppsummeringsfunksjon og refererer til samme detaljtabell og detaljkolonne, er ikke tillatt.Duplicate aggregations, where two entries use the same Summarization function and refer to the same Detail Table and Detail Column, aren't allowed.
  • Detaljtabellen må bruke DirectQuery-lagringsmodus, ikke importmodus.The Detail Table must use DirectQuery storage mode, not Import.
  • Gruppering gjennom en sekundærnøkkelkolonne som brukes av en inaktiv relasjon og som må bruke funksjonen USERELATIONSHIP for aggregasjonstreff, støttes ikke.Grouping by a foreign key column used by an inactive relationship, and relying on the USERELATIONSHIP function for aggregation hits, isn't supported.

De fleste valideringer foretas ved å deaktivere verdier i rullegardinlisten og vise forklarende tekst i verktøytipset, som vist i følgende illustrasjon.Most of the validations are enforced by disabling dropdown values and showing explanatory text in the tooltip, as shown in the following image.

Valideringer som vises av verktøytips

Aggregasjonstabeller er skjultAggregation tables are hidden

Brukere med bare lesetilgang til datasettet kan ikke spørre aggregasjonstabeller.Users with read-only access to the dataset can't query aggregation tables. Med dette unngår man sikkerhetsproblemer når det brukes sikkerhet på radnivå (RLS) .This avoids security concerns when used with row-level security (RLS). Forbrukere og spørringer forholder seg til detaljtabellen, ikke aggregasjonstabellen, og trenger ikke engang vite om aggregasjonsstabellen.Consumers and queries refer to the detail table, not the aggregation table, and don't need to know about the aggregation table.

Av den grunn er aggregasjonstabeller skjult fra rapportvisningen.For this reason, aggregation tables are hidden from Report view. Hvis tabellen ikke allerede er skjult, vil dialogboksen Administrere aggregasjoner sette den til skjult når du velger Bruk alle.If the table isn't already hidden, the Manage aggregations dialog will set it to hidden when you select Apply all.

LagringsmoduserStorage modes

Aggregasjonsfunksjonen fungerer sammen med lagringsmoduser på tabellnivå.The aggregation feature interacts with table-level storage modes. Power BI-tabeller kan bruke lagringsmodusene DirectQuery, Import eller Dobbel.Power BI tables can use DirectQuery, Import, or Dual storage modes. DirectQuery spør serverdelen direkte, mens Import bufrer data i minnet og sender spørringer til de bufrede dataene.DirectQuery queries the backend directly, while Import caches data in memory and sends queries to the cached data. Alle importdatakilder og ikke-flerdimensjonale DirectQuery-datakilder i Power BI fungerer med aggregasjoner.All Power BI Import and non-multidimensional DirectQuery data sources can work with aggregations.

Du kan foreta spørringer raskere ved å sette lagringsmodus for en aggregert tabell til Import. Det gjør du ved å velge den aggregerte tabellen i Power BI Desktop fra visningen Modell.To set the storage mode of an aggregated table to Import to speed up queries, select the aggregated table in Power BI Desktop Model view. I ruten Egenskaper utvider du Avansert, åpner utvalget under Lagringsmodus og velger Import.In the Properties pane, expand Advanced, drop down the selection under Storage mode, and select Import. Vær oppmerksom på at denne handlingen ikke kan angres.Note that this action is irreversible.

Innstilling av lagringsmodus

Du finner mer informasjon om lagringsmodus for tabeller i artikkelen Administrere lagringsmodus i Power BI Desktop.For more information about table storage modes, see Manage storage mode in Power BI Desktop.

Sikkerhet på radnivå (RLS) for aggregasjonerRLS for aggregations

RLS-uttrykk bør filtrere både aggregasjonstabellen og detaljtabellen for å fungere på riktig måte med aggregasjoner.To work correctly for aggregations, RLS expressions should filter both the aggregation table and the detail table.

I det følgende eksemplet fungerer RLS-uttrykket på tabellen Geography (Geografi) med aggregasjoner fordi Geography er på filtreringssiden av relasjoner til både tabellene Sales (Salg) og Sales Agg (Aggregerte salg).In the following example, the RLS expression on the Geography table works for aggregations, because Geography is on the filtering side of relationships to both the Sales table and the Sales Agg table. Både spørringer som har treff i aggregasjonstabellen og de som ikke har, får aktivert RLS.Queries that hit the aggregation table and those that don't will both have RLS successfully applied.

Vellykket aktivering av sikkerhet på radnivå (RLS) for aggregasjoner

Et RLS-uttrykk på tabellen Product (Produkt) filtrerer bare detaljtabellen Sales, ikke aggregasjonstabellen Sales Agg.An RLS expression on the Product table filters only the detail Sales table, not the aggregated Sales Agg table. Ettersom aggregasjonstabellen er en annen representasjon av de samme dataene i detaljtabellen, vil det være utrygt å svare på spørringer fra aggregasjonstabellen hvis RLS-filteret ikke kan brukes.Since the aggregation table is another representation of the data in the detail table, it would be insecure to answer queries from the aggregation table if the RLS filter can't be applied. Filtrering av bare detaljtabellen anbefales ikke ettersom brukerspørringer fra denne rollen ikke kan dra nytte av aggregasjonstreff.Filtering only the detail table isn't recommended, because user queries from this role won't benefit from aggregation hits.

Et RLS-uttrykk som bare filtrerer aggregasjonstabellen Sales Agg og ikke detaljtabellen Sales, er ikke tillatt.An RLS expression that filters only the Sales Agg aggregation table and not the Sales detail table isn't allowed.

Det er ikke tillatt med sikkerhet på radnivå på kun aggregasjonstabeller

I aggregasjoner basert på GroupBy-kolonner kan et RLS-uttrykk på detaljtabellen brukes til å filtrere aggregasjonstabellen fordi alle GroupBy-kolonner i aggregasjonstabellen dekkes av detaljtabellen.For aggregations based on GroupBy columns, an RLS expression applied to the detail table can be used to filter the aggregation table, because all the GroupBy columns in the aggregation table are covered by the detail table. På den andre siden kan ikke et RLS-filter på aggregasjonstabellen brukes på detaljtabellen, så det er ikke tillatt.On the other hand, an RLS filter on the aggregation table can't be applied to the detail table, so is disallowed.

Aggregasjon basert på relasjonerAggregation based on relationships

Dimensjonsmodeller bruker ofte aggregasjoner basert på relasjoner.Dimensional models typically use aggregations based on relationships. Power BI-datasett fra datalagre og datatorg ligner på stjerne- eller snøfnugg-skjemaer med relasjoner mellom dimensjonstabeller og faktatabeller.Power BI datasets from data warehouses and data marts resemble star/snowflake schemas, with relationships between dimension tables and fact tables.

I følgende modell fra én enkelt datakilde bruker tabellene DirectQuery-lagringsmodus.In the following model from a single data source, the tables are using DirectQuery storage mode. Faktatabellen Salg inneholder milliarder med rader.The Sales fact table contains billions of rows. Det krever svært mye minne og administrasjon hvis du angir lagringsmodus for Sales til Import for bufring.Setting the storage mode of Sales to Import for caching would consume considerable memory and management overhead.

Detaljtabeller i en modell

Opprett i stedet aggregasjonstabellen Sales Agg.Instead, create the Sales Agg aggregation table. I tabellen Sales Agg er antallet rader likt summen av SalesAmount, gruppert etter CustomerKey, DateKey og ProductSubcategoryKey.In the Sales Agg table, the number of rows equals the sum of SalesAmount grouped by CustomerKey, DateKey, and ProductSubcategoryKey. Tabellen Sales Agg er mer detaljert enn Sales, så i stedet for milliarder kan den inneholde millioner av rader, noe som er mye enklere å administrere.The Sales Agg table is at a higher granularity than Sales, so instead of billions, it might contain millions of rows, which are much easier to manage.

Hvis følgende dimensjonstabeller er de som brukes mest for spørringer med høy forretningsverdi, kan de filtrere Sales Agg ved hjelp av relasjonene én-til-mange eller mange-til-én.If the following dimension tables are the most commonly used for the queries with high business value, they can filter Sales Agg, using one-to-many or many-to-one relationships.

  • GeografiGeography
  • KundeCustomer
  • DatoDate
  • Underkategori for produktProduct Subcategory
  • ProduktkategoriProduct Category

Bildet nedenfor viser denne modellen.The following image shows this model.

Aggregasjonstabell i en modell

Tabellen nedenfor viser aggregasjoner for Salgsagg-tabellen.The following table shows the aggregations for the Sales Agg table.

Aggregasjoner for tabellen Sales Agg

Obs!

Tabellen Sales Agg, som enhver tabell, har fleksibilitet til å lastes inn på en rekke måter.The Sales Agg table, like any table, has the flexibility of being loaded in a variety of ways. Aggregasjon kan utføres i kildedatabasen ved hjelp av ETL/ELT-prosesser, eller med M-uttrykket for tabellen.The aggregation can be performed in the source database using ETL/ELT processes, or by the M expression for the table. Den aggregerte tabellen kan bruke lagringsmodusen Import med eller uten trinnvis oppdatering i Power BI Premium, eller den kan bruke DirectQuery og bli optimalisert for raske spørringer ved hjelp av kolonnelagerindekser.The aggregated table can use Import storage mode, with or without incremental refresh in Power BI Premium, or it can use DirectQuery and be optimized for fast queries using columnstore indexes. Denne fleksibiliteten muliggjør balanserte arkitekturer som sprer spørringsbelastningen for å unngå flaskehalser.This flexibility enables balanced architectures that can spread query load to avoid bottlenecks.

Hvis du endrer lagringsmodus for den aggregerte tabellen Sales Agg til Import, åpner en dialogboks som sier at de relaterte dimensjonstabellene kan settes til lagringsmodus Dobbel.Changing the storage mode of the aggregated Sales Agg table to Import opens a dialog box saying that the related dimension tables can be set to storage mode Dual.

Dialogboks for lagringsmodus

Hvis du setter dem til Dobbel, kan de relaterte dimensjonstabellene fungere som enten Import eller DirectQuery, avhengig av delspørringen.Setting the related dimension tables to Dual lets them act as either Import or DirectQuery, depending on the subquery. Se på eksemplet:In the example:

  • Spørringer kan returneres fra minneintern buffer hvis de aggregerer måledata fra tabellen Sales Agg, som er i importmodus, og grupperer etter attributter fra relaterte tabeller i dobbelmodus.Queries that aggregate metrics from the Import-mode Sales Agg table, and group by attribute(s) from the related Dual tables, can be returned from the in-memory cache.
  • Spørringer kan returneres i DirectQuery-modus hvis de aggregerer måledata fra DirectQuery-tabellen Sales, og grupperer etter attributter fra relaterte tabeller i dobbelmodus.Queries that aggregate metrics from the DirectQuery Sales table, and group by attribute(s) from the related Dual tables, can be returned in DirectQuery mode. Spørringslogikken, inkludert GroupBy-handlingen, overføres til kildedatabasen.The query logic, including the GroupBy operation, is passed down to the source database.

Du finner mer informasjon om lagringsmodusen Dobbel i artikkelen Administrere lagringsmodus i Power BI Desktop.For more information about Dual storage mode, see Manage storage mode in Power BI Desktop.

Vanlige kontra begrensede relasjonerRegular vs. limited relationships

Aggregasjonstreff basert på relasjoner krever vanlige relasjoner.Aggregation hits based on relationships require regular relationships.

Vanlige relasjoner inkluderer følgende kombinasjoner av lagringsmodus der begge tabellene er fra én enkelt kilde:Regular relationships include the following storage mode combinations, where both tables are from a single source:

Tabell på mange-sideneTable on the many sides Tabell på 1-sidenTable on the 1 side
DobbelDual DobbelDual
ImportImport Import eller DobbelImport or Dual
DirektespørringDirectQuery DirectQuery eller DobbelDirectQuery or Dual

Det eneste tilfellet der en relasjon mellom kilder anses som vanlig, er hvis begge tabellene er satt til Import.The only case where a cross-source relationship is considered regular is if both tables are set to Import. Mange-til-mange-relasjoner betraktes alltid som begrensede.Many-to-many relationships are always considered limited.

Du finner mer informasjon om aggregasjonstreff mellom kilder som ikke avhenger av relasjoner i artikkelen Aggregasjoner basert på GroupBy-kolonner.For cross-source aggregation hits that don't depend on relationships, see Aggregations based on GroupBy columns.

Eksempler på relasjonsbaserte aggregasjonsspørringerRelationship-based aggregation query examples

Følgende spørring treffer aggregasjonen, fordi kolonnene i Dato-tabellen har en tetthet som treffer aggregasjonen.The following query hits the aggregation, because columns in the Date table are at the granularity that can hit the aggregation. Kolonnen SalesAmount (Salgssum) bruker aggregasjonen Sum.The SalesAmount column uses the Sum aggregation.

Vellykket relasjonsbasert aggregasjonsspørring

Følgende spørring finner ingen treff i aggregasjonen.The following query doesn't hit the aggregation. Selv om den spør etter sum for SalesAmount, utfører spørringen en GroupBy-operasjon på en kolonne i tabellen Product. Denne har ikke et detaljnivå som gjør at den kan finne treff i aggregasjonen.Despite requesting the sum of SalesAmount, the query is performing a GroupBy operation on a column in the Product table, which isn't at the granularity that can hit the aggregation. Hvis du ser på relasjonene i modellen, kan en produktunderkategori ha flere produktrader.If you observe the relationships in the model, a product subcategory can have multiple Product rows. Spørringen ville ikke kunne avgjøre hvilket produkt som skal aggregeres.The query wouldn't be able to determine which product to aggregate to. I dette tilfellet tilbakestilles spørringen til DirectQuery, og en SQL-spørring sendes til datakilden.In this case, the query reverts to DirectQuery and submits a SQL query to the data source.

Spørring som ikke kan bruke aggregasjonen

Aggregasjoner er ikke bare for enkle beregninger som utfører enkle summeringer.Aggregations aren't just for simple calculations that perform a straightforward sum. Kompliserte beregninger kan også dra nytte av dem.Complex calculations can also benefit. Begrepsmessig er en kompleks beregning delt opp i delspørringer for hver SUM, MIN, MAX og COUNT, og hver delspørring evalueres for å avgjøre om den kan få treff i aggregasjonen.Conceptually, a complex calculation is broken down into subqueries for each SUM, MIN, MAX, and COUNT, and each subquery is evaluated to determine if it can hit the aggregation. Denne logikken er ikke sann i alle tilfeller på grunn av optimalisering av spørringsplan, men generelt sett gjelder den.This logic doesn't hold true in all cases due to query-plan optimization, but in general it should apply. Følgende eksempel finner treff i aggregasjonen:The following example hits the aggregation:

Kompleks aggregasjonsspørring

COUNTROWS-funksjonen kan dra nytte av aggregasjoner.The COUNTROWS function can benefit from aggregations. Følgende spørring finner treff i aggregasjonen fordi en Antall tabellrader-aggregasjon er definert for tabellen Sales.The following query hits the aggregation because there is a Count table rows aggregation defined for the Sales table.

Aggregasjonsspørringen COUNTROWS (Antall rader)

AVERAGE-funksjonen kan dra nytte av aggregasjoner.The AVERAGE function can benefit from aggregations. Denne spørringen finner treff i aggregasjonen fordi internt GJENNOMSNITT slås sammen til en SUM dividert på et ANTALL.The following query hits the aggregation because AVERAGE internally gets folded to a SUM divided by a COUNT. Siden UnitPrice-kolonnen har aggregasjoner definert for både SUM og COUNT, treffes aggregasjonen.Since the UnitPrice column has aggregations defined for both SUM and COUNT, the aggregation is hit.

Aggregasjonsspørringen AVERAGE (Gjennomsnitt)

I noen tilfeller kan DISTINCTCOUNT-funksjonen dra nytte av aggregasjoner.In some cases, the DISTINCTCOUNT function can benefit from aggregations. Denne spørringen finner treff i aggregasjonen fordi det finnes en Grupper_etter-oppføring for kundenøkkel, som opprettholder den spesifikke kundenøkkelen i aggregasjonsstabellen.The following query hits the aggregation because there is a GroupBy entry for CustomerKey, which maintains the distinctness of CustomerKey in the aggregation table. Denne teknikken kan likevel nå ytelsesterskelen, der mer enn to til fem millioner spesifikke verdier kan påvirke spørringsytelsen.This technique might still hit the performance threshold where more than two to five million distinct values can affect query performance. Dette kan imidlertid være nyttig i scenarioer der det er milliarder av rader i detaljtabellen, men to til fem millioner spesifikke verdier i kolonnen.However, it can be useful in scenarios where there are billions of rows in the detail table, but two to five million distinct values in the column. I dette tilfellet kan DISTINCTCOUNT gi raskere ytelse enn skanning av tabellen med milliarder av rader, selv om den bufres i minnet.In this case, the DISTINCTCOUNT can perform faster than scanning the table with billions of rows, even if it were cached into memory.

Aggregasjonsspørringen DISTINCTCOUNT

DAX-funksjonen for tidsintelligens-funksjoner er bevisste på aggregasjon.DAX time-intelligence functions are aggregation aware. Følgende spørring treffer aggregasjonen fordi DATESYTD-funksjonen genererer en tabell med Kalenderdag verdier, og aggregasjon tabellen er i en tetthet som er dekket for grupper - etter kolonner i tabellen dato.The following query hits the aggregation because the DATESYTD function generates a table of CalendarDay values, and the aggregation table is at a granularity that is covered for group-by columns in the Date table. Dette er et eksempel på et filter med tabellverdier til CALCULATE-funksjonen, som kan fungere med aggregeringer.This is an example of a table-valued filter to the CALCULATE function, which can work with aggregations.

SUMMARIZECOLUMNS aggregasjon spørring

Aggregasjon basert på GroupBy-kolonnerAggregation based on GroupBy columns

Hadoop-baserte modeller for store data har andre egenskaper enn dimensjonsmodeller.Hadoop-based big data models have different characteristics than dimensional models. For å unngå koblinger mellom store tabeller bruker store datamodeller ofte ikke relasjoner, men avnormaliserer dimensjonsattributter til faktatabeller.To avoid joins between large tables, big data models often don't use relationships, but denormalize dimension attributes to fact tables. Du kan få informasjon fra slike store datamodeller til interaktiv analyse ved å bruke aggregasjoner basert på GroupBy-kolonner.You can unlock such big data models for interactive analysis by using aggregations based on GroupBy columns.

Tabellen nedenfor inneholder den numeriske Flytting-kolonnen som skal aggregeres.The following table contains the Movement numeric column to be aggregated. Alle andre kolonner er attributter til GroupBy (Grupper etter).All the other columns are attributes to group by. Tabellen inneholder Tingenes Internett-data og et veldig stort antall rader.The table contains IoT data and a massive number of rows. Lagringsmodus er DirectQuery.The storage mode is DirectQuery. Spørringer i datakilden som aggregeres på tvers av hele datasettet, er trege på grunn av selve volumet.Queries on the data source that aggregate across the whole dataset are slow because of the sheer volume.

En IoT-tabell

Hvis du vil aktivere interaktiv analyse på datasettet, kan du legge til en aggregasjonstabell som grupperer etter de fleste attributtene, men utelater attributter med høy kardinalitet, for eksempel lengdegrad og breddegrad.To enable interactive analysis on this dataset, you can add an aggregation table that groups by most of the attributes, but excludes the high-cardinality attributes like longitude and latitude. Denne reduserer antall rader dramatisk og er liten nok til å få god plass i en minnehurtighuffer.This dramatically reduces the number of rows, and is small enough to comfortably fit into an in-memory cache.

Driveraktivitet-agg-tabellen

Du definerer aggregasjonstilordninger for tabellen Driver Activity Agg (Aggregasjon av driveraktivitet) i dialogboksen Administrere aggregasjoner.You define the aggregation mappings for the Driver Activity Agg table in the Manage aggregations dialog.

Dialogboksen Administrere aggregasjoner for Driveraktivitet-agg-tabellen

I aggregasjoner som er basert på GroupBy-kolonner, er ikke GroupBy-oppføringer valgfritt.In aggregations based on GroupBy columns, the GroupBy entries aren't optional. Uten dem blir det ikke treff i aggregasjonene.Without them, the aggregations won't get hit. Dette er i motsetning til bruk av aggregasjoner basert på relasjoner, der det er valgfritt med GroupBy-oppføringer.This is different from using aggregations based on relationships, where the GroupBy entries are optional.

Tabellen nedenfor viser aggregasjoner for Driver Activity Agg-tabellen.The following table shows the aggregations for the Driver Activity Agg table.

Aggregasjonstabell for Driver Activity Agg

Du kan sette lagringsmodus for den aggregerte tabellen Driver Activity Agg til Import.You can set the storage mode of the aggregated Driver Activity Agg table to Import.

Eksempel på GroupBy-aggregasjonsspørringGroupBy aggregation query example

Den følgende spørringen finner treff i aggregasjonen fordi kolonnen Activity date (Aktivitetsdato) dekkes av aggregasjonsstabellen.The following query hits the aggregation, because the Activity Date column is covered by the aggregation table. COUNTROWS-funksjonen bruker aggregasjonen Antall tabellrader.The COUNTROWS function uses the Count table rows aggregation.

Vellykket GroupBy-aggregasjonsspørring

Spesielt for modeller med filterattributter i faktatabeller er det lurt å bruke aggregasjonen Antall tabellrader.Especially for models that contain filter attributes in fact tables, it's a good idea to use Count table rows aggregations. Power BI kan sende spørringer til datasettet ved å bruke COUNTROWS i tilfeller der det ikke er eksplisitt forespurt av brukeren.Power BI may submit queries to the dataset using COUNTROWS in cases where it is not explicitly requested by the user. Dialogboksen filter viser for eksempel antall rader for hver verdi.For example, the filter dialog shows the count of rows for each value.

Filterdialogboksen

Kombinasjon av aggregasjonsteknikkerCombined aggregation techniques

Du kan kombinere teknikkene relasjoner og GroupBy-kolonner for aggregasjoner.You can combine the relationships and GroupBy columns techniques for aggregations. Aggregasjoner basert på relasjoner kan kreve at de avnormaliserte dimensjonstabellene deles inn i flere tabeller.Aggregations based on relationships may require the denormalized dimension tables to be split into multiple tables. Hvis dette er en kostbar prosess eller upraktisk for enkelte dimensjonstabeller, kan du replikere de nødvendige attributtene i aggregasjonstabellen for disse dimensjonene, og bruke relasjoner for andre.If this is costly or impractical for certain dimension tables, you can replicate the necessary attributes in the aggregation table for those dimensions, and use relationships for others.

Den følgende modellen replikerer for eksempel Month (Måned), Quarter (Kvartal), Semester og Year (År) i tabellen Sales Agg.For example, the following model replicates Month, Quarter, Semester, and Year in the Sales Agg table. Det er ingen relasjon mellom tabellene Sales Agg og Date (Dato), men det finnes relasjoner til Customer (Kunde) og underkategorien Product.There is no relationship between Sales Agg and the Date table, but there are relationships to Customer and Product Subcategory. Lagringsmodusen for Salgs-agg er Importer.The storage mode of Sales Agg is Import.

Kombinasjon av aggregasjonsteknikker

Tabellen nedenfor viser oppføringene som er angitt i dialogboksen Administrere aggregasjoner for Salgsagg-tabellen.The following table shows the entries set in the Manage aggregations dialog for the Sales Agg table. GroupBy-oppføringene der Date er detaljtabellen, er obligatoriske for å treffe aggregasjoner for spørringer som grupperer etter attributtene i Date.The GroupBy entries where Date is the detail table are mandatory, to hit aggregations for queries that group by the Date attributes. Som vist tidligere påvirker ikke GroupBy-oppføringer for CustomerKey og ProductSubcategoryKey aggregasjonstreff på grunn av tilstedeværelsen av relasjoner, med unntak av DISTINCTCOUNT.As in the previous example, the GroupBy entries for CustomerKey and ProductSubcategoryKey don't affect aggregation hits, except for DISTINCTCOUNT, because of the presence of relationships.

Oppføringer for aggregasjonstabellen Sales Agg

Eksempler på kombinert aggregasjonsspørringCombined aggregation query examples

Følgende spørring har treff i aggregasjonen fordi CalendarMonth (Kalendermåned) dekkes av aggregasjonsstabellen, og CategoryName (Kategorinavn) er tilgjengelig via én-til-mange-relasjoner.The following query hits the aggregation, because the aggregation table covers CalendarMonth, and CategoryName is accessible via one-to-many relationships. SalesAmount bruker aggregasjonen SUM.SalesAmount uses the SUM aggregation.

Eksempel på spørring med treff i aggregasjonen

Følgende spørring finner ikke treff i aggregasjonen fordi CalendarDay (Kalenderdag) ikke dekkes av aggregasjonsstabellen.The following query doesn't hit the aggregation, because the aggregation table doesn't cover CalendarDay.

Skjermbilde viser tekst i en spørring som inkluderer CalendarDay.

Følgende tidsintelligensspørring har ikke treff i aggregasjonen fordi DATESYTD-funksjonen genererer en tabell med CalendarDay-verdier, og aggregasjonsstabellen dekker ikke CalendarDay.The following time-intelligence query doesn't hit the aggregation, because the DATESYTD function generates a table of CalendarDay values, and the aggregation table doesn't cover CalendarDay.

Skjermbilde viser tekst i en spørring som inkluderer DATESYTD-funksjonen.

AggregasjonsprioritetAggregation precedence

Aggregasjonsprioritet tillater at flere aggregasjonstabeller vurderes av én enkelt delspørring.Aggregation precedence allows multiple aggregation tables to be considered by a single subquery.

Følgende eksempel er en sammensatt modell med flere kilder:The following example is a composite model containing multiple sources:

  • DirectQuery-tabellen Driver Activity (Driveraktivitet) inneholder mer enn en billion rader med Tingenes Internett-data fra et stordatasystem.The Driver Activity DirectQuery table contains over a trillion rows of IoT data sourced from a big-data system. Den sørger for at ekstraheringsspørringer viser individuelle IoT-avlesninger i kontrollerte filterkontekster.It serves drillthrough queries to view individual IoT readings in controlled filter contexts.
  • Driveraktivitet-agg-tabellen er en mellomliggende aggregasjonstabell i DirectQuery-modus.The Driver Activity Agg table is an intermediate aggregation table in DirectQuery mode. Den inneholder over en milliard rader i Azure SQL Data Warehouse og er optimalisert i kilden ved hjelp av kolonnelagerindekser.It contains over a billion rows in Azure SQL Data Warehouse and is optimized at the source using columnstore indexes.
  • Importtabellen Driver Activity Agg2 har høyt detaljnivå fordi GroupBy-attributtene er få og har lav kardinalitet.The Driver Activity Agg2 Import table is at a high granularity, because the group-by attributes are few and low cardinality. Antall rader kan være så få som noen tusen, slik at de enkelt passer inn i en minnehurtigbuffer.The number of rows could be as low as thousands, so it can easily fit into an in-memory cache. Disse attributtene brukes tilfeldigvis av et høyprofilert administrativt instrumentbord, slik at spørringer som refererer til dem er så raske som mulig.These attributes happen to be used by a high-profile executive dashboard, so queries referring to them should be as fast as possible.

Obs!

DirectQuery-aggregasjonstabeller som bruker en annen datakilde enn detaljtabellen, støttes bare hvis aggregasjonstabellen er fra en kilde i SQL Server, Azure SQL eller Azure SQL Data Warehouse.DirectQuery aggregation tables that use a different data source from the detail table are only supported if the aggregation table is from a SQL Server, Azure SQL, or Azure SQL Data Warehouse source.

Minnekapasiteten til denne modellen er relativt liten, men den låser opp et stort datasett.The memory footprint of this model is relatively small, but it unlocks a huge dataset. Det representerer en balansert arkitektur fordi den sprer innlastingen av spørringer på tvers av komponentene i arkitekturen, og utnytter dem basert på hvilken styrke hver enkelt har.It represents a balanced architecture because it spreads the query load across components of the architecture, utilizing them based on their strengths.

Tabeller for en modell med liten minnekapasitet som låser opp et stort datasett

Dialogboksen Administrere aggregasjoner for Driver Activity Agg2 setter feltet Prioritet til 10, noe som er høyere enn for Driver Activity Agg.The Manage aggregations dialog for Driver Activity Agg2 sets the Precedence field to 10, which is higher than for Driver Activity Agg. Den høyere prioritetsinnstillingen betyr at spørringer som bruker aggregasjoner vil vurdere Driver Activity Agg2 først.The higher precedence setting means queries that use aggregations will consider Driver Activity Agg2 first. Delspørringer som ikke har et detaljnivå som kan besvares av Driver Activity Agg2, vurderer Driver Activity Agg i stedet.Subqueries that aren't at the granularity that can be answered by Driver Activity Agg2 will consider Driver Activity Agg instead. Detaljspørringer som ikke kan besvares av noen av aggregasjonsstabellene, blir henvist til Driveraktivitet.Detail queries that cannot be answered by either aggregation table will be directed to Driver Activity.

Tabellen som er angitt i kolonnen i detaljtabellen er Driver Activity, og ikke Driver Activity Agg, ettersom kjedede aggregasjoner er ikke tillatt.The table specified in the Detail Table column is Driver Activity, not Driver Activity Agg, because chained aggregations are not allowed.

Skjermbilde viser dialogboksen Behandle aggregasjoner med Prioritet valgt.

Tabellen nedenfor viser aggregasjoner for Driver Activity Agg2-tabellen.The following table shows the aggregations for the Driver Activity Agg2 table.

Aggregasjonstabell for Driver Activity Agg2

Slik ser du om spørringer får eller ikke får treff i aggregasjonerDetect whether queries hit or miss aggregations

SQL Profiler kan gjenkjenne om spørringer returneres fra lagringsmotoren i minneintern buffer eller er overført til datakilden av DirectQuery.SQL Profiler can detect whether queries are returned from the in-memory cache storage engine, or pushed to the data source by DirectQuery. Du kan bruke samme prosessen til å finne ut om det er treff i aggregasjoner.You can use the same process to detect whether aggregations are being hit. Du finner mer informasjon i artikkelen Spørringer som får eller ikke får treff i bufferen.For more information, see Queries that hit or miss the cache.

SQL Profiler har også den utvidede hendelsen Query Processing\Aggregate Table Rewrite Query.SQL Profiler also provides the Query Processing\Aggregate Table Rewrite Query extended event.

JSON-snutten nedenfor viser et eksempel på utdataene for hendelsen når en aggregasjon brukes.The following JSON snippet shows an example of the output of the event when an aggregation is used.

  • matchingResult viser at delspørringen brukte en aggregasjon.matchingResult shows that the subquery used an aggregation.
  • dataRequest viser GroupBy-kolonnene og de aggregerte kolonnene som delspørringen brukte.dataRequest shows the GroupBy column(s) and aggregated column(s) the subquery used.
  • tilordning viser kolonnene i aggregasjonstabellen det ble til tilordnet til.mapping shows the columns in the aggregation table that were mapped to.

Utdata for en hendelse ved bruk av aggregasjoner

Det er viktig å holde buffere synkronisertKeep caches in sync

Aggregasjoner som kombinerer lagringsmodusene DirectQuery, Import og/eller Dobbel, kan returnere ulike data med mindre den minneinterne bufferen er synkronisert med kildedataene.Aggregations that combine DirectQuery, Import, and/or Dual storage modes may return different data unless the in-memory cache is kept in sync with the source data. Spørringskjøring vil for eksempel ikke forsøke å skjule problemer med data ved å filtrere DirectQuery-resultater til å samsvare med bufrede verdier.For example, query execution won't attempt to mask data issues by filtering DirectQuery results to match cached values. Det finnes etablerte teknikker for å håndtere slike problemer i kilden hvis det er nødvendig.There are established techniques to handle such issues at the source, if necessary. Ytelsesoptimaliseringer bør kun brukes på måter som ikke går på bekostning av evnen til å oppfylle forretningsmessige krav.Performance optimizations should be used only in ways that don't compromise your ability to meet business requirements. Det er ditt ansvar å kjenne dine egne dataflytprosesser og handle ut fra dette.It's your responsibility to know your data flows and design accordingly.

Neste trinnNext steps

Du finner mer informasjon om sammensatte modeller i artiklene:For more information about composite models, see:

Du finner mer informasjon om DirectQuery i artiklene:For more information about DirectQuery, see: