Aujourd’hui, exploiter des grands volumes de données soulève des problématiques complexes auxquelles aucune technologie, utilisée seule, ne peut répondre de manière globale.
C’est pourquoi, selon Jean-Sébastien, consultant senior, il faut accompagner la mise en place d’une architecture Big Data par la diffusion d’une culture de la donnée dans toutes les strates de l’entreprise. C’est la clé du succès !
À quels défis, l’afflux massif de données confronte les entreprises ?
L’augmentation du volume des données a bouleversé les stratégies d’entreprise. Les organisations doivent désormais relever trois défis : un défi technologique, un défi organisationnel et enfin un défi humain.
La donnée a toujours été une valeur clé pour les entreprises. Cependant les systèmes de stockage et d’exploitation classiques n’étant plus adaptées à l’afflux massif de données auxquels elles sont confrontées, elles doivent faire évoluer leur système d’information. Elles doivent mettre en place de nouvelles technologies pour ingérer, conserver et exploiter un grand volume de données. Le temps d’exploitation, le time-to-data, constitue aujourd’hui un enjeu majeur.
Pour valoriser la data de manière globale les entreprises doivent se réorganiser afin de mettre en place une gouvernance des données. Cela va bien au-delà, du recrutement de nouveaux profils comme ceux de DPO (Data Protection Officer), de CDO (Chief Data Officer) de Data Scientist, de Data Engineer, ou encore de DevSecOps (DevOps avec une compétence sécurité) et de DataViz / Business Intelligence.
En effet, il faut diffuser une culture de la donnée dans toutes les strates de l’entreprise. À la clé : la création et/ou l’amélioration des produits, des services, l’optimisation du parcours client, et in fine l’augmentation des revenus.
Les entreprises se veulent aujourd’hui prédictives et prospectives. Elles veulent de l’IA et du cognitif dans leurs processus. Le choix de l’architecture est-il capital dans une démarche « data driven » ?
Une entreprise est data-driven lorsque toutes les décisions des opérationnels sont basées sur l’analyse de la donnée à disposition : l’entreprise est dès lors, pilotée par la donnée. L’exploitation de la donnée doit être intégrée de façon naturelle dans les tâches quotidiennes des employées et des dirigeants.
L’entreprise doit donc se structurer afin que tous les services qui la constitue disposent des outils nécessaires et adaptés. En cela, l’architecture est décisive. Elle doit être évolutive et répondre aux besoins de chacun.
Quels sont les critères à prendre en compte avant de définir une architecture ?
L’architecture mise en place doit être au service de la stratégie de l’entreprise. Il faut prendre le temps d’identifier les besoins de chaque service afin de les doter d’outils adaptés pour accéder au niveau de donnée nécessaire (brute ou structurée) suivant leur usage. Ces outils forment une brique d’architecture qui doit être évolutive. Cette brique doit apporter la solution optimale pour le cas d’usage.
Par exemple, les data scientists devront pouvoir accéder facilement à la donnée brute dans une phase d’exploration et de construction de modèle mathématique. La donnée sera ensuite « filtrée » et structurée afin qu’elle puisse être exploitée par des services opérationnels.
Aujourd’hui, dans le domaine du Big Data, il existe des problématiques auxquelles aucune technologie isolée ne peut répondre. Trois types d’architectures se dessinent régulièrement au sein des SI : Datalake, Lambda et Kappa. À quel type de besoins correspond chacune de ces 3 architectures ?
Le Data Lake est une solution apparue avec les technologies Big Data. Ce n’est pas en soi une architecture, mais plutôt un composant de stockage. Il permet d’ingérer rapidement des sources hétérogènes et sans limite de stockage de très gros volumes de données dans leur formats natifs. Le plus souvent, on retrouve l’écosystème Hadoop avec HDFS. Le principal inconvénient d’un Data Lake est le temps d’extraction de la donnée. Sur un cluster Hadoop, l’exécution de requêtes complexes impliquent plusieurs opérations de MapReduce qui peuvent prendre des heures.
Pour satisfaire les opérationnels qui ont besoin de meilleurs temps de réponses, de nouvelles architectures de traitement des données en temps réel ont émergé : Lambda et Kappa.
L’architecture Lambda repose sur la mise en place de deux couches de traitement dans lesquelles sont injectées les données. Une couche de traitements par lots et une couche de vitesse (i.e. : speed layer). Le résultat de ces deux types de traitements est indexé dans une couche de service présentant des vues par lots et des vues en temps réel. Toute requête peut ainsi bénéficier des avantages des deux modes de traitement. Cependant, cette architecture impose non seulement la maintenance de deux bases de code mais aussi de deux couches distinctes plus ou moins complexe.
L’architecture Kappa est une solution alternative à Lambda. Elle permet d’éliminer la couche de traitement par lots. Les données sont ingérées et traiter comme un flux d’évènements. Il est possible de simuler le traitement par batch en repassant tous les évènements pour une période données. Malgré tout, l’architecture Kappa ne se substitue pas entièrement à une architecture Lambda. En effet, certains modèles de machine Learning peuvent données des résultats très différents entre un traitement par lots et un traitement par flux.
En quoi les RDBMS, les bases de données relationnelles, ne sont pas adaptées au Big Data ?
Prenons la définition en 3Vs du Big Data proposée par Gartner au début des années 2000 : Volume, Rapidité (Velocity) et Variété (Variety).
Volume : la quantité de données à ingérer est ici de l’ordre de plusieurs centaines de To voire, même de l’ordre de Po pour les plus grandes entreprises. Pour faire face à cette augmentation, un RDBMS classique devra se mettre à l’échelle de manière verticale par l’augmentation du nombre de CPUs, de la mémoire (RAM) et du stockage (Disk). Les limites physiques d’une seule machine et le coût sont prohibitifs.
Rapidité : Les RDBMS sont conçues pour une conservation stable (écriture sur Disk) des données plutôt qu’un afflux et une croissance rapide de celle-ci. La vitesse d’ingestion est limitée par la complétion des opérations d’écritures sur le disque (I/O bound).
Variété : Le schéma d’un RDBMS est fixe et l’injection d’un nouveau type de données nécessite une modification. Dans un contexte Big Data, les données sont diverses. Elles sont semi ou non structurées (textes, emails, social media …) et les RDBMS ne sont pas adaptées à ce type de données.
Pour répondre aux besoins du web et des réseaux sociaux, les bases de données relationnelles ont été remplacées par une nouvelle famille de moteurs de données dite NoSQL. Quels sont les avantages de ces moteurs ?
Les solutions NoSQL sont des bases de données distribuées. Elles supportent de-facto une scalabilité horizontale. L’augmentation de la quantité de données à ingérer se fait par l’ajout de machines standards appelées “commodity hardware” ayant un cout raisonnable.
Les opérations d’écritures et de lectures sont repartis sur toutes les machines du cluster.
Les bases NoSQL, qu’elles soient orientées clé/valeur, colonnes ou document sont, soit “schema less” ou ont un “schema” flexible permettant d’absorber tout type de donnée en entrée.
Dans un contexte Big Data, la scalabilité est-il le facteur le plus important ?
La scalabilité est d’autant plus importante que c’est un prérequis à l’élasticité. Pour moi, la scalabilité d’un système est sa capacité à grossir horizontalement pour augmenter les ressources en CPU, IO et mémoire afin d’absorber la quantité de données à ingérer par exemple.
L’élasticité est la capacité d’ajouter des instances à un système pour absorber un pic de charge puis de revenir à taille initiale.
Par exemple, le nombre d’instances au sein d’un cluster Spark peut varier dynamiquement en fonction des calculs en cours. L’idée est de ne payer que ce que l’on consomme, notamment dans le cloud (AWS, Azure…).
Comment répondre à la domiciliation de son architecture ? Faut-il choisir une Appliance ?
Je ne pense pas qu’il existe une solution miracle. Les entreprises doivent, en fonctions de la sensibilité de leurs données est des contraintes réglementaires, trouver un équilibre entre un cloud privé et l’utilisation de cloud publiques (AWS, Azure …).
Il en va de même sur la mise en place de solution en open source ou en version entreprise. Le coût des licences engendrées pars ces dernières est non négligeable.
