Optimiser les performances des tables dynamiques¶

Simplifier les requêtes individuelles¶

• Utilisez des jointures internes à la place des jointures externes. Les jointures internes sont plus performantes avec une actualisation incrémentielle. Vérifiez l’intégrité référentielle de vos données sources afin d’éviter les jointures externes.

• Évitez les opérations inutiles. Supprimez les clauses DISTINCT redondantes et les colonnes inutilisées. Excluez les grandes colonnes (comme les blobs JSON volumineux) qui ne sont pas fréquemment interrogées.

• Supprimez efficacement les doublons. Utilisez des fonctions de classement au lieu de DISTINCT lorsque cela est possible.

Pour obtenir des conseils détaillés sur la manière dont des opérateurs SQL spécifiques affectent les performances de l’actualisation incrémentielle, consultez Optimiser les requêtes pour l’actualisation incrémentielle.

Répartition des transformations entre les tables dynamiques¶

Le fait de répartir les transformations complexes en plusieurs tables dynamiques facilite l’identification des obstacles et améliore le débogage. Avec les contraintes d’immuabilité, vous pouvez également utiliser différents modes d’actualisation pour différentes zones de préparation.

• Ajoutez des filtres tôt. Appliquez les clauses WHERE dans les tables dynamiques les plus proches de vos données sources afin que les tables en aval traitent moins de lignes.

• Pour éviter des opérations DISTINCT répétées dans les tables en aval, supprimez les lignes en double plus tôt dans votre pipeline.

• Réduisez le nombre d’opérations par table. Déplacez les jointures, les agrégations ou les fonctions de fenêtre dans des tables dynamiques intermédiaires au lieu de les combiner dans une seule requête.

• Matérialisez les expressions composées (comme DATE_TRUNC('minute', ts)) dans une table intermédiaire avant de les regrouper. Pour plus de détails, voir Optimiser les agrégations.

L’exemple suivant montre comment diviser une requête complexe en tables dynamiques intermédiaires.

Requête initiale complexe :

CREATE DYNAMIC TABLE final_result
  TARGET_LAG = '1 hour'
  WAREHOUSE = my_warehouse
AS
  SELECT ...
  FROM large_table a
  JOIN dimension_table b ON ...
  JOIN another_table c ON ...
  GROUP BY ...;

Fractionnez le pipeline complexe en ajoutant une table dynamique intermédiaire :

CREATE DYNAMIC TABLE intermediate_joined
  TARGET_LAG = DOWNSTREAM
  WAREHOUSE = my_warehouse
AS
  SELECT ...
  FROM large_table a
  JOIN dimension_table b ON ...;

CREATE DYNAMIC TABLE final_result
  TARGET_LAG = '1 hour'
  WAREHOUSE = my_warehouse
AS
  SELECT ...
  FROM intermediate_joined
  JOIN another_table c ON ...
  GROUP BY ...;

Pour obtenir des informations détaillées et des exemples sur la manière dont les opérateurs affectent les performances, consultez Optimiser les requêtes pour l’actualisation incrémentielle.

Utiliser un entrepôt séparé pour l’initialisation¶

Les actualisations initiales traitent souvent beaucoup plus de données que les actualisations incrémentielles. Utilisez INITIALIZATION_WAREHOUSE pour exécuter des initialisations sur un entrepôt plus volumineux. Réservez un entrepôt plus petit et plus rentable pour des actualisations régulières :

CREATE DYNAMIC TABLE my_dynamic_table
  TARGET_LAG = 'DOWNSTREAM'
  WAREHOUSE = 'XS_WAREHOUSE'
  INITIALIZATION_WAREHOUSE = '4XL_WAREHOUSE'
  AS <query>;

Pour ajouter ou modifier l’entrepôt d’initialisation d’une table dynamique existante, procédez comme suit :

ALTER DYNAMIC TABLE my_dynamic_table SET INITIALIZATION_WAREHOUSE = '4XL_WAREHOUSE';

Pour supprimer l’entrepôt d’initialisation et utiliser l’entrepôt principal pour toutes les actualisations, procédez comme suit :

ALTER DYNAMIC TABLE my_dynamic_table UNSET INITIALIZATION_WAREHOUSE;

Pour voir la configuration de l’entrepôt, utilisez SHOW DYNAMIC TABLES ou vérifiez la fonction de table DYNAMIC_TABLE_REFRESH_HISTORY.

Redimensionner si nécessaire¶

Pour équilibrer les coûts et les performances, choisissez une taille d’entrepôt qui empêche les octets de se déverser, mais qui ne dépasse pas ce que votre charge de travail peut utiliser en parallèle. Lorsque des actualisations plus rapides sont essentielles, augmentez la taille légèrement au-delà du point optimal en matière de coût.

Considérations relatives à l’actualisation des tables dynamiques :

• Octets déversés : Lorsque l’historique des requêtes indique que des octets se sont déversés sur le stockage local ou le stockage distant, ’”entrepôt a épuisé la mémoire lors de l’actualisation. Un entrepôt plus grand fournit plus de mémoire pour éviter les déversements. Pour plus de détails, voir Requêtes trop volumineuses pour la mémoire.

• Actualisation initiale lente : Lorsque l’actualisation initiale est lente, envisagez de définir INITIALIZATION_WAREHOUSE pour la création initiale, ou redimensionnez temporairement l’entrepôt, puis redimensionnez-le après la création de la table.

• Parallélisme saturé : Au-delà d’un certain point, le parallélisme supplémentaire fournit des rendements décroissants. Le fait de doubler la taille de l’entrepôt peut doubler les coûts sans réduire de moitié la durée d’exécution. Pour vérifier comment votre actualisation utilise le parallélisme, examinez le profil de requête.

Pour redimensionner un entrepôt, consultez Augmentation de la taille des entrepôts.

Pour connaître les considérations relatives aux coûts, consultez Utilisation du crédit d’entrepôt virtuel et Utilisation d’entrepôts.

Gérer les actualisations simultanées avec les entrepôts multi-clusters¶

Si plusieurs tables dynamiques partagent un entrepôt et actualisent fréquemment la file d’attente, envisagez d’utiliser un entrepôt multi-clusters. Les entrepôts multi-clusters ajoutent automatiquement des clusters lorsque les requêtes sont mises en file d’attente et les suppriment lorsque la demande diminue. Cela améliore la latence d’actualisation pendant les périodes de forte activité sans avoir à payer pour la capacité inutilisée pendant les périodes creuses.

Pour obtenir des conseils sur l’identification et la réduction des files d’attente, consultez Réduction des files d’attente.

Les entrepôts multi-clusters nécessitent Enterprise Edition ou une version supérieure. Pour connaître les considérations relatives aux coûts, consultez Définition de la politique de mise à l’échelle d’un entrepôt multi-clusters.

Modifier la latence cible¶

ALTER DYNAMIC TABLE my_dynamic_table SET TARGET_LAG = '1 hour';

Pour définir une table dynamique de sorte qu’elle soit actualisée en fonction de la demande en aval, procédez comme suit :

ALTER DYNAMIC TABLE my_dynamic_table SET TARGET_LAG = DOWNSTREAM;

Cluster de tables sources¶

Le moyen le plus efficace d’améliorer la localité est de regrouper vos tables sources en fonction des clés utilisées dans votre requête de table dynamique (clés JOIN, GROUP BY ou PARTITION BY) :

ALTER TABLE my_source_table CLUSTER BY (join_key_column);

Lorsque vous joignez plusieurs colonnes et que vous ne pouvez pas toutes les clusteriser :

• Priorisez le clustering des tables plus volumineuses en fonction des clés les plus sélectives.

• Envisagez de créer des copies séparées des mêmes données clusterisées en fonction de différentes clés pour les utiliser dans différentes tables dynamiques.

Pour plus d’informations, voir Clés de clustering et tables en cluster. Pour activer le reclustering automatique, consultez Clustering automatique.

Facteurs qui affectent la localité¶

Au-delà du clustering de la table source, deux autres facteurs affectent la localité. Ceux-ci dépendent de vos modèles de données et sont plus difficiles à modifier directement :

• Comment les nouvelles données s’alignent sur les clés de partition : L’actualisation incrémentielle est plus rapide lorsque les nouvelles lignes n’affectent qu’une petite partie de la table. Cela dépend de vos modèles d’ingestion de données, et non de la structure de vos requêtes.

  Par exemple, les données de séries temporelles regroupées par heure présentent une bonne localité, car de nouvelles lignes partagent des horodatages récents. Les données regroupées par une colonne dont les valeurs sont réparties sur l’ensemble de la table présentent une faible localité.

• Comment les changements s’alignent sur le clustering des tables dynamiques : Lorsque Snowflake applique des mises à jour ou des suppressions à une table dynamique, il doit localiser les lignes affectées. Cela est plus rapide lorsque les lignes modifiées sont stockées proches les unes des autres.

  Par exemple, les mises à jour des lignes récentes fonctionnent bien lorsque la table dynamique est naturellement ordonnée en fonction du temps. Les mises à jour réparties sur l’ensemble de la table sont plus lentes. Ce facteur dépend de vos modèles de charge de travail, y compris des lignes qui changent et de la fréquence à laquelle elles changent.

Lorsque vous constatez une faible localité en raison de ces facteurs, demandez-vous si vous pouvez ajuster votre modèle de données ou vos modèles d’ingestion en amont.