Notes de version 9.21 : 29 juillet 2025 - 1er août 2025¶

GENERATE_SYNTHETIC_DATA : Le secret de cohérence est désormais facultatif dans la plupart des cas¶

Auparavant, lorsque vous appeliez GENERATE_SYNTHETIC_DATA avec une propriété de remplacement de colonne, vous deviez fournir un SECRET pour consistency_secret. Avec cette modification, consistency_secret est désormais facultatif. Cependant, si vous exécutez GENERATE_SYNTHETIC_DATA dans une procédure stockée avec droits de propriétaire, vous devez toujours fournir une valeur à consistency_secret.

Utilisation du compte : vues TABLE_QUERY_PRUNING_HISTORY et COLUMN_QUERY_PRUNING_HISTORY (Mise à disposition générale)¶

Vous pouvez surveiller les modèles d’accès aux données au niveau des tables et des colonnes en interrogeant deux nouvelles vues d’utilisation du compte :

• TABLE_QUERY_PRUNING_HISTORY fournit une ventilation du temps d’exécution des requêtes et de l’élagage par table, hachage de requête et entrepôt.

• COLUMN_QUERY_PRUNING_HISTORY renvoie un résumé d’élagage équivalent qui est agrégé par nom de colonne.

La fonction SEARCH_IP prend en charge la recherche d’adresses IPv6¶

Vous pouvez utiliser la fonction SEARCH_IP pour rechercher des adresses IPv6 dans les données. Auparavant, la fonction ne prenait en charge que la recherche d’adresses IPv4.

Pour plus d’informations, voir SEARCH_IP.

Génération de YAML pour une vue sémantique et création d’une vue sémantique à partir de YAML¶

Pour générer la spécification YAML pour une vue sémantique, vous pouvez appeler la fonction SYSTEM$READ_YAML_FROM_SEMANTIC_VIEW. Par exemple :

SELECT SYSTEM$READ_YAML_FROM_SEMANTIC_VIEW(
  'my_db.my_schema.tpch_rev_analysis'
);

Vous pouvez également créer une vue sémantique à partir d’une spécification YAML en appelant la procédure stockée SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML. Par exemple :

CALL SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML(
  'my_db.my_schema',
  $$
  name: TPCH_REV_ANALYSIS
  description: Semantic view for revenue analysis
  ...
  $$
);

Pour plus d’informations, voir :

• SYSTEM$READ_YAML_FROM_SEMANTIC_VIEW

• SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML

Tarification simplifiée de Snowpipe¶

À compter du 1er août 2025, nous mettrons en place un nouveau modèle de tarification simplifié pour Snowpipe pour tous les comptes Business Critical et VPS. Au lieu d’une facturation à la seconde/par cœur de calcul et d’une redevance par 1 000 fichiers, vous vous verrez désormais facturer une quantité de crédit fixe par gigaoctet (GB) de données ingérées. Cette modification vous permettra de mieux prévoir vos coûts d’ingestion de données.

• Les fichiers texte (par exemple, CSV, JSON) sont facturés en fonction de leur taille non compressée.

• Les fichiers binaires (par exemple, Parquet, Avro) sont facturés en fonction de leur taille observée.

Ce nouveau modèle est automatiquement appliqué à tous les comptes Business Critical et VPS. Les versions Enterprise et Standard seront mises à jour ultérieurement.

Pour plus d’informations, consultez le tableau de consommation du service Snowflake et Coûts Snowpipe.

Snowpark Connect for Spark et Snowpark Submit (Preview)¶

Avec Snowpark Connect for Spark, vous pouvez exécuter Spark DataFrame, SQL et les APIs UDF directement sur la plateforme Snowflake en utilisant le même code Spark que celui que vous utilisez actuellement. Vous pouvez développer à l’aide d’outils client tels que Snowflake Notebooks, Jupyter Notebooks et autres. Avec Snowpark Submit, vous pouvez exécuter des charges de travail Spark de manière non interactive et asynchrone directement sur l’infrastructure Snowflake tout en utilisant la sémantique Spark qui vous est familière.

Snowpark Connect for Spark et Snowpark Submit sont en Avant-première.

Pour plus d’informations, voir Exécuter des charges de travail Spark sur Snowflake avec Snowpark Connect for Spark.