Facturas de BigQuery que se triplican de la noche a la mañana, y los seis controles que lo frenan

BigQuery es el servicio con más probabilidad de producir una factura sorpresa en Google Cloud, y el motivo es estructural: el precio bajo demanda cobra por bytes escaneados, y nada en la configuración por defecto impide que un SELECT * contra una tabla de 40 TB se ejecute cuarenta veces al día porque alguien lo puso detrás del refresco de un panel.

La buena noticia es que todos los controles que necesitas existen, son gratis y se ponen en un día.

1. Averigua quién escanea qué, hoy

INFORMATION_SCHEMA.JOBS_BY_PROJECT tiene todas las consultas, su usuario, sus bytes facturados y su duración. Una consulta sobre los últimos 30 días agrupada por usuario y por tabla referenciada te dice dónde se va el dinero. Casi siempre la respuesta está concentrada: dos o tres consultas recurrentes se llevan la mayor parte, y suelen ser una herramienta de BI refrescando según un horario.

Pon esa consulta en un informe programado que aterrice en un canal cada semana. La visibilidad sola cambia el comportamiento más que ninguna política.

2. Particiona y agrupa las tablas grandes

Esta es la mayor palanca y es un cambio de esquema, no de consulta. Una tabla particionada por fecha de ingesta hace que una consulta con filtro de fecha escanee un día en lugar de tres años. Agrupar (clustering) por las columnas por las que la gente filtra —ID de cliente, región, tipo de evento— lo reduce más.

Después activa require_partition_filter en las tablas particionadas. Una consulta sin predicado de fecha falla en lugar de escanearlo todo. Los equipos refunfuñan una semana y después sus consultas van más rápidas.

3. Cuotas personalizadas, por proyecto y por usuario

Ajuste de consola, sin código: una cuota diaria de bytes escaneados por proyecto y por usuario. Pon la de usuario en unas cinco veces el uso diario de un analista normal. No molestará a nadie que trabaje con normalidad y convierte un bucle descontrolado de una factura de cuatro cifras en un mensaje de error.

Este es el control que casi ningún equipo ha activado, y es el que habría evitado todos los sustos de factura de BigQuery a los que nos han llamado.

4. Materializa lo que se consulta una y otra vez

Un panel que recalcula el mismo agregado cada quince minutos debería leer una vista materializada o una tabla de agregados programada, no los eventos en crudo. El patrón: tabla cruda particionada, una consulta programada que escribe agregados diarios y paneles apuntando exclusivamente a los agregados. El volumen escaneado suele caer dos órdenes de magnitud.

Mira también BI Engine para los paneles que se mantienen calientes: cachea a un precio mensual fijo y saca los escaneos repetidos del contador bajo demanda por completo.

5. Decide bajo demanda frente a editions, con números reales

Editions (precio por capacidad) compra slots en lugar de bytes. El punto de cruce depende enteramente de tu patrón:

• Picos impredecibles y volumen total bajo — quédate bajo demanda. No pagas nada cuando nadie consulta.
• Pipelines diarios estables con un suelo predecible — Editions con autoescalado y una base de slots reservados suele salir más barato, y pone techo al peor caso, que a menudo vale más que el ahorro medio.

Modélalo desde la tabla JOBS antes de comprometerte, y ten en cuenta que pueden convivir: reservas para el proyecto de ETL, bajo demanda para el de análisis ad hoc.

6. Almacenamiento, que se olvida por completo

El almacenamiento es la mitad silenciosa de la factura. Tres cosas: el precio de almacenamiento a largo plazo se activa solo tras 90 días sin modificación (así que evita reescrituras inútiles de particiones antiguas), la caducidad de particiones borra datos que no tienes motivo para guardar, y los snapshots de tabla son más baratos que copias completas para el caso "guarda una versión antes de la migración".

Aprovecha para buscar datasets duplicados. Todo entorno tiene tres copias de la tabla de eventos de tres intentos de migración distintos.

Cómo se ve lo bueno

Un mes después de este trabajo, el resultado típico es entre un 50 y un 70 por ciento menos en la línea de BigQuery sin reducir lo que nadie puede hacer y, más importante, con un techo duro para que la siguiente sorpresa no ocurra. Lo tratamos como parte del trabajo de coste en un proyecto cloud, igual que las cinco capas en AWS.

Qué hacer esta semana

Ejecuta la consulta de JOBS_BY_PROJECT sobre los últimos 30 días agrupando por usuario y ordenando por bytes facturados. Después pon una cuota diaria por usuario. Lo primero te cuenta la historia, lo segundo hace que no pueda empeorar mientras la arreglas.