Pour les plus de 40 ans 😉 Oracle a toujours été la référence du stockage que ce soit pour le transactionnel ou l’analytique.
Depuis la mouvance Big Data et après sa plus grande compréhension, de nombreux projets se lancent enfin concrètement et les marches ne sont pas faciles à franchir. Je veux partager avec vous un constat que je considère comme une problématique assez fréquente.
Comme depuis toujours on souhaite avoir des performances pour que toutes requêtes prennent vie en quelques millisecondes. Aujourd’hui cette offre de performance existe dans l’écosystème Big Data mais revêt 2 pivots essentiels en terme de choix, Hadoop et NoSql.
Pour moi le premier est un cluster de traitement de la donnée et le file système idéal qui remplace entre autres nos anciennes staging area. Aujourd’hui ce stockage brut massif se dénomme Data Lake lorsqu’on ne l’applique plus exclusivement aux données destinées à être traitées par votre Datawarehouse. Le Data Lake a vraiment cet objectif d’être un espace de stockage universel bien au-delà du périmètre des responsables décisionnels. C’est un espace centralisé ou nativement le hardware permet déjà de retrouver un grand nombre d’informations par les seules metadata initiales stockées au moment de leur ingestion.
De plus son mode cluster en mode distribué, comme d’autres, est un générateur de puissance de traitement sans fin au regard des moyens d’infrastructure que vous lui allouez.
NoSql offre dans le même temps des modes de modélisation des données très souple et évolutif tout en conservant d’excellente performance en terme de requête car le maître mot reste « base de données ». Mais quelque soit la souplesse de ces modèles dont le plus en vogue est la structure Json, cela reste un concept de formatage des datas ayant donc son propre mode d’ingestion. Les offres disponibles savent elles aussi rendre la gestion de grands volumes sans limite en mode distribué.
Au temps de l’IoT cette conceptualisation est moins présente car l’urgence est de collecter et stocker pour rendre disponible à tout moment si besoin. Dans ce domaine Hadoop poursuit son règne. Cela n’interdit pas d’alimenter des processus temps réels avec des orchestration de Apache Kafka qu’il supporte. Au delà vous pourrez choisir de traiter la data en mode stream ou batch avec Spark ou MapReduce.
Aussi voir des projets aujourd’hui se lancer exclusivement sur un concept NoSql revient à mon sens à s’interdire de futur projet analytique. Si ces solutions répondent aux objectifs d’un projet c’est parfait et c’est leur objectif. Vous pouvez ainsi économiser sur toutes les évolutions que vous souhaitez apporter à un outil transactionnel ou de reporting dédié. Si vous souhaitez ajouter une information, ou même démultiplier une information existante en plusieurs attributs, NoSql vous aidera largement a réaliser cela quasi instantanément. Mais à mon sens, NoSql ne peut pas être confondu avec une architecture Data Lake.
Ces Big questions très familières au projet Big Data, ne doivent pas cacher qu’aujourd’hui on travaille sur le repositionnement de la donnée. On a commencé par faire de l’analyse sur des projets prioritaires et aujourd’hui on est en mesure de définir des architectures « globales » en terme d’analytique facilitant le management « driver » par la data. La richesse de votre analyse de demain naîtra du croisement de multiples sources et si vos premiers choix sont trop réducteurs, vous serez moins réactif.
A l’heure où dans votre espace digital privé vous pouvez retrouver toutes informations textes, images, musiques, …etc… d’un simple clic, nos entreprises ne peuvent plus se contenter de définir la liste des « domaines » réservés à l’analyse. Certes la confidentialité doit toujours être gérée (et c’est le cas) mais les défis sont de pouvoir rapidement écouter les flux manipulés par l’entreprise pour qu’à n’importe quelle étape on puisse retrouver et analyser des données. Au rythme toujours incessant des nouveautés dans le Big Data les choix initiaux ne sont pas simples mais néanmoins pas neutres.
opentoile 