a data catalog is not a query solution

Les 7 mensonges de fournisseurs de Data Catalog – n°4 – Un Data Catalog n’est pas une solution de requêtage

juillet 2, 2021

Le marché du Data Catalog a beaucoup évolué depuis ses débuts, et ce composant est désormais identifié comme une brique essentielle dans le déploiement d’une stratégie data-centric.

Victime de son succès, ce marché a attiré un grand nombre d’acteurs opérant sur des marchés adjacents et qui ont revu leur positionnement marketing pour se présenter comme solution de Data Catalog.

En réalité, faibles sur les promesses du Data Catalog, ils cherchent à convaincre, avec un succès proportionnel à leurs moyens marketing, qu’un Data Catalog n’est pas simplement un outil de recherche ultra-performant destiné aux équipes data, mais une solution intégrée susceptible d’adresser tout un tas d’autres sujets.

C’est le discours de ces vendeurs de Data Catalog de la dernière heure que l’on souhaite déconstruire dans cette série d’articles.

Voici selon nous, les 7 principaux mensonges des vendeurs de Data Catalog :

  1. un Data Catalog est une plateforme de gouvernance des données,
  2. un Data Catalog permet de mesurer et piloter la qualité des données,
  3. un Data Catalog permet de gérer la conformité réglementaire,
  4. un Data Catalog permet de requêter directement les données,
  5. un Data Catalog permet de modéliser l’architecture logique et les processus métiers autour de la data,
  6. un Data Catalog est un outil collaboratif de cartographie et de gestion de métadonnées impossible à automatiser,
  7. un Data Catalog est un projet long, complex et très couteux.

Un Data Catalog n’est pas une solution de Requêtage 

C’est une autre bizarrerie du marché du Data Catalog.

Plusieurs vendeurs, dont l’ambition initiale était de permettre leurs utilisateurs de requêter simultanément plusieurs sources de données, ont “pivoté” vers un positionnement de Data Catalog. S’ils ont pivoté, ce n’est pas pour rien.

L’émergence des Data Lakes et du Big Data les a menés dans une impasse technologique qui a anémié leur marché d’origine.

Un Data Lake est typiquement segment en plusieurs couches. La couche “raw” intègre les données sans transformation, dans des formats plus ou moins structurés, et des volumétries  normes (c’est le principe). Une seconde couche, que l’on va appeler “clean” va contenir plus ou moins les mêmes données, mais dans des formats normalisés, et après un peu de nettoyage.

Ensuite, il peut y avoir une ou plusieurs couches “business” dédiées aux usages: un data warehouse et un outil de visualisation pour l’analytique, un cluster Spark pour la data science, un système de stockage pour la distribution commerciale, etc. Dans ces couches, les données sont transformées, agrégées et optimisées pour les usages, et les outils qui supportent ces usages (outils de dataviz, notebooks, massive processing, etc.).

Dans ce paysage, un outil de requêtage universel en self-service n’est pas souhaitable. Il est bien sûr possible de monter une couche d’interprétation SQL au-dessus de la couche “clean” (style Hive), mais exécuter les requêtes reste une affaire de spécialistes. Les données sont très volumineuses et peu ou pas du tout indexées.

Laisser des utilisateurs définir leurs propres requêtes est très risqué : sur des systèmes on-prem, ils risquent d’écrouler le cluster en lançant une requête très coûteuse. Et sur le Cloud, ils risquent de faire exploser la facture. Sans compter les problématiques de sécurité et de sensibilité des données…

 

Quant aux couches “business”, elles sont généralement couplées des solutions spécialisées (par exemple, une combinaison Snowflake + Tableau pour l’analytique) qui proposent un outillage sécurisé très complet et très performant pour le requêtage self-service. Et qui sont déjà maîtrisés par les utilisateurs.

Leur marché se réduisant comme peau de chagrin, certains vendeurs de requêteurs multi-sources ont donc pivoté vers le Data Catalog; ils cherchent maintenant à convaincre que la capacité à  exécuter des requêtes fait de leur solution la Rolls du Data Catalog (et justifie leurs tarifs à 6 chiffres). Je vous invite vraiment à y réfléchir à deux fois…

Take Away

 Sur une architecture data moderne, la capacité à exécuter des requêtes depuis le Data Catalog est non seulement inutile, mais aussi très risquée (performance, coût, sécurité).

Les équipes data disposent déjà de leurs propres outils pour exécuter des requêtes sur les données qui leur sont destinées – et si ce n’est pas le cas, il faut songer à les équiper. Intégrer les problématiques d’accès aux données dans le déploiement du catalogue est le meilleur moyen d’en faire un projet long, coûteux, et décevant.

 

Téléchargez notre eBook : Les 7 mensonges des fournisseurs de Data Catalog pour en savoir plus !

zeenea logo

At Zeenea, we work hard to create a data fluent world by providing our customers with the tools and services that allow enterprises to be data driven.

zeenea logo

Chez Zeenea, notre objectif est de créer un monde “data fluent” en proposant à nos clients une plateforme et des services permettant aux entreprises de devenir data-driven.

Be(come) Data Fluent

Read the latest trends on big data, data cataloging, data governance and more on Zeenea’s data blog.

Join our community by signing up to our newsletter!

Devenez Data Fluent

Découvrez les dernières tendances en matière de big data, data management, de gouvernance des données et plus encore sur le blog de Zeenea.

Rejoignez notre communauté en vous inscrivant à notre newsletter !

LET’S GET STARTED

Make data meaningful & discoverable for your teams

Démarrer MAINTeNaNT

Donnez du sens à votre patrimoine de données