Analytics temps réel en production

Servir des dashboards qui se rafraîchissent à la seconde est un défi. Sans la bonne architecture, les requêtes sur des flux de données en continu peuvent exploser la latence et les coûts. La solution ne réside pas dans la puissance brute, mais dans l’application de patterns intelligents : un schéma de données adapté à l’écriture rapide, une indexation agressive sur le temps, et des garde-fous clairs pour le requêtage. L’objectif est de fournir des chiffres quasi temps réel de manière fiable et économique.

prérequis et idées clefs

Plutôt qu’une liste, voici une carte mentale des principes fondamentaux à respecter pour construire un système d’analytics temps réel robuste.

pas à pas

étape 1: ingestion des événements en continu

La première étape est de capturer les données sous forme d’un flux d’événements. Des outils comme Kafka ou AWS Kinesis sont conçus pour absorber des volumes très élevés d’écritures sans ralentir les applications sources.

# Exemple: un producteur simple envoie un événement JSON dans un topic Kafka
kafka-console-producer --topic user_events --broker-list broker:9092 << EOF
{"ts": "2022-10-09T10:00:05Z", "user_id": "abc-123", "event": "addToCart", "country": "FR"}
EOF

étape 2: requêter des fenêtres de temps courtes

Les bases de données temps réel (Druid, ClickHouse, Pinot) sont optimisées pour des requêtes analytiques (agrégations, filtres) sur de très larges volumes de données. La clé de leur performance est de toujours filtrer les requêtes sur une fenêtre de temps la plus courte possible.

-- Requête type pour un dashboard: compter les événements par pays sur les 2 dernières heures
-- La clause WHERE sur __time est la plus importante pour garantir une faible latence.
SELECT
    TIME_FLOOR(__time, 'PT1M') AS minute, -- Agrégation par minute
    country,
    COUNT(*) as event_count
FROM
    user_events
WHERE
    __time >= NOW() - INTERVAL '2' HOUR
GROUP BY 1, 2
ORDER BY 1 DESC;

étape 3: mettre en place une politique de rétention

Conserver des données brutes à l’infini dans une base de données temps réel est extrêmement coûteux. Il est essentiel de définir une politique de rétention pour automatiquement supprimer ou archiver les données anciennes qui ne nécessitent plus une faible latence.

-- Exemple de tâche de rétention qui s'exécute chaque nuit
-- Supprime toutes les données de plus de 90 jours de la table "chaude"
DELETE FROM user_events WHERE __time < NOW() - INTERVAL '90' DAY;

exemples concrets

cas 1: un dashboard de supervision e-commerce

Une équipe marketing a besoin de suivre les ventes et les erreurs d’ajout au panier en temps réel pendant une opération commerciale.

stack: Kafka pour les événements, Druid pour le stockage, Superset pour la visualisation.
requête type: SELECT SUM(prix), COUNT(DISTINCT user_id) FROM sales_events WHERE __time >= NOW() - INTERVAL '1' HOUR AND event_type = 'purchase'.
impact: L’équipe peut réagir en quelques minutes à une baisse anormale des ventes ou à une hausse des erreurs.

cas 2: une api de détection d’anomalies

Un système de sécurité a besoin de détecter les pics de tentatives de connexion échouées.

stack: Kinesis pour les événements, ClickHouse pour le stockage, une API custom en Python.
requête type: SELECT client_ip, count() FROM login_attempts WHERE ts > now() - interval 5 minute AND success = false GROUP BY client_ip HAVING count() > 10.
impact: L’API peut automatiquement bloquer des adresses IP suspectes en quasi temps réel.

pièges fréquents

Symptôme: Les requêtes sont lentes ou le dashboard plante.
- Cause: Absence de filtre de temps dans la requête, forçant un scan complet de la table.
- Correctif: Rendre le filtre de temps obligatoire. La plupart des outils de BI permettent de définir un filtre par défaut dans le modèle de données.
Symptôme: La facture cloud explose à la fin du mois.
- Cause: Les utilisateurs demandent des données sur des fenêtres de temps trop larges (ex: 6 mois) dans le système temps réel.
- Correctif: Définir une borne par défaut (ex: 7 jours) dans l’interface de requêtage. Pour les analyses historiques, rediriger les utilisateurs vers le data lake (ex: S3 + Snowflake/BigQuery) qui est bien moins cher.
Symptôme: Les chiffres du dashboard sont frais, mais la page met 10 secondes à charger.
- Cause: Latence réseau ou requêtes trop complexes pour un affichage instantané.
- Correctif: Utiliser des vues matérialisées pour pré-calculer les agrégats les plus courants. Mettre en place une couche de cache (ex: Redis) devant l’API de requêtage pour les requêtes identiques.

faq

Quelle est la différence entre “temps réel” et “quasi temps réel” ? Le “vrai” temps réel (hard real-time) est une affaire de millisecondes, crucial pour des systèmes industriels. En analytics, le “quasi” temps réel (near real-time) est ce dont on a besoin : une latence de quelques secondes à une minute entre l’événement et sa disponibilité dans un dashboard.
Pourquoi ne pas utiliser ma base de données transactionnelle (ex: postgresql) ? Les bases de données comme PostgreSQL sont optimisées pour des écritures et lectures de lignes individuelles (OLTP). Elles ne sont pas conçues pour les écritures en masse à haute vélocité et les scans analytiques sur des milliards de lignes (OLAP) que requiert le temps réel. Utiliser le mauvais outil mène à des problèmes de performance et de coûts.

Menu