Restaurer et rejouer un pipeline
Bêta
Cette fonctionnalité est en bêta. Les administrateurs du workspace peuvent contrôler l'accès à cette fonctionnalité depuis la page Prévisualisations . Consultez Gérer les aperçus Databricks.
Une transformation erronée, un batch d'enregistrements sources mal formé ou un changement de schéma inattendu peuvent corrompre les tables d'un pipeline à partir d'un point dans le temps connu. La fonction de restauration ramène le pipeline à un point antérieur au problème afin que vous puissiez déployer un correctif et retraiter uniquement les données concernées.
Rewind restaure simultanément les versions de table, les décalages de source de streaming et l’état de l’opérateur, de sorte que la relecture ne saute pas d’enregistrements et n’écrit pas de doublons. Trois opérations retraitent les données et résolvent des problèmes différents :
- Le mot clé Rewind s’adresse à un pipeline récupérable qui a écrit des données incorrectes à partir d’un moment précis dans le temps, par exemple à la suite d’une transformation erronée, d’une entrée malformée ou d’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 antérieur au problème, puis il retraite uniquement les données concernées tout en conservant l’état de l’opérateur. Les données antérieures à ce point ne sont pas modifiées.
- Full refresh rebuilds a table from all available source data and discards its current contents. Use it to recompute everything from scratch, or when a code change is not compatible with the existing state.
- Checkpoint Reset permet de récupérer un pipeline dont le point de contrôle est invalide ou corrompu, ou qui est bloqué par une modification de code incompatible avec le point de contrôle. Il Reset le point de contrôle et poursuit son exécution tout en préservant le contenu actuel de la table. Le retour arrière ne permet pas de résoudre ces cas, car il ne relâche pas les règles de compatibilité de Structured Streaming.
Prérequis
Exigence | Détail |
|---|---|
Canal | Le pipeline doit être sur le canal de distribution Prévisualisation . Consultez la page Configurer des pipelines. |
Configuration | Définissez la configuration du pipeline |
Mode pipeline | Pipelines déclenchés et continus. Le mode temps réel n’est pas pris en charge. |
Sources | Tables Delta, streaming tables, Kafka et Auto Loader. |
Cibles | Tables de streaming et vues matérialisées. |
Flux | Flux en streaming et flux AUTO change data capture (CDC), y compris les cibles SCD de type 1 et SCD de type 2. Les requêtes stateful telles que les agrégations, les jointures et la déduplication sont prises en charge. |
Chaque flux du pipeline doit répondre à ces exigences. Lorsque pipelines.rewind.betaEnabled est true, un pipeline contenant un flux qui ne remplit pas les conditions échoue lors de ses mises à jour. Confirmez que chaque flux répond aux exigences ci-dessus avant de l’activer.
Un pipeline pour lequel pipelines.rewind.betaEnabled est défini sur true ne peut pas revenir au Canal de distribution Current tant que celui-ci n’est pas mis à jour vers un runtime prenant en charge le retour en arrière.
Fonctionnement du rembobinage et de la relecture
Le retour arrière et la relecture sont des étapes distinctes.
Rewind restitue chaque table à la version qu'elle possédait à un point de retour et réinitialise les points de contrôle du streaming qui permettent de suivre la progression de lecture de chaque flux. Vos transformations ne s'exécutent pas et aucune donnée source n'est retraitée.
Un rejeu s’effectue lors de la prochaine exécution du pipeline. Il effectue un nouveau traitement à partir du point de retour en arrière en utilisant la définition actuelle du pipeline, rattrape le retard jusqu'au moment présent, puis reprend le traitement incrémentiel normal. Le retour en arrière ne start pas le pipeline, vous devez donc le start vous-même lorsque vous êtes prêt.
Le pipeline génère des points de retour automatiquement, environ toutes les heures, et les conserve pendant 7 jours. Un pipeline que vous venez de créer ne dispose d’aucun point vers lequel revenir tant qu’il n’a pas généré son premier point.
La restauration d'un dataset restaure également tout ce qui se trouve en aval dans le même pipeline. La restauration couvre un seul pipeline. Il ne se coordonne pas avec d'autres pipelines ou avec des lecteurs externes des mêmes tables. Vous devez donc les gérer séparément.
Restaurer un pipeline à l’aide de l’interface utilisateur
L’interface utilisateur et Genie sont les principaux moyens d’utiliser le retour. L'interface utilisateur répertorie les points de rembobinage disponibles et indique les datasets affectés par chacun d'eux avant le commit.
- Sur votre page de pipeline, cliquez sur le bouton
situé à côté de Run pipeline , puis sur Rewind pipeline . - Sélectionnez un point de retour ou utilisez un raccourci tel que Rewind to yesterday ou Rewind to the latest point . Cliquez sur Suivant .
- Sélectionnez les tables à inclure. Utilisez la vue Graphe pour sélectionner des datasets dans le Graphe du pipeline, ou la vue List pour les sélectionner à partir d’une table. Laissez l’option Reset all checkpoints sélectionnée (default) pour restaurer les décalages de 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 retour. Désélectionnez cette option pour restaurer uniquement les données de la table, sans retraitement, par exemple lorsque vous souhaitez que le contenu d’une table soit restauré sans retraiter les données concernées. Ce paramètre doit être identique pour une table et ses tables en amont, et il ne peut pas être effacé pour un flux qui lit une source externe telle que Kafka ou Auto Loader. Cliquez sur Suivant .
- Examinez le point de retour, le paramètre de point de contrôle et les datasets affectés, puis cliquez sur Restaurer .
start le pipeline pour rejouer les données.
Vous pouvez rembobiner à plusieurs reprises. Chaque retour en arrière remplace le précédent, de sorte que vous pouvez vous remettre d’une relecture échouée en effectuant un retour en arrière ailleurs.
eng-streamteam
Un échec de relecture laisse le pipeline rembobiné mais arrêté. Corrigez le code ou les données source et start le pipeline pour réessayer, ou rembobinez vers un point différent. Le pipeline ne revient pas en arrière de lui-même, et les erreurs apparaissent via les diagnostics standard du pipeline et l'event Logs.
La relecture ne réussit que si la définition actuelle du pipeline est compatible avec l’état restauré ; le retour en arrière ne modifie pas les règles de compatibilité de Structured Streaming. Pour connaître les modifications compatibles, consultez Types of changes in Structured Streaming queries. Les vues matérialisées suivent la sémantique de batch et tolèrent des modifications de schéma plus larges, mais échouent tout de même si une dépendance est incompatible.
Une restauration qui échoue en cours de route peut laisser le pipeline partiellement restauré. Vous avez deux options :
- Rembobinez à nouveau vers le même point ou vers un point différent, et le pipeline converge vers ce point.
- Pour forcer le pipeline à start une mise à jour normale malgré la restauration incomplète, définissez
pipelines.allowUpdateAfterIncompleteRewindsurtrueet redémarrez le pipeline.
Jusqu'où vous pouvez remonter dans le temps
Les points de rembobinage sont conservés pendant 7 jours. Pendant cette période, un retour en arrière échoue si les données requises ont déjà été supprimées. Vérifiez ces éléments avant de recourir au rembobinage :
VACUUMou un brefdelta.deletedFileRetentionDurationsur vos tables. Consultez Travailler avec l'historique de la table.- Rétention de la source inférieure à la fenêtre sur laquelle vous souhaitez effectuer un retour en arrière, par exemple un sujet Kafka conservé pendant un jour.
Les pipelines dotés de plusieurs sources ou de longues chaînes de dépendance nécessitent une rétention plus importante, car chaque table et chaque point de contrôle doivent remonter jusqu'à un point cohérent.
Limitations
- La fonction de retour en arrière ne peut pas restaurer un pipeline à un point antérieur à un refresh complet.
- Les points de restauration sont conservés pendant 7 jours, et une restauration échoue si l'historique de la table ou les données source nécessaires pour atteindre ce point ont déjà été supprimés, par exemple par
VACUUMou en raison d'une courte période de rétention des sources. Consultez la rubrique Jusqu'où vous pouvez remonter dans le temps. - Le mode temps réel n’est pas pris en charge.
- Kinesis, Pulsar, Google Pub/Sub, et les sources personnalisées créées avec les API de source de données DSv2 ou Python ne sont pas prises en charge en tant que sources.
- External sinks and custom sinks are not supported, including sinks defined with
create_sink(). See Use sinks in pipelines. - Les tables de streaming qui utilisent un filtre de ligne ou un masque de colonne ne peuvent pas être rembobinées. Voir Appliquer manuellement des filtres de lignes et des masques de colonnes.
- La restauration avec état nécessite le magasin d’états RocksDB, que les pipelines utilisent par default. Une restauration échoue pour un flux configuré avec un magasin d’états différent.
- Certaines tables en streaming AUTO CDC ont besoin d'un refresh avant de pouvoir être rembobinées. Le pipeline vous avertit lorsque vous demandez le rembobinage.
- Les vues matérialisées peuvent être entièrement recalculées plutôt que de faire l'objet d'un refresh incrémentiel après un retour en arrière. Voir Refresh incrémentiel pour les vues matérialisées.
- La fonction de retour couvre un seul pipeline et ne se coordonne pas avec les lecteurs externes ou d'autres pipelines lisant les mêmes tables.
- Le retour en arrière ne restaure pas le code du pipeline, la configuration du pipeline ou les métadonnées d'objets Unity Catalog telles que les tags et les attributions.