Revenir en arrière et rejouer un pipeline

Important

Cette fonctionnalité est en version bêta. Les administrateurs d’espace de travail peuvent contrôler l’accès à cette fonctionnalité à partir de la page Aperçus . Consultez Gérer les préversions d’Azure Databricks.

Une mauvaise transformation, un lot déformé d’enregistrements sources ou un changement inattendu de schéma peuvent laisser les tables d’un pipeline incorrectes à partir d’un moment connu. Rewind ramène le pipeline à un point avant le problème afin que vous puissiez déployer une correction et ne retraiter que les données affectées.

Rewind restaure simultanément les versions de la table, les offsets des sources de streaming et l’état de l’opérateur, afin que la relecture n’ignore aucun enregistrement et n’entraîne pas d’écritures en double. Trois opérations retraitent les données, et elles résolvent différents problèmes :

  • Rewind s’applique à un pipeline corrigible qui a écrit des données incorrectes depuis un point précis dans le temps, par exemple après une mauvaise transformation, des données d’entrée mal formées ou un mauvais déploiement de code. Il restaure les données de table, les décalages de source et l’état de l’opérateur à un point avant le problème et ne retraite que les données affectées, en conservant l’état de l’opérateur. Les données antérieures à ce point restent intactes.
  • Le rafraîchissement complet reconstruit un tableau à partir de toutes les données sources disponibles et en supprime le contenu actuel. Utilisez-le pour tout recalculer à partir de zéro, ou lorsqu’un changement de code n’est pas compatible avec l’état existant.
  • La réinitialisation du point de contrôle récupère un pipeline dont le point de contrôle est invalide ou corrompu, ou qui est bloqué par un changement de code incompatible avec le point de contrôle. Il réinitialise le point de contrôle et continue d’avancer tout en préservant le contenu actuel de la table. Rewind ne peut pas récupérer ces cas, car il ne relâche pas les règles de compatibilité du Structured Streaming.

Exigences

Requirement Détails
Canal Le pipeline doit être sur le canal Preview. Consultez Configurer des pipelines.
Configuration Réglez la pipelines.rewind.betaEnabled configuration du pipeline sur true, puis exécutez le pipeline une fois. Chaque flux ne devient rembobinable qu’une fois sa mise à jour terminée avec l’option de voyage dans le temps activée.
Mode de pipeline Pipelines déclenchés et en continu. Le mode temps réel n’est pas pris en charge.
Sources Tables Delta, tables de streaming, Kafka et Auto Loader.
Cibles Tables de streaming et vues matérialisées.
Flows Flux en continu et flux de capture de données par changement automatique (CDC), incluant les cibles SCD Type 1 et SCD Type 2. Les requêtes avec état, telles que les agrégations, les jointures, et la déduplication, sont prises en charge.

Chaque flux dans le pipeline doit répondre à ces exigences. Bien que pipelines.rewind.betaEnabled soit true, un pipeline contenant un flux qui ne remplit pas les critères voit ses mises à jour échouer. Confirmez que chaque flux répond aux exigences ci-dessus avant de l’activer.

Note

Un pipeline pour lequel pipelines.rewind.betaEnabled est défini sur true ne peut pas revenir au canal Current tant que celui-ci n’a pas été mis à jour vers une version du runtime qui prend en charge le rembobinage.

Comment fonctionnent le rembobinage et la répétition

Revenir et rejouer sont des étapes distinctes.

Rewind restaure chaque table à la version qu’elle détenait à un point de rembobinement et réinitialise les points de contrôle en streaming qui suivent la distance de lecture de chaque flux. Vos transformations ne s’exécutent pas, et aucune donnée source n’est retraitée.

Replay se produit la prochaine fois que le pipeline s’exécute. Il retraite les données à partir du point de retour arrière en utilisant la définition actuelle du pipeline, se remet à jour jusqu’au moment présent, puis reprend le traitement incrémental normal. Rewind ne démarre pas le pipeline, vous devez donc le démarrer vous-même lorsque vous êtes prêt(e).

Le pipeline génère automatiquement des points de rembobinage, environ une fois par heure, et les conserve pendant 7 jours. Un pipeline que vous venez de créer n’a aucun état antérieur auquel revenir avant d’avoir produit un premier résultat.

Le retour en arrière d’un jeu de données entraîne également celui de tous les éléments en aval dans le même pipeline. Rewind couvre un pipeline. Il ne se coordonne pas avec d’autres pipelines ni avec des lecteurs externes des mêmes tables, donc gérez-les séparément.

Relancer un pipeline via l’interface utilisateur

L’interface utilisateur et Genie sont les deux principaux moyens d’utiliser rewind. L’interface indique les points de retour en arrière disponibles et indique quels ensembles de données chacun affecte avant de valider le commit.

  1. Sur la page de votre pipeline, cliquez sur l’icône Chevron vers le bas. à côté de Exécuter le pipeline, puis cliquez sur Rewind pipeline.
  2. Sélectionnez un point de rembobinage, ou utilisez un raccourci comme Rembobinage jusqu’à hier ou Rembobinage jusqu’au dernier point. Cliquez sur Suivant.
  3. Sélectionnez les tables à inclure. Utilisez la vue Graphe pour sélectionner les ensembles de données dans le graphe pipeline, ou la Vue Liste pour les sélectionner dans une table. Laissez l’option Réinitialiser tous les points de contrôle sélectionnée (option par défaut) pour restaurer les offsets de la source et l’état de l’opérateur ainsi que les données de la table, afin que le pipeline reprenne le traitement à partir du point de rembobinage. Effacez-le pour restaurer uniquement les données de la table, sans retraitement, par exemple lorsque vous souhaitez restaurer la sommaire d’une table mais que vous ne souhaitez pas retraiter les données affectées. Ce réglage doit être identique pour une table et ses sources amont, et il ne peut pas être désactivé pour un flux qui lit une source externe telle que Kafka ou Auto Loader. Cliquez sur Suivant.
  4. Examinez le point de rembobinage, le réglage du point de contrôle et les ensembles de données concernés, puis cliquez sur Rembobinage.

Lancez le pipeline pour relire les données.

Vous pouvez revenir en arrière plusieurs fois. Chaque rembobinage remplace le précédent, de sorte que vous pouvez récupérer après un échec de relecture en rembobinant à un autre endroit.

Après un retour en arrière

Une défaillance de la rediffusion laisse le pipeline rembobiné mais arrêté. Corrigez le code ou les données sources et lancez le pipeline pour réessayer, ou remontez à un autre point. Le pipeline ne revient pas en arrière de lui-même, et des erreurs apparaissent via les diagnostics standards du pipeline et le journal des événements.

La relecture ne réussit que si la définition actuelle du pipeline est compatible avec l’état restauré ; le rewind ne relâche pas les règles de compatibilité du Structured Streaming. Pour les changements compatibles, voir Types de modifications dans les requêtes de streaming structuré. Les vues matérialisées suivent la sémantique par lots et tolèrent des changements de schéma plus larges, mais échouent tout de même si une dépendance est incompatible.

Un rembobinage qui échoue en partie peut laisser le pipeline partiellement rembobiné. Vous avez deux options :

  1. Remontez à nouveau jusqu’au même point ou à un autre, et le pipeline converge vers ce point.
  2. Pour forcer le pipeline à démarrer une mise à jour normale malgré le rembobinage incomplet, réglez pipelines.allowUpdateAfterIncompleteRewind sur true et redémarrez le pipeline.

Jusqu’où pouvez-vous remonter en arrière

Les points de retour en arrière sont conservés pendant 7 jours. Pendant cette période, un retour en arrière échoue si les données dont il a besoin ont déjà été supprimées. Vérifiez les points suivants avant de compter sur le rembobinage :

  • VACUUM ou un raccourci delta.deletedFileRetentionDuration dans vos tableaux. Voir Utiliser l’historique des tables.
  • Une durée de rétention de la source plus courte que la fenêtre sur laquelle vous souhaitez revenir en arrière, comme un topic Kafka qui conserve les données pendant un jour.

Les pipelines comportant plusieurs sources ou de longues chaînes de dépendances nécessitent une durée de rétention plus longue, car chaque table et chaque point de contrôle doit pouvoir remonter jusqu’à un point cohérent.

Limitations

  • Le retour en arrière ne peut pas restaurer un pipeline à un état antérieur à une actualisation complète.
  • Les points de rembobinage sont conservés pendant 7 jours, et l’opération de rembobinage échoue si l’historique de la table ou les données source nécessaires pour revenir à ce point ont déjà été supprimés, par exemple par VACUUM ou en raison d’une courte durée de rétention des données source. Voyez jusqu’où vous pouvez remonter en arrière.
  • Le mode temps réel n’est pas pris en charge.
  • Kinesis, Pulsar, Google Pub/Sub et des sources personnalisées construites avec les API de source de données DSv2 ou Python ne sont pas prises en charge comme sources.
  • Les puits externes et les puits personnalisés ne sont pas pris en charge, y compris les puits définis avec create_sink(). Consultez Utiliser des récepteurs dans des pipelines.
  • Les tables de streaming utilisant un filtre de ligne ou un masque de colonne ne peuvent pas être rembobinées. Consultez Appliquer manuellement des filtres de lignes et des masques de colonne.
  • Le retour arrière avec état nécessite le stockage d’état RocksDB, que les pipelines utilisent par défaut. Un retour en arrière échoue pour un flux configuré avec un autre store d’état.
  • Certaines tables de streaming AUTO CDC ont besoin d’une mise à jour avant de pouvoir être rembobinées. Le pipeline vous avertit lorsque vous demandez un retour en arrière.
  • Les vues matérialisées peuvent être entièrement recalculées plutôt que d’être actualisées de façon incrémentielle après un retour en arrière. Consultez Actualisation incrémentielle pour les vues matérialisées.
  • Rewind couvre un pipeline et n’assure aucune coordination avec des lecteurs externes ni avec d’autres pipelines qui lisent les mêmes tables.
  • Rewind ne restaure pas le code du pipeline, la configuration du pipeline, ni les métadonnées des objets du catalogue Unity telles que les tags et les concessions.

Ressources additionnelles

  • Last updated on