Mesurer la latence des données avant de choisir une stratégie incrémentale

La question centrale pour tout modèle incrémental gérant des données en retard est : avec quel retard vos données arrivent-elles réellement ? La réponse dépend du système source. Les événements GA4 peuvent arriver des jours après qu’ils se sont produits. Les conversions des plateformes publicitaires sont rétroactivement mises à jour pendant 28 jours. Les pipelines CDC rejouent les enregistrements après des pannes en rafales imprévisibles. Les fenêtres de lookback doivent être dimensionnées d’après les distributions d’arrivée mesurées, pas sur l’intuition.

Deux horodatages, un écart

Deux horodatages définissent si un enregistrement est « en retard » :

• Heure d’événement : quand quelque chose s’est réellement produit (un achat, une page vue, un clic)
• Heure de chargement : quand cet enregistrement a atterri dans votre entrepôt (souvent suivi comme _loaded_at ou _ingested_at)

Un enregistrement est en retard quand son heure d’événement est antérieure à l’heure d’événement maximale déjà traitée par votre modèle incrémental. L’écart entre l’heure d’événement et l’heure de chargement — appelons-le latence d’arrivée — est ce que vous mesurez.

La requête de profil de latence

Exécutez ceci contre vos tables sources avant de construire tout modèle incrémental qui traitera ces données :

SELECT
  DATE_DIFF(DATE(_loaded_at), DATE(event_timestamp), DAY) AS days_late,
  COUNT(*) AS record_count,
  ROUND(COUNT(*) * 100.0 / SUM(COUNT(*)) OVER(), 2) AS pct_of_total
FROM source_table
WHERE _loaded_at > event_timestamp  -- Uniquement les enregistrements en retard
GROUP BY 1
ORDER BY 1

Cela vous donne une distribution : parmi tous les enregistrements arrivés après leur horodatage d’événement, quel pourcentage est arrivé 1 jour en retard, 2 jours en retard, 3 jours en retard, etc.

Une sortie typique pourrait ressembler à ceci :

Lecture de ce tableau : 71 % des enregistrements en retard arrivent dans le jour, 94 % dans les 3 jours, 97 % dans les 4 jours. Cette queue s’étendant jusqu’à 28+ jours représente 0,2 % des enregistrements en retard.

Ce que la distribution vous indique

La distribution répond à trois questions :

Quelle fenêtre couvre la majorité de mes données ? Additionnez le pourcentage cumulatif. Dans l’exemple ci-dessus, 3 jours couvre 94,3 % des arrivées tardives. 7 jours couvre 97,8 %. Le coût incrémental d’étendre de 3 à 7 jours est une couverture supplémentaire de 3,5 %.

Y a-t-il une longue queue significative ? Si 5 % des enregistrements arrivent après 14 jours, une fenêtre de 3 jours rate silencieusement beaucoup de données. Si 0,2 % arrivent après 28 jours (comme ci-dessus), une fenêtre de 7 jours est probablement suffisante avec des rafraîchissements complets périodiques pour attraper le reste.

Quelles sources nécessitent une gestion particulière ? Certains systèmes ont des latences bien comportées et prévisibles. D’autres ont des patterns en pics — principalement le jour même, avec des retards occasionnels de plusieurs semaines dus à des pannes ou des backfills. Ceux-là nécessitent des stratégies différentes.

Dimensionner la fenêtre d’après la distribution

Une fois que vous avez la distribution, adaptez la fenêtre à votre tolérance aux données manquées :

-- Version plus complète : incluez les enregistrements du jour même pour voir l'image globale
SELECT
  DATE_DIFF(DATE(_loaded_at), DATE(event_timestamp), DAY) AS days_late,
  COUNT(*) AS record_count,
  ROUND(
    SUM(COUNT(*)) OVER (ORDER BY DATE_DIFF(DATE(_loaded_at), DATE(event_timestamp), DAY)
                        ROWS UNBOUNDED PRECEDING) * 100.0 / SUM(COUNT(*)) OVER(),
    1
  ) AS cumulative_pct
FROM source_table
GROUP BY 1
ORDER BY 1
LIMIT 30

La colonne cumulative_pct vous indique directement quel pourcentage de tous les enregistrements une fenêtre donnée capturerait. Trouvez la taille de fenêtre où la couverture cumulative atteint votre seuil — typiquement 99 % ou 99,5 % — et utilisez-la comme point de départ.

Tenez ensuite compte du coût. Sur BigQuery avec la tarification à la demande, un lookback de 3 jours traite 3 fois plus de données source par exécution qu’un lookback d’1 jour. Sur une table qui traite 100 Go par jour, c’est la différence entre 100 Go et 300 Go scannés par exécution — environ 0,50 $ contre 1,50 $ au tarif standard. À grande échelle ou haute fréquence, cela s’accumule.

Segmenter par système source

Toutes les données d’un pipeline n’ont pas le même profil de latence. Segmentez votre analyse par source quand vous avez plusieurs flux :

SELECT
  source_system,
  DATE_DIFF(DATE(_loaded_at), DATE(event_timestamp), DAY) AS days_late,
  COUNT(*) AS record_count,
  ROUND(COUNT(*) * 100.0 / SUM(COUNT(*)) OVER(PARTITION BY source_system), 2) AS pct_of_source
FROM events_with_metadata
WHERE _loaded_at > event_timestamp
GROUP BY 1, 2
ORDER BY 1, 2

Un modèle d’événements unifié peut combiner GA4 (principalement le jour même) avec des conversions de plateformes publicitaires (latence courante de 3 à 7 jours) et un enrichissement tiers (peut atteindre 14+ jours). Une seule fenêtre de lookback doit couvrir le pire cas, ce qui peut être inutilement coûteux pour les sources mieux comportées.

Si les sources ont des profils de latence radicalement différents, envisagez des modèles séparés avec des configurations de fenêtres différentes plutôt que de forcer une seule fenêtre à couvrir tous les cas.

Réexécuter l’analyse

Les profils de latence des données changent. Le pipeline ETL d’un système source ralentit, ou un nouvel endpoint API a un comportement d’actualisation différent. Exécutez cette analyse :

• Avant de construire tout nouveau modèle incrémental sur une source avec laquelle vous n’avez pas travaillé
• Trimestriellement sur les modèles existants, surtout si vous commencez à voir des divergences par rapport aux rafraîchissements complets
• Après tout incident connu du système source qui pourrait avoir changé la façon dont les données arrivent

La fenêtre de lookback choisie d’après le profil de latence de l’année dernière peut ne plus correspondre aux données de cette année. La requête de distribution est rapide — c’est une agrégation group-by sur votre table source — donc il n’y a aucune raison de ne pas vérifier.

Relier l’analyse à la stratégie

Le profil de latence ne fait pas que dimensionner votre fenêtre de lookback. Il aide également à choisir la bonne stratégie incrémentale :

• Latence étroite et prévisible (95 %+ dans les 1 à 2 jours) : merge standard ou insert_overwrite avec une fenêtre de 3 jours. Économique et couvre la grande majorité des arrivées.
• Latence modérée avec une longue queue (queue s’étendant 7 à 14 jours) : envisagez si le merge avec des prédicats incrémentiels est plus approprié qu’une large fenêtre insert_overwrite. Ou acceptez que des rafraîchissements complets périodiques gèrent la queue.
• Latence sévère ou imprévisible (semaines, depuis des flux tiers ou des pannes) : la longue queue peut être trop coûteuse à attraper avec une fenêtre large. Concevez-la explicitement : rafraîchissements complets planifiés, ou alerte quand des enregistrements arrivent en dehors de la fenêtre.

Le schéma de modèle incrémental est une optimisation qui échange une certaine cohérence contre un coût plus bas et des temps d’exécution plus rapides. Mesurer votre profil de latence réel est ce qui rend ce compromis conscient plutôt qu’accidentel.