Beregnede objektscenarier og use cases

Der er fordele ved at bruge beregnede objekter i et dataflow. I denne artikel beskrives use cases for beregnede objekter, og hvordan de fungerer i baggrunden.

Hvad er en beregnet enhed?

En enhed repræsenterer dataoutputtet af en forespørgsel, der er oprettet i et dataflow, når dataflowet er blevet opdateret. Den repræsenterer data fra en kilde og eventuelt de transformationer, der blev anvendt til dem. Nogle gange kan det være en god ide at oprette nye objekter, der er en funktion i et tidligere indtaget objekt.

Selvom det er muligt at gentage de forespørgsler, der oprettede et objekt og anvende nye transformationer på dem, har denne fremgangsmåde ulemper: Data indtages to gange, og belastningen på datakilden fordobles.

Beregnede enheder løser begge problemer. Beregnede objekter ligner andre objekter, da de henter data fra en kilde, og du kan anvende yderligere transformationer for at oprette dem. Men deres data stammer fra det anvendte lagerdataflow og ikke den oprindelige datakilde. Det vil sige, at de tidligere blev oprettet af et dataflow og derefter genbrugt.

Du kan oprette beregnede objekter ved at referere til en enhed i det samme dataflow eller ved at referere til en enhed, der er oprettet i et andet dataflow.

Hvorfor bruge en beregnet enhed?

Det kan tage langsomt at udføre alle transformationstrin i ét objekt. Der kan være mange grunde til, at datakilden er langsom, eller de transformationer, du udfører, skal muligvis replikeres i to eller — flere forespørgsler. Det kan være fordelagtigt først at indtage dataene fra kilden og derefter genbruge dem i en eller flere enheder. I sådanne tilfælde kan du vælge at oprette to enheder: en, der henter data fra datakilden, og en anden beregnet enhed, der anvender yderligere transformationer på data, der allerede er skrevet til den data lake, der bruges af et — — dataflow. Dette kan øge ydeevnen og genanvendeligheden af data, hvilket sparer tid og ressourcer.

Hvis to objekter f.eks. deler en del af deres transformationslogik, skal transformationen udføres to gange uden et beregnet objekt.

Men hvis der bruges en beregnet enhed, behandles den fælles (delte) del af transformationen én gang og gemmes i Azure Data Lake-Storage. De resterende transformationer behandles derefter fra outputtet af den fælles transformation. Denne behandling er generelt meget hurtigere.

En beregnet enhed leverer ét sted som kildekoden til transformationen og øger transformationen, fordi den kun skal udføres én gang i stedet for flere gange. Belastningen på datakilden reduceres også.

Eksempelscenarie for brug af en beregnet enhed

Hvis du bygger en sammenlagt tabel i Power BI for at fremskynde datamodellen, kan du oprette den sammenlagte tabel ved at referere til den oprindelige tabel og anvende yderligere transformationer på den. Ved hjælp af denne metode behøver du ikke at replikere din transformation fra kilden (den del, der er fra den oprindelige tabel).

Følgende figur viser f.eks. objektet Orders.

Ved hjælp af en reference fra dette objekt kan du oprette et beregnet objekt.

Det beregnede objekt kan have yderligere transformationer. Du kan f.eks. bruge Gruppe efter til at samle dataene på kundeniveau.

Det betyder, at objektet Orders Aggregated henter data fra objektet Orders og ikke fra datakilden igen. Da nogle af de transformationer, der skal udføres, allerede er udført i objektet Ordrer, er ydeevnen bedre, og datatransformationen er hurtigere.

Beregnet enhed i andre dataflow

Du kan også oprette et beregnet objekt i andre dataflow. Det kan oprettes ved at hente data fra et dataflow ved hjælp Microsoft Power Platform dataflow-connectoren.

Begrebet beregnet enhed er, at en tabel skal bevares i lageret og andre tabeller, der kommer fra den, så du kan reducere læsetiden fra datakilden og dele nogle af de almindelige transformationer. Dette kan opnås ved at hente data fra andre dataflow via dataflow-connectoren eller referere til en anden forespørgsel i det samme dataflow.

Beregnet enhed: Med transformationer eller uden?

Nu, hvor du ved, at beregnede enheder er gode til at forbedre ydeevnen af datatransformationen, er det en god idé at stille spørgsmål, om transformationer altid skal udskydes til det beregnede objekt, eller om de skal anvendes på kildeenheden. Det vil sige, at data altid skal indtages i én enhed og derefter transformeres i en beregnet enhed? Hvad er fordele og ulemper?

Indlæs data uden transformation for tekst/CSV-filer

Når en datakilde ikke understøtter forespørgselsfoldning (f.eks. tekst/CSV-filer), er der kun lidt fordel ved at anvende transformationer, når du henter data fra kilden, især hvis datamængderne er store. Kildeenheden skal blot indlæse data fra Tekst/CSV-filen uden at anvende transformationer. Derefter kan beregnede objekter hente data fra kildeobjektet og udføre transformationen oven på de data, der indtages.

Du spørger måske, hvilken værdi er det at oprette en kildeenhed, der kun indtager data? En sådan enhed kan stadig være nyttig, da den reducerer belastningen af datakilden, hvis dataene fra kilden bruges i mere end ét objekt. Derudover kan data nu genbruges af andre personer og dataflow. Beregnede enheder er især nyttige i scenarier, hvor datamængden er stor, eller når en datakilde tilgås via en datagateway i det lokale miljø, da de reducerer trafikken fra gatewayen og belastningen på de underfortalte datakilder.

Udføre nogle af de almindelige transformationer for en SQL tabel

Hvis din datakilde understøtter forespørgselsde foldning, er det en god idé at udføre nogle af transformationerne i kildeenheden, fordi forespørgslen delebares til datakilden, og det kun er de transformerede data, der hentes fra den. Dette forbedrer den overordnede ydeevne. Sættet af transformationer, der er fælles i downstream-beregnede objekter, skal anvendes i kildeenheden, så de kan foldes til kilden. Andre transformationer, der kun gælder for downstreamenheder, skal udføres i beregnede enheder.