© Ben Chams - Fotolia.com
S’il y a un secteur qui m’intéresse en ce moment, c’est celui du traitement de données en masse, ce que l’on appelle « BigData » en Anglais. Comme le disait Antonio Goncalves lors de sa keynote du Jug Summer camp 2011 : nous créons chaque jour un volume important de données, bien plus qu’il y a 10 ans et bien plus que nous n’avons jamais créé dans l’histoire de l’humanité.
The McKinsey Global Institute estimates that data volume is growing 40 percent per year, and will grow 44-fold between 2009 and 2020 (source: big-data-strategy-guide-1536569.pdf).
Chaque jour, Facebook ou Twitter par exemple créent d’énormes quantités d’information. Chaque jour, dans la finance, nous créons d’énormes volumes d’informations financières qu’il faut traiter. Chaque jour qui passe, c’est plusieurs Gogol de données en plus. Et la clé, c’est d’être capable de créer une entreprise qui valorise de la donnée, dans un secteur particulier.
Un des facteurs de compétitivité pour les entreprises de demain sera la capacité à valoriser les données créés. Le métier de demain c’est mineur de données d’entreprise, psychologue des réseaux sociaux, analyste financier dans le cloud, réparateur de données financières, expert-comptable big data… Bref des métiers qui auront besoin d’une infrastructure dans l’entreprise qui réponde à ce besoin.
Nous nous emballons pour l’open-data dans le public. Et si demain nous pensions à l’open-data dans l’entreprise ? Pourquoi le jeune stagiaire ne pourrait-il pas coder une solution d’analyse du risque financier sur les données de votre entreprise ? Pourquoi l’expert comptable ne pourrait-il pas naviguer dans les états des ventes d’il y a 5 ans comme dans celui de la semaine passée ? A qui appartient cette donnée ? Votre ficher client, votre état comptable et les logs de vos serveurs webs pourraient devenir magiquement un moyen de créer de la valeur. Rêvons un peu à des outils pour que toutes les données d’une entreprise soient facilement accessibles… Autant je ne crois pas au réseau social en entreprise, autant je crois au stagiaire qui te code en 3 mois LA solution que l’équipe d’architecture n’arrive pas à pondre depuis un an.
Quelque chose qui semble acquis, c’est que nos systèmes d’informations ont une durée de vie limitée. Imaginez la date limite de consomation de votre yahourt, remplacez-là par votre S.I, vous y êtes… votre belle machine va coûter de plus en plus cher à maintenir, tout en continuant à créer chaque jour de la donnée. Les petites rivières créent les grands fleuves. Etes-vous capable aujourd’hui de valoriser l’information que produit votre système d’information ?
Les systèmes d’informations doivent s’adapter. C’est pour cela que ces dernières années nous avons vu l’émergence de nouveaux produits, venus des grands du Web. Quelque part, cruellement, nous avons le sentiment que les éditeurs classiques ne suivent pas. Pour votre startup qui démarre demain, est-ce que vous prenez une base Oracle ou est-ce que vous regardez du côté de MongoDB, Hadoop, Cassandra et consors ? Pour votre nouvelle architecture de calcul du risque dans la finance, est-ce que vous utilisez une base Oracle ?
L’innovation dans ce domaine vient des grands du web : Google, Facebook, Amazon par exemple. Toutes ces solutions sont open-sources, car le métier de Facebook n’est pas de vous vendre une base de données, mais de la donnée. Oracle vend peut-être encore des boîtes avec des DVD, avec des licences annuelles ou calculées sur le nombre d’utilisateurs…. Mais cela semble assez décalé lorsque l’on regarde ce qu’il se passe dans le monde du NoSQL.
Ce qui sera critique demain pour nous, informaticien, c’est d’être capable d’absorber et de valoriser ces énormes volumes de données. Côté architecture, si vous allez voir du côté « Big Data », il y a de nouveaux territoires à explorer. Il y a aujourd’hui de très belles opportunités techniques et professionnelles pour celui qui s’intéresse à ces technologies. Les différentes solutions demandent un temps d’apprentissage, mais un développeur qui ne connaît pas MongoDB, Redis, Cassandra ou Hadoop ne pourra pas venir travailler dans ces territoires.
Les éditeurs historiques ne sont pas tous à la traine et il ne faut sous-estimer Oracle. La difficulté aujourd’hui est d’agréger différents formats de données, de conserver une solution qui permettra de relire ses données dans 3 ou 4 ans, et de les traiter. Ol ne faut pas cependant sous-estimer les éditeurs classiques comme IBM ou Oracle. De par leur culture d’entreprise, je pense qu’ils sont plus adapté à résoudre des problèmes d’un SI. En même temps, en tant que développeur, je pense qu’il existe de bonnes solutions alternatives dans le monde de l’open-source, et qui font leurs preuves. Bref, si l’éditeur classique séduit le DSI, le monde de l’open-source séduit le développeur. Et il faudra cohabiter et trouver une approche globale. Nous aurons très certainement une base NosQL Oracle et une base MongoDB dans notre projet demain.
Oracle est aujourd’hui un fournisseur complet de solution. De la machine jusqu’au logiciel. Vous pouvez très bien acheter un « Oracle Big Data Appliance » au supermarché. Il s’agit d’une solution complète composée de serveurs physiques et de logiciels avec Hadoop, base nosql et de belles machines. Bref un système « clé en main » pour DSI. Mais encore une fois, est-ce que l’idée d’acheter une machine physique n’est pas un peu décalée à moyen-long terme pour une DSI ? Bon j’exagère et j’ai bien conscience que c’est complètement adapté à l’approche actuelle.
Les messages les plus importants à retenir pour le développeur :
- il y a des opportunités professionnelles dans le monde des startups autour du Big Data
- si vous voulez vous frotter à des problèmes d’architecture des grands du web dès lundi dans votre projet : c’est possible
- le volume de données créé par une entreprise est en constante augmentation
- valoriser de la donnée ouvre la porte à de nouvelles opportunités dans l’entreprise
- il existe des outils open-source pour traiter ces données, éprouvés par les grands du web comme Google, Amazon, LinkedIn ou Facebook
- Un éditeur comme Oracle propose des solutions complètes et se positionne sur ce secteur
A suivre donc.
0 no like
Voilà un débat ouvert. Sur BigData, je trouve qu’on est entre réalité et vaporware. Il y a quelques années, je faisais très attention à soigner les données et le code. Plus tard, malgré le fait que je fasse toujours très attention au code, mon discours a été de dire que seules les données resteraient et que les applis devaient être considérées comme jetables. A présent, j’ai le sentiment qu’on est en passe de sacrifier la qualité des données elle-même. Tous les efforts faits pour avoir des contenus cohérentes volent en éclat au fur et à mesure qu’on construit des systèmes sur-distribués. Le concept de transaction se ringardise pour n’être plus qu’un « truc à papa ». Alors on en est où finalement? Finalement, je pense qu’on est en rendu à accepter d’avoir des applis et des données de moindre qualité en regard à leur durée de vie limitée. Les entreprises naissent, fusionnent ou meurent rapidement. Leur SI doivent se construire vite. OK, je prends note et j’accepte en trouvant les meilleurs solutions à ce paradigme. Sauf que tout le monde se fichent de la déconstruction. Je n’ai pas encore vu de projet d’entreprise de purge des données périmées. On laisse même des applis tourner sur des serveurs oubliés. De toute façon, ça semble coûter moins cher de rajouter des disques durs. So what? Il faudrait laisser faire? Je ne suis pas d’accord. Je me hisse en jardinier du SI et j’entretiens mon parc d’applis. Je ramasse les feuilles mortes, coupe des branches et taille les haies de données. C’est comme cela que je vois un beau SI. Alors rebellez vous et faites comme moi : ayez la main verte. Faites du BigData si ça vous chante mais, par pitié, ne laissez pas pourrir vos données.
Je me mets du côté d’Alexandre sur ce point. L’avantage des bases de données relationnelles est la consistance des données : aucune donnée ne peut être insérée si elle ne respecte pas les règles définies à la création de la base, on a ainsi une base propre et des données complètes.
Je n’ai pas encore réellement expérimenté les bases NoSQL mais j’ai un peu l’impression qu’on y stocke tout et n’importe quoi. Toutes les vérifications de consistances se font donc dans les applications ?
@Alexandre
nous partageons le même ressenti et vécu mais contrairement à toi je reste super optimiste.
Le responsable technique foufou
* qui s’emballera trop vite pour du NoSql pour de mauvaises raisons,
* qui à la première montée en charge ou au premier process ne prenant pas soin de manipuler les données avec coherence, … se fera virer à cause des conséquences néfastes de son choix, de son laxisme, de sa bétise.
Il sera ensuite bien content de ré utiliser la transaction a papi et de devoir respecter les contraintes imposées par la bdd relationnelle.
Comme toi je redoute le choix de telles technos pour tout simplement aller plus vite et ne pas devoir trop réfléchir… ça ne durera qu’un temps.
@Chafik
C’est tout le problème d’utiliser NoSql c’est que la cohérence des données est censée être prise en charge par le code…
Il se *peut* qu’elle ne soit pas implémentée du tout ou même pas bien implémentée,
C’est un problème lorsque l’on créé une appli mais ça devient un cauchemar lors de la maintenance. Si tes structures de données évoluent, s’ajoutent, s’agrègent et que c’est la valse des développeurs, ça ne peut être que la catastrophe.
Et on ne parle ici que de l’aspect cohérence, quid des écritures en accès concurrent sur des données sensibles…
Comme Alexandre j’observe une tendance à l’écriture d’applis poubelles que l’on préférera ré écrire plutôt que d’écrire correctement pour en permettre la maintenance et l’évolution, c’est un choix, beaucoup de paramètres entrent en jeu. Pas si simple à critiquer.
Ok donc le couplage entre les applications et la base de données sont très forts. Si on développe une application web par exemple qui interroge une base de données NoSQL, et son équivalent sur mobile par exemple (interrogeant la même base de données) on écrit le code de vérification deux fois ? :/
L’idée serait peut-être de créer une couche supplémentaire entre l’application et la base NoSQL vérifiant la cohérence des données et comme tu l’as dit l’accès concurrent ?
Il faut aussi évoquer un autre problème: la plupart des solutions NOSQL ne proposent pas de fonctionnalités équivalentes aux jointures que l’on trouve en relationnel. Cela nous conduit à dupliquer nos données si l’on souhaite pouvoir les récupérer sans qu’il soit nécessaire de lancer une tonne de requêtes. La pertinence de la structure de données est donc fonction des requêtes qu’on exécute. Et il semble que la mesure de cette pertinence soit difficile à établir: j’ai récemment assisté à une présentation de Cassandra au cours de laquelle un des intervenants nous apprenait qu’il avait fallu 6 mois de travail à une équipe de développement pour stabiliser sa structure de données. J’espère pour eux que leur application ne sera pas amené à évoluer trop rapidement…
perso, l’annonce recente de F1 par google me semble prometteuse.
Avantage, elle promet de reunir le meilleur des deux mondes. Apres l’introduction de mysql pour gae et maintenant F1, il semble y avoir des googlers préocupés par les transactions et coherence des donnees.
Inconvenient, F1 sera t’il uniquement disponible sur leur cloud?
@benoit: « The strong consistency properties of F1 and its storage system come at the cost of higher write latencies compared to MySQL »
http://research.google.com/pubs/pub38125.html
les avantages de F1 viennent avec des inconvenients, toujours pas de silver bullet !