Object Tagging Snowflake : la clé d'une gouvernance des données maîtrisée

L'Object Tagging dans Snowflake est une fonctionnalité de gouvernance des données qui permet de catégoriser et de regrouper des objets (warehouses, tables, etc.). L'objectif : améliorer la découvrabilité, suivre l'utilisation et veiller à la conformité des objets Snowflake. Les tags sont particulièrement utiles pour repérer les objets Snowflake contenant des informations sensibles, telles que des données personnelles (PII) ou financières. Ils servent également à attribuer la propriété des ressources, à des fins de suivi des coûts ou de gouvernance.

Pour tagger des objets dans Snowflake, il faut d'abord créer le tag lui-même.

Les tags sont des objets de niveau schéma dans Snowflake, qui peuvent être rattachés à d'autres objets Snowflake : bases de données, schémas, tables, colonnes, utilisateurs, warehouses, rôles, etc. La liste des objets taggables est assez étendue ; elle est disponible ici.

Un tag est une paire clé-valeur. Le nom du tag (create tag <tag name>) constitue la clé, et les valeurs peuvent être issues d'une liste prédéfinie ou rester libres, autorisant n'importe quelle chaîne de caractères.

Par exemple, pour suivre l'audience d'une table spécifique, vous pouvez créer un tag (clé) nommé audience, avec des valeurs comme HR, Sales, Operations, IT, etc. Ces tags se requêtent facilement : montre-moi toutes les tables utilisées par Sales. Nous y reviendrons plus loin dans cet article.

Petit rappel sur la Container Hierarchy de Snowflake. Une Organisation Snowflake est un conteneur d'Accounts. Un Account est un conteneur de bases de données. Une base de données est un conteneur de schémas. Et un schéma est un conteneur de tables, vues, pipes, formats de fichier, stages et bien d'autres objets.

Tagger un objet à n'importe quel niveau de la hiérarchie propage le tag à tous les objets situés en dessous. Par exemple, si j'applique un tag à une base de données, chaque table, vue, colonne et autre objet — pipes, stages, etc. — héritera du tag de la base.

Imaginons des tags définis explicitement aux niveaux account, database et schema, comme dans cet exemple :

{
  "account": {
    "tags": {
      "env": "prod",
      "region": "us-east-1"
    },
    "databases": {
      "analytics": {
        "tags": {
          "owner": "data_team",
          "classification": "restricted"
        },
        "schemas": {
          "sales": {
            "tags": {

Expand Code

Comme region est taggé au niveau de l'account, chaque database, schema, table, vue et même chaque colonne héritera de la valeur us-east-1. Plutôt pratique !

L'interrogation du lineage des tags se fait facilement avec la fonction snowflake.account_usage.tag_references_with_lineage, comme indiqué ci-dessous. Voir Observer les tags en SQL.

Dans Snowflake, un query tag est une simple valeur de type chaîne attachée à une requête ou à une session, ce qui facilite le filtrage et la recherche dans l'historique des requêtes. Les query tags ne sont pas des paires clé-valeur — il s'agit simplement de chaînes recherchables. À l'inverse, les object tags sont des paires clé-valeur et s'inscrivent dans le framework de gouvernance des données de Snowflake. Ils servent à classifier, contrôler et auditer l'accès aux actifs de données comme les tables, les colonnes ou les schémas.

Lorsque l'on évoque le tagging dans Snowflake, prenez soin de préciser s'il s'agit de query tags ou d'object tags, car leurs usages sont très différents.

Créer un tag

La syntaxe pour créer un tag est très simple : create tag <tag_name> <allowed values>;

Les tags étant des objets de niveau schéma, utilisez du SQL pleinement qualifié ou soyez attentif au contexte de votre worksheet. Comme tout dans Snowflake, un tag peut être créé dans une base de données (ou un schéma) et utilisé dans une autre.

Exemples :

use schema governance.tags;
create tag table_classification allowed_values 'metadata', 'fact', 'dimension';
-- creates a tag with a specific list of allowed values.

create tag user_group;
-- creates a tag with any value allowed.

Créer un tag sans préciser de valeurs autorisées fixe le paramètre allowed_values à null, ce qui permet d'utiliser n'importe quelle chaîne comme valeur. C'est pratique lorsque la liste des valeurs doit rester dynamique, mais le plus souvent vous listerez les valeurs autorisées dès le départ, puis utiliserez alter sur le tag pour en ajouter d'autres au besoin.

Vérifier les valeurs autorisées d'un tag

Pour consulter les valeurs autorisées d'un tag existant, plusieurs méthodes simples existent.

La commande show tags; affiche les métadonnées de tous les tags de votre account. L'une des colonnes retournées est allowed_values.

Une autre option consiste à appeler la fonction système system$get_tag_allowed_values pour un tag donné.

select system$get_tag_allowed_values(
    'governance.tags.cost_center');

Une troisième possibilité est d'appeler la fonction get_ddl dans Snowflake. Par exemple :

1select get_ddl('tag','dev.public.TESTING_TAG_1');

Utiliser le tag en l'appliquant à un objet :

Pour appliquer un tag à un objet, utilisez la commande alter. Par exemple, pour poser un tag sur une table appelée select_blog.workday.workday_users :

alter table select_blog.workday.workday_users
set tag tutorial_db.public.table_classification = 'metadata';

Dans cet exemple, le tag est créé dans une base de données nommée tutorial_db et utilisé dans une base nommée select_blog.

Option 1 : interroger la vue account_usage.tag_references

La vue snowflake.account_usage.tag_references indique tous les endroits où un tag est utilisé et sa valeur associée. Les colonnes de filtrage les plus courantes sont tag_name et tag_value. Cette table n'affiche pas l'héritage des tags ; elle ne montre que les objets directement taggés.

SELECT * FROM
snowflake.account_usage.tag_references
where tag_name ilike 'table_class%'
or tag_value ilike 'meta%'
ORDER BY TAG_NAME, DOMAIN, OBJECT_ID;

Attention : les données de cette vue subissent un délai non négligeable. La documentation Snowflake mentionne un délai pouvant atteindre deux heures. Dans la plupart des cas, j'ai constaté un délai d'au moins une heure.

Option 2 : la fonction get_tag

La vue snowflake.account_usage.tag_references étant différée, il faut parfois observer immédiatement les changements appliqués aux objets taggés. La fonction système system$get_tag, elle, est toujours à jour.

Syntaxe :

SELECT SYSTEM$GET_TAG( <fully qualified tag name>,
<'fully qualified object name'>, <'object class such as table, view, etc' > )
AS TAG_META;

Exemple :

SELECT SYSTEM$GET_TAG( 'tutorial_db.public.table_classification',
'SELECT_BLOG.WORKDAY.WORKDAY_USERS', 'TABLE' )
AS TAG_META;

Option 3 : la fonction account_usage.tag_lineage

Nous avons évoqué plus haut l'héritage des tags : les tags sont automatiquement propagés des niveaux supérieurs vers les niveaux inférieurs. La fonction tag_lineage permet de voir tous les objets directement taggés ou ayant hérité d'un tag. En reprenant l'exemple table_classification, on peut écrire le SQL suivant :

SELECT *
FROM TABLE(
  snowflake.account_usage.tag_references_with_lineage(
    'TUTORIAL_DB.PUBLIC.TABLE_CLASSIFICATION'
  )
);

On voit ici que le tag a été appliqué manuellement à la table WORKDAY_USERS et que chaque colonne de la table en hérite.

Dans cette capture d'écran, plusieurs colonnes ont été masquées dans l'interface Snowsight pour que l'ensemble tienne à l'écran.

Snowflake propose un dashboard pratique pour observer tous les tags présents dans Snowflake.

Avec le rôle accountadmin ou un rôle correctement configuré pour accéder au dashboard, utilisez la barre latérale de Snowsight pour naviguer vers Monitoring —> Governance.

Voici à quoi ressemble le dashboard. Comme j'utilise un compte de démo, aucun tag n'est défini, mais vous pouvez déjà entrevoir son utilité.

Cliquez sur l'onglet Tagged Objects pour visualiser toutes les tables et vues de votre account ainsi que les tags qui s'y appliquent. Les objets sont listés qu'un tag leur soit appliqué ou non. Malheureusement, des objets comme les utilisateurs et les warehouses n'apparaissent pas ici. Snowflake propose de bonnes capacités de filtrage sur cette page : n'hésitez pas à parcourir les filtres.

Activez le filtre has tags pour n'afficher que les objets dotés de tags :

Élaborer une politique de tagging centralisée

La gouvernance des données et la gestion des PII et des données sensibles ne sont pas chose facile. Il s'agit principalement d'un travail non technique qui demande beaucoup de discussions et d'alignement !

La première étape consiste à définir une stratégie réfléchie. Voici quelques questions pour démarrer.

• Que cherchons-nous à accomplir avec les tags ? (reporting de coûts, sécurisation des données sensibles, etc.)
• Qui définit la liste des tags et leurs valeurs autorisées ? (Stratégie)
• Quels rôles peuvent appliquer des tags, et qui obtient ces rôles ? (Tactique)
• Comment exploiter l'héritage des tags de la manière la plus efficace ?

Exploiter les valeurs autorisées pour les tags

Surtout lorsque les tags sont définis manuellement, tirez parti du paramètre allowed values. Lorsque l'attribution des tags est automatisée à partir de données issues d'une table, ce point devient moins critique.

Automatiser le tagging dès que possible

Le tagging perd de son intérêt dès lors que les équipes doivent l'appliquer manuellement. Cherchez des façons créatives d'automatiser le tagging. Un exemple ci-dessous !

Intégrer le tagging aux pipelines de données dès que possible

Il existe un package dbt très utile, dbt_tags : il aide à automatiser l'Object Tagging dans Snowflake et à aligner le masquage dynamique sur les tags. Si vous avez besoin de masquage de données basé sur les tags, jetez-y un œil !

Surveiller et auditer l'utilisation des tags

À quoi bon créer tous ces tags si vous ne les revoyez jamais ? Consacrez une heure par mois à passer en revue vos tags, leur utilisation, et à faire évoluer votre politique de tagging.

Le scénario

Imaginez un scénario où vous tenez à jour les métadonnées de vos employés dans Workday (ou l'ERP de votre choix), et où cette table est intégrée à Snowflake via ETL. Appelons-la workday_users. Elle contient une ligne par utilisateur, et chaque colonne représente un attribut que nous souhaitons conserver comme tag sur l'utilisateur Snowflake. Cela nous permet d'auditer, d'observer et de définir les permissions des utilisateurs partageant les mêmes tags.

Lorsqu'un utilisateur change de département ou de fonction, les tags Snowflake doivent se mettre à jour automatiquement.

Créer des données fictives

Créons une table et des données fictives pour notre scénario :

-- This table represents a table that would be ETL'd from Workday to Snowflake, containing user metadata
-- I'm using a demo database, change yours.
create or replace table select_blog.workday.workday_users
(
employee_id text,
work_email text,
manger_email text,
is_manager boolean,
pillar_id text,
group_id text,
team_id text,
department_id text,
job_family_id text,
area text,
cost_center text,

Expand Code

Remplissez la table avec quelques données fictives :

1insert into select_blog.workday.workday_users

2values(

33000,

4'[email protected]',

5null,

6true,

7'Pillar-C-SUITE',

8'Group-C-SUITE',

9'Team-Founders',

10'Department-All',

11'JF-Founders',

12'Founders',

13'CC Board of Directors',

14'CC3625'

15),

Expand Code

Dans ce scénario, nous voulons transformer tout champ se terminant par _id en un tag sur l'utilisateur Snowflake.

Créer les tags

Supposons que le nombre de colonnes de workday_users soit relativement stable, et que la création des tags soit un exercice ponctuel (ou peu fréquent) qui n'a pas besoin d'être automatisé. Si une colonne est ajoutée, on créera un nouveau tag. (Ou bien planifiez le code ci-dessous dans une task ! Évitez simplement de replace les tags si vous le planifiez.)

Le code ci-dessous interroge les métadonnées des colonnes, en filtrant celles qui contiennent _id, conformément à notre besoin. Ces noms de colonnes deviennent nos noms de tags. Pour chaque colonne _id, on crée simplement un nouveau tag. Ici, je ne prédéfinis pas les valeurs autorisées, puisque celles-ci proviendront des données.

Ce code vous évite de rédiger manuellement une douzaine d'instructions create tag ou plus. Il exécute create or replace tag ... pour chaque ligne d'un select.

BEGIN
    -- Declare variables
    LET create_tag_statements RESULTSET := (
        SELECT
            'CREATE OR REPLACE TAG "' || COLUMN_NAME || '" COMMENT = ''Tag for ' || COLUMN_NAME || ''';' AS create_tag_statement
        FROM INFORMATION_SCHEMA.COLUMNS
        WHERE TABLE_NAME = 'WORKDAY_USERS'
          AND TABLE_SCHEMA = 'WORKDAY'
          AND LOWER(COLUMN_NAME) ILIKE '%_ID'
    );

    -- Loop through the result set and execute each statement
    LET stmt VARCHAR DEFAULT '';
    LET create_tag_cursor CURSOR FOR SELECT * FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()));

Expand Code

Vous pouvez également exécuter manuellement des commandes de ce type :

use schema select_blog.workday;
create tag pillar_id;
create tag team_id;

-- drop tags if desired
drop tag my_obsolete_tag;

Créer une vue qui compare les tags utilisateurs réels à l'état souhaité

La table workday_users représente l'état souhaité : elle contient les informations Workday les plus à jour sur la manière dont nous voulons configurer les tags utilisateurs. Il faut maintenant comparer les tags utilisateurs réels à cet état souhaité, et faire ressortir les lignes dont les tags ne sont pas correctement définis. (Dans ce cas, nous partons du principe que la colonne work_email de la table workday_users correspond à l'adresse e-mail de l'utilisateur Snowflake dans la table snowflake.account_usage.users.)

Enregistrons cette requête sous forme de vue, car elle sera réutilisée fréquemment.

create or replace view tag_updates as
with desired_tags as (
    select
        upper(work_email) as user_email,
        upper(tag_name) as tag_name,
        replace(upper(desired_tag_value), '-', '_') as desired_tag_value,
    from
        workday_users unpivot (
            desired_tag_value for tag_name in (pillar_id, group_id, group_id)
        )
),

snowflake_user_email as (
    select
        upper(name) as user_name,

Expand Code

Résumons ce que fait la vue :

• Dépivoter la table Workday (générer des lignes à partir des colonnes) pour obtenir une ligne par utilisateur et tag possible.
• Récupérer le USER_NAME Snowflake qui sera taggé, ainsi que l'adresse e-mail Snowflake qui sera jointe à la table d'état souhaité.
• Joindre sur l'e-mail pour récupérer les tags existants de chaque utilisateur.
• Enfin, afficher tous les enregistrements dont la valeur de tag existante ne correspond pas à la valeur souhaitée.

Ce sont ces enregistrements que nous pourrons mettre à jour automatiquement via une procédure stockée.

La vue tag_updates étant filtrée sur les lignes où la valeur du tag existant ne correspond pas à la valeur souhaitée, elle est idéalement vide lorsque nos tags sont correctement définis.

Créer une procédure stockée pour appliquer les tags à l'utilisateur

La procédure stockée effectue ces étapes basiques :

• Pour chaque ligne de la vue tag_updates :
  • alter user, set tag = tag souhaité

Ci-dessous, je propose deux versions de la procédure stockée. Une version simple, sans logging : claire et facile à lire. La seconde est plus verbeuse et sert au dépannage si vos tags souhaités ne sont pas appliqués. Elle inclut des messages de sortie dans le panneau de résultats SQL.

Procédure simple :

CREATE OR REPLACE PROCEDURE SET_USER_TAGS()
  RETURNS VARCHAR
  LANGUAGE PYTHON
  RUNTIME_VERSION = '3.8'
  PACKAGES = ('snowflake-snowpark-python')
  HANDLER = 'main'
AS
$$
def main(session):
    query = """
      SELECT
        user_name as USER_NAME,
        tag_name as TAG_NAME,
        desired_tag_value as DESIRED_TAG_VALUE
      FROM tag_updates

Expand Code

Sproc verbeuse avec logging :

-- create the procedure using an admin role that has permissions to "alter user".
user role accountadmin; -- or, use role useradmin if your users are actually owned by useradmin
-- if you are using useradmin role, you need to grant usage to that role on the database.  Therefore it is easire to use accountadmin.
CREATE OR REPLACE PROCEDURE SET_USER_TAGS()
  RETURNS VARCHAR
  LANGUAGE PYTHON
  RUNTIME_VERSION = '3.8'
  PACKAGES = ('snowflake-snowpark-python')
  HANDLER = 'main'
AS
$$
def main(session):
    # Pull exactly the columns you need from the revised view
    query = """
      SELECT

Expand Code

Appelez la procédure :

1call set_user_tags();

Profitez-en pour faire une pause déjeuner et attendez environ une heure (parfois davantage) que la vue account_usage.tag_references se mette à jour. Si les tags ont été correctement définis et que la vue a été rafraîchie, select * from tag_updates; ne renvoie rien ! Exactement ce que nous voulions.

Créer une task pour planifier la procédure stockée

Cette task exécutera la procédure tous les jours à 4 h UTC.

CREATE TASK set_user_tags
SCHEDULE = 'USING CRON 0 4 * * * UTC' AS
CALL set_user_tags();
alter task set_user_tags resume;

Et voilà : nous avons mis en place un processus d'automatisation des tags utilisateurs à partir de notre table de métadonnées Workday.

À vous de jouer

Cet exemple illustre un scénario parmi d'autres pour automatiser les tags. Mais, conformément à nos bonnes pratiques, cherchez toujours à automatiser le tagging dès que possible. La démarche restera la même :

• Définir un état souhaité connu.
• Créer les tags (manuellement ou de façon automatisée).
• Automatiser l'application des tags en comparant l'état souhaité à l'état réel.

Dans cet article, nous avons abordé les usages des tags dans Snowflake, leur création, les bonnes pratiques associées, ainsi qu'un scénario avancé. Soyez créatifs ! Imaginez de nouvelles façons d'automatiser le tagging dans votre account Snowflake !

Jeff est consultant Data et Analytics, fort de plus de 15 ans d'expérience dans l'automatisation des analyses et l'exploitation des données pour piloter les processus métier. Côté technologies, il est spécialisé sur Snowflake + dbt + Tableau. Côté secteurs, il a travaillé dans les services publics, les essais cliniques, l'édition, les biens de consommation et l'industrie. N'hésitez pas à le contacter : [email protected].