Aller au contenu principal
Dernière mise à jour le

Préparation à la production pour les LakeFlow Pipelines

La préparation à la production est le stade où un pipeline peut s'exécuter sans surveillance sur des données métier réelles, et cette page vous fournit une liste de contrôle pour confirmer que vous y êtes avant de vous appuyer sur lui.

Présentation​

Un pipeline prêt pour la production s'exécute selon une planification, sur des données métier réelles, avec des échecs détectés automatiquement plutôt que signalés par un consommateur en aval. L'état de préparation est une liste de contrôle couvrant la qualité, la fiabilité, l'observabilité, le déploiement, le coût et la gouvernance des données.

Les Lakeflow pipelines vous offrent plusieurs primitives intégrées qui correspondent directement à ces dimensions. Plutôt que d'essayer de deviner si vous êtes prêt, parcourez la liste de contrôle ci-dessous et considérez toute case non cochée comme une lacune connue. Si la plupart des cases sont cochées, le pipeline est prêt à être exécuté en production. Si plusieurs cases ne sont pas cochées, considérez-les comme votre liste de tâches prioritaires. start par la qualité des données et les notifications, car ce sont les éléments les moins coûteux à ajouter et les plus susceptibles de détecter une exécution défectueuse non identifiée.

Checklist​

Parcourez la liste de contrôle suivante pour chaque dimension de la préparation à la production, et considérez toute case non cochée comme une lacune à combler avant de vous appuyer sur le pipeline.

Qualité des données​

  • Chaque dataset susceptible de recevoir des données erronées possède au moins une attente (expect, expect_or_drop ou expect_or_fail) définie, et pas seulement un commentaire docstring indiquant « supposer une entrée propre ».
  • Vous avez délibérément choisi warn drop ou fail selon la contrainte : fail pour des conditions qui devraient arrêter le monde (comme une clé primaire cassée), drop pour des enregistrements que vous pouvez supprimer en toute sécurité (avec une table de quarantaine capturant ce qui a été abandonné), et warn seulement là où vous suivez activement la tendance.
  • Vous avez consulté l'onglet Data quality dans l'interface utilisateur du pipeline, ou query le journal des événements au moins une fois, et vous connaissez votre taux de réussite actuel des attentes, et pas seulement le fait que des attentes existent. Voir Gérer la qualité des données avec les attentes de pipeline.

Fiabilité​

  • Vous avez consciemment choisi entre le mode trigger et le mode pipeline continu . Trigger is the right default for the vast majority of pipelines. Réservez le continu pour de véritables besoins de latence inférieure à la minute, car cela nécessite un cluster toujours activé. See Trigger vs. continuous pipeline mode.
  • Le pipeline est planifié via le planificateur de tâches ou un Lakeflow Job plutôt que de devoir se souvenir de sélectionner Start . Voir Exécuter des pipelines dans un workflow.
  • Des notifications d'échec sont configurées pour l'e-mail, un webhook ou un event hook afin que vous soyez informé d'une exécution interrompue avant vos parties prenantes.
  • Pour les sources de streaming, vous avez testé ce qui se passe en cas d'échec du point de contrôle et connaissez la procédure de récupération plutôt que de la découvrir lors d'un incident. Voir Récupérer un pipeline après un échec de point de contrôle de streaming.
  • Le pipeline s’exécute en tant que Service Principal , et non en tant qu’identité utilisateur personnelle, ce qui rend les exécutions plus sécurisées et stables pour l’automatisation sans surveillance.

Observabilité​

  • Vous savez où se trouve le log d'événements et vous avez exécuté au moins une query dessus pour le lignage, les métriques de qualité des données ou l'utilisation des ressources. Le log d'événements est la primitive d'observabilité principale des pipelines, et l'interface utilisateur du pipeline en est une vue. Voir Superviser les pipelines.
  • Vous avez vérifié system.lakeflow.pipelines et les tables système associées, ou créé un petit tableau de bord, de sorte que l'état du pipeline est interrogeable, et pas seulement visualisable dans l'interface utilisateur.
  • Vous connaissez la durée actuelle de votre mise à jour et pouvez déterminer si elle tend à augmenter ou si elle reste stable d'une mise à jour à l'autre.

Gestion des déploiements et des changements​

  • Le pipeline est défini et déployé via un bundle, et non créé manuellement par des clics dans l'interface utilisateur, afin qu'il puisse être révisé par le code et soumis à un contrôle de version. Voir Créer un pipeline contrôlé par les sources.
  • Vous avez au moins un dev et un objectif prod (idéalement dev, staginget prod), donc les changements sont validés quelque part avant d’atteindre les données réelles.
  • Les valeurs spécifiques à l’environnement (noms de catalogues, plannings, chemins sources) sont paramétrées via la configuration du pipeline plutôt que codées en dur, de sorte que le même code promuit proprement entre cibles.

Compute et coûts​

  • Vous avez fait un choix explicite entre le compute serverless et le compute classique (serverless est la recommandation « default » pour les nouveaux pipelines) et documenté la raison, si vous avez choisi le classique. Voir Configurer un pipeline serverless.
  • Si vous utilisez le compute classique, le dimensionnement automatique amélioré est activé plutôt qu'une taille de cluster fixe, afin que le pipeline ne manque pas silencieusement de Worker sous la charge.
  • Vous avez examiné system.billing.usage au moins une fois pour la consommation d’unités Databricks (DBU) de ce pipeline et ce n’est pas un chiffre surprenant.

Gouvernance​

  • Les tables cibles résident dans Unity Catalog avec un layout de catalogue et de schéma intentionnel (par exemple, des catalogues ou des schémas distincts par environnement), et non dans l'ancien Hive metastore.
  • L'accès aux objets source et cible suit le principe du moindre privilège : le Service Principal du pipeline peut lire et écrire ce dont il a besoin, et rien de plus. Voir Gérer les identités, les autorisations et les privilèges des pipelines.

Ressources supplémentaires​

Sur cette page