Projet

Ce projet consistera à monter une petite suite permettant d'exploiter les données de stations de vélo.

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.

<note important> Attention, le cluster est isolé d'Internet. Il faut donc passer par le proxy http de l'université pour accéder à l'API JCDecaux depuis le cluster. L'adresse du proxy (pour tous les protocoles: HTTP et HTTPS) http://proxy.univ-lyon1.fr:3128.</note>

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
    1. dans HDFS dans un format au choix
    2. 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)

Une fois ce travail terminé, vous êtes encouragés à enrichir la capacité de prévision du système. Cette partie est libre: l'objectif est de pouvoir anticiper les alertes. Vous pouvez commencer par analyser les données archivées et construire un modèle de prévision. Vous pouvez également enrichir les données à partir de sources open-data (e.g. météo).

Une soutenance aura lieu le 12/02/2019. On y présentera les différents traitements en mettant l'accent sur les difficultés rencontrée et les solutions apportées. Il est également demandé de déposer tout le code source sur https://forge.univ-lyon1.fr dans un projet accessible à Emmanuel Coquery (avec le rôle reporter).

Le planning des soutenances sera indiqué dans tomuss.

<note tip>Pensez aux différentes tâches qu'il sera nécessaire de mettre en oeuvre et répartissez-vous le travail selon vos compétences et vos affinités. Prévoyez des jeux de données simulés pour les briques qui ne sont pas encore fonctionnelles.</note>

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.2.2) 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.

<note important>Le port de l'interface Web Storm UI a été changé, il s'agit du port 8081.

Pour rediriger l'interface Storm UI, on peut utiliser la commande suivante:

ssh p4567890@www.xxx.yyy.zzz -L8081:www.xxx.yyy.zzz:8081

Une fois le tunnel établi, l'interface est disponible ici: http://localhost:8081 </note> <note important>Il est inutile de chercher à démarrer zookeeper, c'est celui du cluster qui est utilisé</note>

Zeppelin

Lancer setup-zeppelin.sh. Cela va copier une installation de zeppelin (0.8.0) 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 1.0.1. Cette version ne dispose pas de kafka-connect. Un tutoriel permet de démarrer rapidement en pratique. Attention, Kafka étant préinstallé, quelques changements sont à prendre en compte:

  1. kafka est déjà démarré sur le cluster
  2. l'adresse zookeeper à utiliser est cl-ter-manager-jt3m3gbgctz6-qdrjqxrsgate-nlx635i3m5wq:2181
  3. l'adresse du broker est cluster-node-cztqntk4f5x6-clogovtafhcq-ikmht4fosq6e.novalocal:9092
  4. les exécutables ne finissent pas en .sh (e.g. utiliser kafka-topics au lieu de bin/kafka-topics.sh)
  5. l'ensemble des script kafka se trouvent dans le répertoire /usr/bin

<note important>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.</note>

Hive

  1. L'URL JDBC pour se connecter à hive est: jdbc:hive2://cluster-node-cztqntk4f5x6-e5kbhg3sdc2o-v47yamcxijkc:10000, exemples en Java

<note important>L'infrastructure Hive est partagée, il est donc important de nommer vos tables en les préfixant par votre login étudiant afin d'éviter les conflits de nom.</note>

Packages installés

Versions des logiciels du cluster

Les packages Ubuntu suivants sont installés sur les machines: oracle-j2sdk1.8,cloudera-manager-agent,python-numpy,python-matplotlib,python-pip,python-virtualenv,git,zip,unzip

Les packages Python2 suivants sont installés sur les machines: kafka-python, pipenv, pytest, pytest-spark, streamparse, pykafka

Si vous avez besoin d'un autre package, demander à Emmanuel Coquery.