Cas pratiques Snowflake

Contexte : Un fichier CSV contenant des données clients doit être intégré dans Snowflake pour analyse. Le Problème : Aucune procédure de chargement n’a encore été définie. Contraintes : Créer une table adaptée. Définir un stage interne. Charger les données via COPY INTO. Assurer la compatibilité avec un fichier CSV standard. Livrable attendu : Fournir les commandes SQL permettant de créer la table, le stage et d’importer correctement le fichier CSV.

Contexte : Plusieurs warehouses de test sont utilisés occasionnellement par les développeurs. Le Problème : Ces warehouses restent actifs longtemps après usage. Configuration actuelle : AUTO_SUSPEND = 0 La suspension automatique est désactivée. Contraintes : Configurer AUTO_SUSPEND à 120 secondes. Maintenir AUTO_RESUME activé. Livrable attendu : Proposer une modification de configuration réduisant les coûts liés aux environnements de test.

Contexte : Lors du chargement d’un fichier CSV, certaines lignes sont rejetées. Le Problème : La colonne date est au format DD/MM/YYYY alors que Snowflake attend un format différent. Extrait actuel : COPY INTO sales FROM @stage FILE_FORMAT = (TYPE = CSV); Aucun format spécifique n’est défini. Contraintes : Définir un FILE FORMAT adapté avec le bon DATE_FORMAT. Ne pas modifier les données source. Livrable attendu : Proposer une configuration FILE FORMAT correcte permettant d’importer les dates sans erreur.

Contexte : Un analyste tente d’exécuter une requête SELECT sur une table mais reçoit une erreur d’autorisation. Le Problème : Le rôle assigné ne dispose pas des privilèges nécessaires. Extrait actuel : GRANT USAGE ON DATABASE sales_db TO ROLE analyst_role; Aucun privilège sur le schéma ni la table. Contraintes : Accorder les droits minimaux nécessaires (USAGE et SELECT). Respecter le principe du moindre privilège. Livrable attendu : Fournir les commandes GRANT appropriées permettant à l’analyste d’accéder à la table en lecture seule.

Contexte : L’équipe finance constate une augmentation inattendue des coûts Snowflake. Le Problème : Un warehouse reste actif en permanence même lorsqu’aucune requête n’est exécutée. Configuration actuelle : AUTO_SUSPEND = NULL AUTO_RESUME = TRUE Le warehouse ne se met jamais en pause automatiquement. Contraintes : Configurer un AUTO_SUSPEND adapté (ex : 60 secondes). Maintenir AUTO_RESUME activé. Livrable attendu : Proposer une modification de configuration permettant de réduire les coûts tout en conservant la réactivité des requêtes.

Contexte : Une table contenant des millions de lignes est fréquemment interrogée par date. Le Problème : Les performances des requêtes sont lentes car aucun clustering n’a été défini. Contraintes : Ajouter une clé de clustering basée sur la colonne date. Améliorer les performances des requêtes filtrées par période. Livrable attendu : Fournir la commande permettant d’ajouter un clustering key adaptée pour optimiser les performances.

Contexte : Votre entreprise vient de migrer ses données de ventes vers Snowflake afin de centraliser l’analyse décisionnelle. Le Problème : Aucun warehouse ni base de données n’a encore été configuré pour permettre aux analystes d’exécuter leurs requêtes. Contraintes : Créer un warehouse de taille X-SMALL. Définir une base de données et un schéma dédiés aux ventes. Accorder les permissions de lecture à un rôle analyst. Ne pas utiliser de ressources excessives. Livrable attendu : Fournir les commandes SQL nécessaires pour créer le warehouse, la base, le schéma et accorder les droits appropriés.

Contexte : Certaines lignes importées contiennent des valeurs NULL non souhaitées dans des colonnes critiques. Le Problème : Les analyses sont faussées par ces valeurs manquantes. Contraintes : Écrire une requête SQL permettant de remplacer les NULL par une valeur par défaut appropriée. Ne pas supprimer les lignes. Livrable attendu : Fournir une requête UPDATE adaptée pour corriger les données existantes.

Contexte : L’équipe métier souhaite accéder facilement au total des ventes par mois sans écrire de requêtes complexes. Le Problème : Les données brutes nécessitent une agrégation avant exploitation. Contraintes : Créer une vue SQL calculant la somme des ventes par mois à partir d’une table transactions. Utiliser GROUP BY sur une colonne date. Livrable attendu : Fournir la requête CREATE VIEW permettant de simplifier l’accès aux données agrégées.

Contexte : Deux équipes doivent accéder aux mêmes données analytiques dans Snowflake. Le Problème : Les permissions actuelles ne permettent pas un partage structuré. Contraintes : Créer un rôle intermédiaire ayant accès en lecture aux données. Assigner ce rôle aux deux équipes. Respecter le principe du moindre privilège. Livrable attendu : Fournir les commandes SQL nécessaires pour créer le rôle et attribuer les permissions adaptées.

Contexte : Votre entreprise reçoit quotidiennement des fichiers CSV déposés dans un bucket cloud contenant les nouvelles ventes. Le Problème : Le chargement manuel via COPY INTO devient impraticable et risque d’introduire des doublons. Contraintes : Mettre en place Snowpipe pour automatiser l’ingestion continue. Gérer un chargement incrémental basé sur les nouveaux fichiers uniquement. Éviter les duplications de données. Livrable attendu : Proposer l’architecture Snowpipe incluant stage, pipe et mécanisme d’auto-ingestion permettant un chargement fiable et automatisé.

Contexte : Le volume de stockage Snowflake augmente rapidement. Le Problème : Certaines tables contiennent des colonnes inutilisées ou redondantes. Contraintes : Identifier les colonnes inutiles. Mettre en place une stratégie d’archivage ou de suppression. Optimiser le stockage sans perte critique d’information. Livrable attendu : Proposer une stratégie de rationalisation des données permettant de réduire les coûts de stockage.

Contexte : Un processus d’upsert est utilisé pour synchroniser une table clients avec des données externes. Le Problème : Des doublons apparaissent malgré l’utilisation d’une instruction MERGE. Extrait actuel : MERGE INTO clients USING staging ON clients.email = staging.email WHEN NOT MATCHED THEN INSERT ... La clause UPDATE est absente. Contraintes : Corriger la logique MERGE pour gérer à la fois les insertions et les mises à jour. Garantir l’unicité des emails. Livrable attendu : Fournir une requête MERGE complète permettant un upsert fiable sans duplication.

Contexte : Certaines transactions exécutées par les analystes restent ouvertes longtemps et bloquent des ressources. Le Problème : Les sessions longues provoquent une consommation excessive de compute. Contraintes : Identifier les transactions actives. Mettre en place des politiques de gestion ou timeout appropriées. Minimiser l’impact sur les utilisateurs. Livrable attendu : Proposer une stratégie de surveillance et gestion des transactions longues afin d’optimiser l’utilisation des ressources.

Contexte : Une table volumineuse contenant des centaines de millions de lignes est fréquemment interrogée par date et région. Le Problème : Les requêtes scannent trop de micro-partitions, entraînant une latence élevée. Configuration actuelle : Aucune clé de clustering définie Les filtres sur date ne sont pas optimisés. Contraintes : Analyser le pattern de requêtes. Définir une clustering key pertinente. Éviter une surcharge de maintenance excessive. Livrable attendu : Proposer une stratégie de clustering permettant de réduire le nombre de micro-partitions scannées et améliorer les performances.

Contexte : Les analystes exécutent des requêtes complexes impliquant de larges jointures. Le Problème : Le warehouse X-SMALL provoque des temps de réponse élevés. Configuration actuelle : WAREHOUSE_SIZE = 'XSMALL' Les performances sont insuffisantes. Contraintes : Ajuster dynamiquement la taille du warehouse ou utiliser multi-cluster si nécessaire. Optimiser les coûts. Livrable attendu : Proposer une stratégie de redimensionnement adaptée aux charges analytiques lourdes tout en maîtrisant les dépenses.

Contexte : Votre organisation souhaite partager certaines données analytiques avec un partenaire externe. Le Problème : Le partage actuel via export CSV est manuel et peu sécurisé. Contraintes : Utiliser Secure Data Sharing natif de Snowflake. Limiter l’accès à certaines tables uniquement. Assurer l’absence de duplication physique des données. Livrable attendu : Proposer une configuration de partage sécurisé entre comptes Snowflake avec les commandes nécessaires.

Contexte : Une table reçoit régulièrement de nouvelles données nécessitant un traitement automatique. Le Problème : Les transformations sont actuellement exécutées manuellement. Contraintes : Utiliser Streams pour détecter les changements et Tasks pour déclencher un traitement planifié. Assurer l’idempotence du processus. Livrable attendu : Proposer une architecture utilisant Streams et Tasks permettant un traitement automatisé des nouvelles données.

Contexte : Plusieurs équipes (finance, marketing, data science) partagent la même base Snowflake mais avec des besoins d’accès différents. Le Problème : Les rôles actuels sont plats et difficiles à maintenir. Contraintes : Mettre en place une hiérarchie de rôles avec séparation claire entre privilèges de lecture, écriture et administration. Respecter le principe du moindre privilège. Livrable attendu : Proposer une architecture RBAC hiérarchique avec commandes SQL GRANT adaptées et justification des choix.

Contexte : L’équipe conformité souhaite pouvoir consulter l’état passé des données en cas d’erreur ou d’audit. Le Problème : La durée de rétention actuelle n’est pas adaptée et peut générer des coûts inutiles. Contraintes : Configurer Time Travel avec une durée adaptée au besoin métier. Équilibrer conformité et coûts de stockage. Livrable attendu : Proposer une configuration Time Travel optimale et expliquer son impact sur la gouvernance des données.

Contexte : Votre entreprise stocke une grande quantité de données brutes dans un data lake cloud. Le Problème : Les données doivent être interrogées sans duplication complète dans Snowflake. Contraintes : Utiliser des external tables. Gérer les performances et la sécurité d’accès. Assurer la compatibilité avec les outils BI existants. Livrable attendu : Proposer une architecture hybride combinant Snowflake et external tables permettant d’interroger efficacement les données du data lake.

Contexte : Votre groupe international possède plusieurs entités utilisant chacune leur propre compte Snowflake. Le Problème : Il n’existe aucune gouvernance centralisée des rôles, des accès ni des standards de sécurité entre comptes. Contraintes : Mettre en place une stratégie Organization-level avec partage sécurisé, rôles standardisés et séparation claire des environnements (dev, test, prod). Garantir conformité et auditabilité. Livrable attendu : Proposer une architecture multi-comptes détaillant gouvernance des accès, partage sécurisé inter-compte et gestion centralisée des politiques de sécurité.

Contexte : Les coûts Snowflake augmentent fortement suite à l’exécution de requêtes ad hoc mal optimisées. Le Problème : Certaines requêtes effectuent des scans complets inutiles sur de larges tables. Contraintes : Identifier les requêtes les plus coûteuses via QUERY_HISTORY. Optimiser les jointures et filtres. Mettre en place une gouvernance d’usage. Livrable attendu : Proposer une stratégie de contrôle et d’optimisation des requêtes permettant de réduire les coûts compute.

Contexte : Des requêtes analytiques complexes provoquent régulièrement la saturation CPU du warehouse principal. Le Problème : Un seul warehouse traite simultanément charges ETL et requêtes BI interactives. Configuration actuelle : Un warehouse partagé pour tous les usages Cela provoque contention et latence. Contraintes : Séparer les workloads. Mettre en place une stratégie multi-warehouse adaptée. Optimiser les coûts et éviter la surconsommation inutile. Livrable attendu : Proposer une architecture de séparation des workloads permettant d’améliorer performance et isolation des ressources.

Contexte : Plusieurs pipelines ETL écrivent simultanément dans la même table. Le Problème : Des conflits ou incohérences apparaissent lors des opérations concurrentes. Contraintes : Garantir l’isolation transactionnelle appropriée. Réviser la logique d’écriture (MERGE ou staging intermédiaire). Préserver la cohérence des données. Livrable attendu : Proposer une stratégie robuste de gestion des écritures concurrentes minimisant les conflits et erreurs.

Contexte : Un pipeline Snowflake utilise Streams et Tasks pour transformer des données entrantes. Le Problème : Certaines données sont traitées plusieurs fois, générant des duplications en aval. Extrait logique actuelle : SELECT * FROM my_stream; Aucune gestion d’idempotence n’est prévue. Contraintes : Garantir que chaque enregistrement soit traité une seule fois. Préserver l’intégrité des données. Livrable attendu : Proposer une correction du pipeline Streams/Tasks assurant un traitement fiable et sans duplication.

Contexte : L’entreprise doit se conformer à des exigences réglementaires strictes concernant l’audit et la traçabilité des accès aux données. Le Problème : Les logs d’accès ne sont pas centralisés et l’audit manuel est complexe. Contraintes : Utiliser les vues ACCOUNT_USAGE et ACCESS_HISTORY. Mettre en place une stratégie d’audit automatisée. Garantir la conservation des preuves. Livrable attendu : Proposer une architecture d’audit Snowflake permettant une traçabilité complète des accès et modifications des données.

Contexte : Certaines colonnes contiennent des données sensibles (emails, numéros fiscaux). Le Problème : Tous les utilisateurs ayant accès à la table peuvent voir les données complètes. Contraintes : Mettre en place des politiques de masking dynamique basées sur le rôle utilisateur. Assurer que seuls certains rôles voient les données en clair. Livrable attendu : Proposer une configuration de dynamic data masking garantissant la protection des données sensibles selon les privilèges définis.

Contexte : Une table transactionnelle contient plusieurs milliards de lignes et subit des requêtes fréquentes filtrées par date et région. Le Problème : Malgré une clé de clustering définie, les requêtes scannent un nombre important de micro-partitions. Contraintes : Analyser les patterns d’accès. Ajuster la clustering key ou restructurer la table si nécessaire. Minimiser les coûts de reclustering. Livrable attendu : Proposer une stratégie avancée d’optimisation des micro-partitions permettant de réduire drastiquement le volume scanné.

Contexte : Les analystes exécutent des requêtes impliquant plusieurs jointures sur des tables volumineuses. Le Problème : Les performances sont variables et parfois imprévisibles. Contraintes : Analyser les patterns de requêtes. Évaluer la possibilité de tables matérialisées ou vues matérialisées. Optimiser les jointures. Livrable attendu : Proposer une refonte partielle du modèle ou l’usage de matérialisation pour améliorer la stabilité des performances analytiques.