Configurer les paramètres de pipeline pour Delta Live Tables

Cet article fournit des détails sur la configuration des paramètres de pipeline pour Delta Live Tables. Delta Live Tables fournit une interface utilisateur pour la configuration et la modification des paramètres de pipeline. L’interface utilisateur fournit également une option permettant d’afficher et de modifier des paramètres au format JSON.

Remarque

Vous pouvez configurer la plupart des paramètres avec l’interface utilisateur ou une spécification JSON. Certaines options avancées sont disponibles uniquement à l’aide de la configuration JSON.

Databricks recommande de vous familiariser avec les paramètres Delta Live Tables à l’aide de l’interface utilisateur. Si nécessaire, vous pouvez modifier directement la configuration JSON dans l’espace de travail. Les fichiers config JSON sont également utiles lors du déploiement de pipelines dans de nouveaux environnements ou lors de l’utilisation de l’interface CLI ou de l’API REST.

Pour obtenir une référence complète sur les paramètres de configuration JSON de Delta Live Tables, consultez Configurations de pipeline Delta Live Tables.

Remarque

Étant donné que les ressources de calcul sont entièrement gérées pour les pipelines serverless, les paramètres de calcul tels que la mise à l’échelle automatique améliorée, les stratégies de cluster, les types d’instances et les balises de cluster ne sont pas disponibles lorsque vous sélectionnez Serverless (préversion publique) pour un pipeline.

Vous pouvez toujours passer des paramètres de configuration à un pipeline serverless, mais tout paramètre défini un objet clusters dans la configuration JSON est ignoré.

Pour en savoir plus sur l’activation des pipelines DLT serverless, contactez votre équipe de compte Azure Databricks.

Choisir une édition de produit

Sélectionnez l’édition de produit de Delta Live Tables avec les fonctionnalités les mieux adaptées à vos exigences de pipeline. Les éditions de produit suivantes sont disponibles :

  • Core pour exécuter des charges de travail d’ingestion de diffusion en continu. Sélectionnez l’édition Core si votre pipeline ne nécessite pas de fonctionnalités avancées telles que la capture des changements de données (CDC) ou les attentes de Delta Live Tables.
  • Pro pour exécuter les charges de travail de diffusion en continu et CDC. L’édition de produit Pro prend en charge toutes les fonctionnalités, ainsi que les charges de travail qui nécessitent la mise à jour des tables Core en fonction des modifications apportées aux données sources.
  • Advanced pour exécuter les charges de travail d’ingestion de diffusion en continu, les charges de travail CDC et les 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 prend également en charge l’application des contraintes de qualité des données avec les attentes de Delta Live Tables.

Vous pouvez sélectionner l’édition du produit lorsque vous créez ou modifiez un pipeline. Vous pouvez sélectionner une édition différente pour chaque pipeline. Consultez la page du produit Delta Live Tables.

Remarque

Si votre pipeline inclut des fonctionnalités non prises en charge par l’édition de produit sélectionnée, par exemple, les attentes, vous recevrez un message d’erreur avec la raison de l’erreur. Vous pouvez ensuite modifier le pipeline pour sélectionner l’édition appropriée.

Choisir un mode de pipeline

Vous pouvez mettre à jour votre pipeline en continu ou avec des déclencheurs manuels basés sur le mode de pipeline. Consultez Exécution continue et déclenchée du pipeline.

Sélectionner une stratégie de cluster

Les utilisateurs doivent disposer des autorisations de déploiement du calcul pour configurer et mettre à jour des pipelines Delta Live Tables. Les administrateurs d’espace de travail peuvent configurer des stratégies de cluster pour permettre aux utilisateurs d’accéder aux ressources de calcul pour Delta Live Tables. Consultez Définir des limites sur le calcul de pipeline Delta Live Tables.

Remarque

  • Les stratégies de cluster sont facultatives. Vérifiez auprès de l’administrateur de votre espace de travail si vous n’avez pas les privilèges de calcul requis pour Delta Live Tables.

  • Pour vous assurer que les valeurs par défaut de stratégie de cluster sont correctement appliquées, définissez la valeur apply_policy_default_values sur true dans les configurations de cluster dans votre configuration de pipeline :

    {
      "clusters": [
        {
          "label": "default",
          "policy_id": "<policy-id>",
          "apply_policy_default_values": true
        }
      ]
    }
    

Configurer des bibliothèques de code source

Vous pouvez utiliser le sélecteur de fichiers dans l’interface utilisateur Delta Live Tables pour configurer le code source définissant votre pipeline. Le code source du pipeline est défini dans des notebooks Databricks ou dans des scripts SQL ou Python stockés dans des fichiers d’espace de travail. Lorsque vous créez ou modifiez votre pipeline, vous pouvez ajouter un ou plusieurs notebooks ou fichiers d’espace de travail ou une combinaison de notebooks et de fichiers d’espace de travail.

Étant donné que Delta Live Tables analyse automatiquement les dépendances de jeu de données pour construire le graphe de traitement de votre pipeline, vous pouvez ajouter des bibliothèques de code source dans n’importe quel ordre.

Vous pouvez également modifier le fichier JSON pour inclure le code source Delta Live Tables défini dans les scripts SQL et Python stockés dans des fichiers d’espace de travail. L’exemple suivant inclut des notebooks et des fichiers d’espace de travail des référentiels Databricks :

{
  "name": "Example pipeline 3",
  "storage": "dbfs:/pipeline-examples/storage-location/example3",
  "libraries": [
    { "notebook": { "path": "/example-notebook_1" } },
    { "notebook": { "path": "/example-notebook_2" } },
    { "file": { "path": "/Repos/<user-name>@databricks.com/Apply_Changes_Into/apply_changes_into.sql" } },
    { "file": { "path": "/Repos/<user-name>@databricks.com/Apply_Changes_Into/apply_changes_into.py" } }
  ]
}

Spécifier un emplacement de stockage

Vous pouvez spécifier un emplacement de stockage pour un pipeline qui publie dans le metastore Hive. La principale motivation pour spécifier un emplacement est de contrôler l’emplacement de stockage de l’objet pour les données écrites par votre pipeline.

Étant donné que toutes les tables, données, points de contrôle et métadonnées des pipelines Delta Live Tables sont entièrement gérés par Delta Live Tables, la plupart des interactions avec les jeux de données Delta Live Tables se produisent via des tables inscrites dans le metastore Hive ou Unity Catalog.

Spécifier un schéma cible pour les tables de sortie de pipeline

Bien que facultatif, vous devez spécifier une cible pour publier les tables créées par votre pipeline chaque fois que vous dépassez le développement et le test d’un nouveau pipeline. La publication d’un pipeline sur une cible rend les jeux de données disponibles pour l’interrogation dans d’autres emplacements de votre environnement Azure Databricks. Consultez Publier des données à partir de pipelines Delta Live Tables dans le metastore Hive ou Utiliser Unity Catalog avec vos pipelines Delta Live Tables.

Configurer vos paramètres de calcul

Chaque pipeline Delta Live Tables a deux clusters associés :

  • Le cluster updates traite les mises à jour du pipeline.
  • Le cluster maintenance exécute des tâches de maintenance quotidiennes.

La configuration utilisée par ces clusters est déterminée par l’attribut clusters spécifié dans les paramètres de votre pipeline.

Vous pouvez ajouter des paramètres de calcul qui s’appliquent uniquement à un type spécifique de cluster à l’aide d’étiquettes de cluster. Vous pouvez utiliser trois étiquettes différentes lors de la configuration de clusters de pipeline :

Remarque

Le paramètre d’étiquette de cluster peut être omis si vous définissez une seule configuration de cluster. L’étiquette default est appliquée aux configurations de cluster si aucun paramètre n’est fourni pour l’étiquette. Le paramètre d’étiquette de cluster est requis uniquement si vous devez personnaliser les paramètres pour différents types de cluster.

  • L’étiquette default définit les paramètres de calcul à appliquer aux clusters updates et maintenance. Appliquer les mêmes paramètres aux deux clusters améliore la fiabilité des exécutions de maintenance en veillant à ce que les configurations requises, par exemple les informations d’identification d’accès aux données pour un emplacement de stockage, soient appliquées au cluster de maintenance.
  • L’étiquette maintenance définit les paramètres de calcul à appliquer uniquement au cluster maintenance. Vous pouvez également utiliser l’étiquette maintenance pour remplacer les paramètres configurés par l’étiquette default.
  • L’étiquette updates définit les paramètres à appliquer uniquement au cluster updates. Utilisez l’étiquette updates pour configurer les paramètres qui ne doivent pas être appliqués au cluster maintenance.

Les paramètres définis à l’aide des étiquettes default et updates sont fusionnés pour créer la configuration finale du cluster updates. Si le même paramètre est défini à l’aide des étiquettes default et updates, le paramètre défini avec l’étiquette updates remplace le paramètre défini par l’étiquette default.

L’exemple suivant définit un paramètre de configuration Spark qui est ajouté uniquement à la configuration du cluster updates :

{
  "clusters": [
    {
      "label": "default",
      "autoscale": {
        "min_workers": 1,
        "max_workers": 5,
        "mode": "ENHANCED"
      }
    },
    {
      "label": "updates",
      "spark_conf": {
         "key": "value"
      }
    }
  ]
}

Delta Live Tables fournit des options similaires pour les paramètres de cluster que d’autres calculs sur Azure Databricks. Comme d’autres paramètres de pipeline, vous pouvez modifier la configuration JSON des clusters afin de spécifier des options qui ne sont pas présentes dans l’interface utilisateur. Voir Calculer.

Remarque

  • Étant donné que le runtime Delta Live Tables gère le cycle de vie des clusters de pipeline et exécute une version personnalisée de Databricks Runtime, vous ne pouvez pas définir manuellement certains paramètres de cluster dans une configuration de pipeline, comme la version Spark ou les noms de cluster. Consultez Attributs de cluster qui ne sont pas définissables par l’utilisateur.
  • Vous pouvez configurer des pipelines Delta Live Tables pour tirer parti de Photon. Consultez Qu’est-ce que Photon ?.

Sélectionner des types d’instance pour exécuter un pipeline

Par défaut, Delta Live Tables sélectionne les types d’instance pour les nœuds pilote et worker qui exécutent votre pipeline, mais vous pouvez également configurer manuellement les types d’instance. Par exemple, vous pouvez sélectionner des types d’instance pour améliorer les performances du pipeline ou résoudre les problèmes de mémoire lors de l’exécution de votre pipeline. Vous pouvez configurer des types d’instance lorsque vous créez ou modifiez un pipeline avec l’API REST, ou dans l’interface utilisateur de Delta Live Tables.

Pour configurer des types d’instance lorsque vous créez ou modifiez un pipeline dans l’interface utilisateur Delta Live Tables :

  1. Cliquez sur le bouton Settings .
  2. Dans la page Paramètres du pipeline, cliquez sur le bouton JSON.
  3. Entrez les configurations du type d’instance dans la configuration du cluster :

Remarque

Pour éviter d’affecter des ressources inutiles au cluster maintenance, cet exemple utilise l’étiquette updates pour définir les types d’instance uniquement pour le cluster updates. Pour affecter les types d’instance aux clusters updates et maintenance, utilisez l’étiquette default ou omettez le paramètre de l’étiquette. L’étiquette default est appliquée aux configurations de cluster de pipeline si aucun paramètre n’est fourni pour l’étiquette. Consultez Configurer vos paramètres de calcul.

{
  "clusters": [
    {
      "label": "updates",
      "node_type_id": "Standard_D12_v2",
      "driver_node_type_id": "Standard_D3_v2",
      "..." : "..."
    }
  ]
}

Utiliser la mise à l’échelle automatique pour augmenter l’efficacité et réduire l’utilisation des ressources

Utilisez la mise à l’échelle automatique améliorée pour optimiser l’utilisation du cluster de vos pipelines. La mise à l’échelle automatique améliorée ajoute des ressources supplémentaires uniquement si le système détermine que ces ressources augmentent la vitesse de traitement du pipeline. Les ressources sont libérées lorsqu’elles ne sont plus nécessaires et les clusters sont arrêtés dès que toutes les mises à jour du pipeline se terminent.

Suivez les instructions suivantes lors de la configuration de la mise à l’échelle automatique améliorée pour les pipelines de production :

  • Conservez le paramètre Min workers par défaut.
  • Définissez le paramètre Max workers sur une valeur en fonction du budget et de la priorité du pipeline.

Retarder l’arrêt du calcul

Comme un cluster Delta Live Tables s’arrête automatiquement lorsqu’il n’est pas utilisé, le référencement d’une stratégie de cluster qui définit autotermination_minutes dans votre configuration de cluster génère une erreur. Pour contrôler le comportement d’arrêt des clusters, vous pouvez utiliser le mode de développement ou de production, ou utiliser le paramètre pipelines.clusterShutdown.delay dans la configuration du pipeline. L’exemple suivant définit la valeur de pipelines.clusterShutdown.delay sur 60 secondes :

{
    "configuration": {
      "pipelines.clusterShutdown.delay": "60s"
    }
}

Lorsque le mode production est activé, la valeur par défaut pour pipelines.clusterShutdown.delay est 0 seconds. Lorsque le mode development est activé, la valeur par défaut est 2 hours.

Créer un cluster mononœud

Si vous définissez num_workers sur 0 dans les paramètres du cluster, le cluster est créé en tant que cluster à nœud unique. La configuration d’un cluster de mise à l’échelle automatique, du paramètre min_workers sur 0 et de max_workers également sur 0 crée un cluster à nœud unique.

Si vous configurez un cluster de mise à l’échelle automatique et que vous définissez uniquement min_workers sur 0, le cluster n’est pas créé en tant que cluster à nœud unique. Le cluster a au moins un Worker actif à tout moment jusqu’à ce qu’il soit arrêté.

Exemple de configuration de cluster pour créer un cluster à nœud unique dans Delta Live Tables :

{
    "clusters": [
      {
        "num_workers": 0
      }
    ]
}

Configurer des étiquettes de cluster

Vous pouvez utiliser des étiquettes de cluster pour surveiller l’utilisation de vos clusters de pipeline. Ajoutez des étiquettes de cluster dans l’interface utilisateur Delta Live Tables lorsque vous créez ou modifiez un pipeline, ou en modifiant les paramètres JSON de vos clusters de pipeline.

Configuration du stockage cloud

Pour accéder au stockage Azure, vous devez configurer les paramètres requis, y compris les jetons d’accès, à l’aide des paramètres spark.conf de vos configurations de cluster. Pour obtenir un exemple de configuration de l’accès à un compte de stockage Azure Data Lake Storage Gen2 (ADLS Gen2), consultez Accéder en toute sécurité aux informations d’identification de stockage en utilisant des secrets dans un pipeline.

Paramétriser les pipelines

Le code Python et SQL qui définit vos jeux de données peut être paramétrisé par les paramètres du pipeline. La paramétrisation permet les cas d’usage suivants :

  • Séparation des chemins longs et d’autres variables dans votre code.
  • Réduction de la quantité de données traitées dans les environnements de développement ou intermédiaire pour accélérer la phase de test.
  • Réutilisation de la même logique de transformation pour le traitement à partir de plusieurs sources de données.

L’exemple suivant utilise la valeur de configuration startDate pour limiter le pipeline de développement à un sous-ensemble des données d’entrée :

CREATE OR REFRESH LIVE TABLE customer_events
AS SELECT * FROM sourceTable WHERE date > '${mypipeline.startDate}';
@dlt.table
def customer_events():
  start_date = spark.conf.get("mypipeline.startDate")
  return read("sourceTable").where(col("date") > start_date)
{
  "name": "Data Ingest - DEV",
  "configuration": {
    "mypipeline.startDate": "2021-01-02"
  }
}
{
  "name": "Data Ingest - PROD",
  "configuration": {
    "mypipeline.startDate": "2010-01-02"
  }
}

Intervalle de déclenchement des pipelines

Vous pouvez utiliser pipelines.trigger.interval pour contrôler l’intervalle de déclenchement d’un flux mettant à jour une table ou un pipeline entier. Étant donné qu’un pipeline déclenché traite chaque table une seule fois, le pipelines.trigger.interval est utilisé uniquement avec des pipelines continus.

Databricks recommande de définir pipelines.trigger.interval sur des tables individuelles en raison de différentes valeurs par défaut pour la diffusion en continu et les requêtes par lots. Définissez la valeur sur un pipeline uniquement lorsque votre traitement nécessite le contrôle des mises à jour pour l’ensemble du graphique de pipeline.

Vous définissez pipelines.trigger.interval sur une table à l’aide de spark_conf dans Python ou de SET dans SQL :

@dlt.table(
  spark_conf={"pipelines.trigger.interval" : "10 seconds"}
)
def <function-name>():
    return (<query>)
SET pipelines.trigger.interval=10 seconds;

CREATE OR REFRESH LIVE TABLE TABLE_NAME
AS SELECT ...

Pour définir pipelines.trigger.interval sur un pipeline, ajoutez-le à l’objet configuration dans les paramètres du pipeline :

{
  "configuration": {
    "pipelines.trigger.interval": "10 seconds"
  }
}

Autoriser les utilisateurs non administrateurs à afficher les journaux des pilotes à partir d’un pipeline avec catalogue Unity

Par défaut, seuls le propriétaire du pipeline et les administrateurs de l’espace de travail ont le droit d’afficher les journaux des pilotes du cluster qui exécute un pipeline compatible avec un catalogue Unity. Vous pouvez activer l’accès aux journaux de pilotes pour n’importe quel utilisateur avec des autorisations PEUT GÉRER, PEUT AFFICHER ou PEUT EXÉCUTER en ajoutant le paramètre de configuration Spark suivant à l’objet configuration dans les paramètres du pipeline :

{
  "configuration": {
    "spark.databricks.acl.needAdminPermissionToViewLogs": "false"
  }
}

Ajouter des notifications par e-mail pour les événements de pipeline

Vous pouvez configurer une ou plusieurs adresses e-mail pour recevoir des notifications lorsque les opérations suivantes se produisent :

  • Une mise à jour du pipeline se termine correctement.
  • Une mise à jour de pipeline échoue, soit avec une nouvelle tentative, soit avec une erreur non renouvelable. Sélectionnez cette option pour recevoir une notification pour toutes les défaillances du pipeline.
  • Une mise à jour de pipeline échoue avec une erreur non retenable (irrécupérable). Sélectionnez cette option pour recevoir une notification uniquement lorsqu’une erreur non renouvelable se produit.
  • Un flux de données unique échoue.

Pour configurer les notifications par e-mail lorsque vous créez ou modifiez un pipeline :

  1. Cliquez sur Ajouter une notification.
  2. Entrez une ou plusieurs adresses e-mail pour recevoir des notifications.
  3. Cochez la case pour chaque type de notification à envoyer aux adresses e-mail configurées.
  4. Cliquez sur Ajouter une notification.

Contrôle de la gestion de l’objet tombstone pour les demandes de renseignements sur le DSC de type 1

Les paramètres suivants peuvent être utilisés pour contrôler le comportement de la gestion des objets tombstone pour les événements DELETE pendant le traitement SCD de type 1 :

  • pipelines.applyChanges.tombstoneGCThresholdInSeconds: définissez cette valeur pour qu’elle corresponde à l’intervalle le plus élevé prévu, en secondes, entre les données non ordonnées. La valeur par défaut est de 172800 secondes (2 jours).
  • pipelines.applyChanges.tombstoneGCFrequencyInSeconds: ce paramètre permet de contrôler la fréquence, en secondes, à laquelle les objet tombstone sont vérifiées pour être nettoyées. La valeur par défaut est 1800 secondes (30 minutes).

Consultez Capture des changements de données simplifiée avec l’API APPLY CHANGES dans Delta Live Tables.