Compromis de la stratégie microbatch dbt

Le microbatch (dbt 1.9+) est une stratégie incrémentale avec backfill intégré, nouvelle tentative au niveau du batch, et une configuration déclarative basée sur le temps plutôt que le boilerplate is_incremental(). Il présente trois limitations qui déterminent s’il convient à un modèle donné.

Comment Fonctionne le Microbatch

Au lieu d’écrire une logique conditionnelle is_incremental(), vous configurez le batching temporel de façon déclarative :

{{ config(
    materialized='incremental',
    incremental_strategy='microbatch',
    event_time='session_start',
    begin='2020-01-01',
    batch_size='day',
    lookback=3
) }}

-- Aucun bloc is_incremental() nécessaire
SELECT
    session_id,
    session_start,
    user_id,
    session_duration
FROM {{ ref('base__analytics__sessions') }}

dbt génère des requêtes séparées pour chaque période de batch (heure, jour ou mois). Lors d’une exécution incrémentale normale, il ne traite que les derniers batches non traités plus la fenêtre lookback. Pour les backfills, vous spécifiez des plages temporelles explicites :

# Backfill ciblé
dbt run --event-time-start "2024-09-01" --event-time-end "2024-09-04"

# Relancer uniquement les batches échoués du dernier run
dbt retry

La nouvelle tentative au niveau du batch est particulièrement précieuse : si un backfill de 30 jours échoue au jour 17, vous ne relancez que le jour 17 plutôt que les 30 jours.

Compromis 1 : Hypothèse de Fuseau Horaire UTC

Le microbatch utilise UTC pour tous les calculs temporels. Les limites de batch tombent toujours à minuit UTC (pour les batches quotidiens) ou au début de l’heure (pour les batches horaires). Il n’y a aucune configuration pour modifier cela.

Si votre colonne event_time est stockée dans un fuseau horaire local — disons US/Eastern — les enregistrements proches de minuit heure locale se retrouveront dans des batches inattendus. Un événement à 23h30 Eastern le 15 mars correspond à 4h30 UTC le 16 mars, il sera donc dans le batch du 16 mars, pas du 15.

Pour la plupart des charges analytiques, cela n’a pas d’importance. Les agrégations qui remontent au niveau mensuel ou hebdomadaire absorbent le décalage de frontière. Mais si votre logique métier dépend d’enregistrements se retrouvant dans le bon batch par date locale — par exemple, un reporting de revenu quotidien où vous clôturez les livres à minuit heure locale — l’hypothèse UTC crée des erreurs de décalage d’un jour.

La solution : Convertissez votre colonne event_time en UTC avant d’utiliser le microbatch. Si vos données sources sont dans un fuseau horaire local :

SELECT
    session_id,
    CONVERT_TIMEZONE('US/Eastern', 'UTC', session_start) AS session_start_utc,
    user_id,
    session_duration
FROM {{ ref('base__analytics__sessions') }}

Puis configurez event_time='session_start_utc'. Cela garantit que les limites de batch s’alignent avec les horodatages UTC réels, et le reporting downstream peut reconvertir vers l’heure locale selon les besoins.

Si la conversion n’est pas faisable, acceptez que les limites de batch ne s’aligneront pas avec votre journée de travail et concevez la logique downstream en conséquence.

Compromis 2 : Pas de Granularité Sub-Horaire

La plus petite batch_size est hour. Si vous devez traiter des données par fenêtres de 15 ou 5 minutes — courant pour les dashboards temps réel, les systèmes d’alertes, ou le reporting quasi-temps-réel — le microbatch ne fonctionnera pas.

Cette limitation est architecturale. Le microbatch génère une requête SQL par batch, et chaque requête a une surcharge : compilation, planification dans l’entrepôt, exécution de la requête, fusion des résultats. À une granularité sub-horaire, cette surcharge par requête domine le temps d’exécution total. Un backfill de 24 heures à une granularité de 5 minutes représenterait 288 requêtes séparées.

Quand cela pose problème : Les systèmes qui nécessitent une fraîcheur des données inférieure à 1 heure. Les charges de travail proches du streaming. Les modèles qui alimentent des dashboards opérationnels avec des SLA de latence.

L’alternative : Utilisez la logique incrémentale traditionnelle avec un filtre temporel manuel. Vous perdez les capacités de backfill et de nouvelle tentative intégrées du microbatch, mais vous pouvez filtrer à n’importe quelle granularité requise par votre cas d’usage :

{% if is_incremental() %}
WHERE event_timestamp >= (
    SELECT DATEADD(MINUTE, -15, MAX(event_timestamp))
    FROM {{ this }}
)
{% endif %}

Compromis 3 : Exécution Séquentielle

Chaque batch s’exécute l’un après l’autre, pas en parallèle. Un backfill de 30 jours avec batch_size='day' signifie 30 exécutions de requêtes séquentielles.

Une seule requête traitant les 30 jours d’un coup est presque toujours plus rapide que 30 requêtes séparées. Chaque requête a une surcharge fixe : compilation Jinja, planification de requête, planification dans l’entrepôt. Multipliez par 30 et la surcharge s’accumule. En pratique, une exécution incrémentale traditionnelle de 30 jours pourrait prendre 5 minutes, tandis que la même plage en microbatch prend 15-20 minutes.

Le compromis est explicite : le microbatch échange la vitesse contre l’isolation des échecs. Si le jour 17 d’une exécution incrémentale traditionnelle de 30 jours échoue, vous retraitez les 30 jours. Avec le microbatch, vous ne relancez que le jour 17. Pour les charges de travail où l’échec est courant (systèmes sources défaillants, requêtes sujettes aux timeouts) ou où le retraitement est coûteux (très grands volumes quotidiens), le bénéfice des nouvelles tentatives peut compenser le coût en vitesse.

Quand l’exécution séquentielle pose le plus de problèmes :

• Les grands backfills historiques (mois ou années de données)
• Les modèles avec de faibles volumes par batch où la surcharge par requête domine
• Les scénarios de backfill urgents où vous avez besoin des données rapidement

Quand c’est acceptable :

• Les exécutions incrémentales quotidiennes ou horaires ne traitant que le dernier batch
• Les charges de travail avec des échecs occasionnels où la nouvelle tentative au niveau du batch économise un retraitement significatif
• Les équipes qui valorisent la simplicité opérationnelle plutôt que la vitesse brute

Comment le Microbatch Délègue aux Stratégies d’Entrepôt

Sous le capot, le microbatch n’implémente pas sa propre logique de merge. Il délègue aux stratégies existantes par entrepôt :

• BigQuery : Utilise insert_overwrite (nécessite partition_by correspondant à votre batch_size)
• Snowflake : Utilise delete+insert
• Databricks : Utilise replace_where

Cela signifie que le microbatch hérite des propriétés de la stratégie sous-jacente. Sur BigQuery, il est atomique et basé sur les partitions. Sur Snowflake, il a les mêmes mises en garde d’atomicité que delete+insert. Connaître la stratégie sous-jacente vous aide à comprendre les modes d’échec et les caractéristiques de performance sans lire la documentation spécifique au microbatch.

Comparaison avec l’Incrémental Traditionnel

Quand le Microbatch Est le Bon Choix

Le microbatch convient le mieux quand :

1. Vos données ont une colonne d’horodatage claire et se traitent dans des fenêtres temporelles naturelles
2. Vous voulez un backfill intégré sans écrire de scripts personnalisés ni de SQL ponctuel
3. La nouvelle tentative au niveau du batch économiserait un temps de retraitement significatif lors des échecs
4. Vous préférez la configuration déclarative à l’écriture de la logique is_incremental()
5. Une granularité horaire ou quotidienne est suffisante pour votre cas d’usage

Il ne convient pas quand vous avez besoin d’un traitement sub-horaire, quand la vitesse de backfill est critique, ou quand vos données n’ont pas de colonne d’horodatage claire pour le partitionnement.

Pour une vue plus large de la façon dont le microbatch se compare aux autres stratégies, consultez le cadre de décision des stratégies. Pour les détails d’implémentation et les commandes de backfill, consultez le guide de la stratégie microbatch.