Plateformes Big Data prêtes à l’emploi : mythes et réalités

Les promesses des fournisseurs nord-américains de cloud public pour pallier ce problème se heurtent aux risques de perte de contrôle des données et de l’infrastructure. Pour se sortir de l’ornière, c’est une rupture totale avec l’architecture classique Hadoop qu’il s’agit d’opérer.

Transformer de la donnée brute plus ou moins structurée et multi-sources en informations utiles : les enjeux de la Big Data sont connus, inutile de revenir dessus. Derrière les aspects métiers, la Big Data est également (et intrinsèquement) un projet IT : extraction, collecte, structuration, traitement et analyses de données. Sans compter qu’il faut également gérer les environnements de développement et de production sous-jacents à tout projet Big Data. Et c’est bien souvent sur ces aspects-là que le bât blesse.

La gestion de la plateforme technologique, véritable enjeu de la Big Data ?

Concrètement, et de façon schématique, un projet Big Data repose sur trois étapes : l’extraction, le nettoyage et le chargement de la donnée tout d’abord, via une brique intermédiaire baptisée ETL (Extract, Transform & Load). Le traitement et l’analyse des données recueillies ensuite, ce qui constitue le cœur du projet, avec une parallélisation massive pour traiter le plus grand nombre de données le plus efficacement possible. Cette brique, généralement conçue autour de l’écosystème Hadoop, accueille notamment les outils de machine learning, d’IA, etc. La dernière étape consiste à stocker les résultats pour qu’ils soient exploitables par des outils métiers (via des outils de visualisation de données ou de reporting) ou des machines (fichiers, informations déversées dans une base de données, etc.). Cette dernière étape est l’aboutissement du projet : elle permet la restitution des données valorisées et doit répondre aux objectifs métier fixés initialement.

Si la brique ETL est généralement bien maîtrisée par les data scientists, c’est en revanche la gestion de la plateforme Big Data qui peut devenir très rapidement problématique pour les DSI. En effet, les compétences sur ces environnements sont assez éloignées de celles liées à l’exploitation des infrastructures et technologies traditionnellement déployées dans les systèmes d’information des organisations. 

Ce que l’on appelle le DataOps, soit le maintien en condition opérationnelle de l’écosystème Hadoop, et notamment le système de fichiers distribués HDFS (Hadoop Distributed File System), est un véritable casse-tête pour les DSI : la montée en compétences internes est chronophage, continue et coûteuse en ressources. Sans compter que les référentiels de sécurité pour ce type de projets sont aussi bien souvent très différents des pratiques courantes des DSI. Si bien que le recours à une tierce maintenance applicative est fréquent, ce qui peut faire doubler voire tripler le budget initial du projet. 

Ces freins technologiques, et surtout financiers, ont participé à donner aux projets Big Data une réputation équivoque, mêlant complexité, coûts exorbitants et donnant des résultats difficiles à valoriser, auprès des directions générales comme des métiers eux-mêmes. En d’autres termes, c’est en se délivrant des contraintes technologiques qu’un projet Big Data a le plus de chances d’aboutir et de rendre le service qu’on attend de lui : apporter de la valeur informationnelle aux métiers.

Externaliser l’infrastructure Big Data : attention aux fausses promesses

L’une des options possibles, pour lever ces freins au développement des projets Big Data, est d’externaliser la gestion de la plateforme technologique. Ou, autrement dit, de la consommer comme un service afin que la Big Data redevienne ce qu’il n’aurait jamais dû cesser d’être : une démarche métier, sur un socle technologique maîtrisé, offrant aux data scientists les outils pour le développement d’applications à valeur ajoutée au service du métier. 

C’est d’ailleurs toute la promesse des grands fournisseurs de cloud : une plateforme Big Data prête-à-l’emploi. À ceci près qu’elle implique généralement un re-développement et une adaptation dans un langage bien souvent propriétaire, des données portées chez le fournisseur lui-même, et mutualisées. Une sorte d’offre SaaS de la Big Data, avec une perte quasi-totale de contrôle sur les données ou l’infrastructure et donc sans réelle option de réversibilité.

Pour bénéficier de l’externalisation tout en limitant ces risques, c’est plutôt une plateforme Big Data dédiée à l’entreprise qui est à privilégier : dans ce cas, les données, si elles restent externalisées, le sont toutefois dans un espace réservé et demeurent totalement maîtrisées. Une certaine sécurité qui inclut, de fait, un coût récurrent supérieur mais relativement stable, face aux coûts à l’usage des cloud providers, qui peuvent très vite s’envoler. En externalisant de cette façon, l’exploitation quotidienne de l’écosystème Hadoop, et en particulier de HDFS, n’est alors plus un problème. Il est d’ailleurs possible de s’affranchir totalement de ce composant, en dissociant les fonctions de calcul et de stockage de la donnée. Ce qui permet, entre outre, de concilier Big Data et réduction de l’empreinte environnementale.

C’est l’approche que nous avons retenue sur notre plateforme Big Data, que nous vous détaillerons dans un autre billet plus technique très bientôt !