Le Big Data dans un grand groupe : des chantiers gigantesques et interminables
A l’occasion du salon Dataworks Summit qui se tenait courant avril à Munich pour réunir la communauté Hadoop, LeMagIT a recueilli des témoignages portant sur le déploiement de projets Big Data. Réussis ou pas, ces projets livrent des expériences de terrain disparates. Aujourd’hui, le témoignage de Pierre Sauvage, ingénieur Big Data sous l’étiquette de l’ESN Adaltas, en mission chez un géant énergétique français.
Pierre Sauvage, ingénieur Big Data sous l’étiquette de l’ESN Adaltas, est en mission chez un géant énergétique français. Il l’accompagne depuis 3 ans dans la mise au point et la maintenance d’un cluster Hadoop géant dédié au Big Data. A l’image de plusieurs autres grands groupes français (Renault, Société Générale...), il a en effet été décidé ici de construire un datalake immense où affluent les données d’absolument toutes les directions métier.
Big Data : un chantier géant, par défaut
« La difficulté du Big Data dans un grand groupe, c’est la décision d’en faire un chantier pharaonique. D’ordinaire, un projet Big Data, c’est mettre cinq ou six machines en cluster pour faire un datalake qui va servir de moteur à un, voire deux, cas d’usage. Dans le grand groupe pour lequel je travaille, il a été décidé de mettre 150 machines en cluster pour mutualiser les milliers de bases de données Oracle ou PostgreSQL de dizaines de départements qui ne se sont jamais parlé. C’est excessivement long : cela fait trois ans que nous ne faisons que de la mise en place.
« Le problème n’est pas tellement technique. Il est surtout qu’il faut aller voir des gens qui ont de l’autorité sur des données pour leur dire que c’est fini, que leurs données seront désormais dans un pot commun. Spontanément, ils refusent. Mais il faut les comprendre : cela fait 30 ans qu’on leur dit qu’ils doivent siloter les données pour les protéger... Pour les convaincre, il faut faire des réunions à n’en plus finir. Et, ça, ça prend réellement des années. »
Comment gérer les mises à jour dans de très longs chantiers
« Sur des périodes aussi longues, se pose la question des mises à jour logicielles qui paraissent régulièrement. Chez nous, la décision a été prise de coller à chaque fois aux dernières versions. Mais, dans les faits, nous mettons 6 mois pour les déployer, à cause des tests de comptabilité qu’il faut refaire à chaque fois et qui prennent des semaines. Il faut considérer que sur un datalake mutuel, la moindre mise à jour impacte tout le monde. Cela fait donc une grande quantité de tests à mener, si ce n’est d’utilisateurs à convaincre de les mener encore et encore.
« Les nouvelles versions compliquent elles-mêmes un peu plus la donne. Il y a celles dont on n’attend pas grand-chose, comme le nouveau HDP 2.6 d’Hortonworks qui reste du Hadoop 2 avec des améliorations à la marge. Et il y a celles dont on se demande si elles ne vont nous obliger à tout refaire ; en l’occurrence le prochain Hadoop 3 pourrait soit converger avec les techniques des containers, soit pas du tout. Nous avons du mal à savoir dans quelle direction technique nous projeter.
« Dans les grands groupes, on se sert du Big Data pour faire des chantiers pharaoniques et c’est interminable »
Faire du Big Data…parce que ça existe
« Globalement, on met en place du Big Data mais on ne sait pas ce qu’on y cherche. On espère que des gens qui vendent de l’énergie à l’international vont corréler leurs données avec ceux qui en vendent aux ménages français, ou encore que ceux qui sont les seuls à disposer de certaines informations (météo...) les partageront désormais avec tout le monde. La vérité, c’est que nous passons au Big Data parce que la technologie est disponible.
Un manque d’outillage
« Ce qui manque au Big Data, c’est un outillage qui en fasse une application orientée décideurs. Il est temps de porter le débat au-delà d’Hadoop. Il faut vraiment que la communauté s’intéresse à l’intégration du Big Data avec les outils de BI. Le problème n’est pas tant d’adapter un logiciel classique comme Tableau au Big Data, il est plutôt de définir des points d’ancrage dans Hadoop sur lesquels on pourra brancher n’importe quel outil de BI, sans avoir besoin de développer à chaque fois des connecteurs d’appoint. Et, dès lors, tous les projets iront beaucoup plus vite, y compris dans les grands groupes. »
