top of page

Gobierno del dato en GCP: la Marie Kondo de BigQuery

  • Foto del escritor: Daniela RBR
    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.SCHEMATA


Dimension 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 ALL


Job 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.


Captura de modelo de datos volcado a Power BI
Captura de modelo de datos volcado a Power BI

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


bottom of page