Voici le deuxième article de la série de livres blancs de Mark Madsen : Le lac de données va-t-il noyer l'entrepôt de données ? Dans le cadre de la premier messageMark a souligné les différences entre le lac de données et l'entrepôt de données traditionnel, avant de conclure : "La capacité principale d'un lac de données, et la source d'une grande partie de sa valeur, est la capacité de traiter des données arbitraires.
Dans ce billet, Mark passe en revue le nouvel environnement et les nouvelles exigences :
"Les environnements pré-Hadoop, y compris les outils d'intégration conçus pour traiter des lignes et des colonnes structurées, limitent le type de données pouvant être traitées. Les exigences du nouvel écosystème qui tendent à causer le plus de problèmes aux environnements traditionnels sont la structure variable des données, les données en continu et les ensembles de données non relationnelles.
Structures de données : JSON est le nouveau CSV
Le format d'échange le plus courant entre les applications n'est pas celui des connecteurs de base de données, mais celui des fichiers plats au format CSV (comma-separated value), souvent échangés via FTP. L'un des grands changements dans la conception des applications au cours des dix dernières années a été le passage aux API REST avec des données utiles formatées en JSON, un format de données de plus en plus courant. Combiné à une infrastructure de diffusion en continu, ce changement de conception réduit la nécessité d'une intégration de fichiers à l'ancienne. JSON et les API sont en train de devenir les nouveaux CSV et FTP.
La plupart des outils d'intégration de données d'entreprise ont été conçus pour utiliser une base de données relationnelle. Cela fonctionne bien pour les données provenant d'applications transactionnelles. Cela fonctionne moins bien pour les journaux, les flux d'événements et les données créées par l'homme. Ces dernières n'ont pas la même structure régulière de lignes, de colonnes et de tables que les bases de données et les outils d'intégration. Ces outils ont des difficultés à travailler avec JSON et doivent effectuer un travail supplémentaire pour le traiter et le stocker.
L'inverse n'est pas vrai. Les nouveaux outils d'intégration de données peuvent facilement représenter des tableaux en JSON, alors que les structures imbriquées en JSON sont difficiles à représenter dans des tableaux. Une représentation souple des données permet de lier tardivement les structures et les types de données.
Il s'agit là d'un avantage clé de JSON par rapport à la liaison initiale et au typage statique utilisés par les anciens outils d'intégration de données. Un simple changement de champ en amont peut interrompre un flux de données dans les anciens outils, alors que le nouvel environnement, plus souple, peut permettre de continuer sans interruption.
Cependant, JSON n'est pas le meilleur format pour le stockage des données. Cela signifie que des outils sont nécessaires pour traduire les données de JSON vers des formats de stockage plus efficaces dans Hadoop, et de ces formats vers JSON pour les applications. La plupart des données web et non transactionnelles sont aujourd'hui envoyées sous forme de messages JSON. Les technologies Hadoop et de streaming, plus flexibles, sont mieux adaptées au transport et au traitement de ces données que les outils d'intégration de données classiques.
Les flux sont le nouveau lot
Souvent, les sources initiales de données dans un lac de données proviennent de flux d'événements et peuvent être traitées en continu plutôt qu'en lots. En règle générale, un entrepôt de données n'est pas un bon endroit pour traiter des données qui doivent être disponibles en moins de quelques minutes. L'architecture a été conçue pour des charges incrémentales périodiques, et non pour un flux continu de données. Un lac de données doit prendre en charge plusieurs vitesses, du quasi temps réel au traitement par lots à forte latence.
Le traitement par lots est en fait un sous-ensemble du traitement par flux. Il est facile de conserver des données pendant un certain temps, puis d'exécuter une tâche pour les traiter par lots. Il n'est pas aussi facile de prendre un système de traitement par lots et de le rendre efficace pour traiter les données un message à la fois. Un moteur de traitement par lots ne peut pas répondre aux exigences du traitement en continu, mais les outils conçus pour traiter des données en continu peuvent se comporter comme un moteur de traitement par lots.
Les données en continu impliquent également que le volume de données peut fluctuer, passant d'un petit filet d'eau au cours d'une heure à une inondation au cours de l'heure suivante. Les modèles de serveurs fixes et la planification de la capacité d'une architecture traditionnelle ne se traduisent pas bien par une mise à l'échelle dynamique des serveurs au fur et à mesure que le volume des messages augmente et diminue. Il faut donc repenser la façon dont on dimensionne la collecte et l'intégration des données".
--
Le document Will the Data Lake Drown the Data Warehouse ? (Le lac de données va-t-il noyer l'entrepôt de données ?) poursuit en notant que "des ensembles de données différents entraînent de nouveaux moteurs". Dans le prochain billet de cette série, Mark décrira la nouvelle architecture du lac de données, en approfondissant certains des concepts qu'il a abordés dans le livre blanc sur le lac de données qui l'accompagne : Comment construire un lac de données d'entreprise : Considérations importantes avant de se lancer. N'oubliez pas de consulter la récente présentation et l'enregistrement de webinar avec SnapLogic ici et d'en savoir plus sur SnapLogic pour l'intégration des big data ici.
