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 !
