Gegevensretentie in Fabric Data Warehouse

Van toepassing op:✅ Warehouse in Microsoft Fabric

In Microsoft Fabric behoudt en onderhoudt een magazijn automatisch verschillende versies van de gegevens op basis van de geconfigureerde bewaarperiode. Deze bewaarperiode bepaalt hoe ver terug in de tijd u query's voor tijdreizen kunt uitvoeren, tabelklonen kunt maken, herstelpunten kunt gebruiken en magazijnmomentopnamen kunt maken.

Gegevensretentie wordt automatisch gestart wanneer u het magazijn maakt. Standaard behouden magazijnen de gegevensgeschiedenis gedurende 30 kalenderdagen. U kunt de bewaarperiode configureren voor elke waarde tussen 1 en 120 dagen. Het systeem verwijdert automatisch verlopen bestanden nadat de bewaarperiode is beëindigd.

Het magazijn behoudt alle invoegingen, updates en verwijderingen binnen de geconfigureerde bewaarperiode.

  • Het verlengen van de bewaarperiode biedt een langer tijdvenster voor tijdreisquery's, tabelklonen op een vroeger tijdstip, herstelpunten en momentopnamen van het datamagazijn. Een langere bewaarperiode verhoogt echter het opslagverbruik en de bijbehorende kosten.
  • Als u de bewaarperiode verlaagt , worden de opslagkosten verlaagd, maar beperkt u hoe ver u terug kunt zoeken of historische gegevens kunt herstellen.

Hoe gegevensretentie werkt

Wanneer gegevens worden gewijzigd, verwijdert het data warehouse de vorige versietoestand niet direct. In plaats daarvan blijven de eerdere versies van de gegevens behouden als onderdeel van het Delta Lake-transactielogboek. Met dit versiebeheermechanisme kunnen tijdreizen, tabelklonen, herstelpunten en magazijnmomentopnamen functioneren.

Wanneer historische gegevensversies de geconfigureerde bewaarperiode overschrijden, verwijdert een garbagecollectionproces op de achtergrond automatisch de verlopen bestanden uit OneLake. Dit opschoningsproces wordt asynchroon uitgevoerd en heeft geen invloed op actieve query's of lopende transacties.

Het magazijn meet de leeftijd van de bewaarde gegevens in absolute kalenderdagen vanaf het moment dat de gegevensversie is gemaakt, inclusief wanneer de Microsoft Fabric capaciteit wordt onderbroken.

Bewaartermijn

Als u de bewaarperiode niet expliciet configureert, gebruiken bestaande magazijnen de standaardretentieperiode van 30 kalenderdagen. U kunt de bewaarperiode voor gegevens tussen 1 en 120 dagen configureren.

Gegevensretentie configureren

Stel de gegevensretentieperiode voor een magazijn in met behulp van de ALTER DATABASE ... SET T-SQL-opdracht. Zie Hoe u gegevensretentie configureert in Fabric Data Warehouse voor meer informatie.

Gedrag bij het wijzigen van de bewaarperiode

Als u het gedrag begrijpt wanneer u de bewaarperiode wijzigt, kunt u wijzigingen plannen om onverwachte gegevensverlies of opslaggrootte te voorkomen.

De bewaarperiode verhogen

Wanneer u de bewaarperiode verhoogt, wordt de nieuwe instelling onmiddellijk van kracht. U kunt echter geen historische gegevens herstellen die het systeem al onder de vorige kortere bewaarperiode heeft opgeschoond. Alleen gegevensversies die nog bestaan in OneLake op het moment van de wijziging, profiteren van de verlengde bewaarperiode.

Als uw magazijn momenteel bijvoorbeeld een retentieperiode van 7 dagen heeft en u deze verhoogt tot 60 dagen, is de wijziging vanaf dat moment van toepassing. Gegevensversies die al door het systeem zijn opgeschoond voordat de wijziging (ouder dan 7 dagen) niet kan worden hersteld. Alle gegevensversies worden echter nog steeds binnen het 7-daagse venster op het moment van de wijziging bewaard, samen met eventuele nieuwe versies die in de toekomst worden gemaakt, tot 60 dagen.

De bewaarperiode verlagen

Wanneer u de bewaarperiode verlaagt, komen gegevensversies die nu buiten de nieuwe kortere bewaarperiode vallen in aanmerking voor opschoning. Het opschoningsproces wordt asynchroon op de achtergrond uitgevoerd en gebeurt niet onmiddellijk. Actieve query's die al worden uitgevoerd, worden niet beïnvloed.

Als uw magazijn bijvoorbeeld een bewaarperiode van 30 dagen heeft en u deze verlaagt tot 7 dagen, komen gegevensversies tussen 8 en 30 dagen oud in aanmerking voor opschoning op de achtergrond.

Important

Het verlagen van de retentieperiode kan niet ongedaan worden, vanuit het perspectief van gegevenstoegang.

Zelfs als u de bewaarperiode kort daarna weer verhoogt, kunnen gegevens die buiten het kortere venster vallen, niet meer worden geopend. Voordat u de bewaarperiode verlaagt, moet u ervoor zorgen dat de nieuwe bewaarperiode voldoet aan de vereisten voor gegevensherstel en naleving van uw organisatie.

Afkapdatum van retentie

De time_travel_retention_cutoff_date kolom in de systeemcatalogusweergave sys.databases weerspiegelt de werkelijke vroegste datum van waaruit tijdreisgegevens beschikbaar zijn, niet de momenteel geconfigureerde bewaarperiode. De oudste werkelijke gegevens kunnen afwijken van de geconfigureerde bewaarperiode.

De door de gebruiker geconfigureerde bewaarperiode bepaalt hoeveel dagen geschiedenis het systeem in de toekomst moet behouden. De werkelijke herstelbare geschiedenis is echter afhankelijk van welke gegevens zijn bewaard vóór eventuele retentiewijzigingen.

Twee situaties veroorzaken een verschil tussen geconfigureerde retentie en werkelijke beschikbare geschiedenis:

  • De retentieperiode is verkort — Het magazijn markeert onmiddellijk historische gegevens ouder dan de nieuwe bewaarperiode voor garbage collection en verwijdert deze permanent.
  • De retentie is vervolgens verhoogd : het magazijn kan de verwijderde geschiedenis niet herstellen. Er moet worden gewacht totdat de nieuwe geschiedenis wordt verzameld voordat het volledige geconfigureerde venster beschikbaar is.

Scenario's voor gegevensretentie

Houd rekening met de volgende scenario's bij het bepalen van de configuratie van uw bewaarperiode:

Naleving en audit

Organisaties met wettelijke of nalevingsvereisten moeten mogelijk gegevens langer bewaren om te voldoen aan auditverplichtingen. Het configureren van een bewaarperiode van 90 of 120 dagen kan een breder historisch venster bieden voor auditors om gegevenswijzigingen in de loop van de tijd te controleren.

Ontwikkeling en testen

Voor ontwikkel- of testwerkruimten waarbij historische gegevens minder belangrijk zijn, kan een kortere bewaarperiode van 1 tot 7 dagen de opslagkosten verlagen. Deze vermindering is handig wanneer de werkruimte wordt gebruikt voor snelle prototypen of iteratieve ontwikkeling.

Kostenoptimalisatie

Als uw datawarehouse regelmatig grootschalige gegevenswijzigingen ondergaat (zoals dagelijkse volledige laadtaken), kan het volume van bewaarde historische data aanzienlijk toenemen. In deze scenario's helpt het verminderen van de retentieperiode bij het beheren van de opslagkosten, terwijl er nog steeds een redelijk herstelvenster wordt bewaard.

Gereedheid voor gegevensherstel

Voor productiewarehouses biedt het onderhouden van een langere bewaarperiode meer flexibiliteit voor gegevensherstel via herstelpunten, tabelklonen en query's voor tijdreizen in geval van onbedoelde beschadiging van gegevens.

Hoe configureerbare retentie van invloed is op afhankelijke functies

De geconfigureerde bewaarperiode is uniform van toepassing op de volgende functies in Fabric Data Warehouse. Het wijzigen van de bewaarperiode heeft rechtstreeks invloed op de beschikbaarheid en het gedrag van deze functies.

Tijdreizen

Met tijdreizen kunt u gegevens opvragen zoals deze bestaan op een bepaald tijdstip binnen de retentieperiode. De FOR TIMESTAMP AS OF queryhint kan gegevens ophalen van elk punt binnen de geconfigureerde bewaarperiode.

Als de bewaarperiode bijvoorbeeld is ingesteld op 15 dagen, kunt u gegevens opvragen zoals ze tot 15 kalenderdagen geleden waren.

Tabel klonen

Tabelklonen zijn afhankelijk van de bewaarperiode. U kunt alleen binnen de geconfigureerde bewaarperiode een kloon van een tabel maken op een bepaald tijdstip. Als u een kloon aanvraagt buiten de bewaarperiode, treedt er een fout op.

Herstelpunten

Gebruik herstelpunten om een magazijn te herstellen. Het systeem behoudt zowel door het systeem gegenereerde als door de gebruiker gedefinieerde herstelpunten voor de geconfigureerde bewaarperiode. Nadat de bewaarperiode is verlopen, verwijdert het systeem automatisch herstelpunten.

  • Het magazijn maakt automatisch om de acht uur systeemgegenereerde herstelpunten. Deze herstelpunten zijn beschikbaar voor de geconfigureerde bewaarperiode.
  • Door de gebruiker gedefinieerde herstelpunten zijn beschikbaar voor de geconfigureerde bewaarperiode. Het systeem verwijdert deze herstelpunten automatisch na de vervaldatum.

Fabric onderhoudt een minimum aantal herstelpunten om ervoor te zorgen dat er altijd voldoende herstelpunten beschikbaar zijn.

Momentopnamen van magazijnen

Momentopnamen van het magazijn kunnen verwijzen naar gegevens binnen de geconfigureerde bewaarperiode. De tijdstempel voor momentopnamen kan worden ingesteld op elk punt binnen de geconfigureerde bewaarperiode of op de aanmaaktijd van de database, afhankelijk van wat later is.

Facturering voor opslag

Gegevensretentie is rechtstreeks van invloed op oneLake-opslagverbruik. Elke bewaarde versie van gegevens neemt opslagruimte in beslag en langere bewaarperioden verzamelen meer historische versies.

Houd tijdens het plannen van de bewaarconfiguratie rekening met de voordelen van langere toegang tot gegevensgeschiedenis en de bijbehorende opslagkosten. Zie Bewaken met behulp van de app Capacity Metrics voor meer informatie over het bewaken van opslag.

  • Bewaarde gegevensbestanden: historische versies van gegevens die zijn opgeslagen als Parquet-bestanden in OneLake verbruiken opslag. De opslagkosten zijn evenredig met het volume en de frequentie van gegevenswijzigingen in de bewaarperiode.
  • Herstelpunten: de metagegevens voor door het systeem gegenereerde en door de gebruiker gedefinieerde herstelpunten verbruiken ook opslag. Herstelpunten slaan echter voornamelijk metagegevens op en verwijzen naar bestaande gegevensbestanden, zodat hun opslagoverhead relatief klein is.
  • Geen rekenkosten voor retentie: er worden geen rekenkosten gemaakt voor het bewaren van historische gegevens. Rekenkosten zijn alleen van toepassing wanneer u actief query's uitvoert of gegevens herstelt.

Als u de opslagimpact van een wijziging in een retentieperiode wilt schatten, kunt u het volgende overwegen:

  • Het gemiddelde dagelijkse volume aan gegevenswijzigingen in uw magazijn.
  • De huidige bewaarperiode en de voorgestelde nieuwe bewaarperiode.
  • De verschillen tussen de twee perioden vermenigvuldigd met het gemiddelde dagelijkse aanpassingsvolume geven een geschatte wijziging van het opslagverbruik.

Ontwerpoverwegingen

  • Configureer de bewaarperiode op basis van de vereisten voor gegevensherstel, naleving en kosten van uw organisatie. De standaardwaarde van 30 dagen biedt een balans tussen de beschikbaarheid van gegevens en opslagkosten voor de meeste workloads.
  • Retentieperiodewijzigingen coördineren met uw strategie voor back-up en herstel na noodgevallen. Zorg ervoor dat de bewaarperiode overeenkomt met uw beoogde herstelpunt (RPO).
  • Bewaak het verbruik van OneLake-opslag na het wijzigen van de bewaarperiode om inzicht te hebben in de impact op de opslagkosten.
  • Wijzigingen in bewaarperioden plannen tijdens perioden met een lage activiteit, indien mogelijk, zodat er geen gevolgen voor de gebruiker zijn.
  • De bewaarperiode wordt ingesteld op magazijnniveau. Als u verschillende bewaarperioden voor verschillende gegevenssets nodig hebt, kunt u overwegen deze in afzonderlijke magazijnen te organiseren. De instellingen voor retentie op tabelniveau worden momenteel niet ondersteund.

Limitations

  • Geef de bewaarperiode in hele dagen op. Breukwaarden worden niet ondersteund.
  • Als u de bewaarperiode verlaagt, wordt opslag niet onmiddellijk vrijgemaakt. Het opschonen van verlopen gegevens vindt asynchroon plaats op de achtergrond.
  • Het onderbreken van de Microsoft Fabric-capaciteit beïnvloedt de verwerking van verwijdering van ongewenste gegevens. Tijdens het proces worden historische gegevens die ouder zijn dan de huidige instellingen voor gegevensretentie niet verwijderd terwijl de capaciteit is onderbroken. De opschoonactiviteiten worden hervat zodra de capaciteit weer beschikbaar is.
  • De bewaarinstelling is alleen van toepassing op magazijnen. Het SQL-analyse-eindpunt van Lakehouse wordt niet ondersteund.
  • Query Insights en SQL-auditlogboeken zijn niet onderhevig aan dit beleid voor gegevensretentie en worden afzonderlijk beheerd.

Bewaarperiode voor verwijderde items (preview)

Verwijderde itemretentie behoudt magazijnen en de bijbehorende tabellen, schema's, momentopnamen, machtigingen en opgeslagen query's voor een configureerbare periode nadat ze zijn verwijderd of verwijderd. Dit zorgt ervoor dat onbedoelde verwijderingen niet leiden tot permanent gegevensverlies of bedrijfsgerelateerde storingen. Verwijderde bewaarperiode garandeert een minimale bewaarperiode van 7 kalenderdagen en heeft een afzonderlijke bewaarconfiguratie op tenantniveau. U kunt de bewaarperiode voor verwijderde items configureren in de instelling itemhersteltenant.

Volgende stap