Snowflake est désormais la norme de facto pour les plates-formes d'entrepôt de données cloud. Il est conçu pour prendre en charge une variété de tâches de données depuis les pipelines, l'ETL, l'analyse et la gouvernance. Traditionnellement, toutes les données devaient être déplacées dans Snowflake pour qu'une entreprise puisse tirer parti des fonctionnalités de Snowflake.
Snowflake a cependant compris que les entreprises souhaitaient intégrer leurs données où qu'elles se trouvent, sans avoir à déplacer les données. Par conséquent, avec l'introduction du support de table externe, les entreprises pourront désormais y parvenir.
Cela a des impacts réels, à la fois sur l'économie du déploiement de Snowflake, mais aussi sur la quantité de données disponibles sur la plateforme Snowflake pour l'analyse et la science des données.
La disponibilité des tables externes ne changera pas les emplacements où Snowflake s'exécute - il fonctionnera toujours exclusivement dans les trois principaux clouds publics (AWS, GCP, Azure). Cependant, cela supprimera l'exigence selon laquelle toutes les données doivent être stockées dans Snowflake pour que Snowflake puisse fonctionner dessus.
MinIO est peut-être le plus grand bénéficiaire de ce changement. MinIO est un magasin d'objets cloud natif hautes performances. Il fonctionnera sur toutes les versions de Kubernetes (en amont, EKS, AKS, GKE, etc.) ainsi que sur des machines virtuelles comme les VM du cloud public, VMWare, etc. et sur du matériel bare metal. Pour cette raison, MinIO peut devenir le magasin de données mondial pour les clients Snowflake, où que se trouvent leurs données.
Pour garantir que les bonnes données sont disponibles pour le bon utilisateur, il est impératif qu'il y ait un contrôle d'accès fin sur ces lacs de données multi-cloud. La capacité de MinIO à s'intégrer à des IDP tiers et ses capacités sophistiquées de contrôle d'accès basé sur des politiques (PBAC) garantissent qu'il ne s'agit pas d'une réflexion après coup.
Bien que Snowflake prenne en charge les points de terminaison S3 (qui incluent naturellement d'autres magasins d'objets), ces magasins d'objets ne sont pas capables de s'exécuter dans tous les endroits où une entreprise conserve ses données. Par exemple, les appliances ne fonctionnent pas dans le cloud public ou sur OpenShift ou Tanzu. Pour parvenir à une stratégie cohérente de données partout, les entreprises devront adopter MinIO.
De plus, Snowflake est devenu une mission essentielle dans l'entreprise. À tel point que la résilience est désormais intégrée à ces systèmes. Cette résilience ne tient pas seulement compte de l'échec de la région dans le cloud, elle tient compte de l'échec complet du cloud.
La dépendance au cloud unique s'est avérée être une mauvaise architecture, comme je l'ai écrit précédemment. MinIO, avec sa capacité à être disponible partout et à se répliquer entre les clouds privés, publics et périphériques, fournit la seule véritable solution pour la disponibilité des données multi-cloud.
Alors, est-ce simple pour l'utilisateur final ? Imaginez que vous ayez un bucket dans MinIO appelé "Bucket1". Vous pouvez le configurer de manière à pouvoir exécuter n'importe quelle commande SnowSQL dessus comme s'il s'agissait simplement d'une autre table.
Par exemple : Sélectionnez * dans Bucket1 ;
Comme la plupart des choses dans Snowflake, la connexion à vos données stockées sur MinIO est également relativement simple.
Voici ce dont vous avez besoin pour commencer :
La prise en charge des tables externes doit être activée pour votre environnement Snowflake. Si vous obtenez des erreurs comme 'préfixe d'URL non valide trouvé dans : ' s3compat://snowflake/ ', cela signifie probablement qu'il n'est pas activé. Veuillez contacter votre représentant Snowflake pour l'activer.
Il n'y a que quelques exigences sur la configuration de MinIO pour qu'elle fonctionne avec Snowflake.
Dans l'exemple ci-dessous, le compartiment "flocon de neige" contient 4 objets et un autre objet dans le dossier/sous-préfixe "sn1". Snowflake récupérera tous ces objets.
Afin de l'intégrer à Snowflake, si le serveur MinIO est sur https://play.min.io , le compartiment doit être accessible sur https://snowflake.play.min.io
Les exemples de fichiers sont disponibles sur https://docs.snowflake.com/en/user-guide/getting-started-tutorial-prerequisites.html#sample-data-files-for-loading
Les buckets MinIO peuvent être intégrés à Snowflake de deux manières. Le premier est en tant que "Staging Area" et le second en tant que table externe. Regardons les deux
Dans le cadre d'un processus ETL, les données sont normalement sélectionnées et préparées à partir d'une source de données ou d'un lac de données, déplacées dans une zone de préparation, puis chargées dans un entrepôt afin que les requêtes puissent être exécutées dessus.
Traditionnellement, ces zones de transit pour Snowflake se trouvaient dans Snowflake lui-même, c'était donc le flux :
Lac de données (sur site, cloud public, etc.) -> Staging Snowflake -> Table interne Snowflake
Les entreprises peuvent désormais configurer MinIO en tant que zone intermédiaire et déplacer les données directement dans une table Snowflake interne pour y exécuter des requêtes.
Cela fait ce qui suit
Le nouveau flux serait : Données dans MinIO (sur site, cloud public, etc.) -> Table interne Snowflake
Les exemples suivants sont affichés dans la console Snowflake, mais ils peuvent être exécutés via la CLI Snowflake.
Pour play.min.io , utilisez
AWS_KEY_ID='Q3AM3UQ867SPQQA43P2F'
AWS_SECRET_KEY='zuf+tfteSlswRu7BJ86wekitnifILbZam1KYY3TG'
La référence de la commande Snowflake CREATE STAGE est disponible ici : https://docs.snowflake.com/en/sql-reference/sql/create-stage.html
Les requêtes dans Snowflake devaient être effectuées sur des tables internes. Cela signifiait que toutes les données - même pour les requêtes ad hoc - devaient être déplacées vers Snowflake. Cela a entraîné à la fois des coûts et l'impossibilité d'interroger en temps opportun.
Les entreprises peuvent désormais accéder directement aux données des compartiments MinIO à l'aide des nouvelles fonctionnalités d'accès aux tables externes introduites par Snowflake.
Le temps pris par la requête initiale dépendra de la quantité de données transférées, mais les lectures sont mises en cache et les requêtes suivantes peuvent être plus rapides jusqu'à la prochaine actualisation.
En utilisant l'approche de table externe, les données n'ont pas besoin d'être copiées et le compartiment peut être utilisé comme table externe pour les requêtes, les jointures, etc.
Cependant, en échange, les avantages sont énormes.
Un exemple est illustré ci-dessous :
La référence de la commande Snowflake CREATE EXTERNAL TABLE est disponible ici : https://docs.snowflake.com/en/sql-reference/sql/create-external-table.html
Les mêmes commandes peuvent être exécutées à l'aide de la CLI Snowflake (SnowSQL).
Vous pouvez trouver les instructions sur la façon d'installer SnowSQL sur votre plate-forme ici : https://docs.snowflake.com/en/user-guide/snowsql-install-config.html
La seule différence est que vous devez commencer par la commande
$ snowsql -a <identifiant_compte> -u <nom_utilisateur>
L'identifiant de compte est au format <organization-name>-<account-name>. Vous pouvez le trouver sur la page Admin de la console Snowflake.
Et c'est tout.
Si vous êtes un client MinIO cherchant à ajouter des fonctionnalités Snowflake ou si vous êtes un client Snowflake cherchant à étendre ses capacités aux données stockées en dehors de Snowflake, essayez-le. Dans tous les cas, vous tirerez le meilleur parti de votre investissement actuel.
Également publié ici .