Snowflake by a dummy !

Prologue

9h00 – chez Komeet

« …voilà pour le projet les amis ! Des questions ?»

« On a quoi comme techno de stockage ? »

« Tu vas voir, y a du Snowflake et c’est cool »

« Snowflake ? Snowflake… Snoooowflake. Ça me dit quelque chose… »

« Quoi ! Tu connais pas ?! Haaaaaan »

« Nan, mais… c’est parce que… ah ah… eh eh… »

Cela c’est presque passé comme ça. En réalité, je connaissais Snowflake au moins de nom depuis longtemps mais il est vrai que je n’avais pas pu tester ou utiliser. J’ai donc découvert il y a quelques mois et je n’ai pas été déçu. Je vais tenter d’expliquer un peu pourquoi, de mon point de vue. Après une brève introduction, bien entendu, cela serait un peu impoli autrement, n’est-ce pas ?

Présentation

Aller, c’est parti pour une petite présentation rapide histoire de ne pas trop naviguer à vue pour les innocents comme moi qui ne connaitraient pas Snowflake.

Snowflake est une plateforme cloud de data warehousing conçue pour stocker, gérer et analyser de grandes quantités de données. Elle est développée par Snowflake Inc., une entreprise américaine fondée en 2012.

La force de la plateforme réside dans sa capacité à s’adapter aux besoins et à fournir la puissance de calcul nécessaire au bon moment. Ce côté évolutif et adaptable apporte une souplesse non négligeable dans l’analyse de données. Le tout est géré de manière sécurisée pour préserver l’intégrité et la confidentialité des données, et l’ensemble repose, bien sûr, sur une architecture distribuée offrant de la haute disponibilité.

Concernant l’intégration de données, Snowflake possède la possibilité d’intégrer des données provenant de sources multiples en passant soit par l’utilisation d’outils ETL externe tel que Talend, en mode « traditionnel », soit en utilisant les fonctionnalités SnowPipe permettant la fédération de données.

Pour finir, tout ceci étant en SaaS, la gestion de l’infrastructure sous-jacente n’est plus une contrainte.

Bien. Les présentations son faites. Mais, je sais que l’envie vous brûle de me demander : « Comment moi, petit utilisateur, vais-je interroger mes données ? L’accès est-il facile ? Réussirai-je à faire mes requêtes sans difficulté ? Le langage est-il toujours le mythique SQL ? Et surtout, SURTOUT, comment puis-je protéger mes données du regard inquiétant de mon collègue du bureau d’en face ?! »

Les premières interrogations étant évidemment anodines, nous allons tenter de répondre succinctement à la dernière question. Car, oui, ce collègue a un regard très inquiétant, beaucoup trop inquiétant…

Ceci étant, ne cédons pas à la panique et voyons ce que Snowflake propose : les rôles.

Rôles

Dans Snowflake, les rôles sont utilisés pour gérer l’accès aux objets de la base de données et aux privilèges de l’utilisateur. Un rôle peut être considéré comme un groupe d’utilisateurs qui ont les mêmes autorisations sur les objets de la base de données.

Un utilisateur peut avoir plusieurs rôles lui donnant accès à différentes bases ou tables ou vues ou… enfin données quoi. Par défaut, le rôle PUBLIC est attribué à tous les utilisateurs. Il permet de se connecter à la base de données et d’exécuter des requêtes, mais ne leur donne pas accès à tous les objets. Eh oui, tout n’est pas public, oh, non mais.

C’est ici que les administrateurs ont un rôle à jouer en créant des rôles personnalisés attribuant des privilèges spécifiques. La personnalisation peut permettre de choisir un environnement en particulier (Développement vs Production) ou encore un schéma dans une base de données. Le niveau d’attribution est assez poussé pour répondre à nombre de cas. De plus, les rôles peuvent être imbriqués pour créer une hiérarchie où les privilèges sont hérités par les membres inférieurs.

Formidable ! Nous savons dorénavant que nous avons un utilisateur qui possède un ou plusieurs rôles lui permettant d’accéder à certaines données. On y voit un peu plus clair. C’est pas mal. Continuons notre belle aventure avec les notions de warehouse, ou « Entrepôt » pour les puristes même si ça n’aurait pas de sens de traduire étant donné que c’est une fonctionnalité inhérente à l’outil et que… voilà… ça serait bizarre… Bref ! Les warehouse !

Warehouse

Dans Snowflake, un warehouse est un groupe de ressources informatiques qui permettent de traiter les requêtes de manière efficace et évolutive, en fonction des besoins de l’utilisateur.

Lorsqu’un utilisateur soumet une requête, elle est envoyée au warehouse pour traitement. Il alloue alors des ressources pour traiter la requête en fonction de la taille de cette dernière et de la charge sur le système. Si la requête est grande ou si le système est chargé, le warehouse peut allouer plus de ressources pour traiter la requête plus rapidement.

Les warehouses sont complètement séparés les uns des autres, ce qui signifie qu’ils fonctionnent de manière autonome. Cela permet aux utilisateurs d’exécuter plusieurs requêtes simultanément sans interférer avec les autres requêtes en cours d’exécution. De plus, ils peuvent être configurés pour se mettre automatiquement en pause lorsqu’ils ne sont pas utilisés, ce qui permet de réduire les coûts de traitement. Les utilisateurs peuvent également configurer des plages horaires pour exécuter des requêtes en dehors des heures de pointe afin de minimiser la charge sur le système.

Associés à ces warehouses, Snowflake utilise le principe du « Shirt sizing » pour permettre l’allocation de ressources adaptées au besoin des utilisateurs en associant des tailles prédéfinies (Small, Medium, Large, etc.) à des configurations spécifiques de ressources de calcul. Ce choix de taille du warehouse peut se faire à la création ou à la modification d’un warehouse. L’évolution de la taille est dynamique permettant le redimensionnement en fonction des besoins afin d’accélérer un traitement lourd ou réduire la consommation pour des traitements plus légers.

Bien entendu, à ces tailles prédéfinies correspond une facturation. Chaque taille a un tarif associé en fonction des ressources allouées. Le monitoring de la consommation est d’autant plus important pour réduire ou mettre en pause les warehouses non utilisés ou sous exploités.

Piouuuh, ça fait de l’information tout ça, hein ? Eheh… ahah… ce n’est pas fini ! Retrouvons notre collègue-au-regard-étrange et posons nous la question : puis-je vraiment restreindre ses accès ? Suis-je en mesure de le priver de droits sur mes données ? Eh bien oui ! C’est envisageable et faisable. Pour répondre à cela : les RLS !

RLS

Les RLS. Voilà un acronyme un peu barbare. Il signifie “Regarde-pas Les Sources-toi!” ou plutôt Row Level Security, littéralement Sécurité au Niveau de la Ligne. Ce procédé de sécurité permet de restreindre l’accès aux données au niveau de chaque ligne en fonction de données prédéfinies.

Prenons un exemple : Claude-Eric, notre collègue suspicieux mains néanmoins courtois, fait partie de l’équipe “les_gens_courtois”. Cette équipe n’a pas la permission de voir les données de notre équipe, la bien nommée, “les_autres”. C’est terrible mais le regard de Claude-Eric est vraiment trop bizarre, soyons honnêtes.

Nos deux équipes partagent une table commune “tout_le_monde.les_donnees” où nos données d’activités sont stockées. Pour éviter que les tout le monde voit les données de tout le monde, nous allons définir lors de la création des objets dans Snowflake des règles d’accès aux données en fonction de l’utilisateur/utilisatrice qui se connecte. Lorsque Claude-Eric va se connecter et qu’il ira exécuter un magnifique “select * from tout_le_monde.les_donnees”, il ne verra que les données estampillées “les_gens_courtois” dans la table. Il ne pourra jamais voir nos données estampillées “les_autres”. Ainsi s’arrêtera la suspicion de Claude-Eric.

Plus concrètement, la table contenant les données sera liée à une autre table de gestion des accès où sont déclarés les utilisateurs (ou rôles). Cette table de gestion d’accès permettra de savoir que Claude-Eric ne peut voir que les données qui le concerne.

Cette image est un peu synthétique mais l’idée globale du fonctionnement est là : une table qui restreint l’accès au niveau des données stockées à la granularité ligne. C’est un mode de protection des données très efficace car l’utilisateur final ne peut pas contourner cette sécurité.

Bien. Nous avons réglé notre problème de collègues suspicieux. Maintenant que nous avons une connaissance un peu plus précise de Snowflake, bien que très légère soyons honnêtes, parlons un peu de l’échange de données et de l’architecture datamesh proposée. Oui, datamesh, oui. C’est peut-être là que réside la grande force de l’outil !

datamesh

Bon, commençons par le commencement, qu’est-ce donc que le datamesh ? Soyons clairvoyants et transparent : je ne me permettrai pas d’affirmer pouvoir expliquer ce qu’est une architecture datamesh en quelques paragraphes. Ceci étant, de ma petite posture (je mesure 1.67m ce qui est bien mais pas grand), je vais tenter d’aborder le sujet en corrélation avec Snowflake. Suivez-moi !

Une architecture datamesh se base sur des données distribuées et gérées de manière décentralisée. Chaque domaine ou service ou entité peut avoir son propre stockage dédié pour traiter ses données. Il est donc possible de gérer ce stockage comme un « projet » classique avec ses flux dédiés, sa modélisation, sa sécurité, etc. tout en faisant partie d’une plate-forme bien plus grande. Une sorte d’entité unique dans un monde bien plus vaste !

Afin d’intégrer tout cela dans son environnement, Snowflake dispose de nombreux connecteurs pour l’intégration des données provenant de différentes sources. Il est possible d’extraire, charger et transformer les données en provenance des différents domaines. Nous pouvons même configurer des pipelines ETL/ELT dans Snowflake pour l’ingestion et la transformation des données. Cela permet de fédérer la donnée pour l’utiliser par la suite.

Une fois les données fédérées au sein de Snowflake, il est possible de les partager au sein de la plate-forme. Le Data Sharing permet de gérer l’accès à la donnée et de partager des données venant de stockage différent dans Snowflake. Le partage entre différents comptes Snowflake est même disponible. Ce Data Sharing permet d’avoir accès aux données les plus pertinentes selon les besoins peu importe le service propriétaire de la donnée. Imaginez un entrepôt où plein d’outils sont stockés et où ils sont accessibles à qui en a besoin. Le partage de données et l’analytique se réjouissent de ça !

Et là, vous me direz : « Mais mon collègue au regard suspicieux, il a accès à tout ?! » Eh bien non, voyons. Restons sérieux. La sécurité fait partie intégrante de ce principe de datamesh en permettant la configuration d’accès selon les rôles utilisés. Il est par exemple possible de ne donner que des accès en lecture.

Epilogue

Bon, résumons, tirons des conclusions de ce voyage initiatique :

• Plateforme de stockage en SaaS
• Architecture permettant de stocker beaucoup de données
• Performances accrues
• Contrôle des charges associées via le « shirt sizing »
• Sécurité d’accès à la donnée
• Fédération et partage de données
• Datamesh

Eh bien, c’est plutôt intéressant tout ça. Et je dois avouer qu’après quelques mois d’utilisation éparse au début puis une peu plus fréquente par la suite, la satisfaction est bien présente. C’est un outil agréable à l’utilisation qui permet de répondre rapidement à des besoins parfois complexes. Là où certains outils traditionnels seraient à la peine, Snowflake surfe sur la vague (vous l’avez ? =D ). Enfin, la capacité de partage via le data sharing et le concept de datamesh est vraiment très intéressante. Cela simplifie grandement la mise à disposition des données pour les utilisateurs.

D’un point de vue analytics, la force de Snowflake est palpable. Couplé à des outils comme dbt pour les traitements ELT et Tableau pour la restitution, c’est une chaîne analytique vraiment intéressante. Snowflake apporte une mise à disposition de la données extrêmement rapide, dbt accélère le cycle d’évolution et d’amélioration continue du modèle et Tableau en bout de chaîne rend la restitution des données saisissante selon les besoins.

J’ai hâte de pouvoir en découvrir plus !