Blog | Intelligence des données | 2 juillet 2021 | 4 min de lecture

7 mensonges sur les catalogues de données #4 : Pas une solution de requête

Par Actian Corporation

catalogue de données #lac de données
un catalogue de données n'est pas une solution de requête

Par Actian Corporation

catalogue de données #lac de données

Résumé

  • Un catalogue de données pas conçu pour exécuter des requêtes sur plusieurs sources de données.
  • Les architectures de données modernes s'appuient déjà sur des outils spécialisés (par exemple, les entrepôts de données ou outils bi) pour interroger les données.
  • Autoriser les requêtes directes à partir d'un catalogue peut entraîner des risques liés aux performances, aux coûts et à la sécurité.
  • Les catalogues de données devraient se concentrer sur découverte de données, leur compréhension et métadonnées , et non sur l'exécution de l'accès aux données.
  • La combinaison Fonctionnalités de requête Fonctionnalités celles du catalogue aboutit souvent à des solutions complexes, coûteuses et moins efficaces.
Dans cet article :

Le catalogue de données s'est développé rapidement et est désormais considéré comme incontournable dans le déploiement d'une stratégie data-driven. Victime de son succès, ce marché a attiré de nombreux acteurs des marchés adjacents.

 Ces acteurs ont modifié leur positionnement marketing pour se présenter comme des solutions de catalogue de données .

La réalité est que, bien que relativement faibles sur les fonctionnalités du catalogue de données elles-mêmes, ces entreprises tentent de convaincre, avec un succès proportionnel à leur budget marketing, qu'un catalogue de données n'est pas seulement un outil de recherche de de haute performance pour les équipes de données, mais une solution intégrée susceptible d'aborder une foule d'autres sujets.

L'objectif de cette série de blogs est de déconstruire l'argumentaire de ces vendeurs de catalogue de données la dernière heure.

Un catalogue de données n'est PAS une solution de requête

Voici une autre bizarrerie du marché des catalogue de données . Plusieurs fournisseurs, dont l'objectif initial était de permettre aux utilisateurs d'requête simultanément plusieurs sources de données, ont "pivoté" vers un positionnement de catalogue de données sur le marché.

Il y a une raison pour qu'ils pivotent.

L'émergence des lacs de données et du Big Data les a acculés dans un cul-de-sac technologique qui a affaibli le segment de marché dans lequel ils se trouvaient initialement.

Un Data Lake est typiquement segmenté en plusieurs couches. La couche " brute " intègre des données sans transformation, dans des formats plus ou moins structurés et en grande quantité ; Une deuxième couche, que nous appellerons " propre ", contiendra à peu près les mêmes données mais dans des formats normalisés, après un dépoussiérage. Ensuite, il peut y avoir une ou plusieurs couches "business" prêtes à l'emploi : Un entrepôt de données et un outil de visualisation pour l'analyse, un cluster Spark pour la science des données, un système de stockage pour la distribution commerciale, etc. Au sein de ces couches, les données sont transformées, agrégées et optimisées pour l'utilisation, ainsi que les outils supportant cette utilisation (outils de visualisation de données, notebooks, traitement massif, etc).

Dans ce paysage, un outil universel de libre-service requête n'est pas adapté.

Il est bien sûr possible de mettre en place une couche d'interprétation SQL au-dessus de la couche "propre" (comme Hive) mais l'exécution de requête reste un domaine de spécialistes. Les volumes de données sont énormes et rarement indexés.

Permettre aux utilisateurs de définir leurs propres requêtes est très risqué : sur les systèmes sur site, ils risquent de faire s'effondrer le cluster en exécutant une requête très coûteuse. Et sur les systèmes en nuage, la facture pourrait être très élevée. Sans parler des problèmes de sécurité et de sensibilité des données.

Quant aux couches "métier", elles sont généralement couplées à des solutions plus spécialisées (comme une combinaison de Snowflake et Tableau pour l'analytique) qui proposent un outillage très complet et sécurisé, offrant de grandes performances pour les requêtes en libre-service . Leur espace de marché se réduisant comme neige au soleil, certains fournisseurs de requête multi-sources se sont orientés vers les catalogues de données.

Leur discours est maintenant de convaincre les clients que la capacité d'exécuter des requêtes fait de leur solution la Rolls-Royce des catalogues de données (afin de justifier leur prix à six chiffres). Nous vous invitons à y réfléchir à deux fois.

À emporter

Dans une architecture de données moderne, la possibilité d'exécuter des requêtes à partir d'un catalogue de données seulement superflue ; elle est également très risquée (en termes de performances, de coûts, de sécurité, etc.).

Les équipes chargées des données disposent déjà de leurs propres outils pour exécuter des requêtes sur les données, et si ce n'est pas le cas, il peut être judicieux de les équiper. Intégrer les problématiques d'accès aux données dans le déploiement 'un catalogue est le plus sûr moyen d'en faire un projet long, coûteux et décevant.