Gobierno del dato en GCP: la Marie Kondo de BigQuery
- Daniela RBR
- 27 jun
- 10 Min. de lectura
Actualizado: 30 jun
El trastorno de acumulación compulsiva es un trastorno mental caracterizado por la dificultad persistente para desechar o desprenderse de objetos, independientemente de su valor real. ¿Te suena de algo? Si tenés un perfil vinculado al mundo data y trabajas o trabajaste en una empresa data-driven seguro que ya fuiste testigo de lo que voy a bautizar como «Data hoarding disorder»: acumular bases, tablas, vistas, logs, backups, en nombre de 'por las dudas'.
Pero, ¿por qué pasa? La verdadera respuesta es: no hay porque, pero por intentar ponerle sentido a algo que no necesariamente lo tenga se me ocurren estos motivos:
Miedo a perder información: el famoso FOMO digital.
Sensación de que limpiar es perder tiempo o correr riesgos: “mejor dejarlo ahí”.
Cultura del ‘más es mejor’: como si guardar fuera gratis y encontrar fácil.
Falta de herramientas o políticas de limpieza automatizada: nadie se encarga, nadie decide.
En mi experiencia trabajando con varios clientes, puedo confirmar que en BigQuery muchos proyectos viven en estado de acumulación digital crónica: datasets sin dueño, tablas olvidadas, vistas rotas... todos las ven, pero nadie las borra.
Donde hay mucho dato, hay mucho poder. Pero si ese dato está desorganizado, duplicado o simplemente olvidado, más que poder, puede convertirse en ruido, costo y debilidad.
En esta nota te voy a mostrar:
Cómo detectar acumulación innecesaria en BigQuery.
Una forma simple de auditar sin herramientas externas.
Qué metadatos ya tenés disponibles para gobernar mejor.
Cómo tomar decisiones sin revisar tabla por tabla.
Por qué este enfoque ahorra tiempo, costos y frustraciones.
El método BrotDani: auditar BigQuery sin morir en el intento
Marie Kondo es una muy conocida consultora de organización y escritora, famosa a nivel mundial por desarrollar el método de organización llamado Método KonMari, que se basa en la idea de mantener solo aquellos objetos que “despiertan alegría”. Este método propone ordenar por categorías, en lugar de hacerlo por espacios físicos. Más que un simple orden, busca reflejar los valores y prioridades de cada persona.
Daniela Rodriguez-Brot Rey —más conocida en ciertos círculos de Slack como Daniela Brot— es una (todavía) nada conocida divulgadora entre el data science y el data engineering. Un día le tocó una tarea desafiante: auditar los BigQuery de varios proyectos de un cliente que acumulaban más de diez mil tablas. El objetivo era claro: entender qué había y hacer limpieza. Así nació lo que bautizaré como Método BrotDani: un enfoque práctico para auditar y documentar BigQuery basado 100% en metadatos.
El método BrotDani es una forma concreta de aplicar principios de gobierno del dato sobre BigQuery, usando metadatos como punto de partida y visualización como herramienta de decisión.
A grandes rasgos, consiste en:
Mapear lo que hay: recolectar información de todos los activos en BigQuery —datasets, tablas, vistas, jobs, estructuras, tamaño, uso, etc.
Cruzar uso real con estructura: combinar actividad (última consulta, última actualización) con características técnicas (cantidad de columnas, particiones, clusterización, tamaño, convención de nombres).
Detectar problemas comunes: vistas innecesarias, tablas sin consultas recientes, backups, tests olvidados, estructuras mal diseñadas o costosas.
Generar recomendaciones automáticas: a partir de un set de reglas simples (CASE WHEN), se clasifican los objetos en acciones posibles: borrar, optimizar, documentar, cambiar nombre, monitorear.
El Método BrotDani es una forma de auditar BigQuery con criterio y decisión. No se limita a listar lo que hay: clasifica, diagnostica y propone acciones concretas para mejorar la salud del dato.
¿Y de dónde saco toda esta info?
Las vistas de INFORMATION_SCHEMA en BigQuery son vistas automáticas que el propio sistema genera y mantiene. Son de solo lectura y te permiten acceder a los metadatos de tus objetos: tablas, vistas, columnas, jobs, etc. sin herramientas externas, sin scripts raros y sin permisos especiales más allá del acceso al proyecto o dataset.
En la documentación oficial van a encontrar alrededor de 70 vistas de INFORMATION_SCHEMA para consultar metadatos en BigQuery. Algunas están marcadas con una cruz (†), que indica que tienen variantes como BY_PROJECT, BY_USER o BY_FOLDER. Otras tienen un ícono de matraz, que señala que están en fase experimental.
Hay vistas para casi todo: desde listar datasets, columnas o rutinas, hasta consultar permisos, monitorear sesiones o revisar recomendaciones automáticas del sistema.
Hay que tener en cuenta que cada vista tiene su propia forma de consultarse. Algunas alcanza con especificar la región:
SELECT *
FROM `region-{eu/us}.INFORMATION_SCHEMA.SCHEMATA`Otras solo admiten calificadores de conjunto de datos:
SELECT *
FROM `{project_id}.{dataset_id}.INFORMATION_SCHEMA.PARTITIONS`Algunas admiten ambos formatos:
SELECT *
FROM `{project_id}.{dataset_id}.INFORMATION_SCHEMA.TABLES`
SELECT *
FROM `region-{eu/us/...}.INFORMATION_SCHEMA.TABLES`Existen otros casos dónde se debe utilizar calificadores de proyecto y es necesario filtrar:
SELECT *
FROM `{project_id}`.`region-{eu/us/...}`.INFORMATION_SCHEMA.OBJECT_PRIVILEGES
WHERE object_schema = "{dataset_id}"
AND object_name = "{table_id}";Todo esto lo detalla en la sección de sintaxis o al ver cada página de los distintos casos.
¿Qué se utilizó en el método BrotDani?
Haciendo un remainder, el objetivo del Método BrotDani es auditar y documentar proyectos de BigQuery usando únicamente metadatos disponibles, sin herramientas externas. La idea es construir un inventario vivo, que combine estructura + uso real, y que permita tomar decisiones concretas: qué borrar, qué documentar, qué optimizar, etc
Este método se basa en estas 7 vistas principales de INFORMATION_SCHEMA, todas consultadas a nivel de región.
Vista | ¿Qué aporta? |
SCHEMATA | Listado completo de datasets, con fecha de creación, última modificación y ubicación regional |
TABLES | Todas las tablas y vistas creadas, con fechas y tipo de objeto. |
JOBS | Actividad real: quién consultó qué, cuándo, cuánto procesó, errores, duración, y destino. |
TABLE_STORAGE | Tamaño lógico y físico de cada tabla, uso de particiones, tiempo de viaje, almacenamiento en frío, etc. |
TABLE_OPTIONS | Metadatos como descripción, etiquetas, URIs o tags personalizados. |
COLUMNS | Número de columnas por tabla, tipos de datos, clustering, etc. |
VIEWS | Definición de cada vista, incluyendo su tabla base o tabla de origen. |
Estas vistas permiten hacer una auditoría completa y escalarla a cualquier proyecto.
Ejecución del método BrotDani
la ejecución del método consistió en diseñar una serie de consultas SQL que cruzan estructura, uso y documentación, para construir un inventario activo de todo el ecosistema BigQuery.
Estas consultas fueron agrupadas en cinco bloques principales:
Bloque de análisis | Objetivo general | Consulta principal (vistas usadas) |
Dataset Detail | Mapear todos los datasets del proyecto | SCHEMATA |
Dimension Table/View | Unificar y agrupar objetos por nombre lógico | TABLES |
Job Detail | Obtener uso real, costo, duración y errores | JOBS + referenced_tables + labels |
Table Detail | Auditar estructura, tamaño, documentación y uso | TABLE_STORAGE, TABLE_OPTIONS, COLUMNS, JOBS |
View Detail | Auditar vistas: origen, documentación y actividad | VIEWS, TABLE_OPTIONS, COLUMNS, JOBS |
Cada bloque tiene su propia lógica para combinar metadatos relevantes. En los casos de tablas y vistas, esta combinación permite derivar una recomendación automática por objeto (por ejemplo: delete, optimize, document, no action, etc.), a partir de reglas simples definidas mediante CASE WHEN.
Dataset detail
Devuelve el listado de todos los datasets del proyecto, con fechas de creación y última modificación, además de su ubicación regional.
¿Para qué sirve?
Permite conocer cuántos datasets hay, cuándo fueron creados y si están activos o abandonados.
Facilita el cruce con otras vistas (como JOBS o TABLES) para detectar datasets sin uso reciente o sin responsable.
Sirve como punto de partida para construir un inventario del ecosistema BigQuery.
Tabla resultado:
Campo | Significado |
project_id | El ID del proyecto (desde catalog_name) |
dataset_id | Nombre completo del dataset (project.dataset) |
dataset_name | Solo el nombre del dataset |
creation_date | Fecha de creación del dataset |
last_modified_date | Fecha de última modificación en el dataset |
location | Región donde está alojado el dataset (por ej. EU) |
Código:
SELECT catalog_name as project_id
, CONCAT(catalog_name, ".",schema_name ) as dataset_id
, schema_name as dataset_name
, EXTRACT(DATE FROM creation_time) as creation_date
, EXTRACT(DATE FROM last_modified_time) as last_modified_date
, location
FROM `region-eu`.INFORMATION_SCHEMA.SCHEMATADimension table view
Agrupa y normaliza tablas y vistas para generar una dimensión de objetos lógicos, estandarizando nombres similares (por ejemplo, versiones fechadas de una misma tabla). es decir, ignorando sufijos numéricos.
¿Para qué sirve?
Permite contar cuántas veces se ha creado una misma tabla con distintas fechas o sufijos.
Ayuda a detectar patrones de creación automatizada o prácticas poco sostenibles (como duplicación masiva).
Funciona como clave para cruzar con otras vistas (como storage o jobs) y consolidar métricas por grupo lógico.
Tabla resultado:
Campo | Significado |
project_id | ID del proyecto (desde table_catalog) |
dataset_id | Dataset al que pertenece la tabla o vista |
table_id | Ruta completa del objeto, con nombre unificado (_* como comodín) |
table_view_name | Nombre lógico: se eliminan sufijos de fecha o versión |
table_type | Si es BASE TABLE o VIEW |
first_creation_date | Fecha de la primera instancia creada con ese nombre lógico |
last_creation_date | Fecha de la última versión con ese nombre lógico |
Código:
SELECT table_catalog as project_id
, CONCAT (table_catalog, ".", table_schema) as dataset_id
, CONCAT (table_catalog, ".", table_schema, ".",
REGEXP_REPLACE(table_name, r'_\d{1,8}\*?$', '_*')) as table_id
, REGEXP_REPLACE(table_name, r'_\d{1,8}\*?$', '_*') AS table_view_name
, table_type
, MIN(EXTRACT(DATE FROM creation_time)) as first_creation_date
, MAX(EXTRACT(DATE FROM creation_time)) as last_creation_date
FROM `region-eu`.INFORMATION_SCHEMA.TABLES
GROUP BY ALLJob detail
Explora el historial de trabajos ejecutados en el proyecto, extrayendo metadatos sobre consultas, usuarios, costos, duraciones, errores y tablas referenciadas.
¿Para qué sirve?
Permite identificar quién usó qué tabla y cuándo fue la última vez que se consultó.
Facilita el análisis de costos estimados y la detección de queries costosas o fallidas.
Es clave para cruzar uso real con los objetos analizados (tablas, vistas) y asignar actividad reciente.
Tabla resultado:
Campo | Significado |
creation_date | Fecha de creación del job (formateada como YYYYMMDD) |
user_email | Usuario que ejecutó el job, o quien lo solicitó (requestor) |
job_type, statement_type | Tipo de job (QUERY, LOAD, etc.) y sentencia SQL ejecutada |
duration_seconds | Duración del job |
state, error_message | Estado final del job y posible error |
total_bytes_processed | Datos procesados (medida bruta) |
total_slot_ms, total_bytes_billed | Consumo de slots y bytes facturados |
estimated_cost_usd | Estimación de costo en dólares |
referenced_table | Tabla accedida o modificada |
table_id_in_query | Tabla detectada a partir del SQL si no aparece como referenced_table (muy útil en SELECT, INSERT, etc.) |
destination_table.* | Tabla de destino (si corresponde) |
looker_studio_report_id | ID de informe si vino de Looker Studio |
is_scheduled_query | Si es una consulta programada (Scheduled Query) |
Código:
Table detail
Consolida estructura, tamaño, uso y configuración técnica de todas las tablas del proyecto. Cruza fuentes para enriquecer cada tabla con metadatos clave.
¿Para qué sirve?
Permite auditar el tamaño lógico/físico, el particionado, el clustering y la cantidad de columnas.
Evalúa si las tablas están bien documentadas (descripción, etiquetas, tags).
Detecta inactividad, estructuras ineficientes o mal diseñadas, y aplica reglas para generar recomendaciones automáticas como delete, optimize, document, etc.
Tabla resultado:
Campo | Qué aporta |
table_id | Identificador único de la tabla |
total_logical_gb / total_physical_gb | Tamaño lógico y físico |
total_rows | Número total de filas |
naming_snake_case | Si cumple convención de nombres |
num_columns | Número de columnas en la tabla |
description, labels, tags | Metadatos útiles para catalogación |
last_date_query | Última vez que alguien consultó la tabla |
storage_last_modified_date | Última modificación real del contenido |
query_made_by | Quién la consultó (usuario, Looker o proceso) |
days_since_last_query / days_since_last_update | Métricas clave para limpieza |
recommendation | Acción sugerida: borrar, documentar, optimizar, etc. |
Código:
View detail
Extrae información sobre las vistas creadas en el proyecto: su origen (tabla base), estructura, documentación y uso reciente.
¿Para qué sirve?
Permite detectar vistas no consultadas en mucho tiempo o con nombres mal definidos.
Facilita revisar si las vistas están documentadas o referencian objetos inexistentes.
Genera recomendaciones como delete view, add description o change name, según reglas establecidas.
Tabla resultado:
Campo | Qué aporta |
view_id / view_name | Nombre completo y nombre lógico de la vista |
origin_table / origin_table_group | Tabla base desde donde se construye la vista |
naming_snake_case | Si sigue una convención de nombres |
description, labels, tags | Metadatos para documentación |
last_date_query, query_made_by | Último uso, por quién |
days_since_last_query | Tiempo desde la última ejecución |
num_columns | Complejidad estructural |
recommendation | Acción sugerida: eliminar, documentar, cambiar nombre, etc. |
Código:
Los códigos completos están publicados en este repositorio público de GitHub: Link al repositorio
Esquema del modelo BrotDani
Detrás del Método BrotDani no hay magia, hay estructura. Se construyó un modelo relacional donde las tablas se conectan mediante claves primarias y foráneas. Así, se combinan uso real, estructura y metadatos descriptivos en una tabla final que permite generar recomendaciones y tomar decisiones con criterio.
Lo que todo gobernador del dato quiere
Este enfoque no es solo una auditoría técnica: es una forma de cubrir, de manera automática y escalable, muchas de las tareas que un gobernador del dato táctico debería llevar adelante.
Concretamente, se cubren tareas de:
Auditoría de uso y actividad: Permite saber qué tablas y vistas se usan, cuándo y por quién, detectando recursos abandonados.
Documentación del dato: Verifica si los objetos tienen descripción, etiquetas u otra metadata útil para entender su propósito.
Control de convenciones de nombres: Evalúa si los nombres respetan un formato definido (como snake_case), para mejorar la coherencia.
Optimización de almacenamiento y performance: Detecta oportunidades de particionar, clusterizar o reducir columnas, bajando costos y mejorando tiempos de consulta.
Eliminación de activos obsoletos: Cruza uso real con estructura y metadata para sugerir qué tablas o vistas deberían eliminarse o revisarse.
Inventario vivo del catálogo: Genera una vista completa del ecosistema de BigQuery, con lógica de salud por objeto y trazabilidad.
Con esta solución se aborda cerca del 80 % del trabajo táctico que implica el gobierno del dato de BigQuery. Y lo mejor: se hace de forma automática, replicable y sostenible. Lo que suele parecer un proyecto eterno, acá se convierte en un sistema con impacto real.
Te paso la idea en limpio y resumida
Auditar BigQuery no es solo una tarea técnica: es una práctica esencial para el gobierno del dato. Sin controles, los proyectos se llenan de tablas, vistas y datasets innecesarios, lo que eleva costos, genera desorden y pone en riesgo la calidad del ecosistema.
El Método BrotDani propone un enfoque práctico y automatizable para auditar y documentar BigQuery usando exclusivamente metadatos. A través de consultas a INFORMATION_SCHEMA, se construye un modelo relacional que combina uso real, estructura técnica y metadata descriptiva para generar recomendaciones automáticas: borrar, optimizar, documentar o monitorear.
El resultado no es solo un diagnóstico puntual, sino un inventario vivo y escalable que cubre cerca del 80 %, si no es más, de las tareas tácticas del rol de gobernador del dato de BigQuery. Una solución concreta para tomar decisiones con criterio y fomentar una cultura de datos más ordenada, eficiente y sostenible.
¡Gracias por leer!
y no te olvides que le podés dar "me gusta" a esta nota sin haberte logueado.
Muchas gracias Esther Ponce por los aportes y el trabajo a la par en todo este aprendizaje.
 | Hola, soy Daniela. Durante muchos años fui docente de matemáticas en colegios y universidades, además de editar y escribir libros educativos. Hoy trabajo como Data Science Engineer y divulgo contenido sobre matemática, estadística y ciencia de datos en este sitio y en redes sociales. Crear y compartir conocimiento es mi forma de seguir conectada con la docencia. Creo firmemente en dos ideas que me acompañan desde siempre: "adquirir nuevos conocimientos te mantiene vigente" y "compartir es vivir". |
Comments