Accueil Le blog ebiznext
Offline WebAnalytics Architecture

 

mogobiz-elastic

 

Dans cette note je décris la mise en oeuvre d’une architecture générique de traitement des données dans le cadre d’analyse offline.

Analyse Offline Objectifs : Sur la base de référentiels et de logs d’accès au serveurs Web, le marketing/l’exploitant/… doit pouvoir effecuter des traitements qui lui permettent de comprendre le comportement des visiteurs sur son site et revoir le site afin d’améliorer l’expérience utilisateur.

Outils sur lesquels on s’appuie
- Les fichiers de logs : :)

- Les fichiers CSV ou  bases de données relationnelles pour les référentiels

- Apache Avro :
Format JSON de données. Plusieurs convertisseurs existent de données sources vers le format Avro (pour les mails notamment)

- Apache Flume :
Couche technique de récupération de données à partie de logs (un appender log4j vers Flume existe mais on peut facilement en écrire pour d’autres formats).
Un processus Agent est colocalisé sur le serveur Web/WebApp qui génère les logs. Ce processus Agent fait suivre les logs vers un processus collecteur chargé de déverser les logs dans un référentiel cible (cela pourrait etre la console par exemple).
Dans notre cas, nous ne déversons pas dans la console, mais dans ElasticSearch avec le connecteur Flume adéquat
Apache Flume déverse les données dans ElasticSearch en temps réel.

- ElasticSearch
ElasticSearch est une base orientée document avec un moteur de recherche full text (lucène). Bref un MongoDB avec du fulltext en plus.
ElasticSearch propose une interface JSON/REST qui permet de faire des requetes sur les attributs du document exactement comme pour MongoDB (Pour rappel, si on veut comparer à un SGBDR, un document est une table et les attributs des colonnes. Par contre d’un document à un autre, on n’est pas obligé de retrouver les memes attributs)
En plus d’ElasticSearch, on installe le tout récent connecteur ElasticSearch-Hadoop pour permettre à Hadoop d’interroger la base ElasticSearch avec les API Hadoop.

- Hadoop
Api Java qui permet de faire un traitement parallèle sur les données. En général quand on a un fichier de logs, on lance des commandes comme celles ci-dessous pour obtenir l’agrégat suivant : Combien d’iPhone4 ont été rejetés pour des raisons de sécurité. $ grep “HTTP/403” *.log | grep iPhone4 | wc -l
Evidemment cela est très peu performant.
Avec Hadoop on peut écrire un programme Java qui va paralléliser les traitements à partir de fonctions Map/Reduce (patterns d’exécution des traitements en // pour obtenir des agrégats).

-Hive
Ecrire du Java pour calculer des agrégats , c’est un peu lourd - n’est ce pas :) - C’est là qu’intervient Apache Hive. Hive est un langage de script minimaliste qui va permettre de scripter les opérations de map/reduce avec un langage à la SQL.
Création d’un document avec Hive

  • CREATE TABLE pokes (foo INT, bar STRING);

Sélection de données avec Hive

  • SELECT a.foo FROM invites a WHERE a.ds=’2013-08-15’

-Pig
Hive est facile d’utilisation mais parfois SQL est insuffisant. Il est parfois utile de pouvoir adjoindre un peu de code Java au SQL pour faire faire à Hadoop des choses un peu plus compliquées que du pur SELECT. C’est là qu’intervient Pig, il se situe entre Java et SQL et permet d’invoquer des fonctions Java dans le script (ce que Hive ne permet pas).
En résumé, Pig est moins confortable mais plus puissant vu qu’on peut augmenter la puissance du langage avec des appels à des fonctions Java.

Exemple de chargement de fichier avec Pig

  • raw = LOAD ‘excite.log’ USING PigStorage(‘\t’) AS (user, time, query);

Exemple de requete Pig qui retient uniquement les requetes dont la querystring n’est pas vide (noter l’appel à la fonction Java NonURLDetector).

  • FILTER raw BY org.apache.pig.tutorial.NonURLDetector(query);

Les agrégats construits avec Hadoop (Pig/Hive/java) sont réinjectés dans ElasticSearch comme des documents qui pourront etre requetés au meme titre que les données unitaires.

- Kibana, le Sytadin de votre activité
Kibana est une WebApp full JavaScript (pas de server side) qui permet d’interroger en REST/JSON ElasticSearch et affiche les données renvoyées dans de beaux histogrammes / bar charts / …
Le marketing / l’exploitant / … peut à présent via Kibana visualiser ses données qui évoluent de minute en minute.

 

Justification des choix pour l’acquisition des logs
Il existe plusieurs outils d’agrégation de logs. Ceux qui reviennent le plus souvent sont logstash et flume, tous deux des projets Apache.

Sans trop rentrer dans les détails, Logstash et Flume font le même boulot à ceci près:

  • Logstash est écrit en JRuby et Flume en Java. Je préfère perso si j’ai des devs à faire le faire en java/scala (pour le moment)
  • Logstash a besoin de redis pour le routage des logs et redis est écrit en C, ce qui en fait un composant hors JVM à surveiller alors que Flume est full JVM
  • Logstash est plus simple à configurer et possède un DSL qui rend la config plus simple
  • Flume permet  des config complexes mais je dois l’admettre que probablement seul Google ou Facebook pourraient mettre en oeuvre.

J’en profite pour dire que pour la visu des logs, il existe d’autre outils que Kibana, à savoir Splunk, graylogUI et logstashUI