🔍 Contexte général
Tu as un data warehouse partagé (par exemple Snowflake ou BigQuery) et plusieurs équipes (produit, finance, marketing) y font tourner des modèles dbt.
Certaines transformations (modèles dbt) sont très lourdes (jointures de millions de lignes, agrégations complexes), d’autres sont légères (filtres simples, chargement de petites tables).
Si tout le monde exécute ses pipelines en même temps, les ressources du warehouse peuvent être saturées → ralentissements, échecs, coûts élevés.
🧩 Solution proposée : tags + fenêtres d’exécution
1. 📌 Taguer les modèles selon leur intensité
Tu ajoutes des tags dans tes modèles dbt pour identifier leur coût en ressources :
-- models/agg_user_metrics.sql
{{ config(materialized='table', tags=['resource_heavy']) }}
SELECT ...-- models/load_countries.sql
{{ config(materialized='view', tags=['resource_light']) }}
SELECT ...2. ⏰ Définir des fenêtres d’exécution selon les tags
Tu définis un planning pour exécuter chaque catégorie de modèles à un moment précis :
| Tag | Créneau horaire autorisé | Raisons |
|---|---|---|
resource_light | 5h à 7h (début de journée) | Pas coûteux, ne bloque pas les autres |
resource_heavy | 2h à 4h du matin | Période creuse, disponibilité maximale des ressources |
marketing | 8h à 10h | Pour que les dashboards soient prêts à 10h |
3. ⚙️ Orchestration avec dbt Cloud ou Airflow
➤ En dbt Cloud, tu crées plusieurs jobs :
job: Run heavy models
schedule: Tous les jours à 2h00
command: dbt run --select tag:resource_heavyjob: Run light models
schedule: Tous les jours à 5h00
command: dbt run --select tag:resource_light➤ En Airflow :
BashOperator(
task_id='run_heavy_jobs',
bash_command='dbt run --select tag:resource_heavy',
execution_timeout=timedelta(hours=2),
start_date=2AM
)✅ Avantages concrets
| Problème évité | Grâce à… |
|---|---|
| Contention de ressources (CPU, slots) | Planification séparée des jobs gourmands |
| Coût imprévu dans Snowflake/BigQuery | Usage plus maîtrisé pendant heures creuses |
| Ralentissement des dashboards métiers | Jobs marketing exécutés en avance ciblée |
| Blocage entre équipes | Coordination par tag et par fenêtre horaire |
🎯 Exemple dans une entreprise
Imagine que tu bosses chez “DataCorp” avec 3 équipes :
- Produit : agrégation des événements utilisateurs (lourds)
- Finance : calcul des KPI financiers journaliers (modéré)
- Marketing : mise à jour des campagnes (léger)
Tu peux organiser tes exécutions comme suit :
| Heure | Action |
|---|---|
| 02h00 | dbt run --select tag:resource_heavy |
| 04h30 | dbt run --select tag:finance |
| 06h30 | dbt run --select tag:marketing |
💡 Exemple 2 d’utilisation :
Tu as 3 modèles dbt :
version: 2
models:
- name: agg_user_metrics
tags: ["heavy"]
- name: product_snapshot
tags: ["light"]
- name: enrich_sales
tags: ["heavy"]Et dans ta pipeline, tu peux orchestrer comme ceci :
# Dans un cron / Airflow / dbt Cloud
# À 1h du matin :
dbt run --select tag:heavy
# À 6h du matin :
dbt run --select tag:light🔚 Résumé
La stratégie tags + execution windows dans dbt te permet de :
- maîtriser le moment où chaque modèle s’exécute
- éviter les conflits de ressources
- respecter les priorités métiers
- partager efficacement un data warehouse