Datakvarhållning i Fabric Data Warehouse (förhandsversion)

gäller för:✅ Warehouse i Microsoft Fabric

I Microsoft Fabric bevarar och underhåller ett lager automatiskt olika versioner av data baserat på den konfigurerade kvarhållningsperioden. Den här kvarhållningsperioden avgör hur långt tillbaka i tiden du kan köra frågor om tidsresor, skapa tabellkloner, använda återställningspunkter och skapa ögonblicksbilder av lager.

Datakvarhållningen startar automatiskt när du skapar informationslagret. Som standard behåller lager datahistoriken i 30 kalenderdagar. Du kan konfigurera kvarhållningsperioden till valfritt värde mellan 1 och 120 dagar. Systemet tar automatiskt bort filer som har upphört att gälla när kvarhållningsperioden är slut.

Lagret behåller alla infogningar, uppdateringar och borttagningar inom den konfigurerade kvarhållningsperioden.

• Att öka kvarhållningsperioden ger ett längre fönster för tidsreseförfrågningar, tabellkloner vid en tidigare tidpunkt, återställningspunkter och datavaruhusögonblicksbilder. En längre kvarhållningsperiod ökar dock lagringsförbrukningen och tillhörande kostnader.
• Att minska kvarhållningsperioden minskar lagringskostnaderna, men begränsar hur långt tillbaka du kan köra frågor mot eller återställa historiska data.

Så här fungerar datakvarhållning

När data ändras kastar inte datavaruhuset omedelbart bort det tidigare versionstillståndet. I stället bevaras de tidigare versionerna av data som en del av Delta Lake-transaktionsloggen. Den här versionsmekanismen gör det möjligt för tidsresor, tabellkloner, återställningspunkter och lagerögonblicksbilder att fungera.

När historiska dataversioner överskrider den konfigurerade kvarhållningsperioden tar en skräpinsamlingsprocess i bakgrunden automatiskt bort de förfallna filerna från OneLake. Den här rensningsprocessen körs asynkront och påverkar inte aktiva frågor eller pågående transaktioner.

Datalagret mäter åldern på de bevarade datauppgifterna i absoluta kalenderdagar från det att dataversionen skapades, även under den tid som Microsoft Fabric-kapaciteten är pausad.

Spann för bevarandeperiod

Om du inte uttryckligen konfigurerar kvarhållningsperioden använder befintliga lager standardkvarhållningsperiod på 30 kalenderdagar. Du kan konfigurera datakvarhållningsperioden från 1 till 120 dagar.

Konfigurera datakvarhållning

Ange datakvarhållningsperioden för ett lager med hjälp av ALTER DATABASE ... ANGE T-SQL-kommando. Anvisningar och mer information finns i Så här konfigurerar du datakvarhållning i Fabric Data Warehouse.

Beteende vid ändring av kvarhållningsperioden

Att förstå beteendet när du ändrar kvarhållningsperioden hjälper dig att planera ändringar för att undvika oväntade dataförluster eller ökningar av lagringsstorleken.

Öka kvarhållningsperioden

När du ökar kvarhållningsperioden börjar den nya inställningen gälla omedelbart. Du kan dock inte återställa historiska data som systemet redan har rensat under den tidigare kortare kvarhållningsperioden. Endast dataversioner som fortfarande finns i OneLake vid tidpunkten för ändringen drar nytta av den utökade kvarhållningsperioden.

Om ditt lager till exempel för närvarande har en kvarhållningsperiod på 7 dagar och du ökar den till 60 dagar, gäller ändringen från och med då. Dataversioner som redan har rensats av systemet innan ändringen (äldre än 7 dagar) kan inte återställas. Men alla dataversioner som fortfarande är inom 7-dagarsfönstret vid tidpunkten för ändringen, tillsammans med eventuella nyligen skapade versioner framöver, behålls i upp till 60 dagar.

Minska kvarhållningsperioden

När du minskar kvarhållningsperioden blir dataversioner som nu ligger utanför den nya kortare kvarhållningsperioden berättigade till rensning. Rensningsprocessen körs asynkront i bakgrunden och sker inte omedelbart. Aktiva frågor som redan pågår påverkas inte.

Om ditt lager till exempel har en kvarhållningsperiod på 30 dagar och du minskar den till 7 dagar blir dataversioner mellan 8 och 30 dagar gamla berättigade till bakgrundsrensning.

Important

Att minska kvarhållningsperioden är oåterkalleligt ur ett dataåtkomstperspektiv.

Även om du ökar kvarhållningsperioden igen kort därefter kan data som föll utanför det kortare fönstret under den tiden inte längre nås. Innan du minskar kvarhållningsperioden kontrollerar du att den nya kvarhållningsperioden uppfyller organisationens krav på dataåterställning och efterlevnad.

Slutdatum för kvarhållning

Kolumnen time_travel_retention_cutoff_date i systemkatalogvyn sys.databases återspeglar det faktiska tidigaste datum från vilket tidsresedata är tillgängliga, inte den för närvarande konfigurerade kvarhållningsperioden. De äldsta faktiska data kan skilja sig från den konfigurerade kvarhållningsperioden.

Den användarkonfigurerade kvarhållningsperioden definierar hur många dagars historik systemet ska bevara framöver. Den faktiska återställningsbara historiken beror dock på vilka data som bevarades innan några kvarhållningsändringar.

Två situationer orsakar skillnader mellan konfigurerad kvarhållning och faktisk tillgänglig historik:

• Kvarhållningen minskade – Lagret markerar omedelbart historiska data som är äldre än den nya kvarhållningsperioden för skräpinsamling och tar bort dem permanent.
• Kvarhållningen ökades senare – Lagret kan inte återställa den borttagna historiken. Den måste vänta tills den nya historiken har ackumulerats innan det fullständiga konfigurerade fönstret är tillgängligt.

Scenarier för datakvarhållning

Tänk på följande scenarier när du bestämmer hur du ska konfigurera kvarhållningsperioden:

Efterlevnad och granskning

Organisationer med regel- eller efterlevnadskrav kan behöva behålla data under längre perioder för att uppfylla granskningsskyldigheter. Att konfigurera en kvarhållningsperiod på 90 eller 120 dagar kan ge ett bredare historiskt fönster för granskare att granska dataändringar över tid.

Utveckling och testning

För utveckling eller testning av arbetsytor där historiska data är mindre viktiga kan en kortare kvarhållningsperiod på 1 till 7 dagar minska lagringskostnaderna. Den här minskningen är användbar när arbetsytan används för snabb prototyputveckling eller iterativ utveckling.

Kostnadsoptimering

Om ditt lager genomgår frekventa storskaliga dataändringar (till exempel dagliga fullständiga belastningar) kan mängden kvarhållna historiska data växa avsevärt. I dessa scenarier hjälper en minskning av kvarhållningsperioden till att kontrollera lagringskostnaderna samtidigt som ett rimligt återställningsfönster bibehålls.

Beredskap för dataåterställning

För produktionslager ger en längre kvarhållningsperiod större flexibilitet för dataåterställning via återställningspunkter, tabellkloning och tidsresefrågor om det uppstår en oavsiktlig skada på data.

Hur konfigurerbar kvarhållning påverkar beroende funktioner

Den konfigurerade kvarhållningsperioden gäller enhetligt för följande funktioner i Fabric Data Warehouse. Om du ändrar kvarhållningsperioden påverkas tillgängligheten och beteendet för dessa funktioner direkt.

Tidsresa

Med tidsresor kan du fråga efter data eftersom de fanns vid en tidigare tidpunkt inom kvarhållningsperioden. Frågetipset FOR TIMESTAMP AS OF kan hämta data från vilken punkt som helst inom den konfigurerade kvarhållningsperioden.

Om kvarhållningsperioden till exempel är inställd på 15 dagar kan du fråga efter data eftersom den fanns upp till 15 kalenderdagar tidigare.

Klona tabell

Tabellkloner är beroende av kvarhållningsperioden. Du kan bara skapa en klon av en tabell vid en tidigare tidpunkt inom den konfigurerade kvarhållningsperioden. Om du begär en klon efter kvarhållningsperioden uppstår ett fel.

Återställningspunkter

Använd återställningspunkter för att återställa ett lager. Systemet behåller både systemgenererade och användardefinierade återställningspunkter för den konfigurerade kvarhållningsperioden. När kvarhållningsperioden har upphört att gälla tar systemet automatiskt bort återställningspunkter.

• Lagret skapar automatiskt systemgenererade återställningspunkter var åttonde timme. Dessa återställningspunkter är tillgängliga för den konfigurerade lagringsperioden.
• Användardefinierade återställningspunkter är tillgängliga för den konfigurerade kvarhållningsperioden. Systemet tar automatiskt bort dessa återställningspunkter efter förfallodatum.

Fabric upprätthåller ett minsta antal återställningspunkter för att säkerställa att tillräckligt många återställningspunkter alltid är tillgängliga.

Ögonblicksbilder av lager

Ögonblicksbilder av datavarulager kan referera till data inom den definierade kvarhållningsperioden. Tidsstämpeln för ögonblicksbilder kan anges till vilken punkt som helst inom den konfigurerade kvarhållningsperioden eller till tiden då databasen skapades, beroende på vilket som infaller senare.

Fakturering för lagring

Datakvarhållning påverkar direkt förbrukningen av OneLake-lagring. Varje behållen version av data upptar lagringsutrymme och längre kvarhållningsperioder ackumulerar fler historiska versioner.

När du planerar kvarhållningskonfigurationen bör du överväga kompromissen mellan fördelarna med längre åtkomst till datahistorik och tillhörande lagringskostnader. Mer information om övervakning av lagring finns i Fakturering och användningsrapportering i Fabric Data Warehouse.

• Bevarade datafiler: Historiska versioner av data som lagras som parquet-filer i OneLake upptar lagringsutrymme. Lagringskostnaden är proportionell mot volymen och frekvensen för dataändringar under kvarhållningsperioden.
• Återställningspunkter: Metadata för systemgenererade och användardefinierade återställningspunkter förbrukar också lagring. Återställningspunkter lagrar dock främst metadata och refererar till befintliga datafiler, så deras lagringskostnader är relativt små.
• Inga beräkningsavgifter för kvarhållning: Det finns inga beräkningsavgifter som endast debiteras för att behålla historiska data. Beräkningsavgifter gäller endast när du aktivt frågar efter eller återställer data.

Tänk på följande om du vill beräkna lagringseffekten för en kvarhållningsperiodändring:

• Den genomsnittliga dagliga mängden dataändringar i ditt lager.
• Den aktuella kvarhållningsperioden och den föreslagna nya kvarhållningsperioden.
• Deltat mellan de två perioderna multiplicerat med den genomsnittliga dagliga ändringsvolymen ger en ungefärlig ändring i lagringsförbrukningen.

Designöverväganden

• Konfigurera kvarhållningsperioden baserat på organisationens krav på dataåterställning, efterlevnad och kostnad. Standardvärdet på 30 dagar ger en balans mellan datatillgänglighet och lagringskostnad för de flesta arbetsbelastningar.
• Samordna ändringar i kvarhållningsperioden med din strategi för säkerhetskopiering och katastrofåterställning. Se till att kvarhållningsperioden överensstämmer med dina mål för återställningspunkter (RPO).
• Övervaka OneLake-lagringsförbrukningen när du har ändrat kvarhållningsperioden för att förstå hur lagringskostnaderna påverkas.
• Planera ändringar i kvarhållningsperioden under perioder med låg aktivitet när det är möjligt så att det inte påverkar användaren.
• Kvarhållningsperioden anges på lagernivå. Om du behöver olika kvarhållningsperioder för olika datauppsättningar bör du överväga att organisera dem i separata lager. För närvarande stöds inte enskilda kvarhållningsinställningar på tabellnivå.

Limitations

• Ange kvarhållningsperioden i hela dagar. Bråkvärden stöds inte.
• Om du minskar kvarhållningsperioden återtas inte lagringen omedelbart. Rensning av utgångna data sker asynkront i bakgrunden.
• Om du pausar Microsoft Fabric kapacitet påverkas skräprensningsaktiviteten. Processen tar inte bort historiska data som är äldre än de aktuella inställningarna för datakvarhållning medan kapaciteten pausas. Rensningsaktiviteterna kommer ikapp när kapaciteten återupptas.
• Kvarhållningsinställningen gäller endast för lager. SQL-analysslutpunkten för Lakehouse stöds inte.
• Query Insights- och SQL-granskningsloggar omfattas inte av den här datakvarhållningsprincipen och hanteras separat.

Kvarhållning av borttagna objekt (förhandsversion)

Kvarhållande av borttagna objekt innebär att datavaruhus och deras associerade tabeller, scheman, ögonblicksbilder, behörigheter och sparade frågor bevaras under en konfigurerbar period efter att de har droppats eller tagits bort. Detta säkerställer att oavsiktliga borttagningar inte resulterar i permanenta dataförluster eller avbrott som påverkar verksamheten. Slopad kvarhållning garanterar en minimal kvarhållningsperiod på 7 kalenderdagar och har en separat kvarhållningskonfiguration på hyresgästs nivå. Du kan konfigurera kvarhållningsperioden för borttagna objekt i klientinställningen Objektåterställning.

Nästa steg

Så här konfigurerar du datakvarhållning i Fabric Data Warehouse

Relaterat innehåll

• Återställningsplats av ett datavaruförråd i Microsoft Fabric