Août 2022¶

Prise en charge du type de données GEOMETRY — Avant-première¶

Avec cette version, nous avons le plaisir de vous présenter en avant-première la prise en charge du nouveau type de données GEOMETRY. Le type de données GEOMETRY représente les caractéristiques dans un système de coordonnées planes (euclidien, cartésien). Cette fonctionnalité est disponible pour tous les comptes Snowflake.

Cette version fournit des fonctions pour la construction, le formatage, la mesure et le calcul des relations entre des objets GEOMETRY. Grâce à ces fonctions, vous pouvez construire des objets GEOMETRY à partir de données aux formats standard, notamment WKT, WKB et GeoJSON.

Pour plus d’informations, voir Types de données géospatiales.

Les fonctionnalités en avant-première sont destinées à des fins d’évaluation et de test. Ces fonctionnalités ne sont pas recommandées pour une utilisation en production.

Procédures stockées Snowpark en Java — Disponibilité générale¶

Avec cette version, nous avons le plaisir d’annoncer la disponibilité générale des procédures stockées Snowpark écrites en Java sur Amazon Web Services (AWS) et Microsoft Azure. Les procédures stockées pour Java sont disponibles en avant-première sur Google Cloud Platform (GCP).

Dans votre procédure stockée, vous pouvez utiliser l’API Snowpark pour Java pour héberger vos pipelines de données dans Snowflake. Par exemple, vous pouvez écrire des procédures stockées dans les cas où vous devez exécuter votre code Snowpark sans lancer une application client (par exemple, à partir d’une tâche).

Pour plus d’informations, consultez Écriture de procédures stockées en Java.

Procédures stockées Snowpark en Scala — Disponibilité générale¶

Avec cette version, nous avons le plaisir d’annoncer la disponibilité générale des procédures stockées Snowpark écrites en Scala sur Amazon Web Services (AWS) et Microsoft Azure. Les procédures stockées pour Scala sont disponibles en avant-première sur Google Cloud Platform (GCP).

Dans votre procédure stockée, vous pouvez utiliser l’API Snowpark pour Scala pour héberger vos pipelines de données dans Snowflake. Par exemple, vous pouvez écrire des procédures stockées dans les cas où vous devez exécuter votre code Snowpark sans lancer une application client (par exemple, à partir d’une tâche).

Pour plus d’informations, consultez Écriture de procédures stockées en Scala.

Réplication de compte — Avant-première¶

Avec cette version, nous avons le plaisir d’annoncer en avant-première ouverte la prise en charge de la réplication de compte. Cette fonctionnalité introduit deux nouveaux objets Snowflake, le groupe de réplication et le groupe de basculement. Un groupe de réplication permet aux clients de spécifier les objets de compte à répliquer, vers quelles régions ou plates-formes Cloud, à des intervalles planifiés personnalisables. Un groupe de basculement permet la réplication et le basculement des objets de compte dans un groupe. Les objets d’un groupe sont répliqués avec une cohérence ponctuelle depuis un compte source vers un ou plusieurs comptes cibles.

Les objets du compte peuvent inclure des entrepôts, des utilisateurs et des rôles, ainsi que des bases de données et des partages (voir Objets répliqués pour obtenir la liste complète des objets qui peuvent être inclus dans un groupe de réplication ou de basculement). Les objets du compte peuvent être regroupés en un ou plusieurs groupes.

Dans le cas d’un basculement, la réplication de compte permet le basculement de l’ensemble de votre compte vers une autre région ou une autre plate-forme Cloud. Chaque groupe de réplication et de basculement possède sa propre planification de réplication, ce qui vous permet de définir la fréquence de réplication à différents intervalles pour différents groupes d’objets. Dans le cas des groupes de basculement, il permet également le basculement des groupes de façon individuelle. Vous pouvez choisir de basculer tous les groupes de basculement ou seulement certains groupes de basculement.

Fonction INFER_SCHEMA : nouveaux paramètres¶

Dans cette version, Snowflake fournit deux nouveaux arguments pour la fonction INFER_SCHEMA :

FILES = ( 'file_name' [ , 'file_name' ... ] )

Spécifie une liste d’un ou plusieurs noms de fichiers (séparés par des virgules) dans un ensemble de fichiers en zone de préparation qui contiennent des données semi-structurées.

IGNORE_CASE = TRUE | FALSE

Spécifie si les noms de colonnes détectés à partir de fichiers en zone de préparation sont traités en respectant la casse. Par défaut, la valeur est FALSE ce qui signifie que Snowflake préserve la casse des caractères alphabétiques lors de la récupération des noms de colonnes. Si vous spécifiez la valeur TRUE, les noms de colonnes sont traités comme insensibles à la casse et tous les noms de colonnes sont récupérés en lettres majuscules.

Dans une prochaine version, la sortie de la fonction INFER_SCHEMA comprendra une nouvelle colonne ORDER_ID qui indiquera l’ordre des colonnes dans les fichiers en zone de préparation. Pour plus d’informations, voir le journal des changements de comportement.

CREATE EXTERNAL TABLE : dériver des définitions de colonnes à partir de fichiers en zone de préparation — Avant-première¶

Avec cette version, Snowflake prend en charge la création de nouvelles tables externes avec les définitions de colonnes dérivées d’un ensemble de fichiers en zone de préparation contenant des données semi-structurées. Incluez les mots-clés USING TEMPLATE dans vos instructions CREATE EXTERNAL TABLE. Auparavant, cette capacité était limitée aux tables.

Par exemple :

CREATE OR REPLACE EXTERNAL TABLE myet
    USING TEMPLATE (
      SELECT ARRAY_AGG(OBJECT_CONSTRUCT(*))
        FROM TABLE(
          INFER_SCHEMA(
            LOCATION=>'@filestage',
            FILE_FORMAT=>'ffparquet'
          )
        )
    )
    location=@filestage
    file_format=ffparquet
    auto_refresh=false;

Nouvelles fonctions SQL¶

La ou les fonctions suivantes ont été introduites dans des versions récentes :

Tâches : prise en charge de la spécification de prédécesseurs dans une seule instruction SQL.¶

Un graphe orienté acyclique (DAG) de tâches se compose d’une seule tâche racine et d’un ensemble de tâches enfants, organisées par leurs dépendances. Toutes les tâches d’un DAG, à l’exception de la tâche racine et de ses enfants directs, peuvent avoir plusieurs prédécesseurs. Une tâche ne s’exécute que lorsque tous les prédécesseurs ont été exécutés avec succès jusqu’à leur terme.

Avec cette version, vous pouvez spécifier plusieurs prédécesseurs lors de la création d’une nouvelle tâche (en utilisant CREATE TASK … AFTER) ou ultérieurement (en utilisant ALTER TASK … ADD AFTER). La syntaxe de la commande SQL existante prend désormais en charge une liste de tâches séparées par des virgules.

L’exemple suivant crée la tâche sans serveur a4 et spécifie les tâches a1, a2, et a3 comme prédécesseurs. La tâche exécute une requête triviale :

CREATE TASK a4
  AFTER a1, a2, a3
  AS SELECT 1;

L’exemple suivant modifie la tâche existante b4 et spécifie les tâches b1, b2, et b3 comme prédécesseurs :

ALTER TASK b4 ADD AFTER b1, b2, b3;

Auparavant, les utilisateurs étaient limités à la spécification d’un seul prédécesseur lors de la création ou de la modification de tâches.

Rôle ORGADMIN — Disponibilité générale¶

Avec cette version, nous avons le plaisir d’annoncer la disponibilité générale du rôle ORGADMIN dans Snowflake. Les administrateurs d’organisation ayant le rôle ORGADMIN peuvent :

• Afficher tous les comptes et régions Snowflake sous une organisation

• Créer de nouveaux comptes Snowflake sous une organisation

• Renommer les comptes Snowflake dans une organisation

• Accédez au schéma ORGANIZATION_USAGE, qui fournit des données d’utilisation et de facturation pour tous les comptes Snowflake appartenant à une organisation.

Pour les organisations ayant plusieurs comptes, le rôle ORGADMIN est disponible dans le premier compte qui a été créé, à moins que vous n’ayez demandé qu’il soit ajouté à un compte différent. Vous pouvez vérifier si le ORGADMIN est disponible en le cherchant dans la liste des rôles dans l’interface Web.

L’administrateur de compte (c’est-à-dire un utilisateur avec le rôle ACCOUNTADMIN) peut accorder le rôle ORGADMIN à lui-même ou à tout autre utilisateur en exécutant la commande suivante :

GRANT ROLE ORGADMIN TO USER user1;

Pour plus d’informations, voir Introduction aux organisations.

ORGANIZATION_USAGE Vues pour le suivi des coûts — Disponibilité générale¶

Avec cette version, nous avons le plaisir d’annoncer la disponibilité générale des vues suivantes dans le schéma ORGANIZATION_USAGE de la base de données partagée SNOWFLAKE. Vous pouvez utiliser ces vues pour ventiler les coûts au niveau de l’objet sur tous les comptes de votre organisation :

• Stockage :

  • DATABASE_STORAGE_USAGE_HISTORY

  • STAGE_STORAGE_USAGE_HISTORY

• Transfert de données :

  • DATA_TRANSFER_HISTORY

• Fonctionnalités sans serveur :

  • AUTOMATIC_CLUSTERING_HISTORY

  • MATERIALIZED_VIEW_REFRESH_HISTORY

  • PIPE_USAGE_HISTORY

  • REPLICATION_USAGE_HISTORY

  • SEARCH_OPTIMIZATION_HISTORY

Prise en charge du renommage des comptes¶

Avec cette version, un administrateur d’organisation peut utiliser la commande ALTER ACCOUNT pour renommer un compte sans avoir à contacter le SnowflakeSupport. Dans l’exemple suivant, on renomme un compte appelé original_acctname en new_acctname :

ALTER ACCOUNT original_acctname RENAME TO new_acctname;

Par défaut, Snowflake continue à vous permettre d’accéder au compte en utilisant l’ancienne URL et le nom précédent, tout en prenant en charge une nouvelle URL qui contient le nouveau nom du compte. Vous avez la possibilité de détruire l’ancienne URL pour demander un accès en utilisant la nouvelle URL. Pour plus de détails, voir Gestion des comptes dans votre organisation.

Historique des accès : visualiser l’accès aux objets partagés dans les comptes de consommateurs¶

Dans cette version, Snowflake ajoute la possibilité de visualiser l’accès aux objets partagés à l’aide de Snowflake Secure Data Sharing par les utilisateurs des comptes de consommateurs. Avec cette mise à jour, Snowflake enregistre l’objet auquel on a accédé dans le partage dans la colonne base_objects_accessed de Vue ACCESS_HISTORY dans Account Usage.

Par exemple, si le fournisseur partage une table et une vue construite à partir de la table avec le compte de consommateur, et qu’il y a une requête sur la vue partagée, Snowflake enregistre l’accès à la vue partagée dans la colonne base_objects_accessed. Cet enregistrement, qui comprend les valeurs columnName et objectName , permet au consommateur de savoir à quel objet on a accédé dans son compte et protège également le fournisseur, car la table sous-jacente (via objectId et columnId) n’est pas révélée au consommateur.

Politiques de masquage et politiques d’accès aux lignes : ajout de la prise en charge de IS_ROLE_IN_SESSION dans les recherches de tables de mappage¶

Avec cette version, Snowflake améliore la polyvalence des politiques de masquage et d’accès aux lignes en permettant à la fonction contextuelle IS_ROLE_IN_SESSION de prendre en charge les consultations de tables de mappage. Les administrateurs de politiques peuvent désormais rédiger des conditions de politiques pour appeler des consultations de tables de mappage à l’aide de cette fonction afin de déterminer si les rôles principaux ou secondaires actifs d’un utilisateur dans une session héritent des privilèges accordés au rôle spécifié dans l’argument de la fonction contextuelle. Avec cette amélioration, Snowflake encourage les clients à utiliser la fonction contextuelle IS_ROLE_IN_SESSION dans les conditions de politiques qui nécessitent de vérifier les rôles activés dans la hiérarchie des rôles du rôle actuel.

Pour plus d’informations, voir Comprendre la sécurité au niveau des colonnes et Présentation des politiques d’accès aux lignes.

Masquage des politiques : Interroger une vue pour des conditions de politique concernant les valeurs de retour NULL, longueur, échelle et précision.¶

Dans cette version, Snowflake fournit une nouvelle vue provisoire dans la base de données partagée SNOWFLAKE nommée :

SNOWFLAKE.BCR_ROLLOUT.BCR_2022_07_DDM_ROLLOUT

Cette vue permet d’identifier les cas où les conditions d’une politique de masquage ne correspondent pas à la longueur, à l’échelle ou à la précision d’une colonne ou lorsque les conditions de la politique renvoient une valeur NULL pour une colonne NOT NULL. La vue renvoie les enregistrements commençant le 15 juillet 2022.

Cette vue est fournie pour aider à déterminer comment le groupe de changements de comportement 2022_07 affectera les requêtes sur les colonnes qui sont protégées par une politique de masquage et pour fournir suffisamment de temps pour commencer le processus de mise à jour des conditions de la politique de masquage.

Pour plus de détails, voir Atténuation des mises à jour des valeurs de retour des politiques de masquage.