BigQuery calculer la durée avec une ligne précédente timestamp
Calculez instantanément l’écart entre un timestamp courant et la ligne précédente, obtenez les conversions en secondes, minutes, heures et jours, puis générez un exemple SQL BigQuery avec LAG() et TIMESTAMP_DIFF().
Calculateur interactif
Résultats
Renseignez vos timestamps puis cliquez sur Calculer la durée.
Guide expert: bigquery calculer la duree avec une ligne precedente timestamp
Dans BigQuery, calculer une durée avec la ligne précédente fait partie des besoins les plus fréquents en analytique: suivi de sessions, temps entre deux clics, latence entre deux états d’un workflow, délai entre commandes successives, durée de traitement de tickets, ou encore temps entre deux événements IoT. La logique générale consiste à récupérer la valeur du timestamp de la ligne précédente avec une fonction de fenêtre, puis à comparer ce timestamp antérieur avec le timestamp courant. En pratique, la combinaison la plus robuste est LAG() pour accéder à la ligne précédente et TIMESTAMP_DIFF() pour obtenir l’écart dans l’unité désirée.
Le vrai défi ne réside pas seulement dans la syntaxe. Il faut aussi définir l’ordre exact des lignes, choisir la bonne clé de partition, comprendre la granularité de l’unité de temps, gérer les valeurs nulles et éviter les résultats incohérents lorsque plusieurs événements portent le même timestamp. Cette page a été conçue pour répondre à ce problème de façon à la fois pédagogique et opérationnelle. Le calculateur vous donne un résultat immédiat, tandis que le guide ci-dessous détaille les bonnes pratiques SQL à appliquer en production.
Principe de base: LAG plus TIMESTAMP_DIFF
La structure standard en BigQuery ressemble à ceci: vous partitionnez vos données par entité logique, par exemple un utilisateur, une machine, un ticket ou une session. Ensuite, vous ordonnez les événements selon leur timestamp, et vous utilisez LAG(timestamp_col) pour récupérer l’horodatage précédent dans cette partition. Enfin, vous calculez la différence avec TIMESTAMP_DIFF(timestamp_courant, timestamp_precedent, MINUTE) ou une autre unité.
Exemple conceptuel
- Choisir l’entité à suivre, par exemple user_id.
- Ordonner les événements par event_ts.
- Récupérer le timestamp précédent avec LAG(event_ts).
- Calculer l’écart avec TIMESTAMP_DIFF(event_ts, previous_event_ts, SECOND).
- Éliminer ou traiter explicitement la première ligne de chaque partition, car elle n’a pas de précédente valeur.
Cette approche est idéale pour mesurer les intervalles inter-événements. Dans le cas d’un parcours utilisateur, on obtient le temps entre deux actions successives. Dans un contexte industriel, on mesure le délai entre deux télémétries. Dans une base de logs applicatifs, on reconstitue les temps d’attente entre statuts.
Pourquoi l’ordre et la partition sont critiques
Deux erreurs reviennent constamment. La première consiste à oublier le PARTITION BY. Sans partition, BigQuery compare toutes les lignes de la table entre elles comme s’il s’agissait d’une seule séquence globale. Le résultat peut sembler valide à petite échelle, mais il devient faux dès que plusieurs utilisateurs, appareils ou dossiers se mélangent. La seconde erreur est un ORDER BY incomplet. Si plusieurs lignes partagent le même timestamp, l’ordre n’est pas déterministe, et votre durée avec la ligne précédente peut varier d’une exécution à l’autre.
La bonne pratique est donc de partitionner par l’entité d’analyse et de compléter l’ordre avec une clé secondaire stable, par exemple event_ts, event_id. Cela garantit un enchaînement reproductible. C’est essentiel dans les tableaux de bord, les audits et les modèles de machine learning qui dépendent d’une séquence temporelle fiable.
| Unité | Équivalence réelle | Usage analytique typique | Quand l’utiliser |
|---|---|---|---|
| SECOND | 1 minute = 60 secondes | Logs, APIs, événements applicatifs | Quand vous avez besoin d’une granularité fine |
| MINUTE | 1 heure = 60 minutes | Sessions web, support, marketing | Quand les écarts sont de quelques minutes à quelques heures |
| HOUR | 1 jour = 24 heures | Processus métier, monitoring lot | Quand les événements sont espacés sur plusieurs heures |
| DAY | 1 jour = 86400 secondes | Rétention, cycle de commande, délais SAV | Quand l’analyse porte sur des périodes longues |
Requête SQL type pour calculer la durée avec la ligne précédente
Voici la logique SQL de référence. D’abord, on fabrique le timestamp précédent dans une sous-requête ou un CTE. Ensuite, on calcule la différence dans l’unité voulue. Cette méthode rend la requête plus lisible et facilite les tests.
Patron recommandé
Dans sa forme la plus simple, le schéma est le suivant: une première étape pour calculer previous_ts, puis une seconde pour calculer duration_minutes. Cette séparation a un avantage majeur: elle rend le plan d’exécution plus simple à relire et évite les répétitions inutiles dans le SQL. Vous pouvez aussi enrichir cette logique avec QUALIFY pour garder seulement certaines lignes, ou avec une condition sur la durée pour détecter des anomalies.
- Utilisez LAG(event_ts) OVER (PARTITION BY user_id ORDER BY event_ts, event_id) pour la ligne précédente.
- Utilisez TIMESTAMP_DIFF(event_ts, previous_ts, MINUTE) pour calculer l’écart.
- Ajoutez WHERE previous_ts IS NOT NULL ou QUALIFY si vous voulez exclure la première ligne.
- Conservez aussi la valeur brute en secondes si vous devez recalculer plusieurs vues.
La granularité mérite une attention particulière. TIMESTAMP_DIFF retourne un entier dans l’unité choisie. Par exemple, un écart de 89 minutes restera 89 en minute, mais il deviendra 1 en heure. Si vous avez besoin d’une représentation décimale plus précise, vous pouvez calculer la différence en secondes, puis la diviser par 60 ou 3600 dans une expression numérique. C’est précisément ce que fait le calculateur de cette page pour afficher des résultats exploitables immédiatement.
Gestion des nulls, doublons et cas limites
Le premier enregistrement de chaque partition n’a par définition aucune ligne précédente. BigQuery renverra donc NULL avec LAG(), ce qui est normal. Il faut ensuite décider si vous souhaitez supprimer ces lignes, leur affecter une valeur par défaut, ou les garder pour matérialiser explicitement le début d’une séquence. Dans les rapports, il est généralement préférable de les filtrer. Dans les pipelines de contrôle qualité, il peut être utile de les conserver.
Autre point essentiel: les timestamps identiques. Si deux événements ont exactement le même horodatage, l’ordre relatif doit être fixé avec une seconde colonne. Sans cela, deux exécutions peuvent produire des durées différentes. Enfin, attention aux événements désordonnés ou en retard d’ingestion. Si vous ordonnez par timestamp métier, vous analysez la chronologie fonctionnelle. Si vous ordonnez par timestamp d’ingestion, vous analysez la chronologie d’arrivée des données. Ce sont deux besoins distincts.
| Point de contrôle | Statistique ou fait réel | Impact sur le calcul | Bonne pratique |
|---|---|---|---|
| Première ligne d’une partition | 1 ligne sur n par partition aura toujours un précédent NULL | La durée ne peut pas être calculée | Filtrer avec previous_ts IS NOT NULL |
| Ordre des événements | Un tri incomplet peut rendre le résultat non déterministe | Durées potentiellement incohérentes | Ajouter une clé stable comme event_id |
| Precision temporelle | Le temps standard utilise 24 heures par jour, 60 minutes par heure, 60 secondes par minute | Les conversions doivent rester cohérentes | Stocker ou recalculer à partir des secondes |
| Volume analytique | Les fonctions de fenêtre évitent souvent des auto-jointures coûteuses | Requêtes plus lisibles et souvent plus efficaces | Privilégier LAG() plutôt qu’un self join |
Fenêtres analytiques versus auto-jointure
Il est techniquement possible de calculer la ligne précédente avec une auto-jointure, mais cette méthode est plus lourde à écrire, plus délicate à maintenir et souvent moins performante conceptuellement qu’une fonction de fenêtre. Avec LAG(), le moteur sait immédiatement que vous demandez la valeur précédente dans une séquence ordonnée. La requête gagne en clarté et le risque d’erreur logique diminue. Dans une équipe data, la lisibilité est un gain de productivité très concret: le code se relit mieux, se teste mieux et se transmet mieux.
Quand utiliser TIMESTAMP, DATETIME ou DATE
Si votre donnée contient un instant absolu, incluant implicitement la notion de fuseau au moment de l’interprétation, TIMESTAMP est généralement le meilleur choix. Si votre besoin est un horaire local sans fuseau, DATETIME peut être plus adapté. Pour un simple jour calendaire, utilisez DATE. La plupart des problèmes autour du calcul de durée avec la ligne précédente apparaissent lorsque ces types sont mélangés sans conversion explicite. La règle d’or est simple: harmonisez vos types avant le calcul.
Cas d’usage métier
1. Analyse de session web
Vous pouvez mesurer le temps entre deux pages consultées par un même utilisateur. Avec un partitionnement par user_id et un ordre par event_ts, la différence entre deux lignes successives représente le temps écoulé entre deux actions. En ajoutant une règle de coupure, par exemple 30 minutes, vous pouvez reconstruire des sessions.
2. Parcours logistique
Dans une chaîne logistique, chaque statut d’un colis dispose d’un timestamp. La durée entre la ligne précédente et la ligne courante permet d’identifier les étapes qui prennent trop de temps: préparation, expédition, transit, remise. C’est une base solide pour le pilotage opérationnel.
3. Monitoring de pipeline de données
Sur des logs techniques, calculer le temps entre événements permet de détecter des latences anormales, des trous de collecte ou des ralentissements périodiques. C’est souvent plus informatif qu’une simple moyenne, car l’analyse séquentielle révèle la dynamique réelle du système.
Optimisation et bonnes pratiques de production
- Partitionnez physiquement vos tables quand c’est pertinent pour réduire les volumes scannés.
- Clusterisez sur les colonnes fréquemment utilisées dans les filtres et l’ordre analytique.
- Évitez les conversions répétées dans les requêtes critiques. Normalisez vos timestamps en amont si possible.
- Calculez une durée brute en secondes si plusieurs équipes ont besoin de vues différentes.
- Ajoutez des tests de qualité pour détecter les durées négatives, souvent signe de données mal ordonnées.
Une astuce souvent négligée consiste à conserver à la fois la durée entière native de TIMESTAMP_DIFF et une version décimale dérivée des secondes. La première est parfaite pour l’agrégation rapide, la seconde pour l’affichage métier. Cette double représentation évite de réécrire la logique dans chaque dashboard ou notebook.
Sources externes fiables sur le temps, les données et l’analytique
Pour approfondir les questions liées au temps, à la mesure et à l’analyse de données, vous pouvez consulter des sources reconnues comme le NIST Time and Frequency Division, le portail public Data.gov pour des jeux de données temporels, ainsi que le centre de recherche CMU Database Group pour les fondements des systèmes analytiques et des traitements SQL à grande échelle.
Résumé opérationnel
Pour bigquery calculer la duree avec une ligne precedente timestamp, retenez le schéma suivant: identifiez votre entité, ordonnez proprement vos événements, récupérez le timestamp précédent avec LAG(), puis calculez l’écart avec TIMESTAMP_DIFF(). Si vous avez besoin d’une précision décimale, calculez d’abord en secondes. Filtrez les premières lignes sans précédent, sécurisez l’ordre avec une clé secondaire, et vérifiez les cas de données en retard ou dupliquées. Avec ces principes, vous obtenez un calcul fiable, maintenable et immédiatement exploitable dans BigQuery.