Aller au contenu principal
Dernière mise à jour le

Configurer les pipelines

Configurez les paramètres de base d'un pipeline, y compris le code source, le catalogue et le schéma cibles, le compute et le mode pipeline, dans l'interface utilisateur du Workspace.

Databricks recommande de développer de nouveaux pipelines en utilisant le serverless. Pour les instructions de configuration des pipelines Serverless, consultez Configurer un pipeline Serverless.

Les instructions de configuration de cette page utilisent Unity Catalog. Pour obtenir des instructions sur la configuration des pipelines avec le Hive metastore hérité, consultez Utiliser LakeFlow Pipelines avec le Hive metastore hérité.

Cette page traite des fonctionnalités du mode de publication par default actuel pour les pipelines. Les pipelines créés avant le 5 février 2025 pourraient utiliser le mode de publication hérité et le schéma virtuel LIVE. Voir le schéma EN DIRECT (hérité).

remarque

L'interface utilisateur a une option pour afficher et modifier les paramètres en JSON. Vous pouvez configurer la plupart des paramètres soit avec l'interface utilisateur, soit avec une spécification JSON. Certaines options avancées sont uniquement disponibles en utilisant la configuration JSON.

Les fichiers de configuration JSON sont également utiles lors du déploiement de pipelines vers de nouveaux environnements ou de l'utilisation de la CLI ou de l'API REST.

Pour une référence complète des paramètres de configuration JSON du pipeline, consultez Configurations de pipeline.

Paramètres du pipeline​

Les paramètres de pipeline se répartissent en deux catégories :

  • Code source : collection de fichiers qui déclarent des datasets à l'aide de la syntaxe de pipeline. Voir Configurer le code source.
  • Infrastructure : Paramètres qui contrôlent le compute, la façon dont les mises à jour sont traitées et l'endroit où les tables sont stockées.

La plupart des paramètres ont des valeurs default raisonnables, mais deux nécessitent une attention avant d'être exécutés en production :

  • Catalogue et schéma cibles : pour rendre les données disponibles en dehors du pipeline, déclarez un catalogue et un schéma cibles. Les données sont publiées dans Unity Catalog par default. Consultez Définir le catalogue et le schéma cibles.
  • Accès aux données : Le compute utilisé pour l'exécution doit disposer des autorisations configurées pour vos sources de données et, le cas échéant, d'un emplacement de stockage.

Configurez un nouveau pipeline​

Pour configurer un nouveau pipeline, procédez comme suit :

  1. En haut de la barre latérale, cliquez sur Icône Plus. Nouveau , puis sélectionnez Icône de pipeline. pipeline ETL .

  2. En haut, donnez un nom unique à votre pipeline.

  3. Sous le nom, vous pouvez voir le catalogue et le schéma default qui ont été choisis pour vous. Modifiez-les pour donner à votre pipeline des valeurs par défaut différentes.

    Le catalogue et le schéma default sont l’endroit où les datasets sont lus ou écrits lorsque vous ne qualifiez pas les datasets avec un catalogue ou un schéma dans votre code. Consultez les objets de base de données dans Databricks pour plus d'informations.

  4. Sélectionnez votre option préférée pour créer un pipeline :

    • Start with sample code in SQL pour créer un nouveau pipeline et une structure de dossiers, incluant un exemple de code SQL.
    • start with un exemple de code en Python pour créer un nouveau pipeline et une nouvelle structure de dossiers, y compris un exemple de code en Python.
    • Start avec une seule Transformation pour créer un nouveau pipeline et une nouvelle structure de dossiers, avec un nouveau fichier de code vierge.
    • Ajoutez des assets existants pour créer un pipeline que vous pouvez associer à des fichiers de code existants dans votre Workspace.
    • Créer un projet en gestion de versions pour créer un pipeline avec un nouveau projet Declarative Automation Bundles, ou pour ajouter le pipeline à un bundle existant.

    Vous pouvez avoir des fichiers de code source SQL et Python dans votre pipeline ETL. Lorsque vous créez un nouveau pipeline et que vous choisissez une langue pour l’exemple de code, la langue est uniquement destinée à l’exemple de code inclus par default dans votre pipeline.

  5. Lorsque vous effectuez votre sélection, vous êtes redirigé vers le pipeline nouvellement créé.

    Le pipeline ETL est créé avec les paramètres default suivants :

    Cette configuration est recommandée pour de nombreux cas d'utilisation, y compris le développement et les tests, et convient parfaitement aux workloads de production qui doivent s'exécuter selon un calendrier. Pour plus de détails sur la planification des pipelines, voir tâche de pipeline pour les jobs.

    Vous pouvez ajuster ces paramètres depuis la barre d’outils du pipeline.

Alternativement, vous pouvez créer un pipeline ETL depuis le navigateur de Workspace :

  1. Cliquez sur Workspace dans le panneau latéral gauche.
  2. Sélectionnez n'importe quel dossier, y compris les dossiers Git.
  3. Cliquez sur **Create** dans le coin supérieur droit, et sur **pipeline ETL**.

Vous pouvez également créer un pipeline ETL depuis la page des Jobs et pipelines :

  1. Dans votre Workspace, cliquez Icône Workflows. sur **Tâches et pipelines** dans la barre latérale.
  2. Sous Nouveau , cliquez sur Pipeline ETL .

Options de configuration compute​

Databricks recommande de toujours utiliser l'**autoscaling amélioré**. Les valeurs par default pour d'autres configurations de compute fonctionnent bien pour de nombreux pipelines.

Les pipelines Serverless suppriment les options de configuration de compute. Pour les instructions de configuration des pipelines Serverless, consultez Configurer un pipeline Serverless.

Utilisez les paramètres suivants pour personnaliser les configurations de compute :

  • Les administrateurs de Workspace peuvent configurer une politique de clusters . Les politiques de compute permettent aux administrateurs de contrôler les options de compute disponibles pour les utilisateurs. Voir Sélectionner une politique de compute.

  • Vous pouvez éventuellement configurer le **mode Cluster** pour fonctionner avec la **taille fixe** ou l'**autoscaling hérité**. Consultez Optimisez l'utilisation des LakeFlow pipeline clusters avec l'autoscaling.

  • Pour les charges de travail avec autoscaling activé, définissez Min workers et Max workers pour définir les limites des comportements de mise à l'échelle. Consultez Configurer le compute classique pour les pipelines.

  • Vous pouvez éventuellement désactiver l'accélération Photon. Consultez Qu'est-ce que Photon ?.

  • Sélectionnez un profil d'instance si votre pipeline utilise un profil d'instance pour contrôler l'accès aux services cloud. Consultez la configuration du stockage cloud.

  • Utilisez les Cluster tags pour aider à surveiller les coûts associés aux pipelines. Voir Configurer les tags de compute.

  • Configurez les types d'instances pour spécifier le type de machines virtuelles utilisées pour exécuter votre pipeline. Voir Sélectionner les types d'instance pour exécuter un pipeline.

    • Sélectionnez un **type de Worker** optimisé pour les charges de travail configurées dans votre pipeline.
    • Vous pouvez éventuellement sélectionner un type de Driver qui diffère de votre type de Worker. Cela peut être utile pour réduire les coûts dans les pipelines avec de grands types de Worker et une faible utilisation du compute du Driver, ou pour choisir un type de Driver plus grand afin d'éviter les problèmes de mémoire insuffisante dans les charges de travail avec de nombreux petits Workers.

Définir l’utilisateur d’exécution​

L'utilisateur « Exécuter en tant que » vous permet de modifier l'identité qu'un pipeline utilise pour s'exécuter, ainsi que la propriété des tables qu'il crée ou met à jour. Ceci est utile dans les situations où l'utilisateur d'origine qui a créé le pipeline a été désactivé, par exemple, s'il a quitté l'entreprise. Dans ces cas, le pipeline peut cesser de fonctionner, et les tables qu'il a publiées peuvent devenir inaccessibles à d'autres. En mettant à jour le pipeline pour qu'il s'exécute sous une identité différente, telle qu'un Service Principal, et en réaffectant la propriété des tables publiées, vous pouvez restaurer l'accès et vous assurer que le pipeline continue de fonctionner. L'exécution de pipelines en tant que Service Principal est considérée comme une bonne pratique car ils ne sont pas liés à des utilisateurs individuels, ce qui les rend plus sécurisés, stables et fiables pour les charges de travail automatisées.

Autorisations requises​

Pour l'utilisateur qui effectue le changement :

  • Autorisations CAN_MANAGE sur le pipeline
  • Rôle CAN_USE sur le Service Principal (si le paramètre d’exécution est défini sur un Service Principal)

Pour l'utilisateur ou le Service Principal exécutant la tâche :

  • Accès au Workspace :

    • Autorisation d'accès au Workspace pour opérer au sein du workspace
    • Peut utiliser l'autorisation sur les politiques de clusters utilisées par le pipeline
    • Autorisation de création de compute dans le workspace.

  • Accès au code source :

    • Autorisation de **lecture** sur tous les Notebook inclus dans le code source du pipeline.
    • Lecture sur les fichiers du workspace si le pipeline les utilise

  • Autorisations Unity Catalog (pour les pipelines utilisant Unity Catalog) :

    • USE CATALOG sur le catalogue cible
    • USE SCHEMA et CREATE TABLE sur le schéma cible
    • MODIFY autorisation sur les tables existantes que le pipeline met à jour
    • CREATE SCHEMA autorisation si le pipeline crée de nouveaux schémas

  • Autorisations du Hive metastore hérité (pour les pipelines utilisant le Hive metastore) :

    • SELECT et MODIFY autorisations sur les bases de données et les tables cibles

  • Accès supplémentaire au stockage cloud (le cas échéant) :

    • Autorisations de lecture à partir des emplacements de stockage source
    • Autorisations d'écriture vers les emplacements de stockage cibles.

Comment définir l'utilisateur d'exécution​

Vous pouvez définir l'utilisateur run-as via les paramètres du pipeline à partir de la page de monitoring du pipeline ou de l'éditeur de pipeline. Pour modifier l'utilisateur depuis la page de monitoring du pipeline :

  1. Cliquez sur **Jobs & Pipelines** pour ouvrir la liste des pipelines et sélectionnez le nom du pipeline que vous souhaitez modifier.

  2. Sur la page de monitoring du pipeline, cliquez sur Paramètres .

  3. Dans la barre latérale Paramètres du pipeline , cliquez sur Icône de crayon. Modifier à côté de Exécuter en tant que .

  4. Dans le widget d’édition, sélectionnez l’une des options suivantes :

    • Votre propre compte utilisateur
    • Un Service Principal pour lequel vous avez l'autorisation **CAN_USE**

  5. Cliquez sur Enregistrer pour appliquer les modifications.

Lorsque vous mettez à jour l'utilisateur d'exécution :

  • L'identité du pipeline est modifiée pour utiliser le nouvel utilisateur ou Service Principal pour toutes les exécutions futures.
  • Dans les pipelines Unity Catalog, le propriétaire des tables publiées par le pipeline est mis à jour pour correspondre à la nouvelle identité d'exécution.
  • Les futures mises à jour du pipeline utilisent les autorisations et les informations d’identification de la nouvelle identité d’exécution.
  • Comme toute modification de paramètres, la nouvelle identité s'applique à la prochaine mise à jour du pipeline : les pipelines continus redémarrent automatiquement avec la nouvelle identité, tandis que les pipelines déclenchés l'appliquent lors de leur prochaine exécution. La modification du mode d'exécution peut interrompre une mise à jour active. Consultez Comment les modifications de configuration prennent effet.
remarque

Si la mise à jour du compte d'exécution échoue, vous recevez un message d'erreur expliquant la raison de l'échec. Les problèmes courants incluent des autorisations insuffisantes sur le Service Principal.

Autres considérations de configuration​

Les options de configuration suivantes sont également disponibles pour les pipelines :

Prise d'effet des modifications de configuration​

Lorsque vous modifiez et enregistrez les paramètres d'un pipeline, la modification s'applique à la prochaine mise à jour du pipeline :

  • Les pipelines continus redémarrent automatiquement avec la configuration mise à jour. Cela peut interrompre une mise à jour active.
  • **Changer le type** de Trigger à continu lancera automatiquement une nouvelle mise à jour avec les paramètres mis à jour. Inversement, le fait de changer le type de continu à Trigger annule une mise à jour active (continue).

Choisir une édition de produit​

Sélectionnez l'édition du produit avec les meilleures fonctionnalités pour les exigences de votre pipeline. Les éditions de produit suivantes sont disponibles :

  • Core pour exécuter des charges de travail d'ingestion en streaming. Sélectionnez l'édition Core si votre pipeline ne nécessite pas de fonctionnalités avancées telles que la capture de données modifiées (CDC) ou les attentes.
  • Pro pour exécuter des charges de travail d'ingestion en streaming et de CDC. L'édition de produit Pro prend en charge toutes les fonctionnalités Core, ainsi que le support des charges de travail qui nécessitent la mise à jour des tables en fonction des changements dans les données sources.
  • Advanced pour exécuter des charges de travail d'ingestion en streaming, des charges de travail CDC et des charges de travail qui nécessitent des attentes. L’édition de produit Advanced prend en charge les fonctionnalités des éditions Core et Pro et inclut des contraintes de qualité des données avec des attentes.

Vous pouvez sélectionner l'édition de produit lorsque vous créez ou modifiez un pipeline. Vous pouvez choisir une édition différente pour chaque pipeline. Pour plus de détails, y compris une répartition plus complète des fonctionnalités par édition, consultez la page produit des pipelines déclaratifs Apache Spark™ sur Databricks.

Les pipelines conservent 60 jours d'anciennes mises à jour dans l'interface utilisateur des pipelines et l'API Pipelines.

Les mises à jour actives (non terminales) apparaissent toujours. Si une mise à jour est plus ancienne que la fenêtre de rétention, Databricks l'exclut des réponses de liste, mais la conserve dans le log d’événements sous-jacent.

Remarque : si votre pipeline inclut des fonctionnalités non prises en charge par l'édition de produit sélectionnée, telles que les attentes, vous recevez un message d'erreur expliquant la raison de l'erreur. Vous pouvez ensuite modifier le pipeline pour sélectionner l'édition appropriée.

Configurer le code source​

Vous pouvez utiliser le navigateur d'assets dans l'éditeur de Lakeflow Pipelines pour configurer le code source qui définit votre pipeline. Le code source du pipeline est défini dans des scripts SQL ou Python stockés dans des fichiers de workspace. Lorsque vous créez ou modifiez votre pipeline, vous pouvez ajouter un ou plusieurs fichiers. By default, le code source du pipeline se trouve dans le dossier transformations du dossier racine de votre pipeline.

Parce que les pipelines analysent automatiquement les dépendances des datasets pour construire le graphe de traitement, vous pouvez ajouter des assets de code source dans n'importe quel ordre.

Pour plus de détails sur l'utilisation de l'éditeur de Lakeflow Pipelines, consultez Développer et déboguer des pipelines ETL avec l'éditeur de Lakeflow Pipelines.

Gérer les dépendances externes pour les pipelines qui utilisent Python​

Les Pipelines prennent en charge l'utilisation de dépendances externes dans vos pipelines, tels que les packages et les bibliothèques Python. Pour en savoir plus sur les options et les recommandations relatives à l'utilisation des dépendances, consultez Gérer les dépendances Python pour les pipelines.

Utilisez des modules Python stockés dans votre Workspace Databricks​

En plus d'implémenter votre code Python dans les fichiers de code source de pipeline, vous pouvez utiliser les dossiers Git Databricks ou les fichiers de Workspace pour stocker votre code en tant que modules Python. Le stockage de votre code sous forme de modules Python est particulièrement utile lorsque vous avez des fonctionnalités communes que vous souhaitez utiliser dans plusieurs pipelines ou notebooks du même pipeline. Pour savoir comment utiliser les modules Python avec vos pipelines, consultez Importer des modules Python à partir de dossiers Git ou de fichiers Workspace.

Sur cette page