Volledig vernieuwen voor streamingtabellen

Bij een volledige vernieuwing van een streamingtabel worden alle bestaande gegevens en metagegevens verwijderd en wordt de stream vanaf het begin opnieuw gestart. De streamingtabel wordt afgekapt, alle controlepuntgegevens verwijderd en het streamingproces opnieuw gestart met nieuwe controlepunten voor elke stroom die naar de tabel wordt geschreven. Op deze pagina wordt beschreven wanneer u mogelijk een volledige vernieuwing moet uitvoeren en wat de gevolgen zijn van het uitvoeren van een volledige vernieuwing. Het bevat ook aanbevolen procedures voor volledige vernieuwingen.

Zie Een pijplijnupdate uitvoeren voor hulp bij het activeren van een volledige vernieuwing.

Impact op gegevensbronnen

Met een volledige vernieuwing worden alle bestaande gegevens uit de streamingtabel verwijderd. Als uw gegevensbron bewaarlimieten heeft, zoals Kafka-onderwerpen met korte bewaarperioden, kunnen sommige historische gegevens na een volledige vernieuwing onherstelbaar worden.

Als uw bron bijvoorbeeld Kafka is met 24-uursretentie en u na dat venster een volledige vernieuwing uitvoert, zijn oudere berichten niet meer beschikbaar en kunnen ze niet opnieuw worden verwerkt.

Opmerking

Volledige vernieuwingen worden niet aanbevolen voor streamingworkloads met een hoog volume of wanneer upstreamretentie voorkomt dat historische gegevens opnieuw worden afgespeeld.

Als de streamingtabel afhankelijke downstreamtabellen bevat, mislukt de pijplijn totdat deze tabellen ook volledig worden vernieuwd, tenzij de streamingtabel skipChangeCommits heeft ingeschakeld. Downstream gematerialiseerde weergaven moeten ook volledig worden vernieuwd.

Wanneer moet u een volledige vernieuwing uitvoeren

Volledige vernieuwingen in Lakeflow Spark-declaratieve pijplijnen moeten expliciet worden geactiveerd. U kunt een volledige vernieuwing uitvoeren door te klikken op Volledig vernieuwen in de pijplijninterface of door automatisch volledig vernieuwen in Lakeflow Connect in te schakelen.

Een volledige vernieuwing wordt aanbevolen wanneer wijzigingen voorkomen dat een streamingquery veilig wordt hervat vanuit het bestaande controlepunt, of wanneer eerder verwerkte gegevens inconsistent zouden worden met bijgewerkte logica, schema of bronconfiguratie. In de volgende secties worden veelvoorkomende scenario's beschreven.

Schemawijzigingen

De volgende schemawijzigingen in de doeltabel zijn niet compatibel met eerdere versies en vereisen een volledige vernieuwing:

  • De naam van kolommen wijzigen zonder dat de kolomtoewijzingsmodus is ingeschakeld.
  • Deduplicatiekolommen aanpassen.
  • Kolomgegevenstypen wijzigen, waaronder:
    • Typ smaling (bijvoorbeeld BIGINT → INT of DOUBLE → FLOAT).
    • Incompatibele typewijzigingen (bijvoorbeeld STRING → INT).
  • Harde verwijdering van kolommen uit het tabelschema.

Voor deze typen schemawijzigingen raadt Databricks aan om een nieuwe kolom met het gewenste schema of de gewenste naam te maken en vervolgens een weergave boven op de streamingtabel te gebruiken om de oude en nieuwe waarden samen te stellen.

Wijzigingen in de indeling van fysieke gegevens

Voor de volgende wijzigingen in de indeling van fysieke gegevens is een volledige vernieuwing vereist:

  • Migreren van verouderde partitionering naar een nieuw clusteringschema.

Upstream-bronwijzigingen

Voor de volgende upstream-bronwijzigingen is een volledige vernieuwing vereist:

  • De brontabellen die de streaming-query leest, wijzigen.
  • Schakelen tussen brontypen (bijvoorbeeld van Kafka naar Delta of van Auto Loader naar Kafka).
  • Bronlocaties wijzigen, zoals tabelpaden of Kafka-onderwerpabonnementen.
  • Een Delta-brontabel verwijderen en opnieuw maken, zelfs wanneer het schema ongewijzigd blijft.

Wijzigingen in de stateful verwerking

Voor de volgende stateful verwerkingswijzigingen is een volledige verversing vereist:

  • Aggregatiegroeperingssleutels of statistische functies wijzigen.
  • Aggregaties toevoegen of verwijderen.
  • Het wijzigen van joinsleutels of jointypen.
  • Joins toevoegen of verwijderen.
  • Het wijzigen van ontdubbelingskolommen of ontdubbelingslogica.

Problemen met gegevenscontinuïteit

Mogelijk is een volledige vernieuwing vereist wanneer de gegevenscontinuïteit wordt aangetast:

  • CDC-logboeken zijn niet meer beschikbaar vanwege verstrijken van de retentieperiode.
  • Beschadiging of verwijdering van de map met streamingcontrolepunten.
  • Beschadiging of verlies van schematracking- of schemalocatiebestanden.

Zie Een pijplijn herstellen van een streamingcontrolepuntfout voor meer informatie over het herstellen van een pijplijn na een controlepuntfout.

Beperkingen

De volgende beperkingen gelden voor volledige vernieuwingen. Zie aanbevolen procedures voor informatie om te helpen bij het werken binnen deze beperkingen.

  • Bij een volledige vernieuwing worden gegevens niet opnieuw verwerkt, tenzij uw bron de volledige historische gegevensset behoudt.
  • Grote gegevenssets kunnen ervoor zorgen dat volledige vernieuwingen kostbaar en tijdrovend zijn.
  • Gebruikers stroomafwaarts die afhankelijk zijn van de tabel kunnen mislukken of onvolledige resultaten retourneren totdat de verversing voltooid is.

Beste praktijken

Situation Beste praktijken
Ontwerp voor stabiliteit Plan uw schema om wijzigingen te voorkomen waarvoor een volledige vernieuwing is vereist. Het toevoegen van kolommen is over het algemeen veilig, terwijl het wijzigen van bestaande kolommen of partitioneringsschema's doorgaans vereist dat de tabel opnieuw wordt aangevuld.
Streamen vanuit bronnen met korte bewaarperioden Streaming vanuit bronnen, zoals een Kafka-onderwerp, dat geen lange bewaarperioden heeft, betekent dat bij een volledige vernieuwing gegevens verloren gaan die niet nog in de bron voorkomen.
Om te voorkomen dat historische gegevens verloren gaan, stream onbewerkte gegevens naar een streamingtabel (een bronzen tabel, in de medallion-architectuur). Gebruik flexibele kolomtypen (bijvoorbeeld variant of tekenreeks) om te voorkomen dat deze tabel een volledige vernieuwing vereist als de gegevens upstream worden gewijzigd. Deze tabel kan historische gegevens opslaan en kunnen worden gebruikt door downstream streaming tabellen (die mogelijk strengere typen of andere structurele wijzigingen kunnen hebben). Als de downstreamtabellen een volledige vernieuwing vereisen, bevat deze tabel historische gegevens, terwijl er geen volledige vernieuwing nodig is.
Alternatieven overwegen voordat u een volledige vernieuwing uitvoert Alternatieven zijn:
  • Als u de bron van een stroom wijzigt, kunt u een nieuwe stroom maken in plaats van de bestaande stroom van een streamingtabel bij te werken. Hierdoor blijven de bestaande gegevens in de tabel behouden, maar kunnen dubbele gegevens worden geschreven omdat de nieuwe stroom een nieuw controlepunt heeft.
  • U kunt ook het controlepunt opnieuw instellen, maar dit kan ertoe leiden dat dubbele gegevens naar de doeltabel worden geschreven.
  • Als geen van beide opties acceptabel is, kunt u een nieuwe streamingtabel maken en een weergave gebruiken om de oude en nieuwe streamingtabellen samen te koppelen.
Wanneer een volledige vernieuwing is vereist Volg deze beste praktijken wanneer een volledige verversing is vereist:
  • Test de bewerking in een ontwikkel- of faseringsomgeving.
  • Documenteer downstreamafhankelijkheden die worden beïnvloed.
  • Plan de vernieuwing tijdens een onderhoudsvenster om de impact op productieworkloads te minimaliseren.
  • Zorg ervoor dat het bronsysteem voldoende historische gegevens bewaart om de stroom opnieuw af te spelen.

Als u gegevens na een volledige vernieuwing wilt doorvoeren, kunt u een append onceworkflow maken. Hiermee wordt een eenmalige backfill uitgevoerd zonder daarna door te gaan met uitvoeren. De code blijft in uw pijplijn staan en als de pijplijn ooit volledig wordt vernieuwd, wordt de backfill opnieuw uitgevoerd.

  • Last updated on