Guide de survie Big Data

En discutant avec plusieurs personnes, je me suis rendu compte que la jungle des outils Big Data reste encore bien souvent impénétrable pour le profane.

Vous êtes dans cette situation ? Vous avez besoin de points de repère sur NoSQL, Hadoop, Fast Load, Analytics, solutions de Search ?

Ce petit guide est fait pour vous !

J’ai besoin d’analyser des volumes importants de données

Souvent le premier besoin des projets Big Data.

C’est un peu le prolongement des besoins décisionnels. On a besoin de stocker des volumes importants de données puis de calculer des indicateurs.

Hadoop est la solution idéale.

Pour l’utiliser, le mieux est encore de vous appuyer sur une distribution du marché:

  • Cloudera ou Hortonworks
  • ou encore de faire le choix d’un éditeur généraliste comme Oracle, IBM, Microsoft ou Teradata.

Pour répondre à vos besoins, vous aurez à votre disposition deux outils au choix:

  • PIG, une solution de traitement de type dataflow (ETL)
  • Hive, une solution like SQL

Si vous avez besoin de performance, vous pouvez également utiliser Spark.

Spark privilégie l’usage de la mémoire, contrairement aux traitements Map Reduce (Pig ou Hive) qui s’appuient beaucoup sur l’usage disque. A noter que Spark est maintenant intégré dans toutes les bonnes distributions Hadoop du marché.

Une autre alternative avec Flink pour les développeurs Java.

Je veux donner un accès aux résultats à mes utilisateurs: comment faire ?

Vous pouvez proposer à vos utilisateurs un accès direct aux résultats via Hive. Certes, l’interface web est austère mais c’est une solution simple pour permettre à des supers users (connaissant le SQL) d’inetragir avec les données. Si les besoins sont récurrents, on peut aussi enregistrer des requêtes types qui sont ensuite simplement relancées par l’utilisateur.

Vous pouvez également laisser vos utilisateurs sur leur outil de reporting classique et leur permettre d’accéder aux données via une simple connexion odbc.

Il faudra mettre en place une sécurité minimale afin de s’assurer que notre gentil utilisateur n’essaie pas de récupérer toutes les données du Big Data dans son Excel.

Les requêtes sous Hive sont un peu lentes. On ne peut pas aller plus vite ?

Hive génère du code Map Reduce pour ses traitements. Cette phase prend du temps, qu’elle que soit la taille de votre cluster.

Pour avoir des temps de réponse intéressants, il est courant de pré-calculer une table de résultats. Ne pas oublier également que Hive a été conçu au départ pour traiter d’immenses requêtes qui ne passaient pas sur des SGBD traditionnels: le temps de réponse était secondaire.

  • Si vous êtes sur une distribution Hortonworks, le mieux est encore de modifier le moteur de Hive par défaut (Map Reduce) et de le remplacer par Tez. C’est un simple changement de paramétrage.

  • Si vous êtes sur une distribution Cloudera, vous avez à votre disposition Impala, un outil extrèmement véloce pour traiter les requêtes, même complexes.

  • Si vous êtes un power-user (Développeur, Datascientiste), la solution d’avenir sera peut-être du côté de Zeppelin, un notebook permettant d’interagir avec les données et de visualiser les résultats au sein d’une même interface web (l’outil est déjà disponible dans la dernière version Hortonworks).

  • edit (Merci Arnaud): Et depuis la semaine dernière, Hive-on-Spark est disponible avec la dernière version de Cloudera 5.7

    http://blog.cloudera.com/blog/2016/04/cloudera-enterprise-5-7-is-released/.

    Hive-on-Spark est une nouvelle fonctionnalité qui permet à Hive d’utiliser le moteur Spark en remplacement de Map Reduce pour de meilleures performances.

J’ai besoin de traiter mes données en temps réel: comment faire ?

Plusieurs solutions existent.

  • Pour faire du vrai temps réel opérationnel, Storm (ou Streams chez IBM), sera sûrement la bonne réponse. Intégré à Haddop, c’est un moteur qui traite la donnée avant même de la stocker (ce n’est pas une obligation). Cas d’usages typiques: Détection d’intrusion sur un réseau, Régulation thermique d’un datacenter, Analyse de vidéo-surveillance.
  • Pour traiter les données au fil de l’eau, vous pouvez utiliser Spark Streaming. On parle ici de micro-batch (intégration dans la seconde) plutôt que de vrai temps réel. Mais cela peut suffire à de nombreux besoins de gestion. L’avantage de Spark est d’offrir un éco-système complet de traitement de données (base graphe ou SQL, Machine Learning). Cas d’usages typiques: Analyse de tendance sur les réseaux sociaux, Détection de fraude.
  • Si vous avez surtout besoin d’intégrer de la donnée au fil de l’eau, Flume est une alternative intéressante. Flume réalise une synchronisation des données entre une source (des fichiers, un flux réseau) et une cible (souvent HDFS) par un simple paramétrage de l’outil. Couplé avec Hive, on peut analyser les données en pseudo temps-réel. Cas d’usages typiques: Analyse de logs.
  • Si votre besoin consiste essentiellement à analyser des logs en temps réel, vous pourriez avoir intérêt à utiliser la suite ELK (Elastic, Logslash, Kibana) qui propose une solution parfaitement adaptée à ce besoin. ELK intègre une librairie de connecteurs à différents types de logs (pour repérer à l’intérieur du log la date, l’heure, l’IP, etc.) ce qui évite de devoir le développer comme dans une solution avec Flume (ce développement serait fait pour être précis côté Hive). ELK propose également une solution de datavisualisation intégrée. ELK malheureusement ne s’intègre pas sur Hadoop et nécessite un cluster dédié.

Je veux proposer à mes commerciaux une vision 360° de nos clients.

Dans ce cas d’usage, on souhaite rassembler au sein d’une seule interface des informations disséminées dans le SI (CRM, ventes, facturation, support client, etc.). On n’a pas réellement besoin de traiter la donnée: cela a déjà été fait dans l’application source. En revanche, on souhaite que les nouvelles données soient prises en compte très rapidement pour que les commerciaux aient toujours une vue à date de la situation.

Les solutions de type Search seront les plus adaptées: elles indexent les données sans les déplacer.

  • SOLR chez Hortonworks
  • Search chez Cloudera
  • ou encore ELK

Et les bases NoSQL ?

Les bases NoSQL (HBase, MongoDB, Cassandra, etc.) sont des solutions complémentaires. Elles présentent deux atouts majeurs par rapport à Hadoop:

  • Recherche rapide d’un élément parmi plusieurs milliards d’enregistrements (grâce à l’indexation des données)
  • Insertion, mise à jour ou suppression d’un enregistrement

Le deuxième point notamment n’est pas vraiment réalisable sous Hadoop car Hive s’appuie sur HDFS qui ne permet pas de modifier un fichier. Aussi, pour modifier un enregistrement sur Hive, il est nécessaire de relire entièrement le fichier sous-jacent, de le modifier puis de le réécrire: ce n’est pas très performant !

  • En terme de cas d’usage, on pourra par exemple utiliser Hive pour traiter des données avant de charger le résultat dans HBase pour offrir des temps d’accès très rapide aux enregistrements.
  • MongoDB sera plutôt utilisé en remplacement d’une base de données traditionnelle dans un contexte de forte scalabilté (application Internet).

Pour aller plus loin: