¿Qué es el Object Tagging en Snowflake?
El object tagging en Snowflake es una función de data governance que permite categorizar y agrupar objetos (warehouses, tablas, etc.). El objetivo es facilitar el descubrimiento, hacer seguimiento del uso y supervisar el cumplimiento sobre los objetos de Snowflake. Los tags resultan especialmente útiles para identificar objetos de Snowflake con información sensible, como PII o datos financieros. También sirven para asignar la propiedad de los recursos, con fines de monitoreo de costos o de data governance.
¿Qué son los tags?
Para etiquetar objetos en Snowflake, primero hay que crear el tag.
Los tags son objetos a nivel de schema en Snowflake y pueden asociarse a otros objetos como bases de datos, schemas, tablas, columnas, usuarios, warehouses, roles, etc. La lista de objetos que se pueden etiquetar es bastante amplia y se puede consultar aquí.
Un tag es un par clave-valor. El nombre del tag ( create tag <tag name>) actúa como la "clave", y los valores pueden ser una lista predefinida de valores permitidos o quedar sin restricción, admitiendo cualquier string.
Por ejemplo, si quieres llevar el control de la audiencia de una tabla concreta, puedes crear un tag (clave) llamado "audience" con valores como: HR, Sales, Operations, IT, etc. Después, consultarlos es sencillo: muéstrame todas las tablas que usa sales. Más adelante en este post lo veremos con detalle.
Herencia de tags
Va un repaso rápido sobre la " Container Hierarchy" de Snowflake. Una Snowflake Organization es un contenedor de Accounts. Una Account contiene bases de datos. Una base de datos contiene Schemas. Y un Schema contiene tablas, vistas, pipes, file formats, stages y muchos otros objetos.
Cuando etiquetas un objeto en cualquier nivel de la jerarquía de contenedores, el tag se propaga hacia abajo a todos los objetos por debajo. Por ejemplo, si aplico un tag a una base de datos, todas las tablas, vistas, columnas y otros objetos como pipes, stages, etc., heredan ese tag.
Supongamos que tienes tags definidos explícitamente a nivel de account, base de datos y schema, como en este ejemplo:
{
"account": {
"tags": {
"env": "prod",
"region": "us-east-1"
},
"databases": {
"analytics": {
"tags": {
"owner": "data_team",
"classification": "restricted"
},
"schemas": {
"sales": {
"tags": {
Expandir código
Como region se etiqueta a nivel de account, cada base de datos, schema, tabla, vista e incluso cada columna heredará el valor us-east-1. ¡Muy práctico!
Consultar el linaje del tag se hace fácilmente con la función snowflake.account_usage.tag_references_with_lineage, que se muestra abajo. Ver "Observar tags con SQL".
¿En qué se diferencian los Object Tags de los Query Tags?
En Snowflake, un query tag es un único valor de tipo string asociado a una consulta o sesión, lo que facilita filtrar y buscar en el historial de queries. Los query tags no son pares clave-valor: son simplemente strings buscables. En cambio, los object tags sí son pares clave-valor y forman parte del framework de data governance de Snowflake. Se usan para clasificar, controlar y auditar el acceso a activos de datos como tablas, columnas o schemas.
Cuando alguien hable de "tagging" en Snowflake, conviene aclarar si se refiere a query tags o a object tags, porque cumplen propósitos muy distintos.
Cómo usar tags en Snowflake
Crear un tag
La sintaxis para crear un tag es muy sencilla. create tag <tag_name> <allowed values>;
Como los tags son objetos a nivel de schema, conviene usar SQL totalmente calificado o tener presente el contexto de tu worksheet. Igual que cualquier otra cosa en Snowflake, los tags se pueden crear en una base de datos (o schema) y usarse en otra.
Ejemplos:
use schema governance.tags;
create tag table_classification allowed_values 'metadata', 'fact', 'dimension';
-- crea un tag con una lista específica de valores permitidos.
create tag user_group;
-- crea un tag que admite cualquier valor.
Crear un tag sin especificar los valores permitidos deja el parámetro allowed_values en null, lo que permite aplicar cualquier string como valor. Esto resulta útil cuando la lista de valores debe ser dinámica, aunque lo más habitual es listar los valores permitidos por adelantado y usar alter sobre el tag cuando haga falta sumar más.
Verificar los valores permitidos de un tag
Si quieres revisar los valores permitidos de un tag existente, hay varias formas sencillas.
El comando show tags; muestra los metadatos de todos los tags de tu account. Una de las columnas que devuelve es allowed_values.
Otra opción es invocar la función del sistema system$get_tag_allowed_values para un tag específico.
select system$get_tag_allowed_values(
'governance.tags.cost_center');
Y otra forma más es invocar la función get_ddl en Snowflake. Por ejemplo:
1select get_ddl('tag','dev.public.TESTING_TAG_1');
Usar el tag etiquetando un objeto:
Para asignar un tag a un objeto, usa el comando alter. Por ejemplo, si quieres asignar un tag a una tabla llamada select_blog.workday.workday_users:
alter table select_blog.workday.workday_users
set tag tutorial_db.public.table_classification = 'metadata';
En este ejemplo, el tag se crea en una base de datos llamada tutorial_db y se usa en una base de datos llamada select_blog.
Observar los tags de Snowflake con SQL
Opción 1: consultar la vista account_usage.tag_references
La vista snowflake.account_usage.tag_references muestra todos los lugares donde se usa un tag y cuál es su valor. Las columnas más comunes para filtrar son tag_name y tag_value. Esta tabla no refleja la herencia de tags: solo muestra los objetos etiquetados directamente.
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;
Ten en cuenta que los datos de esta vista tienen un retraso considerable. La documentación de Snowflake indica que pueden tardar hasta dos horas. En mi experiencia, lo habitual es que el retraso sea de al menos una hora.
Opción 2: función get_tag
Como la vista snowflake.account_usage.tag_references va con retraso, a veces necesitas una forma rápida de ver los cambios en los objetos etiquetados al instante. La función del sistema system$get_tag siempre está al día.
Sintaxis:
SELECT SYSTEM$GET_TAG( <fully qualified tag name>,
<'fully qualified object name'>, <'object class such as table, view, etc' > )
AS TAG_META;
Ejemplo:
SELECT SYSTEM$GET_TAG( 'tutorial_db.public.table_classification',
'SELECT_BLOG.WORKDAY.WORKDAY_USERS', 'TABLE' )
AS TAG_META;
Opción 3: la función account_usage.tag_lineage
Antes hablamos de la "herencia de tags": los tags se propagan automáticamente desde los niveles superiores hacia los inferiores. La función tag_lineage te permite ver todos los objetos que se han etiquetado directamente o que han heredado un tag. Siguiendo con el ejemplo de table_classification, podemos escribir este SQL:
SELECT *
FROM TABLE(
snowflake.account_usage.tag_references_with_lineage(
'TUTORIAL_DB.PUBLIC.TABLE_CLASSIFICATION'
)
);
Aquí vemos que el tag se aplicó manualmente a la tabla WORKDAY_USERS y que cada columna de la tabla hereda el tag.
En esta captura, deseleccioné varias columnas en la interfaz de Snowsight para que la imagen entrara bien.
Observar los tags de Snowflake desde Snowsight
Snowflake ofrece un dashboard muy útil para ver todos los tags en Snowflake.
Con el rol accountadmin o un rol configurado correctamente para ver el dashboard, ve a la barra lateral de Snowsight y entra en Monitoring —> Governance.
Así se ve el dashboard. Como estoy usando una cuenta demo, no hay tags configurados, pero ya se nota lo útil que va a ser.
Haz clic en la pestaña "Tagged Objects" para ver todas las tablas y vistas de tu account, junto con los tags que se les aplican. Los objetos aparecen en la lista tengan o no un tag asignado. Lamentablemente, objetos como usuarios y warehouses no están aquí. Snowflake ofrece buenas opciones de filtrado en esta página, así que vale la pena revisarlas.
Activa el filtro "has tags" para ver solo los objetos con tags:
Buenas prácticas para el tagging en Snowflake
Define una política centralizada de tagging
El data governance y la gestión de PII y datos sensibles no son tareas simples. ¡Es un trabajo mayormente no técnico que requiere mucha conversación y alineación!
El primer paso es contar con una estrategia bien pensada. Aquí van algunas preguntas para empezar.
- ¿Qué buscamos lograr con los tags? (reportes de costos, asegurar datos sensibles, etc.)
- ¿Quién define la lista de tags y los valores permitidos? (Estrategia)
- ¿Qué roles pueden asignar tags y quién recibe esos roles? (Táctica)
- ¿Cómo aprovechamos la herencia de tags de la forma más eficaz?
Aprovecha los Allowed Values en los tags
Sobre todo cuando los tags se asignan a mano, conviene usar la configuración de "allowed values". En los casos en que la asignación se automatiza con base en los datos de una tabla, esto pierde criticidad.
Automatiza el tagging siempre que se pueda
El tagging se queda corto cuando los equipos dependen de aplicar tags manualmente. Busca formas creativas de automatizarlo. ¡Más abajo tienes un ejemplo!
Integra el tagging con tus data pipelines siempre que se pueda
Existe un paquete muy útil de dbt llamado dbt_tags: te ayuda a automatizar el Object Tagging en Snowflake y a alinear el dynamic masking en función de los tags. Si necesitas data masking basado en tags, ¡échale un vistazo!
Monitorea y audita el uso de tags
¡¿De qué sirve crear todos esos tags si después no los revisas?! Dedica una hora al mes a revisar tus tags, su uso y a actualizar tu política de tagging.
Automatizar el tagging en Snowflake: un ejemplo práctico
El escenario
Imagina que mantienes metadatos de tus empleados en Workday (o el ERP que prefieras) y esa tabla se mueve por ETL hacia Snowflake. Llamémosla tabla workday_users. Tiene una fila por usuario, y cada columna representa atributos que queremos mantener como tags sobre el usuario de Snowflake. Esto nos permite auditar, observar y asignar permisos sobre usuarios con los mismos tags.
Cuando los usuarios cambian de departamento o de rol, los tags de Snowflake deberían actualizarse de forma automática.
Crear datos de prueba
Vamos a crear una tabla y datos de prueba para nuestro escenario:
-- Esta tabla representa una tabla que se cargaría por ETL desde Workday a Snowflake, con metadatos de usuario
-- Estoy usando una base de datos demo; cambia la tuya.
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
Carga la tabla con algunos datos de prueba:
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
En este escenario queremos convertir cualquier campo que termine en _id en un tag sobre el usuario de Snowflake.
Crear los tags
Supongamos que el número de columnas de workday_users es relativamente estable y que los tags se pueden crear como un ejercicio único (o poco frecuente) que no necesita automatización. Si se agrega una columna, creamos un nuevo tag. (¡O puedes programar el código de abajo para que se ejecute como una task! Eso sí, no uses "replace" sobre los tags si lo programas.)
El código de abajo consulta los metadatos de columnas y filtra las que contienen _id, según nuestro requisito. Los nombres de esas columnas pasan a ser los nombres de nuestros tags. Por cada columna _id creamos un tag. En este caso no predefiniremos los valores permitidos, ya que se tomarán de los datos.
Este código te ahorra escribir a mano una docena o más de sentencias create tag. Ejecuta el create or replace tag ... por cada fila de 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()));
Expandir código
Como alternativa, puedes ejecutar comandos como estos a mano:
use schema select_blog.workday;
create tag pillar_id;
create tag team_id;
-- elimina tags si lo deseas
drop tag my_obsolete_tag;
Crear una vista que compare los tags reales del usuario con el estado deseado
La tabla workday_users es el "estado deseado", ya que contiene la información más actualizada de Workday sobre cómo queremos configurar los tags de los usuarios. Ahora hay que comparar los tags reales del usuario con el estado deseado y mostrar las filas que no tengan los tags correctos. (En este caso, podemos confiar en que la columna work_email de la tabla workday_users corresponde a la dirección de correo del usuario de Snowflake en la tabla snowflake.account_usage.users.)
Guardemos esta consulta como vista, porque la vamos a reutilizar a menudo.
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
Resumamos lo que hace la vista:
- Hace unpivot sobre la tabla de workday (genera filas a partir de columnas) para obtener una fila por usuario y posible tag.
- Obtiene el
USER_NAMEde Snowflake que se va a etiquetar y la dirección de email de Snowflake para unirla con la tabla del "estado deseado". - Hace join por email para obtener los tags existentes de cada usuario:
- finalmente, muestra todos los registros en los que el valor del tag existente no coincide con el deseado
Estos son los registros que podemos actualizar automáticamente con un stored procedure.
Como la vista tag_updates filtra las filas en las que el valor del tag existente no coincide con el deseado, lo ideal es que esta vista quede vacía cuando los tags estén configurados correctamente.
Crear un stored procedure para asignar los tags al usuario
El stored procedure ejecuta estos pasos básicos:
- Por cada fila en la vista
tag_updates:- alter user, set tag = tag deseado
A continuación dejo dos versiones del stored procedure. Una es una versión simple sin logging. Es muy clara y fácil de leer. La segunda es más detallada y se usa para diagnosticar cuando los tags deseados no se aplican. Incluye mensajes de salida en el panel de resultados de SQL.
Procedimiento 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
Expandir código
Sproc detallado con logging:
-- crea el procedimiento usando un rol de admin con permisos para "alter user".
user role accountadmin; -- o usa el rol useradmin si tus usuarios pertenecen a useradmin
-- si usas el rol useradmin, debes otorgarle usage sobre la base de datos. Por eso es más sencillo usar 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):
# Toma exactamente las columnas que necesitas de la vista revisada
query = """
SELECT
Expandir código
Llama al procedimiento:
1call set_user_tags();
Ahora, tómate un descanso para almorzar y espera alrededor de una hora (quizá más) a que la vista account_usage.tag_references se actualice. Si los tags quedaron bien asignados y la vista ya se refrescó, select * from tag_updates; no devuelve nada. ¡Justo lo que queríamos!
Crear una task para programar el stored procedure
Esta task ejecutará el procedimiento todos los días a las 4 AM UTC.
CREATE TASK set_user_tags
SCHEDULE = 'USING CRON 0 4 * * * UTC' AS
CALL set_user_tags();
alter task set_user_tags resume;
Y listo: creamos un proceso para automatizar los tags de usuario a partir de nuestra tabla de metadatos de Workday.
Ahora te toca a ti
Este ejemplo cubre un escenario posible para automatizar tags. Pero, siguiendo nuestras buenas prácticas, busca siempre automatizar el tagging cuando sea posible. El proceso siempre será el mismo:
- Definir un estado deseado conocido.
- Crear los tags (a mano o de forma automatizada).
- Automatizar la asignación de tags comparando el estado deseado con el estado real.
Para cerrar
En este artículo vimos los usos de los tags en Snowflake, cómo crearlos, buenas prácticas y un escenario avanzado. ¡Sé creativo! Piensa en formas de automatizar el tagging en tu account de Snowflake.
Jeff es Data and Analytics Consultant con más de 15 años de experiencia automatizando insights y usando datos para controlar procesos de negocio. En el plano tecnológico, se especializa en Snowflake + dbt + Tableau. En el plano de negocio, tiene experiencia en Public Utility, Clinical Trials, Publishing, CPG y Manufacturing. Escríbele cuando quieras a [email protected].