Actualisation complète des tables de streaming

Une actualisation complète d’une table de diffusion en continu ignore toutes les données et métadonnées existantes et redémarre le flux à partir du début. Plus précisément, il tronque la table de diffusion en continu, supprime toutes les données de point de contrôle et redémarre le processus de diffusion en continu avec de nouveaux points de contrôle pour chaque flux écrit dans la table. Cette page décrit quand vous devrez peut-être exécuter une actualisation complète et l’impact de l’exécution d’une actualisation complète. Il inclut également les meilleures pratiques relatives aux actualisations complètes.

Pour obtenir des conseils sur la façon de déclencher une actualisation complète, consultez Exécuter une mise à jour de pipeline.

Impact sur les sources de données

Une actualisation complète supprime toutes les données existantes de la table de diffusion en continu. Si votre source de données a des limites de rétention( telles que des rubriques Kafka avec des périodes de rétention courtes), certaines données historiques peuvent devenir irrécupérables après une actualisation complète.

Par exemple, si votre source est Kafka avec une rétention de 24 heures et que vous exécutez une actualisation complète après cette fenêtre, les anciens messages ne sont plus disponibles et ne peuvent pas être traités à nouveau.

Note

Les actualisations complètes ne sont pas recommandées pour les charges de travail de streaming à volume élevé ou lorsque la rétention en amont empêche la relecture des données historiques.

Si la table de streaming a des tables dépendantes en aval, le pipeline échoue jusqu’à ce que ces tables soient également entièrement actualisées, sauf si la table de streaming a skipChangeCommits activée. Les vues matérialisées en aval doivent également être entièrement actualisées.

Quand exécuter une actualisation complète

Les actualisations complètes sur les pipelines déclaratifs Spark Lakeflow doivent être déclenchées explicitement. Vous pouvez exécuter une actualisation complète en cliquant sur Actualisation complète dans l’interface utilisateur du pipeline ou en activant l’actualisation complète automatique dans Lakeflow Connect.

Une actualisation complète est recommandée lorsque les modifications empêchent une requête de diffusion en continu de reprendre en toute sécurité à partir de son point de contrôle existant, ou lorsque les données précédemment traitées ne sont pas cohérentes avec la logique, le schéma ou la configuration source mise à jour. Les sections suivantes décrivent les scénarios courants.

Modifications de schéma

Les modifications de schéma suivantes dans la table cible ne sont pas compatibles rétroactivement et nécessitent une synchronisation complète :

  • Renommage des colonnes sans mode de mappage de colonnes activé.
  • Modification des colonnes de déduplication.
  • Modification des types de données de colonne, notamment :
    • Rétrécissement de type (par exemple, BIGINT → INT ou DOUBLE → FLOAT).
    • Modifications de type incompatibles (par exemple, STRING → INT).
  • Suppression dure des colonnes du schéma de table.

Pour ces types de modifications de schéma, Databricks recommande de créer une colonne avec le schéma ou le nom souhaité, puis d’utiliser une vue en haut de la table de diffusion en continu pour unioner les anciennes et nouvelles valeurs.

Modifications apportées à la disposition des données physiques

Les modifications de disposition des données physiques suivantes nécessitent une actualisation complète :

  • Migration du partitionnement hérité vers un nouveau schéma de clustering.

Modifications de la source en amont

Les modifications sources en amont suivantes nécessitent une actualisation complète :

  • Modification des tables sources lues par la requête de streaming.
  • Basculer entre les types de sources (par exemple, Kafka vers Delta ou Auto Loader vers Kafka).
  • Modification des emplacements sources, tels que les chemins d’accès aux tables ou les abonnements aux rubriques Kafka.
  • Suppression et recréation d’une table Delta source, même lorsque le schéma reste inchangé.

Modifications du traitement étatique

Les modifications de traitement d'état suivantes nécessitent une actualisation complète :

  • Modification des clés de regroupement ou des fonctions d'agrégation.
  • Ajout ou suppression d’agrégations.
  • Modification des clés de jointure ou des types de jointure.
  • Ajout ou suppression de jointures.
  • Modification des colonnes de déduplication ou de la logique de déduplication.

Problèmes de continuité des données

Une actualisation complète peut être nécessaire lorsque la continuité des données est compromise :

  • Les journaux de capture de modifications (CDC) ne sont plus disponibles en raison de l’expiration des règles de rétention.
  • Altération ou suppression du répertoire de point de contrôle de diffusion en continu.
  • Altération ou perte de fichiers de suivi de schéma ou d’emplacement de schéma.

Pour plus d’informations sur la récupération d’un pipeline à partir d’une défaillance de point de contrôle, consultez Récupérer un pipeline à partir d’une défaillance de point de contrôle de streaming.

Limites

Les limitations suivantes s’appliquent aux actualisations complètes. Consultez les meilleures pratiques pour obtenir des informations sur l’utilisation de ces limitations.

  • Une actualisation complète ne retraite pas les données, sauf si votre source conserve le jeu de données historique complet.
  • Les jeux de données volumineux peuvent rendre les actualisations complètes coûteuses et fastidieuses.
  • Les consommateurs en aval qui dépendent de la table peuvent échouer ou retourner des résultats incomplets jusqu’à ce que l’actualisation se termine.

Bonnes pratiques

Situation Bonnes pratiques
Conception pour la stabilité Planifiez votre schéma pour éviter les modifications nécessitant une actualisation complète. L’ajout de colonnes est généralement sécurisé, tandis que la modification de colonnes ou de schémas de partitionnement existants nécessite généralement de recomputer la table.
Diffuser en continu à partir de sources avec une courte durée de rétention La diffusion en continu à partir de sources, telles que des rubriques Kafka, qui n'ont pas de longues périodes de rétention signifie qu'une actualisation complète entraîne la perte de données qui ne sont plus présentes dans la source.
Pour éviter de perdre des données historiques, diffusez des données brutes dans une table de diffusion en continu (table bronze, dans l’architecture de médaillon). Utilisez des types de colonnes flexibles (variante ou chaîne, par exemple), pour éviter cette table nécessitant une actualisation complète si les données en amont changent. Cette table peut stocker des données historiques et être utilisée par des tables de streaming en aval (qui peuvent avoir des types plus stricts ou d’autres changements structurels). Si les tables en aval nécessitent une actualisation complète, cette table a des données historiques, tout en ne nécessitant pas une actualisation complète elle-même.
Envisagez d’utiliser des alternatives avant d’exécuter une actualisation complète Il existe des alternatives :
  • Si vous modifiez la source d’un flux, envisagez de créer un flux plutôt que de mettre à jour le flux existant d’une table de diffusion en continu. Cela conserve les données existantes dans la table, mais peut écrire des données en double, car le nouveau flux a un nouveau point de contrôle.
  • Vous pouvez également réinitialiser le point de contrôle, mais cela peut entraîner l’écriture de données en double dans la table cible.
  • Si aucune des options n’est acceptable, envisagez de créer une nouvelle table de flux et d’utiliser une vue pour faire l'union des anciennes et nouvelles tables de flux.
Quand une actualisation complète est requise Suivez ces bonnes pratiques quand une actualisation complète est requise :
  • Testez l’opération dans un environnement de développement ou de préproduction.
  • Documentez les dépendances en aval qui sont affectées.
  • Planifiez l’actualisation pendant une fenêtre de maintenance pour réduire l’impact sur les charges de travail de production.
  • Assurez-vous que le système source conserve suffisamment de données historiques pour relire le flux.

Pour recharger les données après une actualisation complète, vous pouvez créer un append onceflux. Cela effectue un remplissage unique sans continuer à s’exécuter après le premier remplissage. Le code reste dans votre pipeline et, si le pipeline est à nouveau entièrement actualisé, le rechargement est réexécuté.

  • Last updated on