La SNCF met à disposition en open source de nombreuses données via une API REST, en temps réel pour certaines. Nous avons souhaité vous présenter un mode opératoire sur l’utilisation de ces données temps réel disponibles : Déterminer la position des différents trains en circulation, et les positionner sur une carte.
Pour répondre à cette problématique, nous vous monterons comment mettre en place une architecture technique spécifique.
Les données disponibles
Les données temps réel des trains mises à disposition par la SNCF sont accessibles via une API REST. Chaque enregistrement prend la forme d’un dictionnaire, c’est-à-dire un couple clé-valeur id du trajet / informations du trajet (listes des arrêts avec les horaires d’arrivée et de départ, coordonnées…).
Comment collecter de la donnée en temps réel ?
Différents outils permettent à ce jour de collecter des données en temps réel. On les appelle message-brokers: ce sont des plateformes de messagerie, recevant des messages d’un système source et les transformant pour être consommés par les systèmes cibles. Les messages sont conservés au sein de la plateforme, en attendant d’être consommés puis purgés.
On peut par exemple citer Rabbit MQ, basé sur le protocole AMPQ, Pub/Sub dans Google Cloud Platform, ou Kinesis dans Amazon Web Service .
Apache Kafka
Notre choix s’est porté sur Kafka pour plusieurs raisons:
-
sa popularité. Kafka est aujourd’hui utilisé par de nombreuses sociétés grâce à ses performances très élevées
-
sa gratuité, Kafka étant intégré à la fondation Apache
-
son interfaçage avec Python, langage très maîtrisé chez Avisia.
Kafka est une plateforme distribuée résiliente, c’est-à-dire utilisant de la réplication distribuée sur disque. Kafka repose sur 3 composants:
- le producer: il envoie les messages sous forme de clé (optionnelle) et de valeur vers un topic Kafka. Dès lors que les messages ont la même clé, ils sont envoyés vers la même partition d’un topic. Il s’agit dans notre cas d’un programme écrit en Python, appelant l’API toutes les 5 minutes. Voici un exemple de code python:
-
le topic: il s’agit d’une catégorie de données. Les topics sont partitionnés pour assurer la scalabilité, et les données sont stockées / répliquées dans un format arbitraire, du JSON dans notre cas
-
le consumer: il consomme les messages stockés dans un topic Kafka. Dans notre exemple, le consumer est un programme Python, calculant la position de chaque train, est envoyant les données vers un outil de stockage. Voici un exemple de consumer:
Le stockage des données
A ce stade, vous avez la possibilité de mettre en place deux architectures :
-
une base MongoDB, couplée à l’outil de cartographie Leaflet
-
une base ElasticSearch, couplée à Kibana
MongoDB / Leaflet
MongoDB est un système de gestion de base de données NoSQL, orienté document. Il est donc très adapté à notre contexte, à savoir manipuler des données stockées en JSON (clés valeurs).
Exemple de table MongoDB
Leaflet est une librairie de cartographie, développée en JavaScript, et très performante. Nous avons utilisé la librairie Flask, module python simple permettant de développer des interfaces Web, s’interfaçant simplement avec Leaflet, pour afficher en temps réel la position des différents via une URL.
Exemple de visualisation reposant sur Flask / Leaflet
Cependant, Leaflet étant une librairie dédiée uniquement à la cartographie, nous avons souhaité un autre outil de datavisualisation. Notre choix s’est porté sur la stack ELK (ElasticSearch / Kibana / Logstash)
Elasticsearch / Kibana
Elasticsearch est un moteur de recherche distribué, basé sur Lucene, très performant, et accessible via une API Rest à partir des principaux langages de programmation. Il est supporté par la fondation Apache, et est donc open source. Le principe fondamental d’Elasticsearch est la disponibilté des données, au détriment de la consistence (théorème CAP: Consistency / Availability / Partition Tolerance). Pour assurer la résilience des données, celles-ci sont découpées en shard, qui peuvent être répliqués ou non.
Elasticsearch a été conçu pour requêter des fichiers JSON au travers de requêtes HTTP, c’est pourquoi il s’agit d’un bon candidat pour notre use case.
La base d’Elasticsearch est l’indexation: nous avons indéxé chaque document (enregistrement) dans notre base de stockage.
Kibana est quant à lui un outil de datavisualisation de la suite ELK, permettant de réaliser des dashboards et analyses temps-réel sur des données stockées dans Elasticsearch. Cet outil embarque de nombreuses visualisation différentes, et notamment des cartes, que nous utilisons dans notre exemple.
Exemple de visualisation basée sur Kibana
Conclusions et next steps
L’architecture que nous venons de présenter est donc la suivante : 
Cependant, bien qu’ayant à disposition des données temps-réel, cette première architecture demeure en mode mini-batch (rafraîchissement toutes les 5 minutes). Dans un prochain article, nous vous présenterons comment intégrer une couche reposant sur Spark Streaming, en lieu et place du consumer Python, pour bénéficier des performances de Spark, à savoir tolérance aux pannes et distribution.
Architecture cible
Staytuned …
