Full refresh pour les tables de streaming

Un refresh complet d'une table de streaming supprime toutes les données et métadonnées existantes et redémarre le Stream depuis le début. Plus précisément, elle tronque la table de streaming, supprime toutes les données de point de contrôle et redémarre le processus de streaming avec de nouveaux points de contrôle pour chaque flux écrivant dans la table. Les sections suivantes abordent le moment d'effectuer un refresh complet, son impact sur les sources de données et les meilleures pratiques.

Pour un aperçu du fonctionnement des refresh sur les datasets de pipeline, consultez Comment les pipelines s'actualisent-ils ?. Pour obtenir des conseils sur la façon de Trigger un refresh complet, consultez Exécuter une mise à jour de pipeline.

Impact sur les sources de données

Une refresh complète supprime toutes les données existantes de la table de streaming. Si votre source de données a des limites de rétention (tels que des sujets Kafka avec de courtes périodes de rétention), certaines données historiques peuvent devenir irrécupérables après une full refresh.

Par exemple, si votre source est Kafka avec une rétention de 24 heures et que vous exécutez un refresh complet après cette période, les anciens messages ne sont plus disponibles et ne peuvent pas être retraités.

remarque

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 en aval dépendantes, le pipeline échoue jusqu'à ce que ces tables soient également entièrement actualisées, à moins que la table de streaming n'ait skipChangeCommits activé. Les vues matérialisées en aval doivent également être entièrement actualisées.

Quand exécuter un refresh complet

Les refresh complets doivent être déclenchés explicitement. Vous pouvez exécuter un refresh complet en cliquant sur **Full Refresh** dans l'interface utilisateur du pipeline ou en activant le refresh complet automatique dans Lakeflow Connect.

Une full refresh est recommandée lorsque des modifications empêchent une requête de streaming de reprendre en toute sécurité à partir de son point de contrôle existant, ou lorsque des données précédemment traitées deviendraient incohérentes avec la logique, le schéma ou la configuration source mis à jour. Les sections suivantes décrivent les scénarios courants.

Changements de schéma

Les modifications de schéma suivantes dans la table cible ne sont pas rétrocompatibles et nécessitent un refresh complet :

• Renommage des colonnes sans le mode de mappage des colonnes activé.

• Modification des colonnes de déduplication.

• Modification des types de données de colonne, notamment :

  • Filtrage par type (par exemple, BIGINT → INT ou DOUBLE → FLOAT).
  • Modifications de type incompatibles (par exemple, STRING → INT).

• Suppression définitive des colonnes du schéma de la table.

Pour ces types de modifications de schéma, Databricks recommande de créer une nouvelle colonne avec le schéma ou le nom souhaité, puis d'utiliser une vue au-dessus de la table de streaming pour unir les anciennes et les nouvelles valeurs.

Modifications du Layout physique des données

Les modifications suivantes du Layout de données physiques nécessitent un refresh complet :

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

Modifications de la source en amont

Les modifications de source en amont suivantes nécessitent une refresh complète :

• Modification des tables source lues par la query de streaming.
• Basculement entre les types de source (par exemple, de Kafka à Delta ou d'Auto Loader à Kafka).
• Modification des emplacements source, tels que les chemins de table ou les abonnements aux sujets Kafka.
• Supprimer et recréer une table Delta source, même lorsque le schéma reste inchangé.

Modifications du traitement avec état

Les modifications de traitement avec état suivantes nécessitent un refresh complet :

• Modification des clés de regroupement d'agrégation 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 refresh complète peut être requise lorsque la continuité des données est compromise :

• Les Logs CDC sont devenus indisponibles en raison de l'expiration de la rétention.
• Corruption ou suppression du répertoire de point de contrôle de streaming.
• Corruption ou perte des fichiers de suivi de schéma ou des fichiers d’emplacement de schéma.

Pour plus d'informations sur la récupération d'un pipeline après une défaillance de point de contrôle, voir Récupérer un pipeline après une défaillance de point de contrôle de streaming.

Limitations

Les limitations suivantes s'appliquent aux réactualisations complètes. Consultez les Bonnes pratiques pour des informations vous aidant à travailler dans ces limites.

• A full refresh ne retraite pas les données à moins que votre source ne conserve l'intégralité du dataset historique.
• Les grands datasets peuvent rendre les refresh complètes coûteuses et chronophages.
• Les consommateurs en aval qui dépendent de la table peuvent échouer ou renvoyer des résultats incomplets tant que le refresh n'est pas terminée.

Bonnes pratiques

Situation	Bonnes pratiques
Conception pour la stabilité	Planifiez votre schéma pour éviter les modifications qui nécessitent un refresh complet. L'ajout de colonnes est généralement sûr, tandis que la modification de colonnes existantes ou de schémas de partitionnement nécessite généralement le recalcul de la table.
Stream à partir de sources avec de courtes périodes de rétention	Le streaming à partir de sources, telles qu'un sujet Kafka, qui n'ont pas de longues périodes de rétention, signifie qu'un refresh complet perd les données qui ne sont plus dans la source. Pour éviter de perdre des données historiques, stream les données brutes dans une table de streaming (une table bronze, dans l'architecture en médaillon). Utilisez des types de colonnes flexibles (variant ou string, par exemple), pour éviter que cette table ne nécessite un refresh complet si les données en amont changent. Cette table peut stocker des données historiques et être utilisée par les tables de streaming en aval (qui peuvent avoir des types plus stricts ou d'autres modifications structurelles). Si les tables en aval nécessitent un refresh complet, cette table contient des données historiques, tout en ne nécessitant pas elle-même un refresh complet.
Considérez les alternatives avant d'exécuter un refresh complet	Les alternatives comprennent : Si vous modifiez la source d'un flux, envisagez de créer un nouveau flux plutôt que de mettre à jour le flux existant d'une table de streaming. Cela préserve 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 effectuer un Reset du point de contrôle, mais cela peut entraîner l’écriture de données dupliquées dans la table cible. Si aucune option n’est acceptable, envisagez de créer une nouvelle table de streaming et d’utiliser une vue pour unir les anciennes et les nouvelles tables de streaming.
Lorsqu'un full refresh est requis	Veuillez suivre ces bonnes pratiques lorsqu'un refresh complet est nécessaire : 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 le refresh pendant une fenêtre de maintenance afin de minimiser l'impact sur les charges de travail de production. Assurez-vous que le système source conserve suffisamment de données historiques pour rejouer le Stream.

Situation	Bonnes pratiques
Conception pour la stabilité	Planifiez votre schéma pour éviter les modifications qui nécessitent un refresh complet. L'ajout de colonnes est généralement sûr, tandis que la modification de colonnes existantes ou de schémas de partitionnement nécessite généralement le recalcul de la table.
Stream à partir de sources avec de courtes périodes de rétention	Le streaming à partir de sources, telles qu'un sujet Kafka, qui n'ont pas de longues périodes de rétention, signifie qu'un refresh complet perd les données qui ne sont plus dans la source. Pour éviter de perdre des données historiques, stream les données brutes dans une table de streaming (une table bronze, dans l'architecture en médaillon). Utilisez des types de colonnes flexibles (variant ou string, par exemple), pour éviter que cette table ne nécessite un refresh complet si les données en amont changent. Cette table peut stocker des données historiques et être utilisée par les tables de streaming en aval (qui peuvent avoir des types plus stricts ou d'autres modifications structurelles). Si les tables en aval nécessitent un refresh complet, cette table contient des données historiques, tout en ne nécessitant pas elle-même un refresh complet.
Considérez les alternatives avant d'exécuter un refresh complet	Les alternatives comprennent : Si vous modifiez la source d'un flux, envisagez de créer un nouveau flux plutôt que de mettre à jour le flux existant d'une table de streaming. Cela préserve 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 effectuer un Reset du point de contrôle, mais cela peut entraîner l’écriture de données dupliquées dans la table cible. Si aucune option n’est acceptable, envisagez de créer une nouvelle table de streaming et d’utiliser une vue pour unir les anciennes et les nouvelles tables de streaming.
Lorsqu'un full refresh est requis	Veuillez suivre ces bonnes pratiques lorsqu'un refresh complet est nécessaire : 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 le refresh pendant une fenêtre de maintenance afin de minimiser l'impact sur les charges de travail de production. Assurez-vous que le système source conserve suffisamment de données historiques pour rejouer le Stream.

Pour effectuer un remplissage des données après une refresh complète, vous pouvez créer un append once flux. 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 remplissage est réexécuté.