smart solutions for smarter enterprises

Architecture data-centric : du data lake à la data mesh ?

Par Jérôme Besson,  Associé avec la participation de Olivier Armand, Consultant Architecte Expert 

Résumé : La secousse provoquée par la fusion surprise entre Cloudera & Hortonworks traduit un séisme Big Data d’une plus grande ampleur et dont l’épicentre est le cloud.

#Vers une nouvelle architecture data-centric ?

Les besoins Big Data ont évolué. Les entreprises souhaitent plus que jamais se concentrer sur l’exploitation industrielle de toutes les données à leur disposition et s’abstraire de plus en plus des technologies sous-jacentes. Après une 1ère vague d’investissement autour du concept de lac de données, dont elles espéraient monts et merveilles et donc trop, les entreprises doivent aujourd’hui reconsidérer leur architecture de données face à la montée de l’IoT (Interner-Of-Things), de l’AI (Artificial Intelligence) et du Cloud Computing. Trois tendances fortes qui imposent d’être en mesure d’exploiter les données tout le long de la chaine de valeur, là et au moment où elles apparaissent (Edge Data), pendant leur transit (Data-in-motion) et dans leur lieu de dépôt (Data-at-rest).

Pour opérer cette transition de ‘data’ à ‘data flows’ et d’une ‘data gravity’ hybride ’on/off-premise’, les entreprises doivent accepter l’idée que la concentration de toutes les données dans un lac de données centralisé comme pré-requis à leur analyse en masse a vécu et ne peut plus être le seul pattern ‘data centric’ à poursuivre.  Il faut être en mesure de les traiter tout le long du ‘data pipeline’, ‘from edge to core’ et penser architecture distribuée pour leur stockage et leur traitement.

Enfin et non des moindres, les entreprises ne peuvent plus ignorer l’émergence de solutions alternatives à Hadoop, l’écosystème technologique emblématique motorisant la plupart des ‘data lakes on-premise’. Apparu en 2006, à la fois plateforme de stockage polyglotte (HDFS, HBASE) et de traitement parallèle et distribué (Map Reduce), conçu pour fonctionner sur du ‘commodity hardware’ et dans une logique où il vaut mieux amener les traitements aux donnés que le contraire, Hadoop, révolutionnaire à sa sortie et symbole par excellence du Big Data à la portée de toutes les entreprises, fait presque aujourd’hui figure de ‘legacy’.

La fusion surprise entre deux des trois leaders des distributions Hadoop du marché (Cloudera & Hortonworks) est d’ailleurs révélatrice que nous sommes arrivés à un point d’inflexion technique mais aussi économique et dont le principal inducteur de changement peut schématiquement se résumer au Cloud.

Face à cette nouvelle donne et fortes de leurs premiers retours d’expérience contrastées, les entreprises ont besoin de rééclairer leur stratégie Big Data. Et les choix vont être beaucoup plus compliqués et cornéliens qu’auparavant face à une offre plus abondante que jamais et toujours plus ‘cloud first’.

#Data Lake : Un succès pas toujours au rendez-vous, un capital data toujours sous exploité

Les lacs de données activés par les entreprises, souvent ‘on-premise’ et au-dessus de Hadoop, n’ont pas permis de déployer tous les usages envisagés et voient les entreprises en resserrer le champ d’utilisation.

Plusieurs raisons l’expliquent :

  • La complexité et l’effort d’industrialisation malgré la ‘commodization’ apportée par les distributions
  • La lourdeur des infrastructures à déployer, leur management et leur optimisation
  • Le manque de compétences à tout niveau et pas seulement en ‘data science’
  • La sous-estimation de l’effort d’intégration avec le patrimoine existant
  • Le coût de la scalabilité au-delà de certains seuils de performance en particulier liée à l’impossibilité de scaler indépendamment ressources de ‘storage’ et de ‘compute’
  • Un écosystème riche en frameworks de toute sorte pour délivrer la promesse d’être tout à la fois ‘data store’, ‘data hub’, ‘data fabric’ et offrir des fonctions de ‘data management’ avancées
  • Des limites technologiques inhérentes au modèle d’architecture, à ses composants souches et qui ont incité les entreprises à se tourner vers des ‘data shores’ spécialisés SQL et NoSQL, ‘in database’ et ‘in memory’
  • Un principe de stockage de tout donnée sans considération de la valeur immédiate et dont la plupart restent encore sous-exploitées, voire inexploitées (‘dark data’) et dont le coût marginal de stockage finit par ne plus être neutre avec par ailleurs un risque fort de transformer le ‘data lake’ en ‘data swamp’
  • Des cas d’usage orientés de plus en plus ‘data-in-motion’ où il ne convient plus d’analyser des tonnes de ‘data-at-rest’ mais des flux et nuages de données et d’évènements au fil de l’eau, voire au plus près de leur occurrence lorsque les temps ou les coûts de réseaux deviennent prohibitifs
  • Un recours de plus en plus fréquent à l’intelligence artificielle très gourmande en ressource ‘compute’ et qui nécessite une infrastructure et des technologies indépendantes de celles du ‘Data Lake’

#Des ruptures technologiques qui changent la donne

Pour lever ces limites les entreprises ne sont pas restées en reste et ont étiré l’usage de leur plateforme Data au maximum de leur capacité. Pour doper la productivité de leur ‘Data Factory’ et ‘Data Lab’, elles ont intégré ou développé des ‘Data Fabric’ et des studios ou plateformes de ‘Data Science’, boostées leur capacité de ‘Fast Integration’ via des technologies types ‘Change Data Capture’ et de ‘Real Time Pipelining’ avec l’emblématique Kafka. Elles ont séparé leurs chaines de traitement ‘hot data’ (‘speed layer’) et ‘cold data’ (‘batch layer’) en activant des patterns de type ‘lambda’. D’autres ont essayé de les fusionner via des patterns de type ‘kappa‘. Pour préserver leur investissement Hadoop, certaines ont opté pour de l’IaaS (Infrastructure-as-a-services) et porté leur ‘data lake’ dans le cloud. Peu se sont en revanche tournées vers le PaaS (Platform-as-a-service). D’autres enfin ont pris le virage des services managés, abandonnant au passage l’écosystème Hadoop au profit de nouvelles solutions de ‘storage’ et de ‘compute’.

Un choix qui leur a permis d’utiliser des ‘object stores’ autres que HDFS, qui sans offrir toujours la même richesse fonctionnelle s’avère plus performantes (scalabilité, géodistribution, débit entrée/sortie, interopérabilité) et moins chères, dont le fameux S3 ‘Simple Storage Service’ popularisé par AWS. Ce choix leur a également permis via la ‘containerisation’ de pouvoir faire coexister de multiples moteurs de traitement de données hétérogènes ou dans des versions différentes. Enfin, avec le ‘serverless’ elles ont pu accéder à l’ élasticité dynamique et micro-facturée à l’usage les affranchissant totalement des contraintes d’infrastructure, de langage utilisé (Java, Scala, Python, R) et dans une certaine mesure des moteurs d’exécution parallèles et distribués comme Spark.

#Plateforme Data ‘Cloud’ ou ‘on-premise’ ? Packagée ou ‘best-of-breed’ ?

Avec un système d’information qui inexorablement va s’hybrider à un degré plus ou moins important selon l’entreprise, où les Vs du Big Data ne vont pas s’atténuer, où la ‘data gravity’ va se déplacer vers le Cloud, où faire sens des données sur l’ensemble de la ‘data supply chain’ devient la norme, l’entreprise doit de plus en plus être en mesure  de traiter les ‘data-in-motion’ et avoir recours massivement à l’automatisation qu’apporte l’intelligence artificielle.

Sourcer toutes les capacités nécessaires au sein d’une même plateforme ‘Big Data & AI’ généraliste est ambitieux à l’heure du ‘fast & smart data’, où chaque maillon du ‘data pipeline’ doit être optimisé. Et ce, même si les distributions historiques ‘Hadoop’ (MapR, Cloudera+Hortonworks) sont résolument engagées dans la fourniture de plateformes convergées tout à la fois ‘Data to AI’, ‘Edge to Core’ et ‘on-premise & off-premise’ et prônent le multi-clouds, donc l’indépendance et la réversibilité par rapport aux CSPs (Cloud Service Providers).

Pour autant s’en détourner vers des offres Big Data ‘Black Box’ des CSPs apporte aussi son lot de problématiques. Elles questionnent la souveraineté des données et d’intelligence et étendent le risque de « vendor lock-in » sur quasi toute la stack IT (infrastructure & logicielle). Leur richesse rend difficile le décryptage de leur modèle économique avec pour conséquence que les gains en agilité qu’elles procurent peuvent rapidement être annihilés par leurs coûts financiers.

Pour être en mesure de choisir la bonne souche logicielle, s’orienter vers une offre intégrée ‘all-in-one’ où ‘best-of-breed’ impose de définir la ‘data gravity’ actuelle et en tendance de son système d’information.

La déterminer nécessitera de prendre en compte :

  • le degré de cloudification de son système d’information. Plus celui-ci sera élevé moins il deviendra pertinent de les rapatrier ‘on-premise’ pour les traiter
  • la data-ification de ses produits. Si elle déploie de nombreux objets connectés, les flux données passeront de facto par des plateformes IoT Cloud et un traitement qui devra s’opérer à différents niveaux ‘’Edge’, ‘Fog’, ‘Cloud’ et ‘Core’
  • la géographie de ses activités qui pourra interdire de délocaliser certaines données et imposer leur traitement là où elles ont été acquises
  • les cas d’usage data-driven les plus exigeants qui nécessiteront une architecture de données et des technologies particulières

Sa valeur permettra de définir le barycentre ‘on/off premise’ ou hybride de chacune des capacités usuelles que constituent une plateforme ‘data centric’, en particulier les capacités :

  • Data-as-a-Service
  • Bulk & Stream Data Ingestion
  • Data Broadcast & Delivery
  • Parallel & Distributed Computation (Batch & Stream)
  • Data Lake & Shore Object Storage
  • Data Insight & Intelligence
  • Data Management (Meta-data Mngt, Quality Mng, Security & Privacy Mngt…, Master Data Management, Enterprise Document Mngt, Archive Mngt…)
  • Data Pipeline Automation

Si le barycentre des capacités est ‘on-premise’, on ne peut que lui conseiller de s’assurer qu’elle pourra les redéployer dans une architecture hybride, voire ‘full cloud’.

La ‘Data Fabric’ nécessaire pour faire la glue entre toutes ses capacités est également un critère fondamental de choix. Il faut d’une part  garantir un haut niveau de productivité dans la réalisation des usages ‘data-intensive’ et d’autre part rendre transparent les mouvements de données nécessaires entre les différentes ‘object stores’ quelques soit leurs localisations.

Enfin, parmi toutes ces capacités, la capacité ‘Data Insight & Intelligence’, au cœur de l’extraction de valeur de la donnée, va de plus en plus faire appel à l’intelligence artificielle. A la différence avec l’approche déterministe de la Business Intelligence, les technologies d’IA (‘Machine learning’, ‘Deep learning’) sont moins humainement lisibles. Elles nécessitent un cycle de vie (apprentissage, supervision, recalibration/réentrainement des modèles) et des technologies particulières (e.g. processeurs GPU, puces FPGA, Google TPU, AWS Inferentia). Elles doivent pouvoir ‘scaler’ de façon élastique et économique, s’appuyer sur des services Cloud pour l’IA de commodité et si nécessaire ‘on-premise’ pour l’IA stratégique, c’est-à-dire celle pour laquelle l’entreprise dispose d’une singularité sur les données d’apprentissage et/ou l’algorithmie et veut en ‘bunkeriser’ la souveraineté.

#Data-as-a-service & AI-as-a-service, briques essentielles pour démocratiser l’usage des données

Quelle que soit sa stratégie, l’entreprise aura encore pour un temps, voire durablement pour certaines, ses données distribuées entre de multiple ‘data stores’ pluri-technologies. Elle ne pourra avoir simultanément toutes ses données ‘on’ et ‘off premise’. Elle devra les traiter là où c’est le plus opportun en termes de performance et de coûts. Elle devra en conséquence être en mesure de les exploiter sans les faire systématiquement transiter via un lac de données polyglotte unique et centralisé.  Elle devra les exposer en mode « Self-service » pour une grande variété d’usages (opérationnels, décisionnels, data science, réglementaires, gouvernance) autour d’un catalogue de données normalisées et gouvernées mappant sa ‘data mesh’. Elle devra pouvoir opérer des actes de ‘data management’ cohérents  avec ses politiques de ‘data governance’ (sécurité d’accès, anonymisation, normalisation sémantique, enrichissement, ‘sourcing’, propriété et droit d’usage…) sur des données réparties. Enfin, elle devra maîtriser leurs transits et mouvements ‘on & off-premise’.

Pour satisfaire à toutes ces exigences, elle devra intégrer toujours plus de nouvelles solutions et technologies telles que celles de ‘data catalog‘ (e.g. IBM Watson Knowledge Catalog), de ‘data virtualization’ (e.g. Denodo), de fédération d’Object Storage (e.g. Scality), de ‘Change Data Capture’ (e.g. Attunity) ou encore de passerelle ‘on/off premise’ (e.g Azure Data Edge Box). Et pour pouvoir tirer de la valeur ‘from Edge to Cloud’, elle devra pouvoir invoquer des services d’intelligence artificielle en tout point, en mode ‘stream’ et ‘batch’.

#Conclusion : L’entreprise doit penser ‘data mesh’ et plus seulement ‘data lake’

La secousse provoquée par la fusion surprise entre Cloudera & Hortonworks traduit un séisme Big Data d’une plus grande ampleur et dont l’épicentre est le cloud.

Si le Big Data est entré dans les mœurs, au point que le terme soit de moins en moins usité, la problématique perdure et s’amplifie. L’éléphant Hadoop qui avait tout emporté sur son passage est chahuté et de plus en plus remis en question avec la montée en puissance des offres managées Big Data & AI. Avec le déplacement de la ‘data gravity’ vers le Cloud, les patterns data-centric doivent pouvoir être distribués et les capacités de ‘storage’ et ‘compute’ séparées. La ’data fabric’ doit être distribuable pour limiter les ‘data movements’. Le déplacement en masse des données vers un lac de données unique ne peut plus être le postulat de base au traitement des Big Data. Pour autant, le concept de ‘data lake’, dont Hadoop s’est nourrit, conserve ses vertus fondatrices et reste indispensable pour stocker les données à un grain très fin, jouer le rôle de ‘data hub’ et de ‘data fabric’ en majeur sur les ’data-at-rest’. L’entreprise doit aujourd’hui penser ‘data mesh’ et plus seulement ‘data lake’. Elle doit pouvoir joindre et croiser des données réparties dans de multiples ‘data stores’ pérennes ou éphémères en en fédérant l’accès via un ‘Data catalog’ sécurisé et gouverné qui doit porter tous les états de la ‘Data’ (‘raw’, ‘prepared -normalized, enriched…’, ‘use-case optimized’) mais aussi les ‘AI models’.

Les leaders historiques des distributions Hadoop (Cloudera/Hortonworks, MapR) ont d’ailleurs et heureusement anticipé ce changement de paradigme. Ils ont multiplié les annonces, voire sorti des premières briques autour de l’hybridation et la ‘kubernetisation’ de leur solution avec des capacités de construction/destruction de clusters éphémère automatisés, voire transparentes, la séparation du ‘compute’ du ‘storage’ pour s’adosser aux principales ‘object stores’  des grands offreurs Cloud, l’unification de la gestion des méta-données et politiques de sécurité multi-clusters, la capacité à se déployer ‘from edge to core’. A l’instar des « Cloud Service Brokers », ils se positionnent en « Data Centric Service Broker » et mettent en avant le meilleur de l’hybride. L’entreprise peut choisir du ‘on’ et/ou ‘off-premise’. Mais délivrer cette promesse ne sera pas être simple et va nécessiter des investissements conséquents. D’autant que le temps jouent contre eux face à la vitesse des offreurs Cloud qui ont pris plus une longueur d’avance et dispose surtout de moyens financiers sans limites.

Au delà, ce séisme  marque aussi le passage de la Data@Scale qui a occupé les entreprises ces dernières années vers l’AI@Scale pour tirer le plein potentiel de toutes les données.

Laisser une réponse

*