Snowflake
SnowPro Core : 5 pièges sur les performances, les droits et le stockage
Sur Snowflake, une requête plus rapide après un changement de warehouse peut simplement réutiliser un résultat en cache. Un clone peut conserver du stockage après la suppression de sa table source. Et les droits sur les futures tables, définis au niveau de la base, sont ignorés si des droits sur les futures tables sont aussi définis au niveau du schéma.
1. La requête attend avant même de démarrer
| État | Cause | Action à envisager |
|---|---|---|
| Queued | Le warehouse reçoit plus de travail qu’il ne peut en traiter. | Séparer les traitements ou ajouter des clusters pour exécuter plus de requêtes en parallèle. |
| Queued (Provisioning) | Snowflake prépare les ressources, par exemple au redémarrage. | Vérifier la fréquence des démarrages et le réglage AUTO_SUSPEND. |
| Blocked | Une autre transaction détient un verrou. | Identifier la transaction qui bloque la requête. |
Ajouter des clusters aide lorsque plusieurs requêtes se disputent les ressources. Cela ne répartit pas une requête lente sur plusieurs clusters, elle reste sur un seul. Le multi-clusters demande Enterprise Edition ou une édition supérieure.
Sépare d’abord le temps d’attente du temps d’exécution. Si la requête reste lente quand elle tourne seule, ouvre son Query Profile. Agrandir le warehouse profite aux requêtes suivantes et ne change pas celles qui sont déjà en cours.
Références : Snowflake : taille, concurrence et warehouses multi-clusters, Snowflake : attente de ressources et transactions bloquantes
2. Le warehouse plus grand paraît plus rapide grâce au cache
Snowflake peut renvoyer un résultat déjà calculé sans réexécuter la requête. Il faut notamment le même texte de requête, des données inchangées et un rôle qui a les droits nécessaires sur toutes les tables interrogées. Une réponse immédiate après un changement de taille ne mesure pas l’effet de cette taille.
USE_CACHED_RESULT = FALSE désactive la réutilisation des résultats, mais ne vide pas le cache local du warehouse. Ce cache conserve des données déjà lues et sa capacité dépend de la taille du warehouse. La suspension le vide. Un test de performance doit donc tenir compte des deux mécanismes.
Pour comparer deux tailles, garde la même charge et sépare le premier passage après démarrage des passages suivants. Sinon, le gain mesuré peut venir du cache et non de la taille.
Références : Snowflake : fonctionnement du cache du warehouse, Snowflake : réutilisation des résultats de requête
3. Les nouvelles tables restent invisibles pour un rôle
| Clause | Tables concernées |
|---|---|
| ON ALL TABLES | Les tables qui existent au moment du GRANT. |
| ON FUTURE TABLES | Les tables créées après le GRANT. Un renommage ou un SWAP ne déclenche pas ces droits. |
ALL veut dire toutes les tables présentes au moment de la commande, pas toutes celles qui existeront un jour. Pour couvrir les tables existantes et celles à venir, il faut les deux GRANT.
Si des future grants portent sur le même type d’objet dans la base et dans le schéma, ceux du schéma sont prioritaires. Les droits futurs posés sur la base sont alors ignorés dans ce schéma, même pour un autre rôle.
Références : Snowflake : configuration des accès et rôles de lecture
4. La facture de stockage ne baisse pas après le DROP de la source
Sur les tables standard, un clone réutilise au départ les micro-partitions de la source, sans seconde copie. Chaque modification ultérieure, sur l’une ou l’autre table, crée de nouvelles micro-partitions facturées.
Supprimer la source ne suffit pas à libérer ses micro-partitions. Si un clone les utilise encore, Snowflake doit les garder. Une table permanente supprimée reste aussi facturée pendant sa rétention Time Travel, puis pendant les 7 jours de Fail-safe. DROP n’efface donc pas immédiatement la ligne de coût.
Dans TABLE_STORAGE_METRICS, chaque octet est facturé à la table qui l’a ajouté en premier. RETAINED_FOR_CLONE_BYTES figure donc sur la ligne de la source, même supprimée, et donne les octets conservés parce qu’un clone les utilise encore. La colonne BYTES de SHOW TABLES mesure au contraire le volume lu par un scan complet. L’additionner pour une source et son clone compte deux fois les données partagées.
Références : Snowflake : stockage des tables clonées
5. Une table transient ne se récupère pas comme une permanente
Une table transient garde ses données entre les sessions, mais n’a aucun Fail-safe. Son Time Travel est limité à zéro ou un jour, même en Enterprise.
Avant de choisir transient, vérifie comment reconstruire la table une fois sa rétention dépassée. Pour du staging, il faut conserver la source et le traitement. L’économie porte sur le Fail-safe et, avec une rétention à zéro, sur le Time Travel. Le coût des requêtes ne baisse pas pour autant.
ALTER TABLE ne convertit pas une table transient en permanente. Il faut créer une nouvelle table et y copier les données.
Références : Snowflake : tables temporaires et transient
Sources
- Snowflake : taille, concurrence et warehouses multi-clusters
- Snowflake : fonctionnement du cache du warehouse
- Snowflake : réutilisation des résultats de requête
- Snowflake : configuration des accès et rôles de lecture
- Snowflake : stockage des tables clonées
- Snowflake : tables temporaires et transient
- Snowflake : attente de ressources et transactions bloquantes
Préparation indépendante, sans affiliation aux éditeurs. Une information à corriger ? Signaler le passage concerné.
Travaille ces règles dans nos examens blancs
Les questions SnowPro Core sur DataCertification reprennent les performances, les droits et le stockage. Les corrections permettent de comprendre quelle règle s’applique avant de refaire une série.
Voir la préparation SnowPro Core