ServicesÀ proposNotesContact Me contacter →
EN FR
Note

Configuration de l'environnement dlt

Configurer un projet dlt depuis zéro — environnement virtuel Python, installation, dlt init et le scaffold de projet qu'il crée.

Planté
dltdata engineeringetl

Configurer un projet dlt implique trois étapes : l’environnement Python, l’installation de dlt, et l’initialisation du projet via dlt init. L’étape d’initialisation crée la structure de répertoire que dlt utilise pour les credentials et la configuration.

Environnement Python

dlt nécessite Python 3.9 ou supérieur. Avant d’installer quoi que ce soit, il vaut la peine de vérifier votre version :

Terminal window
python --version
# ou
python3 --version

Si vous avez besoin d’installer Python : le programme d’installation python.org fonctionne sur toutes les plateformes. Sur macOS, Homebrew est une approche plus propre :

Terminal window
brew install python

Environnement virtuel

Créez toujours un environnement virtuel spécifique au projet. dlt a plusieurs dépendances transitives, et les isoler évite les conflits de version avec d’autres projets Python sur votre machine :

Terminal window
mkdir dlt-project
cd dlt-project


# Créer l'environnement virtuel
python -m venv venv


# L'activer
source venv/bin/activate          # macOS / Linux
# ou
venv\Scripts\activate             # Windows

L’activation change le Python et pip de votre shell vers les versions locales au projet. Vous verrez (venv) ajouté en préfixe à votre invite de commande en guise de confirmation.

Installer dlt

Avec l’environnement virtuel actif, installez dlt :

Terminal window
pip install dlt

dlt sépare les dépendances de destination — les bibliothèques nécessaires pour se connecter à chaque entrepôt — du package de base. Cela garde l’installation par défaut légère. Installez uniquement ce dont vous avez besoin :

Terminal window
pip install "dlt[duckdb]"      # développement local / tests
pip install "dlt[bigquery]"    # Google BigQuery
pip install "dlt[snowflake]"   # Snowflake
pip install "dlt[redshift]"    # Amazon Redshift

Pour la plupart des travaux de développement, commencez par DuckDB. C’est une base de données locale sur fichier qui ne nécessite ni serveur ni credentials — vous pouvez vérifier qu’un pipeline fonctionne correctement avant de toucher un entrepôt cloud.

Vous pouvez installer plusieurs destinations ensemble :

Terminal window
pip install "dlt[duckdb,bigquery]"

Initialisation du projet : dlt init

dlt init est la partie que la plupart des documentations couvrent trop rapidement. Il vaut la peine de comprendre ce qu’elle crée.

Terminal window
dlt init rest_api duckdb

Les deux arguments sont : le type de source et la destination. Pour les pipelines basés sur REST API, vous utiliserez presque toujours rest_api. La destination peut être changée plus tard sans réinitialisation.

L’exécution de dlt init crée ce qui suit :

dlt-project/
├── .dlt/
│   ├── config.toml          # configuration non-sensible (committée)
│   └── secrets.toml         # credentials (dans .gitignore)
├── rest_api_pipeline.py     # fichier pipeline de démarrage généré
└── .gitignore               # préconfiguré pour exclure secrets.toml

Répertoire .dlt/ — Le répertoire de configuration principal pour ce projet. dlt regarde ici en premier lors de la résolution des secrets et des valeurs de configuration.

secrets.toml — Où aller les credentials pour le développement local. Il est ajouté automatiquement à .gitignore. Ouvrez-le immédiatement après dlt init et ajoutez vos credentials API :

[sources.github]
api_key = "your-token-here"

Le chemin de clé — sources.github.api_key — devient la façon dont vous référencez cette valeur dans le code : dlt.secrets["sources.github.api_key"]. Voir Gestion des secrets dlt pour la hiérarchie complète et comment les credentials passent du développement local à la production.

config.toml — Configuration non-sensible qui peut être committée. Des choses comme les tailles de page, les URL de base, les niveaux de log. Laissez-le vide jusqu’à ce que vous ayez des paramètres qui appartiennent réellement ici.

rest_api_pipeline.py — Un fichier de démarrage généré avec un exemple de code montrant comment configurer et exécuter un pipeline REST API Source. Supprimez l’exemple de code et remplacez-le par le vôtre. Le fichier existe comme point de départ, pas comme quelque chose que vous étendez en place.

.gitignore — Automatiquement configuré pour exclure secrets.toml et quelques fichiers spécifiques à dlt. Ne remplacez pas ceci — laisser les credentials hors du contrôle de version est essentiel.

Vérifier l’installation

Après dlt init, vérifiez que le projet fonctionne avant d’écrire du code de pipeline :

Terminal window
python rest_api_pipeline.py

L’exemple de code généré effectue un vrai appel API. S’il s’exécute sans erreurs, votre environnement Python, l’installation de dlt et la configuration de base fonctionnent tous. S’il échoue, le message d’erreur vous indiquera exactement ce qui manque.

Ce que vous construirez par-dessus

Avec l’environnement en place, les étapes suivantes sont :

  1. Remplacer l’exemple de code dans rest_api_pipeline.py par votre vraie configuration API — voir Configuration dlt REST API Source pour comprendre comment fonctionne cette configuration.
  2. Ajouter vos credentials API dans secrets.toml — voir Gestion des secrets dlt pour les conventions de nommage attendues par dlt.
  3. Exécuter le pipeline contre DuckDB pour vérifier les résultats avant de pointer vers votre entrepôt de production.

Le pattern de développement DuckDB-first vaut la peine d’être souligné : vous pouvez itérer sur la logique du pipeline, la pagination et le schéma sans toucher aux ressources cloud. Une fois que le pipeline produit des résultats corrects localement, remplacer destination="duckdb" par destination="bigquery" est un changement d’une ligne.

Notes sur le fichier pipeline généré

Le fichier rest_api_pipeline.py généré par dlt init rest_api duckdb contient un exemple fonctionnel utilisant une API publique (souvent l’API GitHub ou une API ouverte similaire). L’exemple est utile comme référence mais n’est pas structuré comme vous organiseriez un pipeline de production. Ne vous sentez pas contraint par son organisation.

Un pipeline de production sépare typiquement la configuration de source de l’exécution dans différents fichiers ou modules, surtout quand vous avez plusieurs sources ou destinations. Mais pour un pipeline à source unique, un seul fichier est tout à fait raisonnable. La contrainte clé est que les credentials n’apparaissent jamais dans les fichiers Python — ils se trouvent dans secrets.toml ou des variables d’environnement, accédés via dlt.secrets.