Partager via

Conseils, recommandations et fonctionnalités pour développer et tester les pipelines Delta Live Tables

  • Article

Cet article décrit les modèles que vous pouvez utiliser pour développer et tester des pipelines Delta Live Tables. Grâce aux paramètres de pipeline, Delta Live Tables vous permet de spécifier des configurations pour isoler les pipelines dans les environnements de développement, de test et de production. Les recommandations de cet article s’appliquent au développement de code SQL et Python.

Databricks recommande d’utiliser des paramètres pour écrire du code Delta Live Tables extensible. Cela est particulièrement utile pour écrire du code portable entre les environnements dev, test et prod. Par exemple, vous pouvez pointer vos pipelines au niveau des données de test avec des problèmes connus pour tester la résilience du code. Consultez Contrôler les sources de données avec des paramètres.

Utiliser le mode de développement pour exécuter des mises à jour de pipeline

Delta Live Tables a une bascule d’interface utilisateur pour contrôler si vos mises à jour de pipeline s’exécutent en mode développement ou production. Ce mode contrôle la façon dont les mises à jour de pipeline sont traitées, notamment :

  • Le mode de développement ne termine pas immédiatement les ressources de calcul après la réussite ou l’échec d’une mise à jour. Vous pouvez réutiliser les mêmes ressources de calcul pour exécuter plusieurs mises à jour de pipeline sans attendre qu’un cluster démarre.
  • Le mode de développement ne réessaye pas automatiquement en cas d’échec de tâche, ce qui vous permet de détecter et de corriger immédiatement les erreurs logiques ou syntactiques dans votre pipeline.

Databricks recommande d’utiliser le mode de développement pendant le développement et les tests. Toutefois, lors du déploiement dans un environnement de production, basculez toujours vers le mode de production.

Consultez Modes de développement et de production.

Tester du code source de pipeline sans attendre la mise à jour de tables

Si vous souhaitez rechercher les problèmes liés au code source de votre pipeline, tels que des erreurs de syntaxe et d’analyse pendant le développement et les tests, vous pouvez exécuter une opération Valider une mise à jour. Étant donné qu’une mise à jour Validate vérifie uniquement l’exactitude du code source de pipeline sans exécuter une mise à jour réelle sur des tables, vous pouvez identifier plus rapidement et corriger des problèmes avant d’exécuter une mise à jour de pipeline réelle.

Spécifier un schéma cible pendant toutes les phases de cycle de vie du développement

Tous les jeux de données d’un pipeline Delta Live Tables référencent le LIVE schéma virtuel, inaccessible en dehors du pipeline. Si un schéma cible est spécifié, le schéma virtuel LIVE indique le schéma cible. Vous devez spécifier un schéma cible pour passer en revue les résultats écrits dans chaque table pendant une mise à jour.

Vous devez spécifier un schéma cible unique à votre environnement. Chaque table d’un schéma donné ne peut être mise à jour que par un seul pipeline.

Vous pouvez isoler ces environnements en créant des pipelines distincts pour le développement, le test et la production avec différentes cibles. L’utilisation du paramètre de schéma cible vous permet de supprimer la logique qui utilise l’interpolation de chaîne ou d’autres widgets ou paramètres pour contrôler les sources et cibles de données.

Consultez Utiliser le catalogue Unity avec vos pipelines Delta Live Tables et utiliser des pipelines Delta Live Tables avec un metastore Hive hérité.

Utiliser des dossiers Git Databricks pour gérer les pipelines Delta Live Tables

Databricks recommande d’utiliser des dossiers Git pendant le développement, les tests et le déploiement en production d’un pipeline Delta Live Tables. Les dossiers Git permettent les actions suivantes :

  • Suivi de l’évolution du code au fil du temps.
  • Fusion des modifications apportées par plusieurs développeurs.
  • Pratiques de développement logiciel telles que les révisions de code.

Databricks recommande de configurer un seul référentiel Git pour tout le code lié à un pipeline.

Chaque développeur doit avoir son propre dossier Git Databricks configuré pour le développement. Pendant le développement, l’utilisateur configure son propre pipeline à partir de son dossier Git Databricks et teste la nouvelle logique à l’aide de jeux de données de développement ainsi que de schémas et d’emplacements isolés. Une fois le travail de développement terminé, l’utilisateur valide et transmet les modifications à sa branche dans le référentiel Git central et ouvre une demande de tirage sur la branche de test ou d’assurance qualité.

La branche résultante doit être extraite dans un dossier Git Databricks, et un pipeline doit être configuré à l’aide de jeux de données de test et d’un schéma de développement. En supposant que la logique s’exécute comme prévu, une requête de tirage ou une branche de mise en production doit être préparée pour envoyer les modifications en production.

Bien que les dossiers Git puissent être utilisés pour synchroniser du code entre les environnements, les paramètres de pipeline doivent être conservés manuellement ou à l’aide d’outils tels que Terraform.

Ce flux de travail est similaire à l’utilisation de dossiers Git pour CI/CD dans tous les travaux Databricks. Consultez les Techniques CI/CD avec Git et les dossiers Git Databricks (Repos).

Segmenter le code source pour les étapes d’ingestion et de transformation

Databricks recommande d’isoler les requêtes qui ingèrent des données de la logique de transformation enrichissant et validant les données. Si vous organisez le code source pour l’ingestion de données à partir de sources de données de développement ou de test dans un répertoire distinct de la logique d’ingestion des données de production, vous pouvez configurer des pipelines pour différents environnements avec des jeux de données spécifiques à ces environnements. Par exemple, vous pouvez accélérer le développement à l’aide de jeux de données plus petits pour les tests. Consultez Créer des exemples de jeux de données pour le développement et les tests.

Vous pouvez également utiliser des paramètres pour contrôler les sources de données pour le développement, les tests et la production. Consultez Utiliser des paramètres avec des pipelines Delta Live Tables.

Étant donné que les pipelines Delta Live Tables utilisent le LIVE schéma virtuel pour gérer toutes les relations de jeu de données, en configurant des pipelines de développement et de test avec du code source d’ingestion qui charge des exemples de données, vous pouvez remplacer des exemples de jeux de données à l’aide de noms de tables de production pour tester le code. La même logique de transformation peut être utilisée dans tous les environnements.

Créer des exemples de jeux de données pour le développement et le test

Databricks recommande de créer des jeux de données de développement et de test pour tester la logique de pipeline avec des données attendues et des enregistrements potentiellement mal formés ou endommagés. Il existe plusieurs façons de créer des jeux de données qui peuvent être utiles pour le développement et les tests, notamment :

  • La sélection d’un sous-ensemble de données à partir d’un jeu de données de production.
  • L’utilisation de données anonymisées ou générées artificiellement pour les sources contenant des informations d'identification personnelle.
  • La création de données de test avec des résultats bien définis basés sur la logique de transformation en aval.
  • L’anticipation d’altération des données, d’enregistrements mal formés et de modifications de données en amont en créant des enregistrements qui ne correspondent pas aux attentes de schéma de données.

Par exemple, si vous avez un notebook qui définit un jeu de données à l’aide du code suivant :

CREATE OR REFRESH STREAMING TABLE input_data AS SELECT * FROM read_files("/production/data", "json")

Vous pouvez créer un échantillon de jeu de données contenant des enregistrements spécifiques à l’aide d’une requête comme celle-ci :

CREATE OR REFRESH MATERIALIZED VIEW input_data AS
SELECT "2021/09/04" AS date, 22.4 as sensor_reading UNION ALL
SELECT "2021/09/05" AS date, 21.5 as sensor_reading

L’exemple suivant illustre le filtrage de données publiées pour créer un sous-ensemble des données de production pour le développement ou les tests :

CREATE OR REFRESH MATERIALIZED VIEW input_data AS SELECT * FROM prod.input_data WHERE date > current_date() - INTERVAL 1 DAY

Pour utiliser ces différents jeux de données, créez plusieurs pipelines avec les blocs-notes qui implémentent la logique de transformation. Chaque pipeline peut lire les données du jeu de donnéesLIVE.input_data, mais il est configuré pour inclure le bloc-notes qui crée le jeu de données spécifique à l’environnement.