BigQuery calculer le temps entre 2 lignes
Calculez instantanément l’écart entre deux lignes horodatées, visualisez le résultat dans plusieurs unités, et récupérez un exemple SQL BigQuery prêt à l’emploi avec TIMESTAMP_DIFF, DATETIME_DIFF, LAG et LEAD.
Calculateur interactif BigQuery
Guide expert: comment calculer le temps entre 2 lignes dans BigQuery
Lorsqu’on travaille dans Google BigQuery, une question revient sans cesse dans les projets d’analytics, d’observabilité, de log processing ou de parcours utilisateur: comment calculer précisément le temps entre 2 lignes ? En pratique, cela signifie souvent mesurer le délai entre deux événements successifs, deux statuts, deux transactions ou deux clics. Le besoin est simple à exprimer, mais il existe plusieurs façons correctes de le faire selon le type de données, la granularité souhaitée et la logique métier. Dans ce guide, vous allez voir les fonctions à privilégier, les erreurs les plus fréquentes, les différences entre TIMESTAMP, DATETIME et DATE, ainsi que les bonnes pratiques SQL pour produire un calcul fiable, performant et facile à maintenir.
Pourquoi ce calcul est si important dans l’analyse de données
Le temps entre deux lignes est un indicateur clé dans de nombreux contextes. Dans l’e-commerce, il permet de mesurer le délai entre une visite et un achat. Dans les systèmes industriels, il sert à calculer le temps entre deux capteurs ou deux changements d’état. Dans les produits SaaS, il aide à comprendre le temps séparant l’inscription, la première action et la conversion. Dans la cybersécurité, il sert à détecter des séquences anormales d’événements trop rapprochées ou au contraire trop espacées.
BigQuery est particulièrement adapté à ce type d’analyse parce qu’il gère nativement les types temporels et les fonctions analytiques. Vous pouvez donc calculer un écart entre deux lignes de manière unitaire avec TIMESTAMP_DIFF, ou de manière séquentielle grâce aux fonctions de fenêtre comme LAG et LEAD. Le bon choix dépend de votre structure de table et de la question métier.
Comprendre les types temporels avant de calculer
Avant même d’écrire votre requête, il faut identifier le type de colonne utilisé. Beaucoup d’erreurs viennent d’un mélange involontaire entre plusieurs représentations du temps. Dans BigQuery, trois types sont particulièrement importants:
- DATE pour une date pure, sans heure.
- DATETIME pour une date et une heure, sans fuseau horaire.
- TIMESTAMP pour un instant absolu stocké en UTC, avec précision à la microseconde.
Si votre question concerne un instant exact partagé entre plusieurs régions, TIMESTAMP est généralement le meilleur choix. Si vous manipulez des horaires métier locaux sans notion de fuseau, DATETIME peut être plus lisible. Enfin, si vous ne comparez que des jours, utilisez DATE_DIFF sur des colonnes DATE.
| Type BigQuery | Contenu | Fuseau horaire | Usage recommandé | Donnée réelle utile |
|---|---|---|---|---|
| DATE | Jour uniquement | Non | Retards, échéances, reporting journalier | Plage standard: 0001-01-01 à 9999-12-31 |
| DATETIME | Date + heure locale | Non | Agenda local, planning, horaires métier | Précision jusqu’à la fraction de seconde |
| TIMESTAMP | Instant absolu | Oui, UTC | Logs, événements, IoT, analytics multi-pays | Précision native à la microseconde |
La méthode la plus simple: TIMESTAMP_DIFF entre deux lignes identifiées
Si vous avez déjà les deux lignes que vous souhaitez comparer, la méthode la plus directe consiste à utiliser TIMESTAMP_DIFF. Le principe est simple: on soustrait un deuxième TIMESTAMP à un premier et on demande le résultat dans une unité précise, par exemple SECOND, MINUTE, HOUR ou DAY.
Exemple conceptuel:
- Vous récupérez la ligne A.
- Vous récupérez la ligne B.
- Vous appliquez TIMESTAMP_DIFF(ts_b, ts_a, MINUTE).
Le résultat est positif si B est après A, négatif si B est avant A. Cette logique est importante, car l’ordre des arguments change le signe du résultat. C’est la source d’erreur la plus fréquente dans les tableaux de bord et dans les pipelines de transformation.
Calculer le temps entre lignes successives avec LAG et LEAD
Dans la vraie vie, les deux lignes ne sont pas toujours connues à l’avance. Vous avez souvent une table d’événements, et vous voulez comparer chaque ligne à la précédente ou à la suivante. C’est exactement le rôle de LAG et LEAD.
Quand utiliser LAG
Utilisez LAG lorsque vous voulez comparer une ligne à la ligne précédente dans un ordre défini. C’est très utile pour calculer le temps entre deux actions successives d’un même utilisateur:
- temps entre deux connexions
- temps entre deux commandes
- temps entre deux erreurs machine
- temps entre deux changements d’état
Quand utiliser LEAD
LEAD fonctionne dans le sens inverse: il regarde la ligne suivante. C’est utile pour calculer la durée jusqu’au prochain événement, par exemple le temps jusqu’à la prochaine visite, au prochain paiement ou au prochain statut.
La structure générale est la suivante:
- partitionner par entité, par exemple utilisateur_id ou device_id
- ordonner par timestamp
- récupérer le timestamp précédent avec LAG ou le suivant avec LEAD
- calculer l’écart avec TIMESTAMP_DIFF
Sans PARTITION BY, vous risquez de comparer des lignes appartenant à des utilisateurs différents. Sans ORDER BY, le résultat n’a pas de sens temporel. Ces deux clauses sont donc essentielles.
Statistiques temporelles utiles pour interpréter les résultats
Le choix de l’unité change fortement la lecture métier. Une durée de 14 400 secondes peut sembler abstraite, alors qu’elle correspond à 240 minutes ou 4 heures. Voici un tableau de conversion simple mais indispensable pour concevoir des analyses robustes et cohérentes.
| Unité | Équivalence exacte | Exemple métier | Quand l’utiliser |
|---|---|---|---|
| 1 minute | 60 secondes | Délai entre deux clics | Suivi fin des parcours utilisateurs |
| 1 heure | 3 600 secondes | Temps de traitement d’un lot | Batch jobs, ETL, opérations métier |
| 1 jour | 86 400 secondes | Délai de livraison | Mesures à plus grande échelle |
| 1 semaine | 604 800 secondes | Cycle de rétention | Analyse de tendance et de cohorte |
Exemple d’approche SQL selon le scénario
1. Comparer deux lignes connues
Si vous comparez deux événements explicitement sélectionnés, utilisez TIMESTAMP_DIFF directement. Cette approche est idéale pour un audit ponctuel, un test ou une validation d’incident.
2. Comparer chaque ligne à la précédente
Si votre table contient des événements répétés pour une même entité, utilisez LAG. C’est le modèle standard pour les calculs de temps entre événements successifs.
3. Comparer chaque ligne à la suivante
Si vous voulez mesurer la durée jusqu’à l’événement futur, utilisez LEAD. Cette approche est fréquente pour les statuts de tickets, les parcours clients et la durée d’un état avant changement.
4. Mesurer au jour près
Si votre logique métier est strictement calendaire, préférez DATE_DIFF. Cela évite les confusions dues aux heures, aux minutes ou aux conversions inutiles.
Erreurs courantes à éviter
- Inverser les arguments de TIMESTAMP_DIFF, ce qui change le signe du résultat.
- Mélanger DATETIME et TIMESTAMP sans conversion explicite.
- Oublier le fuseau horaire lors d’une ingestion depuis plusieurs pays.
- Utiliser LAG sans ORDER BY, ce qui rend la ligne précédente arbitraire.
- Ne pas partitionner par entité quand plusieurs utilisateurs ou machines partagent la même table.
- Comparer des chaînes de caractères au lieu de types temporels natifs.
Une bonne règle est de normaliser le temps dès l’ingestion, de conserver un horodatage de référence en UTC, puis de convertir uniquement pour l’affichage ou l’analyse locale. Cette discipline réduit fortement les erreurs dans les pipelines analytiques.
Performance et lisibilité dans BigQuery
BigQuery est conçu pour traiter de très grands volumes de données, mais cela ne dispense pas d’écrire des requêtes propres. Pour calculer le temps entre lignes efficacement, filtrez d’abord la période nécessaire, limitez les colonnes lues et utilisez une partition temporelle si votre table le permet. Une requête analytique bien cadrée coûtera moins cher et s’exécutera plus vite.
Pour la maintenance, nommez clairement les colonnes dérivées comme previous_event_ts, next_event_ts ou delay_minutes. Cela facilite la relecture, la validation par les équipes data et l’intégration dans les modèles BI.
Méthodologie recommandée pour un calcul fiable
- Identifier le type de colonne: DATE, DATETIME ou TIMESTAMP.
- Choisir l’unité métier pertinente: seconde, minute, heure ou jour.
- Définir l’ordre logique des événements.
- Appliquer LAG ou LEAD si la comparaison est séquentielle.
- Vérifier le signe du résultat et utiliser ABS seulement si nécessaire.
- Tester quelques cas limites: valeurs nulles, doublons, événements hors ordre.
- Valider avec un échantillon métier avant généralisation.
Cette méthode évite la plupart des erreurs de conception. Elle est particulièrement utile dans les contextes où les données arrivent depuis plusieurs sources, plusieurs applications ou plusieurs fuseaux horaires.
Ressources d’autorité pour approfondir
Si vous souhaitez consolider votre compréhension des données temporelles, des standards horaires et de l’analyse de données, ces ressources de référence sont utiles:
- NIST.gov – Time and Frequency Division
- Data.gov – jeux de données publics et pratiques d’analyse
- Berkeley CS186 – fondamentaux des bases de données
Ces références ne remplacent pas la documentation produit, mais elles apportent un socle solide sur les standards temporels, les structures de données et les principes de modélisation analytique.
Conclusion
Calculer le temps entre 2 lignes dans BigQuery est une opération simple en apparence, mais elle exige une vraie rigueur sur le type temporel, l’ordre des événements et l’unité d’analyse. Pour deux lignes connues, TIMESTAMP_DIFF suffit. Pour des séquences d’événements, LAG et LEAD sont les outils les plus puissants. Si vous normalisez vos horodatages, choisissez la bonne unité métier et testez vos cas limites, vous obtiendrez des indicateurs fiables, réutilisables et lisibles. Le calculateur ci-dessus vous aide à valider rapidement vos écarts et à générer un modèle SQL pratique pour accélérer votre travail dans BigQuery.