Article publié par Pierre Coste, Leader Technique – Manager chez Keyrus
De nombreux enjeux actuels tournent autour des données. Cette maîtrise des données offre aux entreprises des leviers pour améliorer leurs performances opérationnelles et financières. En s’appuyant sur Snowflake, une base de données analytique en mode Saas, les entreprises peuvent bénéficier d’un entrepôt de données dans le Cloud évolutif, scalable et performant, leur garantissant un environnement permettant de traiter sereinement toutes leurs données, qu’elles soient structurées ou semi-structurées. Snowflake peut gérer de très grosses volumétries de données, ainsi que des données en temps réel.
Une fois toutes ces données intégrées dans Snowflake, un des aspects de la gouvernance de données peut soulever une question : comment partager facilement les données qui sont stockées dans Snowflake ?
Traditionnellement, peu d’entreprises acceptent de donner des accès à des tiers, même en lecture, et ceci qu’ils soient internes ou externes à l’entreprise. Ces accès sont souvent refusés pour une problématique de sécurité et d’ouverture de pare-feu, mais aussi pour s’assurer de ne pas exposer des données confidentielles. Les utilisateurs finaux n'ayant pas accès directement aux données, les solutions possibles sont :
réaliser régulièrement des traitements d'exports de données, déposant des fichiers sur des répertoires, des FTP ou autre ;
mettre en place des API pour exposer les données. La solution des API est tout à fait convenable mais demande des développements ou des acquisitions de produits ainsi qu'une maintenance logicielle, car une fois que les données sont accessibles, la tendance est d'en fournir plus.
Les limites des API dans un contexte de data sharing peuvent être :
la gestion des forts volumes de données : temps important lorsqu'on dépasse le million de lignes par exemple ;
la nécessité, pour les utilisateurs finaux, de récupérer la donnée et de la stocker dans leurs propres bases de données pour la traiter et la consommer.
En passant par un tiers (fichier ou API), les données ne seront jamais accessibles en direct et des actions seront donc nécessaires pour récupérer les dernières données.
L'architecture Snowflake qui repose sur deux piliers, "Multi-cluster et shared data", permet de revoir ce mode de partage de données. En effet, il est maintenant possible de partager de la donnée facilement, de façon sécurisée et sans impact sur la performance de la base de données. Pas de copie de données, la donnée est disponible au niveau « ligne » en fonction de la sécurité associée et sans avoir à reconstruire/consolider avec des traitements ETL.
Snowflake permet d’accéder directement à la donnée source et de la consommer depuis Snowflake, mais aussi depuis des outils tiers en se connectant avec les connecteurs natifs ou par les drivers ODBC/JDBC.
Comment fonctionne le data sharing sous Snowflake ?
On distinguera la notion de compte Fournisseur, celui qui crée et partage la donnée, et le compte Consommateur qui sera celui qui va traiter et requêter les données. Il existe deux possibilités d'accéder à de la donnée partagée dans Snowflake :
en souscrivant un compte Snowflake. L'utilisateur est alors facturé en fonction de sa consommation.
en ayant un "Read Only Account" qui peut être considéré comme un sous-compte du compte Fournisseur, accessible depuis une URL différente. Dans ce scénario, c'est bien le compte Fournisseur qui est facturé.
Une fois ces comptes créés, soit les données sont « publiques », soit il est nécessaire d'appliquer une sécurité au niveau « ligne » pour restreindre l'accès aux seules données que l'utilisateur a le droit de voir. Dans le second cas, une vue est recommandée pour mettre en place cette sécurité au niveau « ligne ». Cette vue permettra d'appliquer un filtre en fonction de l'utilisateur, et c’est celle-ci qui sera partagée et qui permettra au consommateur de lire la donnée.
Pour sécuriser les données, Snowflake a développé des « vues sécurisées ». En effet, le plan d'exécution de ces requêtes est fait de telle sorte qu'il exécute dans un premier temps le code SQL de la requête, et ensuite les différents filtres et opérations réalisés sur cette vue. Il n'est donc pas possible de savoir d'où proviennent les données ou d'essayer de voir le contenu des données auxquelles l'utilisateur n'a pas accès.
Pour illustrer ceci simplement, prenons le cas d’usage d'un suivi financier d'une entreprise comprenant plusieurs franchises (sources dans le projet GitHub).
L'objectif pour le groupe est de consolider les données et les exploiter, mais aussi de fournir aux franchises la possibilité de voir leurs résultats financiers. Pour ce faire, nous alimenterons une table de finance contenant les données de toutes les franchises, et un identifiant de groupe indiquant qui a le droit de voir ces données. Une deuxième table donnant les accès par l'association groupe / utilisateur sera alimentée pour gérer la sécurité.
Pour faciliter la gestion, les tables seront créées dans un schéma nommé "private". Les objets accessibles comme la vue sécurisée seront, quant à eux, dans un schéma "public". C'est ce schéma qui sera partagé et disponible par les comptes Consommateurs.
Ces comptes, qui ont maintenant accès aux données, peuvent requêter directement depuis la console Snowflake, mais aussi utiliser leurs outils de data visualisation en interne pour explorer les données disponibles. Snowflake fonctionnant sur un modèle de "Warehouse", les utilisateurs consommant les données n'impacteront pas les utilisateurs de la plate-forme Snowflake.
Ainsi, nous avons pu voir dans cet article qu’il était simple de partager des bases de données dans Snowflake. Cela en s'appuyant sur des fonctionnalités natives du produit et en se focalisant sur les données, et non pas sur les outils et les problématiques de performances et mise à disposition des données.