Défis courants liés aux lacs de données et comment les surmonter

Les entreprises ont le problème perpétuel d’essayer de maîtriser leurs performances. Les dirigeants doivent disposer des informations les plus récentes sur leurs revenus, leurs coûts et leur rentabilité. Ils veulent également que ces chiffres soient segmentés par unité commerciale, géographie, gamme de produits et client.

Le problème est qu’il est difficile d’obtenir cette image globale. Une grande entreprise typique peut avoir plusieurs centaines d’applications déployées dans le monde entier pour capturer les données sur les ventes, la logistique et les fournisseurs. Les données client et produit sont dispersées dans ces applications, souvent avec des classifications contradictoires ou incohérentes.

Défis liés à la collecte de données

Rassembler toutes ces données et leur donner un sens est un problème épineux depuis des décennies.

Traditionnellement, les entreprises prenaient des copies des données clés de leurs systèmes de transaction, les fusionnaient dans un entrepôt de données d’entreprise et résolvaient les incohérences dans les définitions en faisant correspondre les ventes ou les hiérarchies de produits incohérentes au fur et à mesure que les données étaient chargées dans l’entrepôt de données.

Les données ont ensuite subi un nettoyage des données et ont été canalisées dans un schéma soigneusement conçu et stockées dans une base de données relationnelle. Des sous-ensembles de la base de données pourraient être répartis dans des magasins de données locaux pour répondre aux besoins d’une unité commerciale spécifique.

La modélisation et le nettoyage des données ont pris du temps et des compétences technologiques rares, et le schéma de base de données soigneusement conçu était inflexible. Si l’entreprise rachetait une autre entreprise, cela pourrait prendre des mois pour adapter le schéma de l’entrepôt de données afin de traiter les données de l’entreprise nouvellement acquise.

Ce décalage inhérent signifiait que les utilisateurs professionnels ne disposaient pas toujours des données à jour dont ils avaient besoin. Beaucoup d’entre eux ont contourné le service informatique et créé des flux de données qu’ils pouvaient contrôler.

Bases de données des déformations volumiques

L’un des défis les plus importants en matière de gestion des données consiste à passer au crible de grandes quantités de données.

Le trafic Web, les données de capteurs et autres peuvent représenter un volume d’un ordre de grandeur supérieur à celui des données de vente traditionnelles, et les bases de données relationnelles ont eu du mal à faire face à la quantité de données, en particulier à un prix abordable. De plus en plus de données provenaient de l’extérieur de l’entreprise. Une grande partie n’était pas structurée, comme des documents et des images plutôt que des chiffres.

Cette pression a conduit au développement de systèmes de fichiers Big Data tels que le système de fichiers distribués Hadoop (HDFS), qui ont été conçus pour un stockage à très grande échelle en utilisant un stockage sur disque peu coûteux. Le lac de données – utilisant un tel stockage et traitant des données brutes et non traitées – était né.

Cependant, HDFS est un système de fichiers – pas une base de données – et ne dispose pas des structures d’index qui permettent les requêtes SQL complexes pour lesquelles les bases de données relationnelles ont été conçues. Un lac de données peut reposer sur HDFS, mais peut également utiliser des bases de données NoSQL dépourvues d’un schéma rigide et de la stricte cohérence des données d’une base de données traditionnelle.

Défis avec la structure des données

Les lacs de données et leurs données brutes sont très différents des entrepôts de données qui ont soigneusement nettoyé, traité et indexé les données.

Les lacs de données complètent les entrepôts de données plutôt que de les concurrencer. Un analyste d’entreprise qui souhaite exécuter des requêtes sur les performances des ventes saurait à peine par où commencer dans les profondeurs sombres d’un lac de données, qui est la chasse gardée naturelle d’un scientifique des données qui a les compétences nécessaires pour naviguer dans des données brutes inexplorées.

En pratique, même les scientifiques des données peuvent être confrontés à des défis liés aux lacs de données. Dans certaines organisations, il y a maintenant une tentative d’apprivoiser cet ouest sauvage des données brutes en ajoutant une couche de métadonnées au-dessus du lac de données pour le cataloguer. Dans certains cas, les métadonnées peuvent ajouter des agrégats et des calculs couramment utilisés.

C’est là que la ligne de démarcation entre un lac de données et un entrepôt de données s’estompe.

Les entrepôts de données ont été construits pour structurer un monde chaotique de données transactionnelles brutes. Mais les gens réalisent maintenant que les lacs de données présentent bon nombre des mêmes défis auxquels étaient confrontés les premiers entrepôts de données. Pour donner un sens à toutes les données, vous avez besoin d’une certaine structure pour savoir quand les différents fichiers de données ont été chargés, d’où ils proviennent et qui les a chargés.

Autres défis liés aux lacs de données

Les incohérences de données peuvent encore devoir être résolues lors de la combinaison de différents ensembles de données. Vous devez également imposer un certain contrôle sur les données, par exemple en différenciant clairement les données de production des données de bac à sable utilisées pour les tests et l’expérimentation.

De plus, certaines questions doivent être résolues. À qui appartiennent les sources de données et les flux ? Qui est l’arbitre lorsque des versions concurrentes des hiérarchies de produits sont trouvées ? Ce dernier est le territoire de la gouvernance des données, un autre domaine nécessaire lors de la construction d’entrepôts de données d’entreprise.

En bref, les défis des lacs de données sont similaires à ceux rencontrés dans les entrepôts de données. La couche de stockage sous-jacente a peut-être changé, mais les problèmes de gouvernance des données, de sécurité, de métadonnées, de qualité et de cohérence des données se cachent toujours sous la surface du lac de données. Ces domaines doivent être intégrés à la conception et à la gestion d’un lac de données, tout comme ils l’étaient avec les entrepôts de données.

Similaire  5 tendances pour les environnements SQL Server alors que SQL Server 2019 se profile