====== Projet ====== Ce projet consistera à monter une petite suite permettant d'exploiter les données de stations de vélo. ** Date de rendu du rapport: 11/03/2018 ** Il s'effectuera en groupes de 4 à 5 étudiant.e.s. La composition des groupes est contrainte comme suit: chaque groupe doit comporter au moins deux étudiants de la formation TIW et deux étudiants de la formation DS. Une machine du cluster Hadoop sera attribuée à chaque groupe (//c.f.// ci-dessous). Au sein de chaque groupe, il faut choisir un login qui sera utilisé pour toutes les tâches du projet (e.g. pour des questions de droit HDFS). Il faudra transmettre aux autres membres du groupe la clé SSH de ce login. ===== Données ===== Une archive contenant un historique des données est disponible via une URL qui sera envoyée par e-mail. Par ailleurs il sera demandé de mettre au point une historisation des données actuelles en consultant les données concernant des stations de la ville de Lyon sur le site https://developer.jcdecaux.com. A noter qu'il sera nécessaire de demander une clé d'API sur ce site pour pouvoir accéder à ces données. ===== Travail demandé ===== Il est demandé: * De mettre en place un chargement via Kafka des données CSV fournies ainsi que les données récupérées via l'API Web aux choix - dans HDFS dans un format au choix - dans des tables Hive * Pour les données récupérées via l'API Web, envoyer également ces données vers une topologie Storm qui détectera les situations où: * Il n'y a plus de vélos / de place disponible * La disponibilité en vélos d'une stations sur les 3 dernières heures est inférieure à 5 * Renvoyer un message d'alerte, via Kafka * Archiver les messages d'alerte dans HDFS/Hive * Afficher un graphique de taux d'occupation pour une station donnée via Zeppelin (interface d'interrogation des données) Il est demandé de produire un rapport par groupe explicitant la mise en place des différents éléments de gestion des données demandés. ===== Environnement technique ===== Une machine sera attribuée à chaque groupe. Il s'agit d'une des machines du cluster utilisé pour le TP Spark. Storm, Zeppelin et Kafka ont également été installés sur ces machines, mais il faut les lancer à la main. ==== Storm ==== Lancer ''setup-storm.sh''. Cela va copier une installation de storm (1.0.5) dans votre compte. Storm a été préconfiguré, vous pouvez directement démarrer ''storm nimbus'', ''storm ui'' et ''storm supervisor'' depuis le répertoire ''storm/bin''. Le port de l'interface Web Storm UI a été changé, il s'agit du port 8081. Il est inutile de chercher à démarrer zookeeper, c'est celui du cluster qui est utilisé Pour rediriger l'interface Storm UI, on peut utiliser la commande suivante: ssh p4567890@www.xxx.yyy.zzz -L8081:www.xxx.yyy.zzz:8081 ==== Zeppelin ==== Lancer ''setup-zeppelin.sh''. Cela va copier une installation de zeppelin (1.0.5) dans votre compte. Zeppelin est préconfiguré et peut être contrôlé via ''zeppelin/bin/zeppelin-daemon.sh start'' / ''stop'' / ''status''. Le port de l'interface Web Zeppelin est le 8080. La commande de redirection pour Zeppelin est: ssh p4567890@www.xxx.yyy.zzz -L8080:localhost:8080 ==== Kafka ==== La version installée est la 0.9. Cette version ne dispose pas de ''kafka-connect''. Un [[https://howtoprogram.xyz/2016/04/30/getting-started-apache-kafka-0-9/]] permet de démarrer rapidement en pratique. Attention, Kafka étant préinstallé, quelques changements sont à prendre en compte: - l'adresse zookeeper à utiliser est ''tp-hadoop-cdh-slave-tpl-01-8:2181'' - l'adresse du broker est ''additionnal-slave-1.novalocal:9092'' - les exécutables ne finissent pas en ''.sh'' (//e.g.// utiliser ''kafka-topics'' au lieu de ''bin/kafka-topics.sh'') - l'ensemble des script kafka se trouvent dans le répertoire ''/usr/lib/kafka/bin'' L'infrastructure kafka est partagée. Il est donc important de bien nommer vos topics en y incluant par exemple le login ou le groupe de projet.