Big Data : hors Hadoop, point de salut

Le monde des moteurs de traitement de données de type Big Data a déjà bien changé, depuis ses récents débuts. Il y a peu, celui-ci était globalement scindé en deux. D’un côté, les moteurs spécialisés qui offrent une optimisation maximale, via une structuration et un stockage des données en colonnes par exemple, et permettent des requêtes analytiques ensemblistes propices aux applications de type décisionnel. Ce sont les « coupés sport » de la base de données, composés d’acteurs tels que Sybase IQ, Vertica, Infobright, Vectorwize, Calpont… De l’autre côté, les moteurs de traitement de données de type Appliance MPP (Massive Parallel Procesing) qui sont davantage adaptés aux grands datawarehouses d’entreprise pour des usages aussi bien transverses que métiers (EDW). Ils centralisent le patrimoine d’informations de l’entreprise et autorisent une organisation des données relativement souple. Ce sont les « semi-remorques » de la base de données, certes plus puissants, mais moins abordables que les moteurs spécialisés. S’y côtoient Teradata, Oracle (Exadata), ou encore IBM (Netezza).

Mais voilà. Si ces deux approches répondent à des usages bien réels, elles peinent à traiter la jungle des données structurées et non structurées désormais produites : commentaires sur réseaux sociaux, mobilité, machine-to-machine, trafic web… Stratégique pour l’entreprise, cette masse croissante d’informations recèle une réelle valeur économique, mais dépasse très largement la capacité des moteurs de traitement traditionnels. Autrement dit, ces derniers ne sont déjà plus adaptés à la gestion intensive de pétaoctets de données. C’est là qu’interviennent les frameworks de type Map Reduce, dont l’approche consiste à explorer, puis à révéler des données chaudes, brutes et potentiellement non structurées. Au prix d’une moindre performance par CPU et d’une relative inertie dans les traitements, la quantité de données traitables est ici démultipliée à l’infini (cf. schéma 1), comme une motrice dont on pourrait accrocher autant de wagons qu’on le souhaite.

Ce nouveau monde est bien différent des deux précédents. Alors que plusieurs éditeurs se partagent historiquement le marché des moteurs de traitement de données de type SGBD, Hadoop s’impose d’ores et déjà comme le principal et incontournable moteur de type Map Reduce. Rappel des faits. En 2008, Google publie l’algorithme de son Framework Map Reduce, dont Yahoo propose un clone Open source. Hadoop est né. Ce moteur, qui fonctionne sur un système de fichiers répartis sur plusieurs machines physiques (HDFS), reprend les grands principes de l’algorithme Map Reduce en java. Très rapidement, cette plateforme fédère un conglomérat d’acteurs divers animés depuis 2009 par la Fondation Apache. Ces derniers l’enrichissent et créent un écosystème complet en ajoutant chacun à leur tour de nouvelles briques. Si Hortonworks, spinoff de Yahoo et Cloudera sont parmi les éditeurs les plus actifs pour enrichir l’écosystème Hadoop (Flume, Scoop, ZooKeeper etc.), ils sont loin d’être les seuls. Pour masquer la relative complexité de l’univers Map Reduce et rendre ce dernier encore plus facile d’accès, Facebook a développé Hive, qui permet d’interroger un cluster Hadoop directement en SQL, quand Pig, autre langage de requêtage de haut niveau, est proposé par Yahoo. Il faut souligner que la liste de ces contributeurs ne cesse de s’allonger (eBay, Twitter, etc.).

Même si Hadoop n’était peut-être pas initialement la technologie la plus performante, son environnement se développe tellement rapidement qu’aucun acteur privé ne semble en mesure d’aligner seul les ressources en R&D nécessaires pour contrer cette dynamique. Résultat, la déferlante Hadoop a étouffé toute velléité de concurrence propriétaire, devenant hégémonique en à peine 4 ans d’existence. Microsoft a même fini par troquer sa technologie propriétaire Windows HPC Server (abandonnée en novembre dernier) contre une solution « Hadoop native » sur Windows Azure, tandis que la technologie Map Reduce développé par Aster Data, racheté (trop tôt ?) par Teradata, n’a eu pas le temps de percer. A l’inverse, Amazon Web Services (AWS) a bâti son offre de Big Data sur le moteur Hadoop proposé en mode On Demand tandis que Oracle installe Cloudera au cœur de sa Big Data Appliance. Finalement, il ne reste plus aux éditeurs qu’un rôle d’assemblage de briques complémentaires (administration, monitoring, sécurité…) sommées d’interagir autour du même noyau Hadoop (cf. schéma 2), à l’instar du modèle économique d’un Red Hat dans l’univers Linux.

Il aura donc fallu attendre l’avènement du Big Data pour voir des éditeurs traditionnellement aussi propriétaires que Microsoft, Oracle ou IBM bâtir des distributions autour d’un cœur en open source. Autrement dit, Hadoop a réussi sur le même modèle que Linux : hégémonie d’une technologie ouverte. Ce constat est lourd de conséquences, pour les éditeurs, désormais obligés de partager la valeur avec leurs clients. Il l’est aussi pour les utilisateurs, qui peuvent accéder au moindre coût à des technologies complexes et avant-gardistes, avec des ROI démultipliés par rapport aux projets habituels. La voilà, la grande nouveauté : Hadoop a permis de déverrouiller le marché du Big Data dès sa genèse et le rendre accessible à tous, des grands groupes jusqu’aux TPE. Un constat qui aurait été impossible avec des outils purement propriétaires. Ce n’est pas la moindre de ses conséquences.