Affichage des articles dont le libellé est hadoop. Afficher tous les articles
Affichage des articles dont le libellé est hadoop. Afficher tous les articles

lundi 8 juillet 2013

Une première introduction à la base NOSQL mongodb

J'ai mis en ligne une nouvelle vidéo consacrée à  mongodb.
Le site de mongodb est ici.



 Le support complet slides et vidéo est sur le site de partage slideshare



Mongodb introduction from eric german


MongoDB et Haddop sont deux compagnons.  Hadoop permet de stocker des volumes importants  et mongoDG s'occupe de la restitutions d'extraction de données venant d'hadoop.
Dans le sens inverse, mongodb peut utiliser la puissance des JVM pilotée par Hadoop pour réaliser des traitements par lots (ex Map-reduce).

MongoDB est une base NOSQL  de type document un peu comme couchDB. Son langage de commande est le Javascript.  Le projet se compose d'une série de programme dont 'mongod' : le serveur de la base et 'mongo' : un client sous la forme d'une console shell.

J'ai mis ici un exemple de script de lancement du service mongod pour ubuntu
 

Et ici le fichier de configuration:

vendredi 5 juillet 2013

Bientôt des vidéos et des articles sur la base NoSQL MongoDB

Voila plusieurs semaines que je bricole avec MongoDB l'étoile montante des bases NoSQL  (Not Only  SQL).

 Après avoir essayé: CouchDB , Redis , Riak , étudié Cassandra et Hadoop (voir les posts ou les vidéos)
(source : http://germanlinux.blogspot.fr/2012/12/la-carte-hadoop-pour-ne-pas-se-perdre.html )

Posts :



C'est lors de la journée des utilisateurs Hadoop France en decembre 2012 que j'ai compris l'importance du rôle de MongoDB.

Il y a d'un coté le BigDATA:
Il   répond à un besoin de stocker un nombre vertigineux de données et surtout à offrir un cadre pour réaliser des traitements parallèles (map-reduce)

De l'autre  coté le mouvement NoSQL qui cherche à assouplir  l'architecture applicative et à simplifier les modèles de données. Le NoSQL souhaite aussi répondre au besoin de stockage de masse engendré par les réseaux sociaux. Ces informations ne sont pas toujours structurées . La disponibilité, le partage des données sont les objectifs principaux, le traitement parallèle est secondaire.

MongoDB fait le lien entre ces deux mondes.
 
Prochaine vidéo

A bientôt.


samedi 8 décembre 2012

La carte Hadoop pour ne pas se perdre dans le bigdata

J'ai assisté à une réunion du HUG_France : Hadoop user group.  Un des conférenciers était Ted Dunning de la société MapR.

Pour clarifier les chose , j'ai fait cette carte d'Hadoop représentant les principaux composants.






L'état de l'art à ce jour:
Il est possible de stocker des gros volume de données structures ou non sur un système de fichier distribué.  Il est possible de réaliser des opérations BATCH distribuées de sélection et de réduction sur ces données.
L'enjeu actuel est la recherche et le la restitution en temps réel dans ces gros volumes (Big Data).
Un contournement peut etre fait par des exports de données d'Hadoop vers des modes de stockage et de restitutions plus rapides: exemple  mongodb.







dimanche 29 avril 2012

Le défi des #bigdata n'est pas le volume mais le facteur humain

Dans un article en anglais disponible ici intitulé : big data : beaucoup de problème et peu de talent, l'auteur  (Benn Rooney)  met en avant le manque d'ingénieur formé à l'analyse de données de masse.
Un ingénieur bigData doit pouvoir transformer les données en information et les informations en action.
Il estime  à   1,5 millions le nombre d'ingénieur à former dans ce domaine rien que pour les USA.
Le profil recherché est  un ingénieur possédant plus un  bagage en  mathématiques qu'en  informatique





lundi 9 janvier 2012

#Hadoop, les limites des #nosql


Le système complet de la famille de stockage NOSQL , HADOOP vient de sortir en version 1.0
Le phénomène NOSQL commence à diffuser au sein des directions informatiques grandes ou petites.
Le sujet des bases nosql soulève deux questions:
Quels sont les cas d'utilisation à retenir ?
 Sur le site http://www.saama.com  une infographie  propose une réponse à cette question.

Le nombre de cas d'utilisation est reduit et les risques d'erreur important.
Les applications métier de gestion sont à écarter, surtout si elles reposent sur un bon vieux framework MVC J2E.
A mon sens l'utilisation d'une base NoSQL se justifie pour des usages :

  • très simples. 

Exemple: l'application ne sert qu'a afficher ou a manipuler quelques table sans valeur ajoutée. Les tables seront regoupées dans une seule entité d'une base NOSQL avec de la denormalisation et de la redondance assumée.

  • Des architectures d'infrastructure  avec des fortes contraintes de volume  ou de disponibilité : Un serveur de session, un gestionnaire de message par l'exemple  
  • Des applications qui mettent en oeuvre des opérations d'indexation ou de comptage. C'est ici qu'intervient le map/reduce mis en avant  par google. 

En conclusion: Le Nosql est en passe de devenir le nouveau truc à vendre par les SSII. Il y très peu de projets candidats.  

Vous avez envie de vous lancer dans l'aventure. 

La tentation est forte de commencer par hadoop: Ce projet a 6 ans d'age, labélisé par La fondation Apache.
 Hadoop se présente  comme un assemblage de plusieurs sous-projet avec à la base  un système de fichier HDFS et HBASE pour le stockage. Avec hadoop les données et les fichiers sont distribués sur plusieurs serveurs. Les opérations de map-reduce se passent sur chaque fragment eléméntaire de données.

Aussi, je vous conseille de commencer avec des produits NOSQL plus modestes comme Riak ou mongodb.
Leur spectre d'utilisation est plus grand que celui d'hadoop.
Avec les produits NOSQL il faudra souvent passer par du javascript (meme pour hadoop) qui s'impose comme le langage 'utilitaire' de ces nouvelles bases.




Les bases NOSQL vont aussi se retrouver au niveau du client,  cette  adoption est favorisée par l'adoption du HTML5 et de la décentralisation des traitements. Votre poste de travail mobile va extraire les informations geo-localisées depuis une base de données centrale. Puis votre terminal travaille sur les données locales pour une re-synchronisation future.

Mais attention.

Pouvoir stocker plus de données c'est bien, mais pour en faire quoi ? Une entreprise ne sait se servir que de moins de 5% de ses données. La donnée doit etre structurée, indexée et tracée  et non pas déversée en vrac dans un entrepot ou une base de données sinon elle sera perdue.
En 2020 , l'écart entre le volume d'information et la capacité de stockage va se creuser : en clair il faudra compresser la donnée et ne sélectionner que l'information pertinente.
Aussi de la même facon qu'il y a des DSI , il y aura de Data manager assurant la gouvernance des données au sein des SI. Après l'urbanisation des SI , c'est le tour des données.