Teknikker til datareduktion i forbindelse med importmodellerData reduction techniques for Import modeling

Denne artikel henvender sig til Power BI Desktop-datamodeludviklere, der udvikler importmodeller.This article targets Power BI Desktop data modelers developing Import models. Heri beskrives de forskellige teknikker, der hjælper med at reducere de data, der indlæses i importmodeller.It describes different techniques to help reduce the data loaded into Import models.

Importmodeller indlæses med data, der komprimeres og optimeres og derefter gemmes på disken af VertiPaq-lagringsprogrammet.Import models are loaded with data that is compressed and optimized and then stored to disk by the VertiPaq storage engine. Når kildedata indlæses i hukommelsen, kan de blive komprimeret op til 10 gange, og det er derfor rimeligt at forvente, at 10 GB kildedata kan komprimeres til ca. 1 GB.When source data is loaded into memory, it is possible to see 10x compression, and so it is reasonable to expect that 10 GB of source data can compress to about 1 GB in size. Når de desuden bevares på en disk, kan de blive yderligere reduceret med 20 %.Further, when persisted to disk an additional 20% reduction can be achieved.

På trods af den effektivitet, der opnås af VertiPaq-lagringsprogrammet, er det vigtigt, at du bestræber dig på at minimere de data, der skal indlæses i dine modeller.Despite the efficiencies achieved by the VertiPaq storage engine, it is important that you strive to minimize the data that is to be loaded into your models. Det er især tilfældet for store modeller, eller modeller, som du forventer, vil vokse, så de bliver store med tiden.It is especially true for large models, or models that you anticipate will grow to become large over time. Fire overbevisende årsager omfatter:Four compelling reasons include:

  • Større modeller understøttes muligvis ikke af din kapacitet.Larger model sizes may not be supported by your capacity. Delt kapacitet kan hoste modeller med en størrelse på op til 1 GB, mens Premium-kapaciteter kan hoste modeller på op til 13 GB.Shared capacity can host models up to 1 GB in size, while Premium capacities can host models up to 13 GB in size. Du kan finde flere oplysninger i artiklen Power BI Premium-understøttelse af store datasæt.For further information, read the Power BI Premium support for large datasets article.
  • Mindre modeller reducerer konflikter i forbindelse med kapacitetsressourcer, især hukommelse.Smaller model sizes reduce contention for capacity resources, in particular memory. Det gør det muligt at indlæse flere modeller samtidigt i længere tid, hvilket resulterer i lavere fjernelseshyppighed.It allows more models to be concurrently loaded for longer periods of time, resulting in lower eviction rates. Du kan finde flere oplysninger under Administration af Premium-kapacitet.For more information, see Managing Premium capacities.
  • Data i mindre modeller opdateres hurtigere, hvilket medfører rapportering om lavere ventetid, højere gennemløb i forbindelse med opdatering af datasæt og mindre tryk på kildesystemet og kapacitetsressourcerne.Smaller models achieve faster data refresh, resulting in lower latency reporting, higher dataset refresh throughput, and less pressure on source system and capacity resources.
  • Et mindre antal tabelrækker kan resultere i hurtigere beregning i forbindelse med evaluering, hvilket kan levere en bedre overordnet ydeevne af forespørgsler.Smaller table row counts can result in faster calculation evaluations, which can deliver better overall query performance.

Der er otte forskellige teknikker til datareduktion, som dækkes i denne artikel.There are eight different data reduction techniques covered in this article. Disse teknikker omfatter:These techniques include:

Fjern unødvendige kolonnerRemove unnecessary columns

Der er to primære formål med modellens tabelkolonner:Model table columns serve two main purposes:

  • Rapportering for at få et rapportdesign, der filtrerer, grupperer og opsummerer modeldata på en passende mådeReporting, to achieve report designs that appropriate filter, group, and summarize model data
  • Modelstruktur for at understøtte modelrelationer, modelberegninger, sikkerhedsroller og tilmed formatering af datafarverModel structure, by supporting model relationships, model calculations, security roles, and even data color formatting

Kolonner, der ikke opfylder disse formål, kan sandsynligvis fjernes.Columns that don't serve these purposes can probably be removed. Fjernelse af kolonner omtales som lodret filtrering.Removing columns is referred to as vertical filtering.

Vi anbefaler, at du designer modeller med præcis det rette antal kolonner baseret på de kendte rapporteringskrav.We recommend that you design models with exactly the right number of columns based on the known reporting requirements. Dine krav kan naturligvis ændre sig over tid, men vær opmærksom på, at det er nemmere at tilføje kolonner senere, end det er at fjerne dem.Your requirements may change over time, but bear in mind that it's easier to add columns later than it is to remove them later. Hvis du fjerner kolonner, kan det ødelægge rapporter eller modelstrukturen.Removing columns can break reports or the model structure.

Fjern unødvendige rækkerRemove unnecessary rows

Modeltabeller skal indlæses med så få rækker som muligt.Model tables should be loaded with as few rows as possible. Det kan opnås ved at indlæse filtrerede rækkesæt i modeltabeller af to forskellige årsager: for at filtrere efter enhed eller efter klokkeslæt.It can be achieved by loading filtered rowsets into model tables for two different reasons: to filter by entity or by time. Fjernelse af rækker omtales som vandret filtrering.Removing rows is referred to as horizontal filtering.

Filtrering efter enhed omfatter indlæsning af et undersæt af kildedata i modellen.Filtering by entity involves loading a subset of source data into the model. I stedet for at indlæse salgsfakta for alle salgsområder, kan du f.eks. nøjes med at indlæse fakta for et enkelt område.For example, instead of loading sales facts for all sales regions, only load facts for a single region. Denne designtilgang vil resultere i mange mindre modeller, og den kan også fjerne behovet for at definere sikkerhed på rækkeniveau, men den kræver, at der gives bestemte tilladelser til datasæt i Power BI-tjenesten, og at der oprettes "duplikerede" rapporter, som opretter forbindelse til hvert datasæt.This design approach will result in many smaller models, and it can also eliminate the need to define row-level security (but will require granting specific dataset permissions in the Power BI service, and creating "duplicate" reports that connect to each dataset). Du kan udnytte brugen af Power Query-parametre og Power BI-skabelonfiler for at forenkle administration og publicering.You can leverage the use of Power Query parameters and Power BI Template files to simplify management and publication. Du kan finde flere oplysninger ved at læse blogindlægget Detaljeret gennemgang af forespørgselsparametre og Power BI-skabeloner.For further information, read the Deep Dive into Query Parameters and Power BI Templates blog entry.

Filtering efter tid omfatter begrænsning af mængden af datahistorik, der indlæses i faktatabeller (og begrænsning af de datorækker, der indlæses i modeldatatabellerne).Filtering by time involves limiting the amount of data history loaded into fact-type tables (and limiting the date rows loaded into the model date tables). Vi foreslår, at du ikke automatisk indlæser al tilgængelig historik, medmindre det er et kendt rapporteringskrav.We suggest you don't automatically load all available history, unless it is a known reporting requirement. Det er nyttigt at forstå, at tidsbaserede Power Query-filtre kan parameteriseres og tilmed angives til at bruge relative tidsperioder (i forhold til opdateringsdatoen, f.eks. de seneste fem år).It is helpful to understand that time-based Power Query filters can be parameterized, and even set to use relative time periods (relative to the refresh date, for example, the past five years). Du skal også være opmærksom på, at tilbagevirkende ændringer af tidsfiltre ikke ødelægger rapporter. Det medfører blot, at der er mindre (eller mere) datahistorik tilgængelig i rapporterne.Also, bear in mind that retrospective changes to time filters will not break reports; it will just result in less (or more) data history available in reports.

Gruppér efter og opsummerGroup by and summarize

Den mest effektive teknik til at reducere en modelstørrelse er måske nok at indlæse data, der allerede er opsummeret.Perhaps the most effective technique to reduce a model size is to load pre-summarized data. Denne teknik kan bruges til at gøre faktatabeller mindre detaljerede.This technique can be used to raise the grain of fact-type tables. Manglen på detaljer er dog én markant konsekvens.There is a distinct trade-off, however, resulting in loss of detail.

Der gemmes f.eks. én række pr. ordrelinje i en kildefaktatabel over salg.For example, a source sales fact table stores one row per order line. Der kan opnås en betydelig datareduktion ved at opsummere alle salgsmålinger og gruppere dem efter dato, kunde og produkt.Significant data reduction could be achieved by summarizing all sales metrics, grouping by date, customer, and product. Overvej derefter, at en endnu mere betydelig datareduktion kan opnås ved at gruppere efter dato på månedsniveau.Consider, then, that an even more significant data reduction could be achieved by grouping by date at month level. Det kan resultere i en mulig reduktion af modelstørrelsen på 99 %, men det vil ikke længere være muligt at rapportere på dagsniveau eller på individuelt ordreniveau.It could achieve a possible 99% reduction in model size, but reporting at day level—or individual order level—is no longer possible. Der er altid en konsekvens ved at opsummere faktatabeller.Deciding to summarize fact-type data always involves tradeoffs. Denne konsekvens kan afhjælpes ved at bruge et design med en blandet model. Denne mulighed beskrives i teknikken Skift til blandet model.Tradeoff could be mitigated by a Mixed model design, and this option is described in the Switch to Mixed mode technique.

Optimer kolonnedatatyperOptimize column data types

Der bruges separate datastrukturer for hver kolonne i VertiPaq-lagringsprogrammet.The VertiPaq storage engine uses separate data structures for each column. Disse datastrukturer resulterer med vilje i den højeste optimering for numeriske kolonnedata, hvor der bruges værdikodning.By design, these data structures achieve the highest optimizations for numeric column data, which use value encoding. Der bruges dog hashkodning til tekst og andre ikke-numeriske data.Text and other non-numeric data, however, uses hash encoding. Det kræver, at der i lagringsprogrammet tildeles et numerisk id til hver enkelt entydige tekstværdi, der findes i kolonnen.It requires the storage engine to assign a numeric identifier to each unique text value contained in the column. Det er derefter det numeriske id, der gemmes i datastrukturen, så der kræves et hashopslag under lagring og forespørgsler.It is the numeric identifier, then, that is then stored in the data structure, requiring a hash lookup during storage and querying.

I nogle bestemte tilfælde kan du konvertere kildetekstdata til numeriske værdier.In some specific instances, you can convert source text data into numeric values. Et salgsordrenummer kan f.eks. have en ensartet foranstillet tekstværdi (f.eks. "SO123456").For example, a sales order number may be consistently prefixed by a text value (e.g. "SO123456"). Den foranstillede værdi kan fjernes, og ordrenummerværdien konverteres til tal.The prefix could be removed, and the order number value converted to whole number. I forbindelse med store tabeller kan det medføre betydelige datareduktioner, især når kolonnen indeholder entydige værdier eller værdier med høj kardinalitet.For large tables, it can result in significant data reduction, especially when the column contains unique or high cardinality values.

I dette eksempel anbefaler vi, at du angiver egenskaben for kolonnen Standardopsummering til "Opsummer ikke".In this example, we recommend that you set the column Default Summarization property to "Do Not Summarize". Det vil hjælpe med at minimere forkert opsummering af ordrenummerværdierne.It will help to minimize the inappropriate summarization of the order number values.

Præference for brugerdefinerede kolonnerPreference for custom columns

I VertiPaq-lagringsprogrammet gemmes modelberegnede kolonner (defineret i DAX) på samme måde som almindelige kolonner, der kommer fra Power Query.The VertiPaq storage engine stores model calculated columns (defined in DAX) just like regular Power Query-sourced columns. Datastrukturerne gemmes dog på en lidt anden måde, hvilket typisk resulterer i mindre effektiv komprimering.However, the data structures are stored slightly differently, and typically achieve less efficient compression. De oprettes i øvrigt, når alle Power Query-tabeller indlæses, hvilket kan resultere i, at det tager længere tid at opdatere data.Also, they are built once all Power Query tables are loaded, which can result in extended data refresh times. Det er derfor mindre effektivt at tilføje tabelkolonner som beregnede kolonner end Power Query-beregnede kolonner (defineret i M).It is therefore less efficient to add table columns as calculated columns than Power Query computed columns (defined in M).

Præferencen bør være at oprette brugerdefinerede kolonner i Power Query.Preference should be creating custom columns in Power Query. Når kilden er en database, kan du opnå større indlæsningseffektivitet på to måder.When the source is a database, you can achieve greater load efficiency in two ways. Beregningen kan defineres i SQL-sætningen (ved hjælp af det oprindelige forespørgselssprog i provideren), eller den kan materialiseres som en kolonne i datakilden.The calculation can be defined in the SQL statement (using the native query language of the provider), or it can be materialized as a column in the data source.

I nogle tilfælde vil modelberegnede kolonner dog være et bedre valg.However, in some instances, model calculated columns may be the better choice. Det kan være tilfældet, når formlen omfatter evaluering af målinger, eller hvis den kræver en specifik udformningsfunktion, som kun understøttes i DAX-funktioner.It can be the case when the formula involves evaluating measures, or it requires specific modeling functionality only supported in DAX functions. Du kan finde flere oplysninger om sådan et eksempel i artiklen Forstå funktioner for underordnet-overordnet-hierarkier i DAX.For information on one such example, refer to the Understanding functions for parent-child hierarchies in DAX article.

Deaktiver indlæsning af Power Query-forespørgslerDisable Power Query query load

Power Query-forespørgsler, der er beregnet til at understøtte dataintegration med andre forespørgsler, bør ikke indlæses i modellen.Power Query queries that are intended support data integration with other queries should not be loaded to the model. Hvis du vil undgå at indlæse forespørgslen i modellen, skal du sørge for at deaktivere indlæsning af forespørgsler i disse tilfælde.To avoid loading the query to the model, take care to ensure that you disable query load in these instances.

Skærmbillede af Power Query med indstillingen "Aktivér indlæsning".

Deaktiver automatisk dato og klokkeslætDisable auto date/time

Power BI Desktop indeholder en indstilling, der hedder Automatisk dato/klokkeslæt.Power BI Desktop includes an option called Auto date/time. Når funktionen er aktiveret, oprettes der en skjult automatisk dato-/klokkeslætstabel, så datokolonner kan understøtte rapportforfattere ved konfiguration af filtre, gruppering og detailudledning for kalendertidsperioder.When enabled, it creates a hidden auto date/time table for date columns to support report authors when configuring filters, grouping, and drill down for calendar time periods. De skjulte tabeller er faktisk beregnede tabeller, der øger modellens størrelse.The hidden tables are in fact calculated tables that will increase the size of the model. Du kan finde oplysninger om, hvordan du bruger denne indstilling, i artiklen Vejledning til automatisk dato/klokkeslæt i Power BI Desktop.For guidance about using this option, refer to the Auto date/time guidance in Power BI Desktop article.

Skift til blandet tilstandSwitch to Mixed mode

I Power BI Desktop skaber et design med en blandet model en sammensat model.In Power BI Desktop, a Mixed mode design produces a Composite model. Den giver dig i bund og grund mulighed for at bestemme lagringstilstanden for hver tabel.Essentially, it allows you to determine storage mode for each table. Hver tabel kan derfor have egenskaben Lagringstilstand angivet som Import eller DirectQuery (Dobbelt er en anden mulighed).Therefore, each table can have its Storage Mode property set as Import or DirectQuery (Dual is another option).

En effektiv teknik til at reducere modelstørrelsen er at angive egenskaben Lagringstilstand til DirectQuery for store faktatabeller.An effective technique to reduce the model size is to set the Storage Mode property for larger fact-type tables to DirectQuery. Denne designtilgang kan fungere godt sammen med teknikken Gruppér efter og opsummer, som blev introduceret tidligere.Consider that this design approach could work well in conjunction with the Group by and summarize technique introduced earlier. Opsummerede salgsdata kan f.eks. bruges til at få "opsummeret" rapportering med høj ydeevne.For example, summarized sales data could be used to achieve high performance "summary" reporting. Der kan vises detaljeret salg for en specifik (og smal) filterkontekst på en side med detaljeadgang, hvor alle salgsordrer i konteksten vises.A drill through page could display granular sales for specific (and narrow) filter context, displaying all in-context sales orders. I dette eksempel ville siden med detaljeadgang indeholde visualiseringer baseret på en DirectQuery-tabel, som blev brugt til at hente salgsordredata.In this example, the drill through page would include visuals based on a DirectQuery table to retrieve the sales order data.

Der er dog mange konsekvenser for sikkerhed og ydeevne forbundet med sammensatte modeller.There are, however, many security and performance implications related to Composite models. Du kan finde flere oplysninger i artiklen Brug sammensatte modeller i Power BI Desktop.For further information, read the Use composite models in Power BI Desktop article.

Næste trinNext steps

Du kan finde flere oplysninger om design af en Power BI-model i følgende artikler:For more information about Power BI Import model design, see the following articles: