Merk
Tilgang til denne siden krever autorisasjon. Du kan prøve å logge på eller endre kataloger.
Tilgang til denne siden krever autorisasjon. Du kan prøve å endre kataloger.
For å forbedre ytelsen og påliteligheten bruker Dataflyt Gen2 oppsamlingselementer til å lagre mellomliggende data under datatransformasjon. Denne artikkelen beskriver hva staging-elementer er, ELT-mønstrene de låser opp gjennom stadiet én gang, refererer til mange modeller, og hvordan man håndterer dataene de inneholder.
Hva er iscenesettelseselementer?
Oppsamlingselementer er mellomliggende datalagringssteder som brukes av Dataflow Gen2 til å lagre data under datatransformasjon. Disse elementene går under navnene «DataflowsStagingLakehouse» og «DataflowsStagingWarehouse». Oppsamlingselementene brukes til å lagre mellomliggende data under datatransformasjon for å forbedre ytelsen. Disse elementene opprettes automatisk når du oppretter din første dataflyt, og administreres av Dataflow Gen2. Disse elementene er skjult for brukeren i arbeidsområdet, men kan være synlige i andre opplevelser som Hent data eller Lakehouse-utforskeren. Vi anbefaler sterkt å ikke få tilgang til eller endre dataene i staging-elementene direkte, da det kan føre til uventet atferd. Lagring av data selv i oppsamlingselementene støttes heller ikke, og det kan føre til tap av data.
ELT-mønstre: trinn én gang, referer til mange
I tillegg til å tilby mellomlagring, låser staging opp et sett med ELT-mønstre bygget på ett enkelt fundament: trinn én gang, referanse mange. En kildespørring merkes som trinnvis slik at utdataene materialiseres til intern staging-lagring. Nedstrøms spørringer refererer deretter til den trinnvise spørringen i stedet for å lese kilden på nytt. Fast Copy er en valgfri akselerator som gjør at den trinnvise spørringen fylles raskere, men det er ikke det som definerer mønsteret.
Mønsteret er viktig fordi når dataene er faset, kan nedstrøms spørringer:
- Kjør mot en indeksert, spørrbar kopi uten å treffe kilden igjen.
- Fold filtre, joins og aggregeringer tilbake til staging-SQL-endepunktet i stedet for å kjøre i mashup-motoren.
- Forgren deg i flere parallelle transformasjoner eller destinasjoner fra et enkelt materialisert resultat.
Vanlige brukstilfeller
Følgende mønstre legges vanligvis oppå en trinnvis kildespørring.
| Brukstilfelle | Beskrivelse |
|---|---|
| Form trinnvise data til analysemodeller | Refererte spørringer former trinnvise data til fakta- og dimensjonstabeller, oppsummeringer, sammenrullinger eller KPI-er gjennom deduplisering, gruppering etter og nøkkelgenerering. |
| Fold-down compute pushdown | Refererte spørringer skrevet mot trinnvis data folder sine joins, filtre og gruppe-for-operasjoner til staging-SQL-endepunktet, og sender beregningen til lagermotoren i stedet for mashup-motoren. Dette er ofte den største enkeltstående performance win staging-muligheten. |
| Datakvalitet og revisjonsgrenen | Refererte spørringer validerer eller inspiserer trinnvise data (nullsjekker, begrensningsvalidering, radtelling) uten å lese kilden på nytt. |
| Spredning til flere destinasjoner | Flere refererte spørringer laster hver inn en forskjellig destinasjon fra samme trinnvise kilde (for eksempel ett Lakehouse og ett Warehouse). |
| Fase-så-sammenslåing | Hver kilde er steget i sin egen spørring, deretter slår en nedstrøms referert spørring sammen eller kobler sammen de trinnvise resultatene, og bretter joinen tilbake til staging-SQL-endepunktet. |
Når iscenesettelse ikke passer
Staging legger til lagringskostnader og en ekstra skriving før nedstrøms spørringer kjøres. Vurder å hoppe over det når:
- Transformasjonen din folder seg allerede ende-til-ende til kildesystemet, uten noen beregning i mashup-motoren.
- Dataflyten har én enkelt utgang og ingen nedstrøms forgrening, validering eller fan-out.
- Kildelatens er flaskehalsen, og kilden kan ikke paralleliseres gjennom staging.
For mer veiledning om når du skal aktivere eller deaktivere staging, se Beste praksis for å oppnå best ytelse med Dataflow Gen2.
Data i oppsamlingselementer
Oppsamlingselementer er ikke utformet for direkte tilgang for brukere. Dataflyt Gen2 administrerer dataene i oppsamlingselementene og sikrer at dataene er i en konsekvent tilstand. Direkte tilgang til data i oppsamlingselementer støttes ikke, da det ikke kan garanteres at dataene er i en konsekvent tilstand. Hvis du trenger tilgang til data i staging-elementer, kan du bruke dataflow-koblingen i Power BI, Excel eller andre dataflyter.
Viktig!
Det interne API-et som leverer trinnvise data til nedstrøms brukere (som semantiske modeller eller andre datastrømmer som bruker Dataflow-koblingen) kan oppleve intermitterende tidsavbrudd. Disse timeoutene kan føre til oppdateringsfeil i forbruk av elementer, ofte med feilmeldingen «Nøkkelen matchet ikke noen rader i tabellen.» Denne feilen indikerer ikke et dataproblem. Det betyr at backenden ikke kunne hente de trinnvise resultatene i tide.
Anbefalt løsning: Konfigurer en datadestinasjon (Lakehouse eller Warehouse) for dataflyten din, og oppdater nedstrøms elementer for å lese direkte fra den destinasjonen ved hjelp av Lakehouse- eller Warehouse-koblingen. Dette omgår det interne staging-API-et og forbedrer oppdateringspåliteligheten.
For mer informasjon, se Data Factory-begrensninger.
Fjerning av data fra oppsamlingselementene kan tvinges ved hjelp av en av følgende handlinger:
- Deaktiver oppsamling i dataflyten og oppdater (etter 30 dager samler vi inn dataene).
- Slett dataflyten (fjerner dataene direkte).
- Slett arbeidsområdet (sletter StagingLakehouse og StagingWarehouse direkte).
Kostnadsimplikasjoner av stadiering
Staging Lakehouse og Staging Warehouse lagrer mellomliggende data som en del av dataflyten din. Lagringen som brukes av disse staging-elementene faktureres som en del av din OneLake-lagring. Dette betyr at dataene lagret i staging-elementene teller mot ditt totale OneLake-lagringsforbruk og tilhørende kostnader.
For å håndtere lagringskostnader effektivt:
- Overvåk bruk av staging-lagring: Vær oppmerksom på at staging-data akkumuleres ved hver dataflytoppdatering til det blir søppelhentet eller eksplisitt fjernet.
- Deaktiver staging når det ikke trengs: Hvis transformasjonene dine folder seg til kildesystemet, trenger du kanskje ikke staging aktivert. Å deaktivere staging reduserer lagringsforbruket.
- Rydd opp i ubrukte dataflyter: Sletting av dataflyter som ikke lenger er nødvendige, fjerner umiddelbart deres tilknyttede staging-data.
- Vurder oppdateringsfrekvens: Hyppige oppdateringer med staging aktivert kan føre til høyere lagringsbruk. Balanser ytelsesfordeler mot lagringskostnader.
For mer informasjon om OneLake-lagringspriser, se Microsoft Fabric-prising.