Dépendances d’objets

Cette rubrique fournit des concepts sur les dépendances d’objets et des informations relatives à la vue Account Usage OBJECT_DEPENDENCIES.

Dans ce chapitre :

Qu’est-ce qu’une dépendance d’objet ?

Une dépendance d’objet signifie que pour pouvoir opérer sur un objet, l’objet sur lequel on opère doit référencer des métadonnées pour lui-même ou référencer des métadonnées pour au moins un autre objet. Snowflake réalise un suivi des dépendances d’objets dans la vue OBJECT_DEPENDENCIES Account Usage.

Snowflake prend en charge les dépendances d’objets dans votre compte Snowflake local et certaines dépendances liées au partage de données, comme la création d’une vue dans le compte du consommateur à partir d’une table mise à disposition par un partage de fournisseur. Les dépendances des objets partagés permettent aux responsables des données d’assurer une plus grande intégrité des données, de se conformer plus complètement à chaque norme réglementaire et de générer une analyse d’impact plus détaillée.

Snowflake prend en charge les types de dépendance suivants qui peuvent déclencher une dépendance : la valeur de l’objet name, la valeur de l’ID objet et la combinaison de la valeur de l’objet name avec la valeur de l’ID objet.

BY_NAME:

Une dépendance BY_NAME se produit lorsque l’instruction SQL spécifie la valeur name de l’objet lui-même (par exemple, une commande CREATE ou ALTER) ou lorsqu’un objet appelle la valeur name d’un autre objet (par exemple, en utilisant une clause FROM) pour effectuer une opération SQL.

Par exemple, considérons l’instruction suivante :

create view myview as select * from mytable;
Copy

La valeur name de la table mytable est une métadonnée pour la table. La vue nommée myview dépend de la table nommée mytable ; la table doit exister pour créer la vue.

Snowflake fait référence à la vue nommée myview comme étant l’objet de référence et à la table mytable comme étant l’objet référencé.

BY_ID:

Une dépendance BY_ID se produit lorsqu’un objet stocke la valeur ID objet d’un autre objet. Un exemple de dépendance ID est une zone de préparation externe stockant la valeur OBJECT_ID d’une intégration de stockage. Actuellement, la valeur ID objet d’intégration de stockage est uniquement accessible à Snowflake et n’est pas rendue visible par une opération SQL orientée vers le client.

create stage my_ext_stage
  url='s3://load/files/'
  storage_integration = myint;
Copy

Snowflake désigne la zone de préparation externe nommée my_ext_stage comme l’objet de référence et l’intégration de stockage nommée myint comme l’objet référencé.

BY_NAME_AND_ID:

Certains objets Snowflake (par exemple, les vues matérialisées) dépendent à la fois de la valeur name de l’objet et de la valeur ID de l’objet. Ces objets sont souvent le résultat d’une instruction CREATE OR REPLACE pour remplacer un objet existant ou d’une instruction ALTER pour renommer un objet.

Pour plus d’informations, voir la section Notes générales sur l’utilisation de la vue Account Usage OBJECT_DEPENDENCIES.

Dépendances d’objets prises en charge

Snowflake prend en charge les objets de référence et les objets référencés comme suit :

Objet de référence

Objet référencé

Type de dépendance

Vue, vue sécurisée, UDF SQL, UDTF SQL et autres objets référencés par leur nom

Vue

Vue sécurisée

Vue matérialisée

UDF (toutes sortes)

UDTF

autres objets référencés par leur nom

BY_NAME

Zone de préparation externe

Flux

Intégration de stockage

Table, vue, vue sécurisée

BY_ID

Table externe

Zone de préparation

BY_ID

Vue matérialisée

Table, table externe

BY_NAME_AND_ID

Notez que Snowflake ne prend en charge que les objets suivants dans le cadre du partage de données :

Objet de référence

Objet référencé

Type de dépendance

Vue, UDF SQL, UDTF SQL

Table

Vue sécurisée

Vue matérialisée sécurisée

UDF sécurisée et UDTF sécurisée

BY_NAME

Vue matérialisée

Table

BY_NAME_AND_ID

Pour plus de détails, voir la section Notes sur l’utilisation de la vue OBJECT_DEPENDENCIES.

Avantages

L’identification des dépendances entre objets peut donner un aperçu des cas d’utilisation du suivi des données, comme suit :

Analyse d’impact:

La connaissance de la dépendance des objets permet aux gestionnaires de données d’identifier les relations entre les objets de référence et les objets référencés afin de garantir que les mises à jour des objets référencés n’ont pas d’impact négatif sur les utilisateurs de l’objet de référence.

Par exemple, le propriétaire d’une table prévoit d’ajouter une colonne à une table. L’interrogation de la vue OBJECT_DEPENDENCIES basée sur le nom de la table renvoie tous les objets (par exemple, les vues) qui seront affectés.

Le gestionnaire de données peut alors coordonner un plan d’action pour s’assurer que le calendrier des mises à jour des tables et des vues ne donne pas lieu à des requêtes rompues qui auraient un impact négatif sur les utilisateurs interrogeant les vues créées à partir de la table.

Conformité:

La relation de dépendance des objets aide le responsable de la conformité à identifier la relation entre les sources de données sensibles (c’est-à-dire l’objet référencé) et les cibles de données (c’est-à-dire l’objet de référence). Le responsable de la conformité peut alors décider de la meilleure façon de mettre à jour l’objet référencé et l’objet de référence en fonction des exigences de conformité (par exemple, GDPR).

Intégrité des données:

La relation de dépendance entre les objets aide les professionnels des données primaires, tels que les analystes, les scientifiques, les responsables de la conformité et d’autres utilisateurs professionnels, à avoir la certitude que les données proviennent d’une source fiable.

Limites

En plus des notes sur l’utilisation de la vue, notez les limitations suivantes lors de l’interrogation de la vue OBJECT_DEPENDENCIES :

Paramètres de session:

Snowflake ne peut pas calculer avec précision les dépendances des objets qui incluent les paramètres de session dans leurs définitions, car les paramètres de session peuvent prendre des valeurs différentes selon le contexte.

Snowflake recommande de ne pas utiliser de variables de session dans les définitions de vues et de fonctions.

Implémentations Snowflake:

Cette vue ne capture pas les dépendances qui sont nécessaires pour les implémentations Snowflake. Par exemple, la vue n’enregistre pas la dépendance nécessaire pour créer une nouvelle table à partir du clone d’une autre table.

Résolution d’objet:

Si une définition de vue utilise une fonction pour appeler un objet afin de créer la vue, ou si un objet est appelé à l’intérieur d’une autre fonction ou vue, Snowflake n’enregistre pas de dépendance d’objet. Par exemple :

create or replace view v_on_stage_function
as
select *
from T1
where get_presigned_url(@stage1, 'data_0.csv.gz')
is not null;
Copy

Dans cet exemple, la fonction get_presigned_url appelle la zone de préparation stage1. Snowflake n’enregistre pas que la vue nommée v_on_stage_function dépend de la zone de préparation nommée stage1.

Dépendances brisées:

Si la valeur du type de dépendance est BY_NAME_AND_ID et que la dépendance d’un objet change suite à une opération CREATE OR REPLACE ou ALTER sur un objet, Snowflake n’enregistre que la dépendance de l’objet avant ces opérations.

Snowflake n’enregistre pas la dépendance de l’objet dans le résultat de la requête de vue après ces opérations, car le résultat est une référence rompue.

Dépendances d’objets avec des fonctionnalités et services Snowflake

Objets externes:

Snowflake suit les dépendances d’objets pour les objets Snowflake uniquement. Par exemple, si un objet Snowflake dépend d’un compartiment Amazon S3, cette vue n’enregistre pas la dépendance du compartiment, car le compartiment est un objet Amazon et non un objet Snowflake.

Réplication:

Si un objet secondaire dépend de l’objet primaire, cette vue n’enregistre pas les dépendances dues à une opération de réplication.

Partage de données:

Pour les comptes fournisseurs, cette vue ne permet pas à un compte fournisseur de partage de données de déterminer les objets dépendants dans le compte de consommateur de partage de données. Par exemple, un fournisseur de partage de données crée une vue et la partage. Le fournisseur de partage de données ne peut pas utiliser cette vue pour déterminer tout objet du compte de consommateur qui a été créé à partir de la vue partagée (par exemple, de nouvelles tables ou vues).

Pour les comptes consommateurs, cette vue ne permet pas à un compte consommateur de partage de données de déterminer les objets dépendants dans le compte fournisseur de partage de données. Par exemple, si un compte de consommateur de partage de données utilise une UDF mise à disposition par le compte de fournisseur de partage de données, le consommateur de partage de données ne peut pas utiliser cette vue pour identifier les objets dont dépend l’UDF partagée.

Pour plus de détails, reportez-vous à Data Sharing : notes sur l’utilisation.

Interrogation de la vue OBJECT_DEPENDENCIES

Les exemples suivants couvrent ces cas d’utilisation :

  1. Afficher les objets dépendant d’une table externe.

  2. Analyse d’impact : trouver les objets référencés par une table.

  3. GDPR : trouver la source de données pour une vue donnée.

  4. Partage de données.

Afficher les objets dépendant d’une table externe

Créer une vue matérialisée nommée sales_view à partir de la table externe nommée sales_staging_table :

CREATE OR REPLACE MATERIALIZED VIEW sales_view AS SELECT * FROM sales_staging_table;
Copy

Interrogez la vue OBJECT_DEPENDENCIES dans le schéma Account Usage de la base de données SNOWFLAKE partagée. Notez que la vue matérialisée est referencing_object_name et la table externe est referenced_object_domain :

SELECT referencing_object_name, referencing_object_domain, referenced_object_name, referenced_object_domain
FROM snowflake.account_usage.object_dependencies
WHERE referenced_object_name = 'SALES_STAGING_TABLE' and referenced_object_domain = 'EXTERNAL TABLE';
Copy
+-------------------------+---------------------------+------------------------+--------------------------+
| REFERENCING_OBJECT_NAME | REFERENCING_OBJECT_DOMAIN | REFERENCED_OBJECT_NAME | REFERENCED_OBJECT_DOMAIN |
+-------------------------+---------------------------+------------------------+--------------------------+
| SALES_VIEW              | MATERIALIZED VIEW         | SALES_STAGING_TABLE    | EXTERNAL TABLE           |
+-------------------------+---------------------------+------------------------+--------------------------+

Analyse d’impact : trouver les objets référencés par une table

Considérons une table de base nommée SALES_NA, où NA indique l’Amérique du Nord, US indique les États-Unis et CAL indique la Californie, avec une série de vues imbriquées :

  • (table) SALES_NA » (vue) NORTH_AMERICA_SALES » (vue) US_SALES

  • (table) SALES_NA » (vue) NORTH_AMERICA_SALES » (vue) CAL_SALES

Pour créer la table et les vues imbriquées, exécutez les commandes suivantes :

CREATE TABLE sales_na(product string);
CREATE OR REPLACE VIEW north_america_sales AS SELECT * FROM sales_na;
CREATE VIEW us_sales AS SELECT * FROM north_america_sales;
CREATE VIEW cal_sales AS SELECT * FROM north_america_sales;
Copy

De même, considérez la relation de la table de base SALES_NA avec ses vues imbriquées, et considérez la table de base SALES_UK, où UK indique le Royaume-Uni, avec sa vue imbriquée.

Notez que deux vues différentes servent d’objets sources pour dériver la vue nommée GLOBAL_SALES :

  • (table) SALES_NA » (vue) NORTH_AMERICA_SALES » (vue) GLOBAL_SALES

  • (table) SALES_UK » (vue) GLOBAL_SALES

Pour créer ces vues imbriquées, exécutez les commandes suivantes :

CREATE TABLE sales_uk (product string);
CREATE VIEW global_sales AS SELECT * FROM sales_uk UNION ALL SELECT * FROM north_america_sales;
Copy

Interrogez la vue OBJECT_DEPENDENCIES dans le schéma Account Usage de la base de données SNOWFLAKE partagée pour déterminer les références d’objet pour la table SALES_NA. Notez la quatrième ligne du résultat de la requête, qui spécifie la table SALES_NA mais ne fait pas référence à la table SALES_UK :

WITH RECURSIVE referenced_cte
(object_name_path, referenced_object_name, referenced_object_domain, referencing_object_domain, referencing_object_name, referenced_object_id, referencing_object_id)
    AS
      (
        SELECT referenced_object_name || '-->' || referencing_object_name as object_name_path,
               referenced_object_name, referenced_object_domain, referencing_object_domain, referencing_object_name, referenced_object_id, referencing_object_id
          FROM snowflake.account_usage.object_dependencies referencing
          WHERE true
            AND referenced_object_name = 'SALES_NA' AND referenced_object_domain='TABLE'

        UNION ALL

        SELECT object_name_path || '-->' || referencing.referencing_object_name,
              referencing.referenced_object_name, referencing.referenced_object_domain, referencing.referencing_object_domain, referencing.referencing_object_name,
              referencing.referenced_object_id, referencing.referencing_object_id
          FROM snowflake.account_usage.object_dependencies referencing JOIN referenced_cte
            ON referencing.referenced_object_id = referenced_cte.referencing_object_id
            AND referencing.referenced_object_domain = referenced_cte.referencing_object_domain
      )

  SELECT object_name_path, referenced_object_name, referenced_object_domain, referencing_object_name, referencing_object_domain
    FROM referenced_cte
;
Copy
+-----------------------------------------------+------------------------+--------------------------+-------------------------+---------------------------+
| OBJECT_NAME_PATH                              | REFERENCED_OBJECT_NAME | REFERENCED_OBJECT_DOMAIN | REFERENCING_OBJECT_NAME | REFERENCING_OBJECT_DOMAIN |
+-----------------------------------------------+------------------------+--------------------------+-------------------------+---------------------------+
| SALES_NA-->NORTH_AMERICA_SALES                | SALES_NA               | TABLE                    | NORTH_AMERICA_SALES     | VIEW                      |
| SALES_NA-->NORTH_AMERICA_SALES-->CAL_SALES    | NORTH_AMERICA_SALES    | VIEW                     | CAL_SALES               | VIEW                      |
| SALES_NA-->NORTH_AMERICA_SALES-->US_SALES     | NORTH_AMERICA_SALES    | VIEW                     | US_SALES                | VIEW                      |
| SALES_NA-->NORTH_AMERICA_SALES-->GLOBAL_SALES | NORTH_AMERICA_SALES    | VIEW                     | GLOBAL_SALES            | VIEW                      |
+-----------------------------------------------+------------------------+--------------------------+-------------------------+---------------------------+

GDPR : trouver la source de données pour une vue donnée

Des objets dérivés (par exemple, des vues, des CTAS) peuvent être créés à partir de nombreux objets sources différents pour fournir une vue ou un tableau de bord personnalisé(e). Pour répondre aux exigences réglementaires telles que le GDPR, les responsables de la conformité et les auditeurs doivent être en mesure de retracer les données d’un objet donné jusqu’à sa source de données d’origine.

Par exemple, la vue GLOBAL_SALES est dérivée de deux chemins de dépendance différents qui pointent vers deux tables de base différentes :

  • (table) SALES_NA » (vue) NORTH_AMERICA_SALES » (vue) GLOBAL_SALES

  • (table) SALES_UK » (vue) GLOBAL_SALES

Pour créer ces vues imbriquées, exécutez les commandes suivantes :

CREATE TABLE sales_na (product string);
CREATE OR REPLACE VIEW north_america_sales AS SELECT * FROM sales_na;
CREATE TABLE sales_uk (product string);
CREATE VIEW global_sales AS SELECT * FROM sales_uk UNION ALL SELECT * FROM north_america_sales;
Copy

Interrogez la vue OBJECT_DEPENDENCIES dans le schéma Account Usage de la base de données partagée SNOWFLAKE pour trouver la ou les sources de données de la vue GLOBAL_SALES. Chaque ligne du résultat de la requête spécifie un chemin de dépendance vers un objet unique.

WITH RECURSIVE referenced_cte
(object_name_path, referenced_object_name, referenced_object_domain, referencing_object_domain, referencing_object_name, referenced_object_id, referencing_object_id)
    AS
      (
        SELECT referenced_object_name || '<--' || referencing_object_name AS object_name_path,
               referenced_object_name, referenced_object_domain, referencing_object_domain, referencing_object_name, referenced_object_id, referencing_object_id
          from snowflake.account_usage.object_dependencies referencing
          WHERE true
            AND referencing_object_name = 'GLOBAL_SALES' and referencing_object_domain='VIEW'

        UNION ALL

        SELECT referencing.referenced_object_name || '<--' || object_name_path,
              referencing.referenced_object_name, referencing.referenced_object_domain, referencing.referencing_object_domain, referencing.referencing_object_name,
              referencing.referenced_object_id, referencing.referencing_object_id
          FROM snowflake.account_usage.object_dependencies referencing JOIN referenced_cte
            ON referencing.referencing_object_id = referenced_cte.referenced_object_id
            AND referencing.referencing_object_domain = referenced_cte.referenced_object_domain
      )

  SELECT object_name_path, referencing_object_name, referencing_object_domain, referenced_object_name, referenced_object_domain
    FROM referenced_cte
;
Copy
+-----------------------------------------------+-------------------------+---------------------------+------------------------+--------------------------+
| OBJECT_NAME_PATH                              | REFERENCING_OBJECT_NAME | REFERENCING_OBJECT_DOMAIN | REFERENCED_OBJECT_NAME | REFERENCED_OBJECT_DOMAIN |
+-----------------------------------------------+-------------------------+---------------------------+------------------------+--------------------------+
| SALES_UK<--GLOBAL_SALES                       | GLOBAL_SALES            | VIEW                      | SALES_UK               | TABLE                    |
| NORTH_AMERICA_SALES<--GLOBAL_SALES            | GLOBAL_SALES            | VIEW                      | NORTH_AMERICA_SALES    | VIEW                     |
| SALES_NA<--NORTH_AMERICA_SALES<--GLOBAL_SALES | NORTH_AMERICA_SALES     | VIEW                      | SALES_NA               | TABLE                    |
+-----------------------------------------------+-------------------------+---------------------------+------------------------+--------------------------+

Partage de données

Considérons le tableau suivant, qui est un extrait de la vue OBJECT_DEPENDENCIES dans le compte du consommateur, où :

  • V1 spécifie une vue que le consommateur crée à partir d’un objet partagé.

  • S_V1 spécifie une vue que le fournisseur partage.

  • S_T1 spécifie une table que le fournisseur partage.

Ligne

REFERENCING_OBJECT_NAME

REFERENCED_OBJECT_NAME

REFERENCED_OBJECT_DOMAIN

REFERENCED_OBJECT_ID

1

V1

S_V1

TABLE

NULL

2

V1

S_T1

TABLE

NULL

Compte tenu de ce tableau, notez ce qui suit :

  • Si le fournisseur révoque S_T1 du partage, le consommateur continue de voir les lignes qui spécifient S_T1 (ligne 2) dans sa vue locale tant que S_T1 n’a pas été renommé avant la révocation.

  • Si le fournisseur supprime une table ou une vue dans son compte, la table ou la vue n’est plus incluse dans le partage. La vue locale du consommateur préserve les enregistrements existants pour la table ou la vue détruite, car la table ou la vue était partagée avant l’opération de destruction dans le compte fournisseur.

    Le consommateur ne peut pas observer les modifications apportées au compte du fournisseur.