Vérinews, phase 2 Marc-Antoine Tardif Pierre-Emmanuel Viau Plan Pierre-Emmanuel VériNews L équipe Gestion du projet Phases du projet, besoins et priorités Cas d utilisations priorisés Marc-Antoine Architecture & Technologies Démonstration
VériNews Démarré par Alain April et Sylvie Ratté avec un partenaire industriel Le partenaire est une entreprise qui distribue des communiqués de presse à des journalistes, blogueurs, influencers, etc. VériNews est un «projet de dévelopement d outils de support aux professionnels de la communication et des relations publiques» Un document de vision a été rédigé par Alain et Sylvie Membres de l équipe et rôles (phase 2) Pierre-Emmanuel déploiement, exigences, architecture de Verinews Marc-Antoine lead développement, architecture de Verinews Gauthier développement, catégorisation et analyse de sentiment Edem développement Web, outil d annotation des données d entrainement
Gestion de projet Plusieurs phases au projet, chacune ayant ses priorités Livrables Études des technologies, plan de projet, BRS, SRS, SAD, notes de développement, compte-rendus, modèles de données, prototypes interfaces Google drives Git (Bitbucket) Rencontres d équipe à chaque fin de semaine Rencontre avec le partenaire à chaque mois Survol de la phase 1
Besoins Principaux besoins identifiés lors de la phase 1 faciliter la rédaction de communiqués «efficaces» avec certains outils; faire le ciblage d une communication automatiquement; générer des messages aux personnes ciblées; distribuer les communications; évaluer l impact sur plusieurs canaux (réseaux sociaux, sites de nouvelles, blogs, etc.). Survol de la phase 2
Besoins Priorités pour la phase 2 traitement d une des sources de données; catégorisation et analyse de sentiments(polarité); 3 catégories pour le moment (sur 13) «food» «arts & entertainement» «beauty & fashion» identifier des produits, termes, etc. Cas d utilisation
Exigences fonctionnelles REQ-101 Récolte des données de Twitter REQ-102 Pré-traitement des données de Twitter REQ-103 Stockage des données de Twitter REQ-104 Analyse des sentiments sur les tweets REQ-105 Catégorisation d un tweet REQ-106 Visualisation de l analyse de sentiment des thèmes Lifestyle REQ-107 Création du corpus Partie 2.1 Architecture Marc-Antoine Tardif
Architecture Retour sur ce qu il y avait à faire: obtenir et stocker les tweets publiés en temps réel; faire une catégorisation des tweets, selon des thèmes Lifestyle; faire une analyse de sentiment sur ces mêmes tweets (polarité); offrir une interface permettant de consulter le résultat des analyses; offrir une interface permettant d annoter des tweets d entrainement. Donc, les 3 principales fonctionnalités sont: traiter des données de Twitter; visualiser des analyses de sentiments et de la catégorisation; annoter des tweets. Architecture Lignes directrices lors de la conception: Priorité sur le traitement et le stockage des données Ce qui semblait demander le plus d effort Utiliser de systèmes qui peuvent être mis facilement à l échelle Garder la solution le plus simple possible (pas de «over-engineering») Utiliser des systèmes/outils/frameworks interchangeables qui permettent de prototyper rapidement (les requis changent trop) Contraintes: l équipe se limite à des langages connus par tous les membres Java, Python, SQL utilisation de bases de données SQL pour faciliter le développement le volume de données n est pas assez important pour se lancer dans des solutions exotiques
Architecture Principales composantes qui ont à interagir ensemble: Twitter Streaming API REST connexion HTTP persistente message queue système de «stream processing» des bases de données des serveurs Web Architecture haut niveau Non fonctionnelle Rétention 30 jours cron job d un script python qui delete les lignes >30 jours «Temps réel» pour le partenaire = 5 minutes en pratique <1 seconde jusqu à la DB Mise à l échelle aucun problème avec Kafka et Storm Les DB SQL font la job pour le moment, pour le type de requêtes utilisées (à remplacer éventuellement) cache dans le dashboard, réduit de beaucoup les hits sur la DB Robustesse Rien ne plante pas si le volume en entrée augment subitement risque avec Storm, pas avec Kafka
Architecture Composantes Frameworks/Lang. Systèmes Message Queue Kafka, Java tweet-endpoint Stream processing Storm, Java tweet-processor Base de données 1 Postgres tweet-processor, dashboard Base de données 2 MySQL annotateur Serveur Web 1 Tomcat, Grails, Groovy annotateur Serveur Web 2 Python (tornado) dashboard Scripting Bash, Python, Cron * OS CentOS 6.5 * 4 systèmes distincts twitter-endpoint (Kafka, Java), twitter-endpoint-simulator REQ-101 Récolte des données de Twitter tweet-processor (Storm, Java, postgres) REQ-102 Pré-traitement des données de Twitter REQ-103 Stockage des données de Twitter REQ-104 Analyse des sentiments sur les tweets REQ-105 Catégorisation d un tweet dashboard (Python, JavaScript) REQ-106 Visualisation de l analyse de sentiment des thèmes Lifestyle annotateur (Java, MySQL) REQ-107 Création du corpus
Partie 2.2 Technologies utilisées Marc-Antoine Tardif Twitter Streaming API (1/2) Twitter offre un API de streaming Envoie jusqu à 1% du traffic, sans garantie Utilise une connexion HTTP persistante comme télécharger un fichier à l infini chaque tweet est séparé par des sauts de lignes le tweet est dans un gros JSON qui contient un maximum d information menaçant votre vie privée Twitter offre d autres API pour obtenir des données historiques mais ceux-ci ne sont pas d intérêt pour cette phase considérant l aspect temps réel
Twitter Streaming API (2/2) Pour obtenir un stream avec plus de données seulement accessible via les partenaires de Twitter; le contact a été initié avec un d entre eux; discussion toujours en cours. Kafka Système de messaging publish-subscribe Facile à mettre à l échelle, distribué «by design» Utilise zookeeper (système distribué de synchronisation) Suffit d implémenter des «producer» et des «consumer» Très très facile d utilisation http://kafka.apache.org/
Storm (1/2) Système de traitement en temps réel distributé tolérant aux pannes Permet de facilement traiter des streams de données en temps réel Projet créé par une entreprise qui été acquise par Twitter en 2011. Le code source est disponible sur GitHub http://storm.incubator.apache.org/ Storm (2/2) Spout émet un ou des streams Bolt consomme un ou des streams émet un ou des streams Lors de l éxécution, les spouts et bolts sont des processus et/ou threads distribués sur le cluster Ils peuvent éxécuter n importe quel code (avec le cadre d application en Java, on implémente des interfaces)
PostgreSQL/MySQL Malentendu lors du développement Sans compter les problèmes d installations, de version, de repositories, #/?$@?/!!$ Principalement causé par le fait que VeriNews a 2 composantes majeures qui ont été développées indépendament: traitement des tweets annotation des tweets Server Web 1: Groovy/Grails Le choix a été laissé au développeur de l annotateur Choix discutable Peu d impact sur le reste du projet, ne sert qu à générer les données d entrainement utilisées par le tweet-processor Serveur Web 2: Python Dashboard qui présente ce qui est stocké dans la DB Temps réel avec websocket tornado + single page app javascript Codé en cowboy en 2-3 heures, il y a 4 jours et hier soir Ne doit jamais voir la production, git filter-branch --tree-filter dashboard' HEAD après la démo 'rm -rf
Partie 2.3 Implémentation Marc-Antoine Tardif Topologie Storm Spout Kafka consumer Kafka (~10-15 lignes de Java du tutoriel) Parse parse un JSON (jackson) Categorization catégorise le text du tweet selon les données d entrainement 3 catégories implémentées pour le moment «food», «arts & entertainment», «beauty & fashion» algorithme pas développé par ceux qui sont en avant Sentiment Metrics + SVM Classifier analyse de sentiment, en 2 étapes(metriques + SVM) algorithme pas développé par ceux qui sont en avant Postgres writer INSERT dans Postgres probablement pas très «scalable» facile à remplacer
Architecture Démonstration. Annotateur Endpoint Twitter Tweet processor Dashboard
Conclusion Questions?