Par Yann Carpentier-Gregson, Practice Manager « Data Architectures » chez Umanis
Les plateformes Hadoop ont paru longtemps incontournables dans la mise en place de projets Big Data, mais il ne s’agit pas toujours de la meilleure solution pour répondre aux besoins de chaque métier de l’entreprise.
S’il ne fait plus aucun doute que les entreprises ont désormais l’obligation d’exploiter leurs données pour assurer leur croissance, voire leur survie, la mise en œuvre d’un tel chantier est en revanche complexe. L’objectif premier est en effet de parvenir à maîtriser les données brutes de l’entreprise pour en tirer de l’information.
Ces dernières années ont ainsi vu naître un boom des projets Big Data, renforcé plus récemment par les chantiers liés à l’IA. Des plateformes Big Data ont donc été déployées massivement dans les entreprises, toutes étant liées pour des raisons historiques à la technologie Hadoop. Mais alors que celles-ci constituaient à une époque le prérequis technologique nécessaire, ce n’est plus du tout vrai aujourd’hui.
Des plateformes Hadoop omniprésentes mais souvent inadaptées
Si les plateformes Hadoop peuvent différer en termes de taille de nœuds et d’usage selon les organisations, on constate toutefois qu’une seule plateforme de production est souvent utilisée pour toute l’entreprise.
Cela s’explique en premier lieu par le fait qu’une plateforme n’est efficiente qu’à partir d’une dizaine de nœuds, entraînant un besoin de mutualisation des usages et donc une rationalisation des coûts. Par ailleurs, étant donné la complexité technique des plateformes et leur spécificité, la DSI, qui porte le plus souvent les projets Big Data, a tendance à déployer ces outils selon un modèle architectural global. Enfin, de nombreuses entreprises optent pour des plateformes Big Data uniques car elles ne réfléchissent pas au préalable aux usages applicables à leur business model, cédant parfois aux mirages de la mode.
Les plateformes Hadoop se sont donc généralisées mais elles n’en souffrent pas moins d’inconvénients importants :
- Complexité d’exploitation : étant constituées par l’agrégation de composants Hadoop liés par la surcouche d’un éditeur, auxquels s’ajoutent des frameworks entreprise, une dépendance aux technologies Java et Linux et des clusters souvent déployés sur des machines virtualisées, il est difficile d’assurer une cohérence d’ensemble de ces plateformes au fil des mises à jour.
- Faible retour sur investissement : 60% des projets Big Data ne dépassent pas le stade de l’étude ou du POC tandis que parmi les 40% déployés, seul un tiers dégage un ROI positif. L’origine du problème est à trouver du côté de la gouvernance, des projets d’une part, lors de l’industrialisation des modèles de Data Science sur la plateforme de production, et des données d’autre part, par manque de connaissance du patrimoine informationnel de l’entreprise et des méthodes pour les rendre exploitables.
- Manque d’agilité : plus une plateforme rencontre le succès dans l’entreprise, moins son usage devient souple, du fait de la nécessité de valider une mise à jour pour l’ensemble des traitements exploités sur le cluster. De plus, ces différents traitements n’ayant pas les mêmes besoins en termes de configuration selon leur consommation de mémoire ou de CPU, un cluster agnostique n’est optimal pour personne et la plateforme mal ou sous-exploitée.
Le marché des plateformes Hadoop est dominé depuis plusieurs années par deux éditeurs majeurs ayant récemment fusionnés, Cloudera et Hortonworks, la place des autres acteurs demeurant anecdotique, comme MapR qui a failli disparaître avant d’être racheté par HP. Ces mouvements sur le marché ne sont pas sans lien avec l’arrivée d’éditeurs plus généralistes sur le terrain du Big Data.
De nouvelles solutions aux usages spécifiques
La plupart des utilisateurs des distributions Hadoop packagées se sont rendus compte qu’ils n’avaient pas besoin de l’intégralité des services qu’elles proposent. Ces solutions ont effectivement été conçues par des experts pour des experts, alors que les utilisateurs de la donnée sont potentiellement tous les acteurs de l’entreprise. Si on ajoute à cela des investissements lourds et un ROI rarement atteint, l’heure est aujourd’hui à la rationalisation technologique.
Pour faire face aux inconvénients constatés à l’usage des plateformes Hadoop, les fournisseurs de solutions cloud se sont mis à proposer des services spécialisés permettant d’assembler des plateformes dédiées répondant chacune à un usage particulier. On peut citer par exemple :
- Le stockage de volumes importants de données avec de bonnes performances d’entrées/sorties (Azure Datalake Store, AWS S3, Google Cloud Storage…)
- Des capacités de calcul à mise en place rapide et ajustables (AWS EC2, K8S…)
- Des outils de Business Intelligence (BI) dédiés au Big Data (Redshift, Azure Synapse, Snowflake, BigQuery…)
- Des outils d’ingestion, transformation et modélisation haute vélocité (Databricks…)
- Des plateformes Hadoop louées en mode cloud (HD Insight, EMR…)
Ces solutions offrent ainsi des parties spécifiques de services proposées par les plateformes Hadoop traditionnelles, mais sans leur complexité d’administration. Si les performances brutes s’en voient amoindries, les avantages sont nombreux : simplicité d’usage et rapidité de prise en main propres aux services managés en cloud, coûts rationalisés à l’utilisation des services utilisés uniquement, meilleure agilité et maîtrise par les équipes IT.
Les clusters Hadoop ont ainsi perdu leur domination sur les technologies Big Data, d’autant que certains produits « on premises » (SQL Server, Oracle…) ont comblé également leur retard dans le domaine.
Le revers de la médaille du SaaS
Les solutions Data déployées en mode cloud ayant maintenant atteint une certaine maturité, il est possible de tirer quelques enseignements de leur mise en œuvre :
- Simples à utiliser, difficiles à intégrer : bien que les nouveaux outils aient permis un gain de temps et d’énergie non négligeable dans le démarrage de nouveaux projets, leur intégration dans un SI sécurisé ainsi que leur interopérabilité sont parfois problématiques.
- Des coûts parfois imprévisibles : très peu d’acteurs sont formés au pilotage financier des plateformes cloud, et le rôle de FinOps est souvent ignoré ou limité à l’ajustement des charges de production. Il n’est pas rare de trouver des plateformes qui ont consommé dès l’été leur budget annuel.
- Un affaiblissement de la propriété des données : tout est fait par les éditeurs pour attirer les usages sur leur plateforme et les y faire rester. Rares sont les outils compatibles sur plusieurs plateformes et le retour des données dans les datacenters « traditionnels » reste très cher à mettre en place. De plus, la sécurisation de ce type de plateforme est beaucoup plus complexe et les fuites de données ne sont pas rares.
- Peu d’expertise sur le marché : ces outils sont relativement récents et les ingénieurs capables de les utiliser correctement sont rares. Face à la pénurie de ressources, de nombreuses personnes se lancent vers ces technologies sans avoir le niveau de formation requis, ce qui impacte le ROI des plateformes : budgets de développement et d’exploitation beaucoup plus importants, stabilité de la production plus faible…
Face à ces problématiques, des réflexions sont menées pour trouver un juste équilibre entre d’une part la souplesse et l’agilité des services cloud et d’autre part la stabilité, la robustesse et la sécurité (technique et financière) des solutions « on premises ».
Adapter les outils Big Data aux besoins des métiers plutôt que l’inverse
Avant de choisir ses outils technologiques, le plus important demeure d’établir une stratégie Big Data claire et adaptée à ses propres besoins. Celle-ci peut s’établir selon 4 principes :
- Les usages métiers priment sur la technologie : en gardant en tête le « pourquoi » d’un projet, on évite de choisir des plateformes déconnectées du métier de l’entreprise. Il est alors plus logique de trouver « comment » le faire, plutôt que de chercher des cas d’usage qui justifient une plateforme existante.
- Des services spécialisés et réactifs plutôt que des monolithes mutualisés : pour que les projets Big Data réussissent, la DSI se doit de fournir un service adapté à chaque besoin, également en termes de roadmap et de time to market. Au risque de voir les métiers avancer sans elles et développer du shadow IT.
- Une gouvernance transverse plutôt que des initiatives en silos : il n’est pas non plus idéal que chaque métier dispose de sa propre plateforme. Il est important de garantir une bonne communication entre les acteurs autour de la donnée de l’entreprise (IT, métiers, CDO, RSSI…) afin de trouver un équilibre entre la souplesse nécessaire aux métiers et la stratégie globale de l’entreprise.
- Un pilotage fluide plutôt qu’une stratégie unidirectionnelle : les technologies évoluent de plus en plus rapidement, tout comme les changements stratégiques des éditeurs. Il est donc nécessaire de maintenir une veille constante sur toutes les activités autour de la donnée et d’intégrer ce qui doit l’être dans la stratégie data de l’entreprise.
Ces principes paraissent limpides, mais leur mise en œuvre peut se révéler complexe dans de nombreux contextes. Comme il n’existe pas de solutions miracles pour résoudre toutes les problématiques, il est essentiel de se faire accompagner pour disposer d’expérience en termes de pilotage, d’expertise technologique et de conduite du changement.
C’est grâce à cela que la mise en œuvre de la stratégie Big Data sera conforme aux attentes et que l’entreprise pourra tirer toute la valeur de son patrimoine informationnel.
