5 techniques essentielles pour maîtriser votre budget data

dbt (data build tool) est devenu un outil indispensable dans le monde de la data. Sa capacité à créer des projets de transformation structurés avec des tests automatisés, une documentation intégrée et une gestion des environnements en fait un allié précieux pour les équipes data. Cependant, cette puissance a un coût : l'utilisation intensive de DBT peut rapidement faire grimper la facture de votre plateforme de stockage, qu'il s'agisse de BigQuery, Redshift ou Snowflake.

Dans cet article, je partage cinq techniques concrètes que j'ai expérimentées chez mes clients pour optimiser leurs coûts BigQuery. Bien que les exemples soient centrés sur BigQuery, ces principes s'appliquent également aux autres data warehouses.

1. Optimiser l'exécution des jobs en développement

L'un des pièges les plus courants en développement est l'utilisation systématique de la commande dbt build. Cette pratique, bien que simple, peut générer des coûts significatifs en réexécutant inutilement l'ensemble des modèles.

Pour optimiser vos développements, voici trois approches progressives :

dbt build --select nom_du_modele : construit uniquement le modèle en cours de développement
dbt build --select nom_du_modele+ : inclut le modèle et tous ses dépendants
dbt build --select nom_du_modele+1 : cible le modèle et son niveau suivant dans le lineage

Cette approche ciblée présente deux avantages majeurs :

Réduction significative des coûts de traitement
Accélération du cycle de développement

À retenir : Chaque exécution a un coût. Limitez-vous aux modèles strictement nécessaires pour votre test ou développement en cours.

2. Maîtriser les modèles incrémentaux

La matérialisation incrémentale est probablement la technique la plus impactante pour réduire les coûts, mais elle requiert une attention particulière dans sa mise en œuvre.

Par défaut, dbt reconstruit entièrement les tables à chaque exécution. La matérialisation incremental permet d'optimiser ce processus en ajoutant uniquement les nouvelles données :

{{ config(materialized='incremental') }}

SELECT
    user_id,
    event_type,
    created_at,
    properties
FROM source_events
WHERE
    {% if is_incremental() %}
        -- Sélectionne uniquement les nouvelles données
        created_at > (SELECT MAX(created_at) FROM {{ this }})
    {% endif %}

Cette approche nécessite une réflexion approfondie sur votre stratégie d'incrémentation. Pour les cas où une reconstruction complète est nécessaire, utilisez l'option --full-refresh.

Important : Les données existantes ne seront pas modifiées. Choisissez judicieusement votre stratégie d'incrémentation.

3. Exploiter l'échantillonnage intelligent

L'utilisation de TABLESAMPLE est une technique sous-estimée mais particulièrement efficace pour réduire les coûts en phase de développement. Contrairement aux approches classiques (WHERE ou LIMIT), elle permet un véritable échantillonnage statistique :

{{ config(materialized='table') }}

WITH sample_data AS (
   SELECT
        user_id,
        event_type,
        created_at,
        properties
   FROM {{ source('analytics', 'events') }}
   TABLESAMPLE SYSTEM (30 percent)
)

SELECT * FROM sample_data

Pour une utilisation optimale, implémentez une logique conditionnelle selon l'environnement :

WITH source_data AS (
    SELECT *
    FROM {% if target.name == 'prod' %}
        {{ source('analytics', 'events') }}
    {% else %}
        {{ ref('sample_events') }}
    {% endif %}
)

À retenir : L'échantillonnage réduit significativement les coûts en phase de développement tout en maintenant la représentativité des données.

4. Optimiser par le partitionnement

Le partitionnement est un levier puissant de réduction des coûts, particulièrement efficace pour les tables volumineuses avec des filtres temporels fréquents :

{{
  config(
    materialized='table',
    partition_by={
      "field": "created_at",
      "data_type": "timestamp",
      "granularity": "day"
    },
    cluster_by=["event_type", "user_id"]
  )
}}

SELECT
    user_id,
    event_type,
    created_at,
    properties
FROM {{ ref('events_processed') }}

Bon à savoir : Le partitionnement permet à BigQuery de scanner uniquement les partitions pertinentes pour votre requête, réduisant drastiquement les coûts.

5. Monitorer vos coûts

Un monitoring efficace est la clé pour identifier et corriger les sources de surcoût. La table INFORMATION_SCHEMA.JOBS offre une mine d'informations précieuses :

SELECT
    creation_time,
    user_email,
    job_type,
    total_bytes_processed,
    total_bytes_billed,
    cache_hit,
    ARRAY(
        SELECT
            project_id || '.' || dataset_id || '.' || table_id
        FROM
            UNNEST(referenced_tables)
    ) AS referenced_tables,
    error_result
FROM `region-eu`.INFORMATION_SCHEMA.JOBS
WHERE
    creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
ORDER BY
    total_bytes_billed DESC

Ces données permettent d'identifier précisément les requêtes coûteuses et d'optimiser les modèles concernés.

Conclusion

La maîtrise des coûts BigQuery avec dbt nécessite une approche multidimensionnelle. Les techniques présentées ici peuvent réduire significativement votre facture tout en maintenant la performance de vos pipelines data. L'essentiel est d'adopter ces pratiques dès le début du projet et de les maintenir rigoureusement.

Pour aller plus loin dans l'optimisation de vos coûts data ou discuter de vos problématiques spécifiques, n'hésitez pas à me contacter. Je propose également des audits personnalisés pour identifier les opportunités d'optimisation dans votre infrastructure.

Comment réduire les coûts BigQuery engendrés par DBT ?