Je viens de publier un livre blanc sur ce que je pense être la convergence inévitable du Big Data et du logiciel libre / open source. Après une définition du big data (« ensembles de données qui deviennent tellement gros qu'ils en deviennent difficiles à travailler avec des outils classiques de gestion de base de données », d'après Wikipedia) et de ses caractéristiques (les « 3 V » de Stonebraker ou les « 4 V » de Popescu), j'expose les raisons pour lesquels les principaux logiciels du domaine ont été mis en open source, et j'en fais un panorama.
Le même jour, le magazine InfoDSI publie un article sur le décollage du Big Data, citant une étude de marché d'IDC qui évalue le marché à 3.2 milliards de $US en 2010 et potentiellement presque 17 milliards de $US en 2015 et qui met en avant également le dynamisme des projets open source dans le domaine.
Pour en revenir à mon livre blanc, il s'agit de la première édition, forcément incomplète. Vos commentaires, qu'ils soient posté sur mon blog ou ici-même, seront pris en compte (s'ils sont pertinents ;-)).
NdM: le livre est sous licence CC BY-SA 3.0.
# wikipedia + tableur ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Est-ce qu'il existe des tableurs collaboratifs pour mettre des données en commun ainsi que les programmes pour dessiner les courbes ou pour traiter les données ?
"La première sécurité est la liberté"
[^] # Re: wikipedia + tableur ?
Posté par Nonolapéro . Évalué à 2.
Avec IPython ça doit être faisable en se servant de l'interface web.
http://ipython.org/ipython-doc/rel-0.12/interactive/htmlnotebook.html#htmlnotebook
# "Moteurs d’indexation et de recherche"
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Dans la section "Moteurs d’indexation et de recherche", j'ai cherché un moteur de recherche qui pourrait indexer des serveurs de fichiers plein de .doc .docx .ppt, et des bases lotus, et du code source.
C'est difficile de savoir si il s'agit de simple library ou des outils en ligne.
Est-ce que quelqu'un a un retour d'expérience sur un moteur de recherche "à la google" mais pour un usage interne ?
"La première sécurité est la liberté"
[^] # Re: "Moteurs d’indexation et de recherche"
Posté par claudex . Évalué à 5.
Tu devrais regardé du côté de Lucene (indexation), tika (lecture des fichier doc, pdf…), solr et elastic search (interface à lucene).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: "Moteurs d’indexation et de recherche"
Posté par Stefane Fermigier (site web personnel) . Évalué à 3.
Oui, tout ce que j'ai qualifié de moteur de recherche d'entreprise ("entreprise search") doit normalement être capable de faire ca. Ca laisse donc plusieurs candidats (Solr, Constellio, Open Search Server, Elastic Search…).
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: "Moteurs d’indexation et de recherche"
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Lucène est clairement uniquement une library.
Elastic search propose du code JSON en page d’accueil, je n'appelle pas cela un "google-like".
"Open Search Server", Constellio semble mieux correspondre.
Solr semble plus roots que les 2 autres. Mais merci pour la liste !
"La première sécurité est la liberté"
[^] # Re: "Moteurs d’indexation et de recherche"
Posté par Ontologia (site web personnel) . Évalué à 2.
Alfresco sait le faire, et l'envoyer à manger à un Lucene, pour quelques formats d'Office.
Lotus, je sais pas.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Petites questions
Posté par Emmanuel Hugonnet (site web personnel) . Évalué à 2.
Où se placent les bases orientées graphes sur le schéma CAP ?
Neo4J par exemple annonce respecter les propriétés ACID cela signifie t il qu'il n'est pas scalable au sens big data ?
Quid aussi des data grids distribués (Oracle Coherence, Red/Hat Infinispan) ? Faut il les voir comme un MemCache ?
[^] # Re: Petites questions
Posté par Stefane Fermigier (site web personnel) . Évalué à 1.
Salut Emmanuel.
Effectivement les bases orientées graphes, et en particulier neo4j, ne semblent pas passer à l'échelle autant que les autres. On les met dans la case "NoSQL" parce que ce ne sont pas des bases relationnelles, mais de ce point de vue-ci on peut difficilement parler de big data à leur sujet.
Quant aux data grids, c'est encore une autre catégorie (qui mériterait peut-être de figurer dans le doc). On est plus il me semble dans le domaine du cache que dans le domaine du stockage.
"There's no such thing as can't. You always have a choice." - Ken Gor
# Base de données Logiciel libre et Big Data
Posté par Paf . Évalué à 3. Dernière modification le 14 mars 2012 à 21:54.
Bon boulot!
Meme si j'aurai bien aime voir un diagramme facon "couche d'os" montrant quels sont les projets qui font quoi. Par exemple avec Apache HAdoop au centre, puis les projets gravitant autour permettant de gerer les jobs, importer les donnees en flux, importer/exporter les donnees depuis les bases de donnees, bases nosql…
Il serait admirable aussi d'introduire des cas d'utilisation. Voir ceux decrits dans les differents blogs et conferences (Hadoop summit, Hadoop World…)
De meme, des informations concernant comment sont utilises se soutils serait un plus. Par exemple pour Apache Hadoop on passe soit par du code java, C/C++ via pipes, ou n;importe quel executable via stdin/stdout.
Mais du fait de la complexite/bas niveau du concept MapReduce, des outils d'abstration tels que Hive ou Pig ont vu le jour.
Pourquoi mettre Apache Zookeeper dans ce sac?
Apache Zookeeper fourni un framework pour coordonner des processus distribues.
Donc je vois comment on pourrait le mettre dans la categorie "infrastructure", mais tout de meme pas au meme niveau que chef/puppet
Dans les clones de BigTable, on pourrait rajouter Apache Accumulo qui a ete developpe par la NSA puis soumis recemment pour incubation a la fondation Apache.
Dans la categorie des moteurs d'indexation et de recherche, il existe aussi blur. Voir http://www.blur.io/
Sinon il manque Hue qui sert d'interface web pour les utilisateurs (lancer des jobs, requetes Hive, pig…), Apache Hive, Apache Pig, Apache sqoop pour pouvoir transferer les donees depuis des bases de donnees vers Apache HAdoop, Apache Oozie pour la coordination de workflow, Apache Whirr pour la creation de clusters dans le cloud et Apache Bigtop (en incubation) qui sert de point d'integration a tous ces projets BigData centres sur Apache Hadoop en fournissant les choses suivantes :
[^] # Re: Base de données Logiciel libre et Big Data
Posté par Paf . Évalué à 2.
A rajouter dans la liste: Apache Gora http://gora.apache.org/
[^] # Re: Base de données Logiciel libre et Big Data
Posté par Paf . Évalué à 1.
Pas vraiment a propos du document, mais a noter aussi la premiere reunion du groupe d'utilisateur d'Apache Hadoop France a Paris demain:
http://fr.amiando.com/GETAYVM.html?page=696595
# Proposition de traduction
Posté par Papey . Évalué à 2.
Puisque personne ne semble s'y être risqué…
Je propose de traduire « Big Data » par « Méga-Donnée(s) ».
Voilou.
[^] # Re: Proposition de traduction
Posté par JEANPOL_PARLFOR . Évalué à -2.
Pourquoi vouloir traduire ? Le terme big data se suffit à lui-même, et il est compréhensible par tout un chacun.
[^] # Re: Proposition de traduction
Posté par Papey . Évalué à 3. Dernière modification le 16 mars 2012 à 23:30.
Cela pose plusieurs problèmes.
Garder le terme anglo-saxon équivaut à renoncer à acclimater le concept à notre culture propre, inscrite dans le « génie » de notre langue au fil des siècles. Quand le nombre de termes importés tels quels reste limité, ce n'est pas vraiment un problème. Quand celui-ci se multiplie, comme c'est le cas avec l'anglais, c'est au final la culture française/francophone qui doit s'effacer point à point face aux concepts anglo-saxons, certes porteurs de sens dans leur langue d'origine mais manifestement pas dans la nôtre. Cela crée fil du temps un ensemble inhomogène, une mosaïque de plus en plus difficile à assimiler, créatrice de tensions voire de souffrance à plus long terme, en plus d'être inefficace car moins « parlante ».
C'est enfin une question d'indépendance terminologique, dont dépend en partie la souveraineté politique (au sens large) in fine. Qui ne maîtrise plus une partie de son vocabulaire ne maîtrise plus les idées afférentes (comme on l'a vu), et ne peut plus faire ses propres choix en toute indépendance.
[^] # Re: Proposition de traduction
Posté par JEANPOL_PARLFOR . Évalué à -2.
WTF?!
[^] # Re: Proposition de traduction
Posté par Paf . Évalué à 1. Dernière modification le 17 mars 2012 à 12:59.
Sauf que maintenant les marketeux commencent à parler d'eXXXtriiiime data.
D'ailleurs le terme "données extrêmes" sonne mieux!
[^] # Re: Proposition de traduction
Posté par Papey . Évalué à 1.
Effectivement ça sonne pas mal du tout !
[^] # Re: Proposition de traduction
Posté par Benoît Sibaud (site web personnel) . Évalué à 2. Dernière modification le 17 mars 2012 à 14:35.
Utiliser le préfixe « méga » serait une erreur, pour décrire des volumes largement supérieurs au méga (1 M) justement. J'aurais bien proposé le préfixe saypa- qui indiquerait plus justement la difficulté à traiter ces volumes.
On parle par ailleurs d'obésité informationnelle ou infobésité, pour évoquer la surcharge d'information.
Données abondantes, colossales, considérables, cyclopéennes, démesurées, énormes, excessives, gigantesques, grosses, immenses, i(nco)mmensurables, imposantes, infinies, interminables, monstrueuses, rondelettes, titanesques, vastes ?
[^] # Re: Proposition de traduction
Posté par Stefane Fermigier (site web personnel) . Évalué à 2.
On utilise souvent en français l'expression "déluge de données". Je l'ai casée dans le doc (je crois, de mémoire).
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Proposition de traduction
Posté par Papey . Évalué à 1.
J'ai pertinenté mais ça sonne un peu bizarre je trouve. Je ne me vois pas dire "on va passer en architecture déluge de données" mais c'est peut-être juste une question d'habitude.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.