Cloud Functions comme environnement d'exécution dbt

Cloud Functions est une option de calcul serverless sur GCP qui exécute du code en réponse à une requête HTTP ou un message Pub/Sub. Pour dbt, c’est un point d’entrée vers l’orchestration planifiée plus simple à configurer que Cloud Run Jobs — pas de Docker, pas de registre de conteneurs, pas de pipeline d’artefacts. Vous pointez vers un fichier Python et un requirements.txt, et GCP gère le reste.

Le compromis est moins de contrôle, moins d’efficacité et une reproduction locale plus difficile. Pour les équipes déjà sur GCP qui veulent une exécution dbt planifiée sans conteneurisation, Cloud Functions est un point de départ viable.

Comment cela fonctionne

Une Cloud Function pour dbt est une fonction Python qui utilise subprocess pour invoquer le CLI dbt :

import os
import subprocess
import logging

logging.basicConfig(level=logging.INFO)

def run_dbt(request):
    try:
        os.environ['DBT_PROFILES_DIR'] = '/workspace/dbt_transform'
        dbt_project_dir = '/workspace/dbt_transform'
        os.chdir(dbt_project_dir)

        logging.info(f"Current working directory: {os.getcwd()}")
        logging.info(f"Files in the current directory: {os.listdir('.')}")

        # Install dbt packages
        subprocess.run(['dbt', 'deps'], check=True, capture_output=True, text=True)

        # Run dbt
        result = subprocess.run(
            ['dbt', 'build'],
            capture_output=True,
            text=True
        )
        return result.stdout
    except subprocess.CalledProcessError as e:
        logging.error(f"Command '{e.cmd}' returned non-zero exit status {e.returncode}.")
        logging.error(f"stdout: {e.stdout}")
        logging.error(f"stderr: {e.stderr}")
        return f"Error running dbt: {e.stderr}"
    except Exception as e:
        logging.error(f"Error running dbt: {str(e)}")
        return f"Error running dbt: {str(e)}"

La fonction se déploie avec un requirements.txt qui liste dbt-core et dbt-bigquery comme dépendances. GCP les installe au moment du déploiement. À l’exécution, dbt est invoqué comme sous-processus dans l’environnement d’exécution de la fonction.

La commande de déploiement ressemble à ceci :

gcloud functions deploy dbt_run \
  --region=europe-west1 \
  --service-account=dbt-transform-sa@projectid.iam.gserviceaccount.com \
  --gen2 \
  --runtime=python310 \
  --entry-point=run_dbt \
  --trigger-http \
  --timeout=3500 \
  --memory=1G

L’indicateur --timeout=3500 (juste sous une heure) est le maximum pour les Cloud Functions de 2e génération. Si votre projet dbt prend plus de temps que cela, Cloud Functions n’est pas le bon choix.

Cloud Functions vs. Cloud Run Jobs

La comparaison est importante parce que Cloud Run Jobs est l’approche le plus souvent recommandée. Les deux sont serverless, les deux ne paient que pour le temps d’exécution, et les deux s’intègrent nativement avec Cloud Scheduler et Eventarc. Les différences significatives sont opérationnelles :

Complexité de configuration. Cloud Functions l’emporte ici. Pas de Docker, pas de registre de conteneurs, pas de builds d’images. Téléchargez votre fichier Python et votre requirements.txt, et GCP gère l’exécution. Cloud Run Jobs nécessite de construire et pousser une image de conteneur avant de pouvoir déployer — plus d’étapes, plus d’outillage, plus à déboguer.

Timing d’installation des dépendances. Avec Cloud Functions, dbt-core et dbt-bigquery s’installent au moment du déploiement mais dbt deps (installation des packages dbt) s’exécute au moment de l’exécution. Cela signifie que chaque démarrage à froid installe vos packages dbt avant d’exécuter les modèles. Sur les projets avec de nombreux packages, cela ajoute des minutes à chaque exécution. Cloud Run Jobs intègre les packages dans l’image au moment de la construction — l’exécution démarre immédiatement.

Reproductibilité. requirements.txt épinglé à des versions spécifiques vous donne la plupart du chemin, mais l’environnement d’exécution Cloud Functions est géré par GCP. Une image Cloud Run que vous avez construite mardi dernier est identique à l’image que vous déployez aujourd’hui. Cloud Functions peut avoir de subtiles différences entre les exécutions.

Plafond de timeout. Cloud Functions 2e génération : jusqu’à 60 minutes. Cloud Run Jobs : jusqu’à 168 heures. Pour les projets dbt avec des modèles à longue exécution, le plafond de timeout sur Cloud Functions est une vraie contrainte.

Tests locaux. Vous pouvez invoquer un Cloud Run Job localement avec docker run. Il n’y a pas d’équivalent pour Cloud Functions sans outillage supplémentaire (Functions Framework). Cloud Run Jobs l’emporte pour les workflows de développement local.

Pour la plupart des équipes, Cloud Run Jobs est la meilleure fondation à long terme. Mais si vous avez besoin que dbt s’exécute sur un planning cette semaine et que vous n’avez pas d’infrastructure de conteneurs configurée, Cloud Functions vous y amène plus rapidement.

Authentification

Les deux options utilisent le même mécanisme sous-jacent : un compte de service attaché, la méthode OAuth dans profiles.yml et les Application Default Credentials à l’exécution.

Dans profiles.yml :

dbt_project_name:
  outputs:
    dev:
      type: bigquery
      method: oauth
      project: gcp_project_name
      dataset: dbt
      location: EU
      threads: 4
      job_execution_timeout_seconds: 3500
      job_retries: 1
      priority: interactive
  target: dev

Le method: oauth indique à dbt-bigquery d’utiliser ADC pour les identifiants. Lorsque la fonction s’exécute, l’identité du compte de service attaché est automatiquement disponible via le service de métadonnées de GCP — pas de fichiers de clés, pas de variable GOOGLE_APPLICATION_CREDENTIALS nécessaire en production. Le compte de service a besoin des bonnes permissions BigQuery sur vos projets source et de transformation.

Quand Cloud Functions est pertinent

Cloud Functions est le bon choix quand :

Vous avez besoin d’une planification rapidement, sans apprendre les workflows de conteneurs ou configurer Artifact Registry.
Votre projet dbt est petit — moins de 30-40 modèles, temps d’exécution total bien inférieur à 30 minutes. Le plafond de timeout et la surcharge de démarrage à froid deviennent non pertinents.
Votre équipe est déjà familière avec Cloud Functions dans d’autres cas d’usage. Utiliser un outil familier réduit la surface opérationnelle.
Il s’agit d’une infrastructure temporaire pendant que vous évaluez des options plus robustes. Cloud Functions est facile à démarrer et facile à remplacer.

Ce n’est pas le bon choix quand :

Votre projet dbt prend plus de 45 minutes à s’exécuter (approche du plafond de timeout).
Vous avez besoin de versions exactes de packages épinglées à un artefact immuable.
Vous souhaitez tester votre environnement de production localement avant de déployer.
Vous utilisez déjà Cloud Run pour d’autres workloads (le coût marginal d’ajouter des Jobs est presque nul).

Pour un nouveau projet avec le temps de le configurer, Cloud Run Jobs est la meilleure fondation à long terme. Cloud Functions est une première étape raisonnable lorsqu’une planification est nécessaire immédiatement.