Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
For at forbedre ydeevnen og pålideligheden bruger Dataflow Gen2 midlertidige elementer til at gemme mellemliggende data under datatransformation. Denne artikel beskriver, hvad staging-elementer er, de ELT-mønstre de låser op for gennem stadiet én gang, refererer til mange modeller, og hvordan man håndterer de data, de indeholder.
Hvad er iscenesættelseselementer?
Midlertidige elementer er mellemliggende datalagerplaceringer, der bruges af Dataflow Gen2 til at gemme data under datatransformation. Disse elementer går under navnene "DataflowsStagingLakehouse" og "DataflowsStagingWarehouse". De midlertidige elementer bruges til at gemme mellemliggende data under datatransformation for at forbedre ydeevnen. Disse elementer oprettes automatisk, når du opretter dit første dataflow, og de administreres af Dataflow Gen2. Disse elementer er skjult for brugeren i arbejdsområdet, men kan være synlige i andre oplevelser som Hent data eller Lakehouse-stifinderen. Vi anbefaler kraftigt ikke at tilgå eller ændre dataene i staging-elementerne direkte, da det kan føre til uventet adfærd. Lagring af data selv i de midlertidige elementer understøttes heller ikke, og det kan medføre tab af data.
ELT-mønstre: trin én gang, referer til mange
Ud over at tilbyde mellemliggende lagring låser staging op for et sæt ELT-mønstre bygget på ét fundament: stage én gang, reference mange. En kildeforespørgsel markeres som trindelt, så dens output materialiseres til intern staging-lagring. Downstream-forespørgsler refererer derefter til den trindelte forespørgsel i stedet for at genlæse kilden. Fast Copy er en valgfri accelerator, der får den trindelte forespørgsel til at udfylde hurtigere, men det er ikke det, der definerer mønsteret.
Mønsteret er vigtigt, fordi når dataene er stabelagt, kan downstream-forespørgsler:
- Kør mod en indekseret, forespørgelig kopi uden at ramme kilden igen.
- Fold filtre, joins og aggregations tilbage til staging-SQL-endpointet i stedet for at køre i mashup-motoren.
- Forgren dig i flere parallelle transformationer eller destinationer fra et enkelt materialiseret resultat.
Almindelige use cases
Følgende mønstre lægges typisk oven på en trindelt kildeforespørgsel.
| Brugssag | Beskrivelse |
|---|---|
| Form stadierede data til analysemodeller | Refererede forespørgsler former trinnede data til fakta- og dimensionstabeller, opsummeringer, sammenstillinger eller KPI'er gennem deduplikering, gruppe-efter og nøglegenerering. |
| Fold-down compute pushdown | Refererede forespørgsler skrevet mod staged data folder deres joins, filtre og group-by-operationer til staging-SQL-endpointet og sender compute til warehouse-motoren i stedet for mashup-motoren. Dette er ofte den største enkeltstående præstationsgevinst, staging muliggør. |
| Datakvalitet og revisionsafdeling | Refererede forespørgsler validerer eller inspicerer trinvise data (null-kontroller, begrænsningsvalidering, rækketælling) uden at genlæse kildekoden. |
| Udbredelse til flere destinationer | Flere refererede forespørgsler indlæser hver en forskellig destination fra samme trinbaserede kilde (for eksempel én Lakehouse og én Warehouse). |
| Fase-så-sammensmeltning | Hver kilde er iscenesat i sin egen forespørgsel, hvorefter en nedstrøms refereret forespørgsel sammenfletter eller joiner de trindelte resultater, hvorefter joinet foldes tilbage til staging-SQL-endpointet. |
Når iscenesættelse ikke er det rigtige match
Staging tilføjer lageromkostninger og en ekstra skrivning, før downstream-forespørgsler kører. Overvej at springe det over, når:
- Din transformation folder allerede fra ende til ende til kildesystemet, uden nogen beregning i mashup-motoren.
- Dataflowet har et enkelt output og ingen downstream branching, validering eller fan-out.
- Kildelatens er flaskehalsen, og kilden kan ikke paralleliseres gennem staging.
For mere vejledning om, hvornår man skal aktivere eller deaktivere staging, se Best practices for at opnå den bedste ydeevne med Dataflow Gen2.
Data i midlertidige elementer
Midlertidige elementer er ikke designet til direkte adgang for brugere. Dataflow Gen2 administrerer dataene i de midlertidige elementer og sikrer, at dataene er i en ensartet tilstand. Direkte adgang til data i midlertidige elementer understøttes ikke, da det ikke kan garanteres, at dataene er i en ensartet tilstand. Hvis du har brug for adgang til data i staging-elementer, kan du bruge dataflow-connectoren i Power BI, Excel eller andre dataflows.
Vigtigt!
Det interne API, der leverer trinvise data til downstream-forbrugere (såsom semantiske modeller eller andre datastrømme ved brug af Dataflows-connectoren), kan opleve intermitterende timeouts. Disse timeouts kan forårsage opdateringsfejl i forbruget af elementer, ofte med fejlen "Nøglen matchede ikke nogen rækker i tabellen." Denne fejl indikerer ikke et dataproblem. Det betyder, at backenden ikke kunne hente de trinvise resultater i tide.
Anbefalet løsning: Konfigurer en datadestination (Lakehouse eller Warehouse) til dit dataflow, og opdater downstream-elementer til at læse direkte fra den destination ved hjælp af Lakehouse- eller Warehouse-connectoren. Dette omgår det interne staging-API og forbedrer opdateringspålideligheden.
For mere information, se Data Factorys begrænsninger.
Fjernelse af data fra de midlertidige elementer kan gennemtvinges ved hjælp af en af følgende handlinger:
- Deaktiver midlertidig lagring i dataflowet, og opdater (efter 30 dage indsamler vi dataene).
- Slet dataflowet (fjerner dataene direkte).
- Slet arbejdsområdet (sletter StagingLakehouse og StagingWarehouse direkte).
Omkostningsmæssige konsekvenser ved iscenesættelse
Staging Lakehouse og staging Warehouse gemmer mellemliggende data som en del af din dataflow-behandling. Den lagerplads, som disse staging-elementer bruger, faktureres som en del af din OneLake-lagring. Det betyder, at dataene, der er gemt i staging-elementerne, tæller med i dit samlede OneLake-lagerforbrug og tilknyttede omkostninger.
For effektivt at håndtere lageromkostninger:
- Overvåg brugen af staging-lagring: Vær opmærksom på, at staging-data akkumuleres ved hver dataflow-opdatering, indtil det bliver garbage collect eller eksplicit fjernet.
- Deaktiver staging, når det ikke er nødvendigt: Hvis dine transformationer folder til kildesystemet, behøver du måske ikke at aktivere staging aktiveret. At deaktivere staging reducerer lagerforbruget.
- Ryd op i ubrugte dataflows: Sletning af dataflows, der ikke længere er nødvendige, fjerner straks deres tilknyttede staging-data.
- Overvej opdateringsfrekvens: Hyppige opdateringer med staging aktiveret kan føre til højere lagerforbrug. Afvej ydelsesfordele mod lageromkostninger.
For mere information om OneLake-lagringspriser, se Microsoft Fabric-prissætning.