Fullständig uppdatering för strömmande tabeller

En fullständig uppdatering av en strömmande tabell tar bort alla befintliga data och metadata och startar om strömmen från början. Mer specifikt trunkerar den strömningstabellen, tar bort alla kontrollpunktsdata och startar om strömningsprocessen med nya kontrollpunkter för varje flöde som skrivs till tabellen. Den här sidan beskriver när du kan behöva köra en fullständig uppdatering och effekten av att köra en fullständig uppdatering. Den innehåller även metodtips för fullständiga uppdateringar.

Information om hur du utlöser en fullständig uppdatering finns i Köra en pipelineuppdatering.

Påverkan på datakällor

En fullständig uppdatering tar bort alla befintliga data från strömningstabellen. Om datakällan har kvarhållningsgränser, till exempel Kafka-ämnen med korta kvarhållningsperioder, kan vissa historiska data bli oåterkalleliga efter en fullständig uppdatering.

Om källan till exempel är Kafka med 24-timmars kvarhållning och du kör en fullständig uppdatering efter det fönstret är äldre meddelanden inte längre tillgängliga och kan inte bearbetas igen.

Anmärkning

Fullständiga uppdateringar rekommenderas inte för strömningsarbetsbelastningar med hög volym eller när överordnad kvarhållning förhindrar att historiska data spelas upp.

Om strömningstabellen har beroende nedströms tabeller misslyckas pipelinen tills även dessa tabeller har uppdaterats fullständigt, såvida inte skipChangeCommits är aktiverat. Nedströms materialiserade vyer måste också uppdateras fullständigt.

När du ska köra en fullständig uppdatering

Fullständiga uppdateringar för Lakeflow Spark Deklarativa Pipelines måste utlösas explicit. Du kan köra en fullständig uppdatering genom att klicka på Fullständig uppdatering i pipelinegränssnittet eller genom att aktivera automatisk fullständig uppdatering i Lakeflow Connect.

En fullständig uppdatering rekommenderas när ändringar förhindrar att en strömmande fråga återupptas från den befintliga kontrollpunkten på ett säkert sätt, eller när tidigare bearbetade data blir inkonsekventa med uppdaterad logik, schema eller källkonfiguration. I följande avsnitt beskrivs vanliga scenarier.

Schemaändringar

Följande schemaändringar i måltabellen är inte bakåtkompatibla och kräver en fullständig uppdatering:

  • Byta namn på kolumner utan att kolumnmappningsläget är aktiverat.
  • Ändra dedupliceringskolumner.
  • Ändra kolumndatatyper, inklusive:
    • Typförminskning (till exempel BIGINT → INT eller DOUBLE → FLOAT).
    • Inkompatibla typändringar (till exempel STRING → INT).
  • Hård borttagning av kolumner från tabellschemat.

För dessa typer av schemaändringar rekommenderar Databricks att du skapar en ny kolumn med önskat schema eller namn och sedan använder en vy ovanpå strömningstabellen för att koppla de gamla och nya värdena.

Ändringar i layouten för fysiska data

Följande fysiska datalayoutändringar kräver en fullständig uppdatering:

  • Migrera från äldre partitionering till ett nytt klusterschema.

Uppströms källändringar

Följande överordnade källändringar kräver en fullständig uppdatering:

  • Ändra källtabellerna som läses av strömningsfrågan.
  • Växla mellan källtyper (till exempel Kafka till Delta eller Auto Loader till Kafka).
  • Ändra källplatser, till exempel tabellsökvägar eller Kafka-ämnesprenumerationer.
  • Ta bort och återskapa en Delta-källtabell, även när schemat förblir oförändrat.

Tillståndskänsliga bearbetningsändringar

Följande tillståndskänsliga bearbetningsändringar kräver en fullständig uppdatering:

  • Ändra aggregeringsgrupperingsnycklar eller aggregeringsfunktioner.
  • Lägga till eller ta bort aggregeringar.
  • Ändra kopplingsnycklar eller kopplingstyper.
  • Lägga till eller ta bort kopplingar.
  • Ändra dedupliceringskolumner eller dedupliceringslogik.

Problem med datakontinuitet

En fullständig uppdatering kan krävas när datakontinuiteten komprometteras:

  • CDC-loggar har blivit otillgängliga på grund av att lagringstiden har gått ut.
  • Skada eller ta bort katalogen för kontrollpunkter för direktuppspelning.
  • Skadade eller förlorade schemaspårnings- eller schemaplatsfiler.

Mer information om hur du återställer en pipeline från kontrollpunktsfel finns i Återställa en pipeline från fel vid kontrollpunkten för direktuppspelning.

Begränsningar

Följande begränsningar gäller för fullständiga uppdateringar. Se Metodtips för information som hjälper dig att arbeta med dessa begränsningar.

  • En fullständig uppdatering ombearbetar inte data om inte källan behåller den fullständiga historiska datamängden.
  • Stora datauppsättningar kan göra fullständiga uppdateringar kostsamma och tidskrävande.
  • Nedströmsanvändare som är beroende av tabellen kan misslyckas eller returnera ofullständiga resultat tills uppdateringen har slutförts.

Metodtips

Situation Metodtips
Design för stabilitet Planera schemat för att undvika ändringar som kräver en fullständig uppdatering. Det är i allmänhet säkert att lägga till kolumner, men om du ändrar befintliga kolumner eller partitioneringsscheman måste du vanligtvis omberäkna tabellen.
Strömma från källor med korta kvarhållningsperioder Direktuppspelning från källor, till exempel ett Kafka-ämne, som inte har långa kvarhållningsperioder innebär att en fullständig uppdatering förlorar data som inte fortfarande finns i källan.
Undvik att förlora historiska data genom att strömma rådata till en strömmande tabell (en bronstabell i medaljongarkitekturen). Använd flexibla kolumntyper (till exempel variant eller sträng) för att undvika att den här tabellen kräver en fullständig uppdatering om överordnade data ändras. Den här tabellen kan lagra historiska data och användas av underordnade strömmande tabeller (som kan ha strängare typer eller andra strukturella ändringar). Om de underordnade tabellerna kräver en fullständig uppdatering har den här tabellen historiska data, men kräver inte en fullständig uppdatering.
Överväg alternativ innan du kör en fullständig uppdatering Alternativen är:
  • Om du ändrar källan för ett flöde bör du överväga att skapa ett nytt flöde i stället för att uppdatera det befintliga flödet i en strömmande tabell. Detta bevarar befintliga data i tabellen, men kan skriva dubblettdata eftersom det nya flödet har en ny kontrollpunkt.
  • Du kan också återställa kontrollpunkten, men det kan leda till att dubbletter av data skrivs till måltabellen.
  • Om inget av alternativen är acceptabelt kan du överväga att skapa en ny strömningstabell och använda en vy för att koppla de gamla och nya strömmande tabellerna.
När en fullständig uppdatering krävs Följ dessa metodtips när en fullständig uppdatering krävs :
  • Testa driften i en utvecklings- eller mellanlagringsmiljö.
  • Dokumentera underordnade beroenden som påverkas.
  • Schemalägg uppdateringen under ett underhållsfönster för att minimera påverkan på produktionsarbetsbelastningar.
  • Se till att källsystemet behåller tillräckligt med historiska data för att spela upp strömmen igen.

Om du vill fylla på data efter en fullständig uppdatering kan du skapa ett append onceflöde. Detta utför en engångsåterfyllnad utan att fortsätta köra efter den första återfyllningen. Koden ligger kvar i pipelinen, och om pipelinen någonsin uppdateras helt igen körs återfyllnaden på nytt.

  • Last updated on