ServicesÀ proposNotesContact Me contacter →
EN FR
Note

dlt pour le développement de pipelines assisté par IA

Pourquoi la conception Python-native et déclarative de dlt se prête bien au développement assisté par IA — le REST API builder, les fonctionnalités spécifiques à BigQuery, la documentation adaptée aux LLMs et les résultats en production

Planté
dltbigquerydata engineeringetlai

dlt (data load tool) est une bibliothèque Python-native et déclarative pour construire des pipelines de données personnalisés sans infrastructure requise. Ses propriétés de conception — Python standard, configuration déclarative, documentation bien structurée — la rendent adaptée à la génération de pipelines assistée par IA.

Pourquoi dlt se prête bien à l’IA

dlt est du Python standard — pas de DSL propriétaire, pas de formats de configuration YAML, pas d’infrastructure backend à gérer.

Trois propriétés sont pertinentes pour le développement assisté par IA :

Python est le langage avec le plus de données d’entraînement LLM. Générer un pipeline dlt signifie travailler en Python plutôt qu’un DSL propriétaire comme le YAML de Meltano ou les configs de connecteurs Airbyte, qui ont bien moins de représentation dans les données d’entraînement.

Les patterns déclaratifs sont contraints. Le REST API builder de dlt utilise un style déclaratif où vous décrivez les endpoints, la pagination, l’authentification et la write disposition, et le framework gère l’exécution. Les patterns de sortie contraints produisent du code généré par IA plus cohérent.

La documentation est structurée pour la consommation machine. Les assistants IA peuvent la parcourir pour générer des configurations à partir de la documentation API. Un utilisateur de dlt a rapporté avoir complété un pipeline entier “en cinq minutes en utilisant la documentation de la bibliothèque”, avec le flux de travail suivant : pointer l’IA vers les docs de l’API source et la référence de dlt, et générer la configuration.

Le REST API builder en pratique

Le REST API source de dlt fournit un moyen déclaratif de se connecter à n’importe quelle API REST. Un pipeline API marketing typique ciblant BigQuery tient en environ 30 lignes :

import dlt
from dlt.sources.rest_api import rest_api_source


# Définir une source API marketing avec pagination
source = rest_api_source({
    "client": {
        "base_url": "https://api.marketing-platform.com/v1",
        "auth": {"type": "bearer", "token": dlt.secrets.value}
    },
    "resources": [
        {
            "name": "campaigns",
            "endpoint": {
                "path": "campaigns",
                "paginator": {"type": "offset", "limit": 100}
            },
            "write_disposition": "merge",
            "primary_key": "id"
        }
    ]
})


# Créer le pipeline ciblant BigQuery
pipeline = dlt.pipeline(
    pipeline_name="marketing_data",
    destination="bigquery",
    dataset_name="marketing"
)


# L'exécuter
load_info = pipeline.run(source)

Cela couvre la pagination, l’authentification, le chargement incrémental via merge disposition, et les optimisations spécifiques à BigQuery — dans une configuration qu’un assistant IA peut générer depuis une spec API.

Les fonctionnalités clés qui éliminent le boilerplate :

  • Inférence de schéma automatique. dlt inspecte les données et crée les schémas. Pas de mapping colonne par colonne manuel.
  • Évolution du schéma. Quand les schémas sources changent (un problème constant avec les APIs de plateformes publicitaires), dlt le gère automatiquement. Les nouvelles colonnes sont ajoutées. Les changements de type sont gérés. Cela élimine l’une des plus grandes charges de maintenance des pipelines personnalisés.
  • Chargement incrémental. La configuration write_disposition: "merge" gère la gestion d’état de manière déclarative. Pas de suivi manuel de ce qui a été chargé, pas de gestion de checkpoint.
  • Gestion des JSON imbriqués. Les structures JSON imbriquées s’aplatissent automatiquement en tables enfants avec une profondeur d’imbrication configurable. Les réponses des APIs marketing sont souvent profondément imbriquées, et dlt gère cela sans logique d’aplatissement personnalisée.

Fonctionnalités spécifiques à BigQuery

dlt n’est pas agnostique aux entrepôts de la façon dont certains outils le sont — il dispose d’optimisations spécifiques pour chaque destination. Pour BigQuery :

Staging GCS pour les grands chargements. Au lieu de streamer les données directement vers BigQuery (qui coûte 0,01 $ par 200 Mo), dlt peut passer par Google Cloud Storage et utiliser le chargement par lot gratuit. Pour les pipelines de données marketing qui déplacent des gigaoctets quotidiennement, c’est une différence de coût significative. Voir Modèle de coût BigQuery pour comprendre pourquoi les coûts du chargement par lot vs. streaming insert importent.

Partitionnement et clustering. La fonction bigquery_adapter() vous permet de configurer les colonnes de partition et les clés de clustering dans le cadre de la définition du pipeline :

from dlt.destinations.adapters import bigquery_adapter


# Appliquer les optimisations spécifiques à BigQuery
bigquery_adapter(
    source.campaigns,
    partition="date",
    cluster=["campaign_id", "ad_group_id"]
)

Pour les données marketing, partitionner par date et clusterer sur les IDs de campagne ou de groupe d’annonces est la configuration standard. Ces optimisations sont de la simple configuration, pas du travail d’ingénierie.

Streaming inserts. Pour les scénarios à faible latence où les données doivent être interrogeables en quelques secondes, dlt supporte les streaming inserts BigQuery. La plupart des pipelines de données marketing n’en ont pas besoin (une granularité horaire ou quotidienne est suffisante), mais c’est disponible pour les cas d’usage de bidding en temps réel ou d’alerting.

Nommage automatique des tables. Les données atterrissent dans des datasets avec des tables nommées d’après les ressources. Le pipeline ci-dessus crée une table marketing.campaigns. Les structures JSON imbriquées produisent des tables enfants comme marketing.campaigns__tags avec des clés référentielles vers le parent.

Résultats en production

Artsy a remplacé un pipeline Ruby vieux de 10 ans par dlt. Les temps de chargement sont passés de 2,5 heures à moins de 30 minutes. Certains pipelines se sont améliorés de 98 %, avec des économies de coûts de 96 % ou plus.

Un utilisateur a rapporté des réductions de coûts ETL de 182x par mois après être passé de Fivetran à dlt, reflétant le passage d’une tarification managée par ligne à une bibliothèque s’exécutant sur l’infrastructure existante.

En septembre 2024, les utilisateurs avaient créé 50 000 connecteurs personnalisés — une multiplication par 20 depuis le début de cette année. Les téléchargements mensuels ont atteint 3 millions. La bibliothèque a franchi le jalón de stabilité 1.0 à la version 1.19. PostHog l’exécute en production.

Le workflow IA + dlt

Le flux de travail pratique ressemble à ceci :

  1. Identifier l’API. Lire la documentation API de la source. Comprendre les endpoints, la méthode d’authentification, le style de pagination et les limites de débit.
  2. Générer avec l’IA. Donner à l’IA la documentation API et la référence REST API de dlt. Lui demander de générer la configuration du pipeline. Pour les APIs bien documentées (Google Ads, Meta, la plupart des plateformes SaaS), l’IA génère une configuration fonctionnelle en quelques minutes.
  3. Ajouter les optimisations BigQuery. Configurer le partitionnement, le clustering et le staging GCS. Ce sont des configurations standard que l’IA gère bien.
  4. Gérer les cas limites manuellement. Les nuances des limites de débit, les bizarreries non documentées des APIs, la logique de transformation spécifique au métier. C’est là où le jugement humain importe le plus.
  5. Tester de manière incrémentale. Exécuter sur une petite tranche de données. Vérifier l’inférence de schéma. Vérifier que le chargement incrémental gère correctement les mises à jour. Promouvoir en production.

La gestion de l’authentification, la gestion des erreurs et les scripts de déploiement deviennent réutilisables entre les pipelines. Chaque connecteur supplémentaire prend moins de temps au fur et à mesure que les patterns s’accumulent.

La note sur l’économie build vs. buy des pipelines de données couvre comment ce workflow change les estimations de coût par connecteur de 50 à 100 heures vers 10 à 20 heures pour les patterns d’API standard, et comment le framework gère la maintenance continue qui consommait auparavant 44 % du temps d’ingénierie.