Governança de Dados com Object Tagging no Snowflake

Object tagging no Snowflake é um recurso de governança de dados que permite categorizar e agrupar objetos (warehouses, tabelas etc.). O objetivo é facilitar a descoberta, monitorar o uso e acompanhar a conformidade dos objetos no Snowflake. As tags são especialmente úteis para identificar objetos do Snowflake que contêm informações sensíveis, como PII ou dados financeiros. Também ajudam a atribuir a propriedade de recursos, monitorar custos ou apoiar iniciativas de governança de dados.

Para marcar objetos no Snowflake, primeiro você precisa criar a própria tag.

Tags são objetos em nível de schema no Snowflake e podem ser associadas a outros objetos, como bancos de dados, schemas, tabelas, colunas, usuários, warehouses, roles etc. A lista de objetos que podem receber tags é bem extensa e pode ser consultada aqui.

Uma tag é um par chave-valor. O nome da tag ( create tag <tag name>) funciona como a "chave", e os valores podem vir de uma lista pré-definida ou ficar sem restrição, aceitando qualquer string.

Por exemplo, se você quiser acompanhar o público de uma tabela específica, dá para criar uma tag (chave) chamada "audience" com valores como: HR, Sales, Operations, IT etc. Depois é fácil consultar essas tags: mostre todas as tabelas usadas por vendas. Veremos mais sobre isso ao longo deste post.

Vale relembrar rapidamente a " Hierarquia de Containers" do Snowflake. Uma Organization do Snowflake é um container de Accounts. Uma Account é um container de bancos de dados. Um banco de dados é um container de Schemas. E um Schema é um container de tabelas, views, pipes, file formats, stages e muitos outros objetos.

Marcar um objeto em qualquer nível dessa hierarquia propaga a tag para todos os objetos abaixo dele. Por exemplo, se eu aplicar uma tag a um banco de dados, todas as tabelas, views, colunas e demais objetos como pipes, stages etc. vão herdar a tag do banco.

Digamos que você tenha tags definidas explicitamente nos níveis de account, banco de dados e schema, como neste exemplo:

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

Expandir Código

Como region está marcada no nível da account, cada banco de dados, schema, tabela, view e até cada coluna vai herdar o valor us-east-1. Bem bacana!

Consultar a linhagem das tags fica simples com a função snowflake.account_usage.tag_references_with_lineage, mostrada a seguir. Veja a seção "Observando Tags com SQL".

No Snowflake, uma query tag é uma string única associada a uma query ou sessão, o que facilita filtrar e pesquisar o histórico de queries. Query tags não são pares chave-valor — são apenas strings pesquisáveis. Já as object tags são pares chave-valor e fazem parte do framework de governança de dados do Snowflake. Servem para classificar, controlar e auditar o acesso a ativos de dados, como tabelas, colunas ou schemas.

Quando alguém falar em "tagging" no Snowflake, vale confirmar se está se referindo a query tags ou object tags, já que cumprem propósitos bem diferentes.

Criar uma tag

A sintaxe para criar uma tag é bem simples. create tag <tag_name> <allowed values>;

Como as tags são objetos em nível de schema, use SQL totalmente qualificado ou fique de olho no contexto da sua worksheet. Como tudo no Snowflake, as tags podem ser criadas em um banco de dados (ou schema) e usadas em outro.

Exemplos:

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.

Criar uma tag sem especificar os valores permitidos define o parâmetro allowed_values como null, permitindo aplicar qualquer string como valor. Isso é prático quando a lista de valores precisa ser dinâmica, mas, na maioria das vezes, o ideal é listar os valores permitidos de antemão e usar alter na tag quando precisar adicionar novos valores.

Conferir os valores permitidos de uma tag

Se quiser verificar os valores permitidos de uma tag existente, há algumas formas simples.

O comando show tags; mostra os metadados de todas as tags da sua account. Uma das colunas retornadas é allowed_values.

Outra opção é chamar a função de sistema system$get_tag_allowed_values para uma tag específica.

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

E ainda há uma terceira: chamar a função get_ddl do Snowflake. Por exemplo:

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

Aplicar a tag em um objeto:

Para aplicar uma tag em um objeto, use o comando alter. Por exemplo, para definir uma tag na tabela select_blog.workday.workday_users:

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

Neste exemplo, a tag foi criada em um banco de dados chamado tutorial_db e usada em outro chamado select_blog.

Opção 1: consultar a view account_usage.tag_references

A view snowflake.account_usage.tag_references mostra todos os lugares em que uma tag é usada e qual é o valor dela. As colunas mais comuns para filtrar são tag_name e tag_value. Essa tabela não mostra a herança de tags; só exibe os objetos marcados diretamente.

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;

Atenção: os dados dessa view têm um atraso considerável. A documentação do Snowflake diz que esse atraso pode chegar a duas horas. Na prática, costumo ver pelo menos uma hora de defasagem.

Opção 2: função get_tag

Como a view snowflake.account_usage.tag_references tem atraso, às vezes você precisa de uma forma rápida de ver mudanças em objetos marcados na hora. A função de sistema system$get_tag está sempre atualizada.

Sintaxe:

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

Exemplo:

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

Opção 3: função account_usage.tag_lineage

Mais cedo falamos sobre "herança de tags"; as tags são propagadas automaticamente dos níveis superiores para os inferiores. A função tag_lineage permite ver todos os objetos marcados diretamente ou que herdaram alguma tag. Seguindo com o exemplo de table_classification, dá para escrever este SQL:

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

Aqui dá para ver que a tag foi aplicada manualmente à tabela WORKDAY_USERS e cada coluna da tabela herda a tag.

Nesta captura de tela, várias colunas foram desmarcadas na interface do Snowsight para a imagem caber.

O Snowflake oferece um dashboard bem prático para acompanhar todas as tags da sua conta.

Com a role accountadmin ou outra configurada corretamente para acessar o dashboard, use a barra lateral do Snowsight para ir até Monitoring —> Governance.

Abaixo está o visual do dashboard. Como estou usando uma conta de demonstração, não há tags definidas, mas dá para perceber a utilidade dele.

Clique na aba "Tagged Objects" para ver todas as tabelas e views da sua account e quais tags se aplicam a esses objetos. Os objetos aparecem na lista tendo ou não uma tag aplicada. Infelizmente, objetos como usuários e warehouses não aparecem aqui. O Snowflake oferece bons filtros nessa página, então vale a pena explorar cada um deles.

Ative o filtro "has tags" para ver apenas objetos com tags:

Crie uma política centralizada de tagging

Governança de dados e o gerenciamento de PII e dados sensíveis é um desafio. É um trabalho majoritariamente não técnico, que exige muita discussão e alinhamento!

O primeiro passo é ter uma estratégia bem pensada. Aqui vão algumas perguntas para começar:

• O que queremos alcançar com as tags? (relatórios de custo, proteção de dados sensíveis etc.)
• Quem define a lista de tags e os valores permitidos? (Estratégia)
• Quais roles podem aplicar tags e quem recebe essas roles? (Tática)
• Como aproveitar a herança de tags da forma mais eficaz?

Use Allowed Values nas tags

Principalmente nos casos em que as tags forem aplicadas manualmente, aproveite a configuração "allowed values". Quando a atribuição é automatizada com base nos dados de uma tabela, isso fica menos crítico.

Automatize o tagging sempre que puder

O tagging perde força quando as equipes dependem da aplicação manual. Pense em formas criativas de automatizar. Tem um exemplo logo abaixo!

Integre o tagging aos pipelines de dados sempre que possível

Existe um pacote útil do dbt chamado dbt_tags; ele ajuda a automatizar o Object Tagging no Snowflake e a alinhar o dynamic masking com base em tags. Se você precisa de mascaramento de dados baseado em tags, vale conferir esse pacote!

Monitore e audite o uso das tags

De que adianta criar todas essas tags se você nunca revisa?! Reserve uma hora por mês para revisar tags, uso e aprimorar sua política de tagging.

O cenário

Imagine que você mantém os metadados dos funcionários no Workday (ou no ERP de sua preferência) e essa tabela é carregada via ETL para o Snowflake. Vamos chamá-la de workday_users. Ela tem uma linha por usuário, e cada coluna representa atributos que queremos manter como tags no usuário do Snowflake. Isso nos permite auditar, observar e definir permissões para usuários com as mesmas tags.

Quando os usuários mudam de departamento ou função, as tags no Snowflake devem ser atualizadas automaticamente.

Crie alguns dados fictícios

Vamos criar uma tabela e dados fictícios para o nosso cenário:

-- 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,

Expandir Código

Preencha a tabela com alguns dados fictícios:

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),

Expandir Código

Neste cenário, queremos transformar qualquer campo terminado em _id em uma tag no usuário do Snowflake.

Crie as tags

Vamos supor que o número de colunas em workday_users seja relativamente estável e que as tags possam ser criadas uma única vez (ou com pouca frequência), sem necessidade de automação. Se uma coluna for adicionada, basta criar uma nova tag. (Ou você pode agendar o código abaixo em uma task! Só não use "replace" nas tags se for agendar.)

O código a seguir consulta os metadados das colunas, filtrando aquelas que contêm _id, conforme nosso requisito. Esses nomes de colunas viram os nomes das nossas tags. Para cada coluna _id, simplesmente criamos uma nova tag. Neste caso, não estou pré-definindo os valores permitidos, já que eles virão dos dados.

Esse código evita escrever manualmente uma dúzia (ou mais) de create tag. Ele executa create or replace tag ... para cada linha de um 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()));

Expandir Código

Como alternativa, você pode executar manualmente comandos como este:

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

-- drop tags if desired
drop tag my_obsolete_tag;

Crie uma view que compare as tags atuais do usuário com o estado desejado

A tabela workday_users representa o "estado desejado", pois contém as informações mais atuais do Workday sobre como queremos que as tags de usuário fiquem. Agora é preciso comparar as tags reais dos usuários com esse estado desejado e mostrar as linhas que não estão com as tags corretas. (Aqui, podemos confiar que a coluna work_email da tabela workday_users corresponde ao e-mail do usuário do Snowflake na tabela snowflake.account_usage.users.)

Vamos salvar essa consulta como uma view, já que ela será reaproveitada com frequência.

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,

Expandir Código

Resumindo o que a view faz:

• Faz unpivot da tabela workday (gera linhas a partir das colunas) para obter uma linha por usuário e tag possível.
• Obtém o USER_NAME do Snowflake que será marcado e o e-mail do Snowflake para fazer o join com a tabela de "estado desejado".
• Faz join pelo e-mail para trazer as tags existentes de cada usuário:
• por fim, mostra todos os registros em que o valor da tag existente é diferente do valor desejado

Esses são os registros que dá para corrigir automaticamente com uma stored procedure.

Como a view tag_updates filtra justamente as linhas em que o valor da tag existente não bate com o desejado, o ideal é que ela fique vazia quando nossas tags estão corretas.

Crie uma stored procedure para aplicar as tags no usuário

A stored procedure faz basicamente o seguinte:

• Para cada linha da view tag_updates:
  • alter user, set tag = tag desejada

Abaixo, apresento duas versões da stored procedure. Uma é simples, sem logging — bem clara e fácil de ler. A segunda é mais detalhada e serve para troubleshooting caso as tags desejadas não sejam aplicadas. Ela inclui mensagens de saída no painel de resultados SQL.

Procedure simples:

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

Expandir Código

Sproc detalhada com 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

Expandir Código

Chame a procedure:

1call set_user_tags();

Agora é só dar uma pausa para o almoço e esperar cerca de uma hora (talvez mais) até a view account_usage.tag_references atualizar. Se as tags estiverem corretas e a view tiver sido atualizada, select * from tag_updates; não retorna nada! Exatamente o que queríamos.

Crie uma task para agendar a stored procedure

Essa task executa a procedure todos os dias às 4h UTC.

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

E pronto: criamos um processo para automatizar as tags de usuário com base na nossa tabela de metadados do Workday.

Agora é a sua vez

Este exemplo cobre um cenário possível de automação de tags. Mas, seguindo nossas boas práticas, busque sempre automatizar o tagging quando der. O processo vai ser sempre o mesmo:

• Defina um estado desejado conhecido.
• Crie as tags (manual ou automaticamente).
• Automatize a aplicação das tags comparando o estado desejado com o estado atual.

Neste artigo, vimos os usos das tags no Snowflake, como criá-las, boas práticas e um cenário avançado. Solte a criatividade! Pense em formas de automatizar o tagging na sua account do Snowflake!

Jeff é Consultor de Dados e Analytics, com mais de 15 anos de experiência em automação de insights e no uso de dados para conduzir processos de negócio. Do lado da tecnologia, é especialista em Snowflake + dbt + Tableau. Em termos de áreas de negócio, atuou em Serviços Públicos, Pesquisa Clínica, Publishing, CPG e Manufatura. Entre em contato a qualquer momento: [email protected].