Exécuter une mise à jour de pipeline
Une mise à jour du pipeline start un cluster, valide votre code source et refresh les tables et les vues définies dans le pipeline. Vous pouvez trigger une mise à jour manuellement, selon un calendrier ou par programme.
Qu'est-ce qu'une mise à jour de pipeline ?
Après avoir créé un pipeline et être prêt à l'exécuter, vous start une mise à jour. Une mise à jour de pipeline effectue les opérations suivantes :
- Démarre un cluster avec la configuration correcte.
- Découvre toutes les tables et vues définies et recherche les erreurs d'analyse telles que les noms de colonnes non valides, les dépendances manquantes et les erreurs de syntaxe.
- Crée ou met à jour des tables et des vues avec les données les plus récentes disponibles.
En utilisant une simulation, vous pouvez vérifier les problèmes dans le code source d'un pipeline sans attendre que les tables soient créées ou mises à jour. Cette fonctionnalité est utile lors du développement ou du test de pipelines, car elle vous permet de trouver et de corriger les erreurs dans votre pipeline, telles que des noms de table ou de colonne incorrects.
Comment les mises à jour des pipelines sont-elles déclenchées ?
Utilisez l'une des options suivantes pour start les mises à jour de pipeline :
Trigger de mise à jour | Détails |
|---|---|
Manuel | Vous pouvez déclencher manuellement des mises à jour de pipeline à partir de l'éditeur de Lakeflow Pipelines ou de la liste des pipelines. Voir Manually Trigger a pipeline update. |
Planifiée | Vous pouvez planifier des mises à jour pour les pipelines à l'aide de jobs. Consultez la tâche de pipeline pour les Jobs. |
Programmatique | Vous pouvez Trigger des mises à jour par programmation à l'aide d'outils tiers, d'APIs et de CLIs. Voir Exécuter des pipelines dans un workflow et API REST du pipeline. |
Manually Trigger a pipeline update
Utilisez l'une des options suivantes pour déclencher manuellement une mise à jour du pipeline :
- Exécutez le pipeline complet, ou un sous-ensemble du pipeline (un seul fichier source ou une seule table), depuis l'Éditeur de Lakeflow Pipelines. Pour plus d'informations, consultez Exécuter le code du pipeline.
- Exécutez le pipeline complet à partir de la liste Tâches et pipelines . Cliquez sur
sur la même ligne que le pipeline dans la liste. - Depuis la page de monitoring du pipeline, cliquez sur le bouton
.
Le comportement default des mises à jour de pipeline déclenchées manuellement est de refresh tous les datasets définis dans le pipeline.
Sémantique de refresh du pipeline
Le tableau suivant décrit le comportement des points de contrôle par default, de refresh complet et de Reset pour les vues matérialisées et les tables de streaming :
Type de mise à jour | Vue matérialisée | Table de streaming |
|---|---|---|
Refresh (default) | Met à jour les résultats pour refléter les résultats actuels de la query de définition. Databricks examine le coût et effectue un refresh incrémentiel lorsque c'est plus efficace. Voir Incremental refresh pour les vues matérialisées | Traite les nouveaux enregistrements via la logique définie dans les tables et les flux de streaming. |
refresh complète | Recalcule les résultats pour refléter les résultats actuels de la définition query. | Efface les données des tables de streaming, efface les points de contrôle des flux et retraite tous les enregistrements de la source de données. Consultez Refresh complet pour les tables de streaming |
Reset les points de contrôle du flux de streaming | Non applicable aux vues matérialisées. | Efface les points de contrôle des flux, mais n'efface pas les données des tables de streaming, puis retraîte tous les enregistrements de la source de données. |
Par default, toutes les vues matérialisées et les tables streaming d'un pipeline refresh à chaque mise à jour. Vous pouvez éventuellement omettre des tables des mises à jour en utilisant les fonctionnalités suivantes :
- Sélectionner les tables pour le refresh : utilisez cette interface utilisateur pour ajouter ou supprimer des vues matérialisées et des tables de streaming avant d'exécuter une mise à jour. Consultez start une mise à jour de pipeline pour les tables sélectionnées.
- refresh failed tables : start une mise à jour pour les vues matérialisées et les tables de streaming ayant échoué, y compris les dépendances en aval. Consulter start une mise à jour du pipeline pour les tables en échec.
Ces deux fonctionnalités prennent en charge la sémantique de refresh par default ou une actualisation complète. Vous pouvez éventuellement utiliser la boîte de dialogue Sélectionner les tables à refresh pour exclure des tables supplémentaires lors de l'exécution d'un refresh pour les tables ayant échoué.
Pour les tables de streaming, vous pouvez choisir d'effacer les points de contrôle de streaming pour les flux sélectionnés et non les données des tables de streaming associées. Pour effacer les points de contrôle des flux sélectionnés, utilisez l'API REST Databricks pour start un refresh. Voir start une mise à jour de pipeline pour effacer les points de contrôle des flux de streaming sélectifs.
Quand utiliser une full refresh
Databricks recommande d'exécuter des refresh complets uniquement lorsque cela est nécessaire. Un refresh complet retraite toujours tous les enregistrements des sources de données spécifiées via la logique qui définit le dataset. Le temps et les Ressources nécessaires pour effectuer un refresh complet sont corrélés à la taille des données source.
Les vues matérialisées renvoient les mêmes résultats, que le refresh par default ou le refresh complet soit utilisé. L'utilisation d'un full refresh avec des tables de streaming resets tout le traitement d'état et les informations de point de contrôle, et peut entraîner des enregistrements perdus si les données d'entrée ne sont plus disponibles. Consultez Full refresh pour les tables de streaming
Databricks ne recommande une full refresh que lorsque les sources de données d’entrée contiennent les données nécessaires pour recréer l’état souhaité de la table ou de la vue. Considérez les scénarios suivants où les données sources d'entrée ne sont plus disponibles et le résultat de l'exécution d'un refresh complet :
Source de données | Raison pour laquelle les données d'entrée sont absentes | Résultat du full refresh |
|---|---|---|
Kafka | Short threshold | Les enregistrements qui ne sont plus présents dans la source Kafka sont supprimés de la table cible. |
Fichiers dans le stockage d'objets | Politique de cycle de vie | Les fichiers de données qui ne sont plus présents dans le répertoire source sont supprimés de la table cible. |
Enregistrements dans une table | Supprimé pour conformité | Seuls les enregistrements présents dans la table source sont traités. |
Pour empêcher les actualisations complètes d'être exécutées sur une table ou une vue, définissez la propriété de table pipelines.reset.allowed sur false. Consultez les propriétés de la table pipeline. Vous pouvez également utiliser un flux d'ajout pour ajouter des données à une table de streaming existante sans nécessiter un full refresh.
start une mise à jour du pipeline pour les tables sélectionnées
Vous pouvez éventuellement retraiter les données uniquement pour les tables sélectionnées dans votre pipeline. Par exemple, pendant le développement, vous ne modifiez qu'une seule table et souhaitez réduire le temps de test, ou une mise à jour de pipeline échoue et vous voulez refresh uniquement les tables ayant échoué.
L'Éditeur de Lakeflow Pipelines dispose d'options pour retraiter un fichier source, des tables sélectionnées ou une seule table. Pour plus de détails, consultez Exécuter le code du pipeline.
start une mise à jour de pipeline pour les tables échouées
Si une mise à jour du pipeline échoue en raison d'erreurs dans une ou plusieurs tables dans le graphe du pipeline, vous pouvez start une mise à jour des seules tables ayant échoué et de toutes les dépendances en aval.
Les tables exclues ne sont pas actualisées, même si elles dépendent d’une table défaillante.
Pour mettre à jour les tables en échec, sur la page de monitoring du pipeline, cliquez sur refresh failed tables .
Pour mettre à jour uniquement les tables échouées sélectionnées depuis la page de monitoring du pipeline :
-
Cliquez sur
à côté du bouton refresh les tables échouées et cliquez sur Sélectionner les tables à refresh . La boîte de dialogue Sélectionner les tables à refresh s'affiche. -
Pour sélectionner les tables à refresh, cliquez sur chaque table. Les tables sélectionnées sont mises en surbrillance et étiquetées. Pour supprimer une table de la mise à jour, cliquez de nouveau sur la table.
-
Cliquez sur Refresh la sélection .
Le bouton Refresh selection affiche le nombre de tables sélectionnées entre parenthèses.
Pour retraiter les données déjà ingérées pour les tables sélectionnées, cliquez sur 
à côté du bouton Refresh selection et cliquez sur Full Refresh selection .
start une mise à jour de pipeline pour effacer les points de contrôle des flux de streaming sélectifs
Vous pouvez éventuellement retraiter les données pour les flux de streaming sélectionnés dans votre pipeline sans effacer les données déjà ingérées.
Les flux non sélectionnés sont exécutés à l'aide d'une mise à jour REFRESH. Vous pouvez également spécifier full_refresh_selection ou refresh_selection pour refresh de manière sélective d'autres tables.
Pour start une mise à jour afin de refresh les points de contrôle streaming sélectionnés, utilisez la requête mises à jour de l'API REST LakeFlow Pipelines.
Le paramètre reset_checkpoint_selection accepte une liste de noms de flux. Vous devez transmettre chaque nom de flux dans un format catalog.schema.flow_name entièrement qualifié. L'utilisation du nom simple uniquement (par exemple, my_flow au lieu de my_catalog.my_schema.my_flow) entraîne l'échec de la mise à jour du pipeline avec un IllegalArgumentException.
- Si vous avez défini un flux avec un nom explicite (par exemple, en utilisant le parameter
flow_namedanscreate_auto_cdc_flow), le nom de flux entièrement qualifié est<catalog>.<schema>.<flow_name>. - Si vous n'avez pas défini de nom de flux explicite, le nom de flux default est le nom de table cible entièrement qualifié, au format
catalog.schema.table.
Vous pouvez trouver les noms de flux dans l'interface utilisateur du pipeline ou dans les Logs d'événements du pipeline.
L’exemple suivant utilise la commande curl pour appeler la requête updates afin de start une mise à jour de pipeline :
curl -X POST \
-H "Authorization: Bearer <your-token>" \
-H "Content-Type: application/json" \
-d '{
"reset_checkpoint_selection": ["my_catalog.my_schema.my_streaming_table"]
}' \
https://<your-databricks-instance>/api/2.0/pipelines/<your-pipeline-id>/updates
L'exemple suivant Reset le point de contrôle pour un flux défini avec un nom personnalisé :
curl -X POST \
-H "Authorization: Bearer <your-token>" \
-H "Content-Type: application/json" \
-d '{
"reset_checkpoint_selection": ["my_catalog.my_schema.my_custom_flow_name"]
}' \
https://<your-databricks-instance>/api/2.0/pipelines/<your-pipeline-id>/updates
Vérifier un pipeline pour les erreurs sans attendre la mise à jour des tables
Aperçu
La fonctionnalité de pipeline Dry run est en aperçu public.
Pour vérifier si le code source d'un pipeline est valide sans effectuer de mise à jour complète, utilisez une simulation . Un essai à blanc résout les définitions des datasets et des flux définis dans le pipeline, mais ne matérialise ni ne publie aucun dataset. Les erreurs trouvées lors de l'essai à blanc, telles que des noms de table ou de colonne incorrects, sont signalées dans l'interface utilisateur.
Pour lancer une simulation, cliquez sur sur la page de détails du pipeline à côté de Start et cliquez sur Dry run .
Une fois l'exécution à blanc terminée, toutes les erreurs sont affichées dans le bac d'événements du panneau inférieur. En cliquant sur le bac d'événements, tous les problèmes détectés s'affichent dans le panneau inférieur. De plus, le journal des événements n'affiche que les événements liés à l'exécution à blanc, et aucune métrique n'est affichée dans le Graphe de pipeline. Si des erreurs sont détectées, les détails sont disponibles dans le journal des logs.
Vous pouvez afficher les résultats de l'exécution à blanc dans l'interface utilisateur uniquement tant que l'exécution à blanc est la mise à jour la plus récente de votre pipeline. Sélectionnez-le dans l'historique des mises à jour pour afficher les résultats. Pour connaître la durée pendant laquelle chaque type de mise à jour reste disponible dans l'interface utilisateur, consultez la disponibilité des résultats de mise à jour.
Mettre à jour la disponibilité des résultats
L'affichage des résultats d'une mise à jour dans l'interface utilisateur dépend du type de mise à jour et de deux conditions :
- Fenêtre de rétention : durée de conservation des mises à jour terminées. Les pipelines conservent 60 jours d'anciennes mises à jour.
- **Dernière mise à jour** : si la mise à jour est la plus récente start pour le pipeline.
Le tableau suivant indique quand chaque type de mise à jour est disponible :
Type de mise à jour | Disponible dans l’interface utilisateur tandis que | Supprimé de l'interface utilisateur lorsque |
|---|---|---|
Mise à jour régulière | Il se trouve dans la fenêtre de rétention ou il est toujours actif (non terminé). Une mise à jour active reste disponible même si elle a démarré avant la fenêtre de rétention. | Il est terminé et est plus ancien que la fenêtre de rétention. |
Simulation | C'est la dernière mise à jour du pipeline. | Toute mise à jour ultérieure start, qu'il s'agisse d'un autre test à blanc ou d'une mise à jour régulière. |
Dans tous les cas, les événements d’une mise à jour restent dans le log des événements une fois que ses résultats ne sont plus affichés dans l’interface utilisateur.
Mettre à jour le comportement d'exécution
Le comportement d'une mise à jour de pipeline est déterminé par la façon dont vous la Trigger :
- **Les mises à jour déclenchées depuis l'interface utilisateur de monitoring du pipeline** à l'aide de **Exécuter maintenant** utilisent un comportement de démarrage rapide et axé sur le debugging.
- Mises à jour Trigger par les Jobs, l’API Pipelines ou les pipelines continus utilisent un comportement de nouvelle tentative et de redémarrage automatique.
Pour les pipelines déclenchés, vous pouvez remplacer le comportement par default d'une exécution spécifique en sélectionnant Exécuter maintenant avec des paramètres différents dans le menu déroulant de l'éditeur Lakeflow Pipelines ou de la page de surveillance du pipeline.
Fast-start, axé sur le debugging
Utilisé pour l'interface utilisateur Exécuter maintenant et les mises à jour ad hoc. Ces exécutions optimisent l'itération rapide :
- Réutilise un cluster pour éviter la surcharge des redémarrages. Par default, les clusters s'exécutent pendant deux heures. Vous pouvez modifier cela avec le paramètre
pipelines.clusterShutdown.delaydans Configurer le compute classique pour les pipelines. - Désactive les nouvelles tentatives de pipeline afin que vous puissiez immédiatement détecter et corriger les erreurs.
Comportement de réessai et de redémarrage automatiques
Utilisé pour les Jobs, les mises à jour Trigger-déclenchées par API et les pipelines continus. Ces exécutions privilégient la fiabilité et la rentabilité :
- Redémarre le cluster pour des erreurs récupérables spécifiques, y compris les fuites de mémoire et les identifiants périmés.
- Réexécute l'exécution en cas d'erreurs spécifiques, telles qu'un échec de start d'un cluster.
- Le cluster s'arrête immédiatement après la fin de l'exécution.
Le comportement d'exécution contrôle uniquement l'exécution des clusters et des pipelines. Les emplacements de stockage et les schémas cibles dans le catalogue pour la publication des tables doivent être configurés dans les paramètres de pipeline et ne sont pas affectés par le comportement d'exécution.