Datalagring i Fabric datalager

Gjelder for:✅ Lager i Microsoft Fabric

I Microsoft Fabric bevarer og vedlikeholder et lager automatisk ulike versjoner av dataene basert på den konfigurerte lagringsperioden. Denne lagringsperioden bestemmer hvor langt tilbake i tid du kan utføre tidsreise-spørringer, lage tabellkloner, bruke gjenopprettingspunkter og lage lagerøyeblikksbilder.

Datalagring starter automatisk når du oppretter lageret. Som standard lagrer lagrene datahistorikk i 30 kalenderdager. Du kan konfigurere oppbevaringsperioden til en hvilken som helst verdi mellom 1 og 120 dager. Systemet sletter automatisk utløpte filer etter at oppbevaringsperioden er over.

Lageret beholder alle innsettinger, oppdateringer og slettinger innenfor den konfigurerte oppbevaringsperioden.

  • Å øke oppbevaringsperioden gir et lengre vindu for tidsreise-spørsler, tabellkloner på et tidligere tidspunkt, gjenopprettingspunkter og lager-snapshots. En lengre oppbevaringsperiode øker imidlertid lagringsforbruket og tilhørende kostnader.
  • Å redusere oppbevaringstiden reduserer lagringskostnadene, men begrenser hvor langt tilbake du kan spørre eller gjenopprette historiske data.

Hvordan datalagring fungerer

Når data endres, kaster ikke lageret umiddelbart den forrige versjonens tilstand. I stedet bevares tidligere versjoner av dataene som en del av Delta Lake-transaksjonsloggen. Denne versjoneringsmekanismen er det som gjør det mulig for tidsreiser, tabellkloner, gjenopprettingspunkter og lagersnapshots å fungere.

Når historiske dataversjoner overskrider den konfigurerte oppbevaringsperioden, fjerner en bakgrunnsprosess automatisk de utløpte filene fra OneLake. Denne oppryddingsprosessen kjører asynkront og påvirker ikke aktive forespørsler eller pågående transaksjoner.

Lageret måler alderen på de lagrede dataene i absolutte kalenderdager fra det tidspunktet dataversjonen ble opprettet, inkludert hver gang Microsoft Fabric-kapasiteten er satt på pause.

Retensjonstidsområde

Hvis du ikke eksplisitt konfigurerer oppbevaringsperioden, bruker eksisterende lagre standard oppbevaringstid på 30 kalenderdager. Du kan konfigurere lagringsperioden for data fra 1 til 120 dager.

Konfigurer dataoppbevaring

Sett lagringsperioden for et lager ved å bruke ALTER DATABASE ... SET T-SQL-kommando. For steg og mer informasjon, se Hvordan konfigurere datalagring i Fabric datalager.

Atferd ved endring av oppbevaringsperioden

Å forstå oppførselen når du endrer oppbevaringsperioden hjelper deg å planlegge endringer for å unngå uventet datatap eller økning i lagringsstørrelse.

Økning av oppbevaringstiden

Når du øker oppbevaringsperioden, trer den nye innstillingen i kraft umiddelbart. Du kan imidlertid ikke gjenopprette historiske data som systemet allerede har ryddet opp i under den tidligere kortere lagringsperioden. Kun dataversjoner som fortsatt eksisterer i OneLake på tidspunktet for endringen drar nytte av den forlengede lagringsperioden.

For eksempel, hvis lageret ditt for øyeblikket har en oppbevaringsperiode på 7 dager og du øker den til 60 dager, gjelder endringen fra det tidspunktet og fremover. Dataversjoner som allerede ble renset av systemet før endringen (eldre enn 7 dager) kan ikke gjenopprettes. Alle dataversjoner som fortsatt er innenfor 7-dagersvinduet på tidspunktet for endringen, sammen med eventuelle nyopprettede versjoner fremover, vil imidlertid bli beholdt i opptil 60 dager.

Reduksjon av oppbevaringstiden

Når du reduserer oppbevaringsperioden, blir dataversjoner som nå faller utenfor den nye, kortere lagringsperioden kvalifisert for opprydding. Oppryddingsprosessen kjører asynkront i bakgrunnen og skjer ikke umiddelbart. Aktive forespørsler som allerede pågår påvirkes ikke.

For eksempel, hvis lageret ditt har en oppbevaringsperiode på 30 dager og du reduserer den til 7 dager, blir dataversjoner mellom 8 og 30 dager gamle kvalifisert for bakgrunnsopprydding.

Important

Å redusere lagringstiden er irreversibelt, sett fra et dataaksessperspektiv.

Selv om du øker lagringsperioden igjen kort tid etterpå, kan data som falt utenfor det kortere tidsvinduet ikke lenger nås. Før du reduserer oppbevaringsperioden, sørg for at den nye lagringsperioden oppfyller organisasjonens krav til datagjenoppretting og etterlevelse.

Beholdningsfrist

Kolonnen time_travel_retention_cutoff_date i sys.databases systemkatalogvisning viser den faktiske tidligste datoen tidsreisedata er tilgjengelig fra, ikke den nåværende konfigurerte lagringsperioden. De eldste faktiske dataene kan være forskjellige fra den konfigurerte lagringsperioden.

Den brukerkonfigurerte lagringsperioden definerer hvor mange dager med historikk systemet skal bevare fremover. Den faktiske gjenopprettingshistorikken avhenger imidlertid av hvilke data som ble bevart før eventuelle endringer i oppbevaring.

To situasjoner forårsaker en divergens mellom konfigurert oppbevaring og faktisk tilgjengelig historikk:

  • Bevaringen ble redusert — Lageret markerer umiddelbart historiske data eldre enn den nye oppbevaringsperioden for søppelrydding og fjerner dem permanent.
  • Beholdningen ble deretter økt — Lageret kan ikke gjenopprette slettet historikk. Den må vente på at ny historikk skal akkumuleres før det fullstendige konfigurerte vinduet er tilgjengelig.

Datalagringsscenarier

Vurder følgende scenarier når du bestemmer hvordan du skal konfigurere oppbevaringsperioden:

Samsvar og revisjon

Organisasjoner med regulatoriske eller etterlevelseskrav kan trenge å lagre data over lengre perioder for å oppfylle revisjonsforpliktelser. Å konfigurere en oppbevaringsperiode på 90 eller 120 dager kan gi et bredere historisk vindu for revisorer til å gjennomgå dataendringer over tid.

Utvikling og testing

For utviklings- eller testarbeidsområder hvor historiske data er mindre viktige, kan en kortere lagringsperiode på 1 til 7 dager redusere lagringskostnadene. Denne reduksjonen er nyttig når arbeidsområdet brukes til rask prototyping eller iterativ utvikling.

Kostnadsoptimalisering

Hvis lageret ditt ofte gjennomgår store dataendringer (som daglige fulllastinger), kan volumet av lagrede historiske data vokse betydelig. I slike situasjoner hjelper det å redusere oppbevaringstiden med å kontrollere lagringskostnadene samtidig som man opprettholder et rimelig gjenopprettingsvindu.

Beredskap for datagjenoppretting

For produksjonslagre gir lengre lagringstid mer fleksibilitet for datagjenoppretting gjennom gjenopprettingspunkter, tabellkloner og tidsreiseforespørsler ved utilsiktet datakorrupsjon.

Hvordan konfigurerbar bevaring påvirker avhengige egenskaper

Den konfigurerte lagringsperioden gjelder jevnt for følgende funksjoner i Fabric datalager. Endring av oppbevaringsperioden påvirker direkte tilgjengeligheten og oppførselen til disse funksjonene.

Tidsreiser

Tidsreiser lar deg spørre data slik de eksisterte på et tidligere tidspunkt i lagringsperioden. Spørringshintet FOR TIMESTAMP AS OF kan hente data fra hvilket som helst punkt innenfor den konfigurerte lagringsperioden.

For eksempel, hvis oppbevaringsperioden er satt til 15 dager, kan du spørre i data slik den eksisterte opptil 15 kalenderdager tidligere.

Klonetabell

Tabellkloner er avhengige av oppbevaringstiden. Du kan lage en klone av en tabell på et tidligere tidspunkt kun innenfor den konfigurerte lagringsperioden. Hvis du ber om en klone utover oppbevaringsperioden, oppstår det en feil.

Gjenopprette poeng

Bruk gjenopprettingspunkter for å gjenopprette et lager. Systemet beholder både systemgenererte og brukerdefinerte gjenopprettingspunkter for den konfigurerte lagringsperioden. Etter at oppbevaringsperioden utløper, sletter systemet automatisk gjenopprettingspunkter.

  • Lageret oppretter automatisk systemgenererte gjenopprettingspunkter hver åttende time. Disse gjenopprettingspunktene er tilgjengelige for den konfigurerte lagringsperioden.
  • Brukerdefinerte gjenopprettingspunkter er tilgjengelige for den konfigurerte lagringsperioden. Systemet sletter automatisk disse gjenopprettingspunktene etter utløp.

Fabric opprettholder et minimum antall gjenopprettingspunkter for å sikre at tilstrekkelige gjenopprettingspunkter alltid er tilgjengelige.

Øyeblikksbilder av lager

Warehouse-snapshots kan referere til data innenfor den konfigurerte lagringsperioden. Øyeblikksbildetidsstempelet kan settes til et hvilket som helst tidspunkt innenfor den konfigurerte lagringsperioden eller til databaseopprettelsestidspunktet, avhengig av hva som kommer sist.

Fakturering av lagringsplass

Datalagring påvirker direkte lagringsforbruket i OneLake. Hver beholdt versjon av data opptar lagringsplass, og lengre lagringsperioder akkumulerer flere historiske versjoner.

Når du planlegger oppbevaringskonfigurasjonen, bør du vurdere avveiningen mellom fordelene ved lengre tilgang til datahistorikk og de tilhørende lagringskostnadene. For mer informasjon om overvåking av lagring, se Overvåk ved bruk av Capacity Metrics-appen.

  • Lagrede datafiler: Historiske versjoner av data lagret som parquet-filer i OneLake bruker lagring. Lagringskostnaden er proporsjonal med volumet og hyppigheten av dataendringer i lagringsperioden.
  • Gjenopprettingspunkter: Metadata for systemgenererte og brukerdefinerte gjenopprettingspunkter bruker også lagringsplass. Gjenopprettingspunktene lagrer imidlertid primært metadata og refererer til eksisterende datafiler, så lagringsoverhead er relativt liten.
  • Ingen beregningskostnader for oppbevaring: Det påløper ingen beregningskostnader kun for å lagre historiske data. Beregningsgebyrer gjelder kun når du aktivt spør eller gjenoppretter data.

For å estimere lagringspåvirkningen av en endring i oppbevaringsperioden, vurder:

  • Det gjennomsnittlige daglige volumet av dataendringer i lageret ditt.
  • Den nåværende oppbevaringsperioden og den foreslåtte nye oppbevaringsperioden.
  • Forskjellen mellom de to periodene multiplisert med gjennomsnittlig daglig modifikasjonsvolum gir en omtrentlig endring i lagringsforbruket.

Utformingshensyn

  • Konfigurer oppbevaringsperioden basert på organisasjonens krav til datagjenoppretting, etterlevelse og kostnader. Standarden på 30 dager gir en balanse mellom datatilgjengelighet og lagringskostnader for de fleste arbeidsbelastninger.
  • Koordiner endringer i oppbevaringsperioden med backup- og katastrofegjenopprettingsstrategien din. Sørg for at oppbevaringsperioden samsvarer med dine mål for gjenopprettingspoeng (RPO).
  • Overvåk lagringsforbruket i OneLake etter å ha endret oppbevaringsperioden for å forstå effekten på lagringskostnadene.
  • Planlegg endringer i lagringsperioden i perioder med lav aktivitet når det er mulig, slik at det ikke oppstår brukerpåvirkning.
  • Oppbevaringsperioden settes på lagernivå. Hvis du trenger ulike oppbevaringsperioder for ulike datasett, vurder å organisere dem i separate lagre. Individuelle lagringsinnstillinger på tabellnivå støttes for øyeblikket ikke.

Begrensninger

  • Spesifiser oppbevaringstiden i hele dager. Brøkverdier støttes ikke.
  • Å redusere oppbevaringstiden gir ikke umiddelbart lagringsplass. Opprydding av utgåtte data skjer asynkront i bakgrunnen.
  • Å pause Microsoft Fabric-kapasiteten påvirker søppelryddingsaktiviteten. Prosessen fjerner ikke historiske data som er eldre enn de nåværende datalagringsinnstillingene mens kapasiteten er pauset. Opprydningsaktivitetene tar igjen når kapasiteten gjenopptas.
  • Retensjonsinnstillingen gjelder kun for lagre. SQL-analyseendepunktet til Lakehouse støttes ikke.
  • Query Insights- og SQL-revisjonslogger er ikke underlagt denne datalagringspolicyen og administreres separat.

Droppet gjenstand (forhåndsvisning)

Droppet vareoppbevaring bevarer lagre og deres tilhørende tabeller, skjemaer, øyeblikksbilder, tillatelser og lagrede spørringer i en konfigurerbar periode etter at de er fjernet eller slettet. Dette sikrer at utilsiktede slettinger ikke fører til permanent datatap eller forretningsmessige avbrudd. Droppet oppbevaring garanterer en minimum oppbevaringsperiode på 7 kalenderdager, og har en separat konfigurasjon på leietakernivå. Du kan konfigurere lagringsperioden for tapte gjenstander i Item Recovery-innstillingen.

Neste trinn:

Hvordan konfigurere datalagring

Relatert innhold

  • Last updated on