AlpinaShop lleva tres módulos generando datos sin mirarlos. Los pedidos se acumulan en alpinashop-pedidos, las visitas quedan en los registros del balanceador, las imágenes se sirven desde el CDN y los carritos se abandonan en Firestore. Lucía, la analista, tiene una libreta con preguntas que nadie ha respondido: qué mochila se vende más en Cataluña, si la campaña de otoño movió la aguja, por qué el 30 % de los carritos se quedan en el paso de envío, cuánto vale de media un pedido y cómo ha evolucionado ese número en dos años.

La reacción instintiva de mucha gente ante ese problema es abrir una conexión a la base de datos de producción y empezar a escribir SELECT. En 02-03 ya evitamos lo peor creando la réplica de lectura alpinashop-pedidos-replica-informes, para que los informes no compitan con las compras. Pero esa réplica es un parche. Una consulta que recorra dos años de líneas de pedido para agrupar por categoría y mes seguirá tardando minutos y seguirá siendo incómoda de escribir, porque PostgreSQL no está construido para eso. PostgreSQL está construido para responder "dame el pedido 48213" en un milisegundo, no para responder "dame la media de todos los pedidos de los últimos dos años agrupados por seis dimensiones".

En esta lección vas a entender por qué esas dos preguntas requieren máquinas distintas, vas a crear el dataset alpinashop_analitica en alpinashop-datos, vas a cargar en él el histórico de pedidos, vas a escribir el SQL que responde de verdad a las preguntas de Lucía y —esto es lo que separa a quien sabe usar BigQuery de quien recibe una factura sorpresa— vas a aprender exactamente cómo se paga y cómo se evita pagar de más.

1. Por qué un almacén analítico no es "una base de datos más grande"
2. Cómo funciona BigQuery por dentro: columnas, separación y Dremel
3. Cloud SQL frente a BigQuery: la tabla que hay que interiorizar
4. Estructura: proyecto, dataset, tabla y vista
5. Creación del dataset alpinashop_analitica
6. Tipos de datos, STRUCT y ARRAY: la desnormalización como virtud
7. Creación de las tablas de AlpinaShop
8. Cargar datos: desde Cloud Storage, en streaming y sin cargarlos
9. Traer el histórico desde Cloud SQL con consultas federadas
10. SQL de negocio: las preguntas de Lucía, respondidas
11. El modelo de coste y cómo no arruinarse
12. Particionado y clustering: el antes y el después medido
13. Vistas materializadas, caché de resultados y cuotas
14. Almacenamiento lógico frente a físico
15. Control de acceso: dataset, tabla, columna y fila
16. INFORMATION_SCHEMA: auditar quién gasta y en qué
17. BigQuery ML, mencionado y aplazado

Hay dos familias de carga de trabajo sobre datos, y confundirlas es el error conceptual más caro de esta profesión.

OLTP (procesamiento de transacciones en línea) es lo que hace alpinashop-pedidos. Muchas operaciones muy pequeñas, concurrentes, que leen y escriben unas pocas filas identificadas por clave primaria, con garantías transaccionales estrictas. "Inserta este pedido", "actualiza el stock del SKU MOCH-40L-AZ", "dame el carrito del usuario 8821".

OLAP (procesamiento analítico en línea) es lo que quiere Lucía. Pocas consultas, muy grandes, que leen millones de filas, tocan pocas columnas de cada una, agregan, agrupan y ordenan, y no escriben nada.

La diferencia no es de tamaño, es de forma. Y esa forma determina cómo conviene guardar los bytes en disco.

Imagina la tabla lineas_pedido con 8 millones de filas y estas columnas: pedido_id, sku, nombre_producto, categoria, cantidad, precio_unitario, descuento, iva, fecha, pais_envio, metodo_pago, email_cliente, notas.

• PostgreSQL guarda los datos por filas: todos los campos de la línea 1, luego todos los de la línea 2, etc. Es perfecto para "dame la línea 1 entera", porque está contigua en disco.
• La pregunta de Lucía, en cambio, es SELECT categoria, SUM(cantidad * precio_unitario) FROM lineas_pedido GROUP BY categoria. Solo necesita tres de las trece columnas. Pero para leer esas tres, PostgreSQL tiene que arrastrar del disco las trece, porque están entrelazadas. Lee diez veces más bytes de los que usa.

BigQuery guarda los datos por columnas: todos los valores de categoria juntos, todos los de cantidad juntos. La consulta anterior lee exclusivamente tres bloques de disco y no toca los otros diez. Y como cada bloque contiene valores del mismo tipo y muy repetitivos —categoria tendrá una docena de valores distintos en ocho millones de filas—, se comprime brutalmente bien.

De ahí se derivan las dos reglas que gobiernan todo lo demás en BigQuery:

• Leer pocas columnas es barato; leer todas es caro. Por eso SELECT * es, literalmente, la forma más rápida de gastar dinero.
• Filtrar por una columna no evita leerla. Si filtras por WHERE pais_envio = 'ES', BigQuery tiene que leer toda la columna pais_envio para saber qué filas cumplen. La única forma de no leer datos es que estén particionados o clusterizados, que veremos en el apartado 12.

Tres decisiones de arquitectura explican por qué BigQuery se comporta como se comporta.

Almacenamiento columnar propio (Capacitor). Los datos se guardan en un formato columnar comprimido en el sistema de ficheros distribuido de Google (Colossus), replicado automáticamente. Tú no ves ficheros, no gestionas índices, no haces VACUUM y no defines tablespaces. No hay nada que administrar.

Separación total de almacenamiento y cómputo. Esta es la más importante y la que cambia la mentalidad. En Cloud SQL, el disco y la CPU están en la misma máquina: si necesitas más CPU, pagas también más máquina, y si la base de datos está parada, la máquina sigue encendida y facturando. En BigQuery no hay máquina.

• El almacenamiento se factura por GB al mes que hay guardados. Existe siempre.
• El cómputo se factura por consulta ejecutada (o por capacidad reservada). Si nadie consulta, el cómputo cuesta cero.

Consecuencia inmediata para AlpinaShop: puedes tener 2 TB de histórico guardados y, si Lucía se va de vacaciones, pagar únicamente el almacenamiento —unos pocos euros— sin apagar nada. Y al revés: una consulta puede movilizar cientos de máquinas durante 8 segundos y luego devolverlas. Esa elasticidad es imposible en un modelo con servidor.

Ejecución distribuida (motor Dremel). Cuando lanzas una consulta, el planificador la descompone en un árbol de ejecución. Las hojas del árbol —los workers— leen fragmentos de columnas en paralelo, cada uno hace su parte de la agregación, y los resultados intermedios suben por el árbol mezclándose en una capa de shuffle en memoria hasta producir el resultado final.

La unidad de ese cómputo se llama slot: un slot es, aproximadamente, una porción de CPU con su memoria asociada. Una consulta usa tantos slots como el planificador considere y haya disponibles. Volveremos a los slots en el apartado 11, porque son la clave del modelo de precios por capacidad.

La lectura correcta de esta tabla no es "BigQuery es mejor". Es: son herramientas complementarias y AlpinaShop necesita las dos. La tienda seguirá comprando contra Cloud SQL. Lucía analizará contra BigQuery. El trabajo de esta lección y de las siguientes es construir la tubería que lleva los datos de la primera a la segunda.

La jerarquía de BigQuery se apoya en la jerarquía de recursos que ya conoces de 01-04:

Cuatro precisiones que evitan problemas más adelante:

• El proyecto es la unidad de facturación. Las consultas que Lucía lance se cargan al proyecto donde se ejecutan, no al proyecto donde vive la tabla. Esto permite, por ejemplo, que marketing consulte datos de alpinashop-datos pagando desde su propio proyecto. Para AlpinaShop, todo se ejecuta y se factura en alpinashop-datos, que ya tiene su etiqueta centro-coste.
• El dataset es la unidad de organización y de permisos. Es donde se conceden roles, y es lo que se comparte.
• La ubicación del dataset es inmutable. Se decide al crearlo y no se puede cambiar: para moverlo hay que crear otro y copiar los datos. Elegiremos europe-west1, coherente con el resto de la infraestructura de AlpinaShop y con la exigencia del RGPD de mantener los datos personales de clientes europeos en la UE.
• No se puede hacer un JOIN entre datasets de ubicaciones distintas. Si mañana alguien crea alpinashop_marketing en us-central1, no podrá cruzarlo con alpinashop_analitica. Es el error de diseño irreversible más común en BigQuery. Fija la ubicación como estándar del equipo desde el primer día.

El nombre completo de una tabla es proyecto.dataset.tabla, y en SQL estándar se escribe entre acentos graves cuando el proyecto lleva guiones:

Una nota de nomenclatura: los identificadores de dataset y tabla admiten letras, números y guiones bajos, pero no guiones. Por eso el proyecto es alpinashop-datos (con guion) y el dataset es alpinashop_analitica (con guion bajo).

Trabajaremos con la herramienta bq, que viene incluida en la CLI de gcloud y en Cloud Shell desde 01-06.

Opción por opción:

• --location=europe-west1: la ubicación inmutable. Va antes del subcomando mk, no después; es un error habitual.
• --dataset: indica que el recurso a crear es un dataset y no una tabla.
• --default_table_expiration=0: sin caducidad automática. Si pusieras 2592000 (30 días en segundos), toda tabla creada aquí se autodestruiría a los 30 días. Es utilísimo en un dataset de pruebas y catastrófico en producción, así que conviene ser explícito.
• Las tres etiquetas replican el esquema entorno/equipo/centro-coste que AlpinaShop fijó en 01-04, para que el coste de analítica se pueda aislar en el informe de facturación.

Conviene crear también un dataset de trabajo con caducidad, para que las tablas temporales de los análisis no se acumulen para siempre:

Verificación:

En la salida de bq show fíjate en "location": "europe-west1". Si dice US, has creado el dataset en el sitio equivocado: bórralo ahora, antes de meterle datos, porque después ya no hay marcha atrás barata.

Los tipos escalares de BigQuery son pocos y deliberadamente estrictos:

Regla que ahorra disgustos: los importes van en NUMERIC, jamás en FLOAT64. Con FLOAT64, sumar 1.10 € y 2.20 € puede dar 3.3000000000000003, y ese céntimo fantasma aparecerá en un informe de dirección en el peor momento posible.

Y ahora la parte que distingue el modelado en BigQuery del modelado relacional clásico: los tipos anidados.

• ARRAY<T>: una lista ordenada de valores del tipo T dentro de una única celda.
• STRUCT<...>: un registro con campos nombrados dentro de una única celda.
• Se combinan: ARRAY<STRUCT<sku STRING, cantidad INT64, precio NUMERIC>> es "una lista de líneas de pedido dentro de la fila del pedido".

En PostgreSQL, un pedido con tres líneas son cuatro filas repartidas en dos tablas unidas por clave foránea. En BigQuery puede ser una sola fila que contiene, dentro, sus tres líneas.

¿Por qué esto es mejor aquí? Porque en un motor distribuido, un JOIN entre dos tablas grandes obliga a mover datos entre máquinas por la capa de shuffle, y eso es lo caro. Si las líneas ya viajan pegadas a su pedido, el JOIN desaparece: se convierte en un UNNEST, que es una operación local dentro de cada worker, sin red de por medio.

Esa fila contiene un pedido completo. envio es un STRUCT (un registro), y lineas es un ARRAY<STRUCT<...>> (una lista de registros). Todo lo que hace falta para analizar el pedido está en un solo sitio del disco.

La regla práctica de modelado: normaliza en OLTP para evitar duplicidad al escribir; desnormaliza en OLAP para evitar JOIN al leer. El almacenamiento es barato (unos céntimos por GB al mes); el shuffle no lo es.

Dicho esto, no hay que llevarlo al extremo. Para AlpinaShop mantendremos pedidos y lineas_pedido como tablas separadas —porque es como llegan de PostgreSQL y facilita la carga incremental— y anidaremos donde aporte de verdad: el bloque de envío dentro del pedido, y los eventos dentro de la sesión de navegación. Es un punto intermedio honesto y muy común en la práctica.

Vamos a crear las cuatro tablas con DDL en SQL, que es más legible y versionable que un JSON de esquema. Estas sentencias se ejecutan en BigQuery Studio, la interfaz de consulta de la consola (menú BigQuery), o desde bq query --use_legacy_sql=false.

Los tres detalles que importan:

• PARTITION BY fecha_pedido divide físicamente la tabla en una partición por día. Una consulta que filtre por fecha solo leerá las particiones necesarias.
• CLUSTER BY estado, canal ordena los datos dentro de cada partición por esas columnas, en ese orden. Los filtros por estado podrán saltarse bloques enteros.
• require_partition_filter=TRUE es la mejor decisión defensiva de toda la lección: rechaza cualquier consulta que no filtre por fecha_pedido. Un SELECT * FROM pedidos fallará con un error explícito en lugar de escanear dos años de datos. Es un cinturón de seguridad barato que evita facturas absurdas.

Nota de diseño sobre lineas_pedido: hemos duplicado fecha_pedido desde la cabecera. En un modelo relacional eso sería redundancia censurable. Aquí es imprescindible, porque una tabla solo puede particionarse por una columna propia. Sin esa duplicación, cualquier JOIN entre pedidos y líneas obligaría a escanear la tabla de líneas entera. Es el ejemplo perfecto de por qué las reglas del modelado OLTP no se trasladan literalmente.

Y la tabla de navegación, que sí aprovecha el anidamiento a fondo:

Una sesión de 40 clics es una fila, no 40. Contar cuántas sesiones llegaron a iniciar_pago pero no a compra —la pregunta del carrito abandonado que traía Lucía— será una operación local, sin JOIN y sin shuffle.

Hay cuatro maneras de meter datos en BigQuery, y elegir la equivocada es una fuente clásica de coste y de dolor.

Es el caballo de batalla y es gratis, lo que sorprende a mucha gente. Google no cobra la ingesta por lotes: cobra el almacenamiento resultante y las consultas posteriores.

Supongamos que el volcado nocturno del histórico de pedidos deja ficheros en el bucket. Formatos admitidos: CSV, JSON delimitado por líneas (NDJSON), Avro, Parquet y ORC.

• El comodín pedidos-*.csv permite cargar decenas de ficheros en una sola operación, y BigQuery los procesa en paralelo. Es mucho mejor que un fichero gigante.
• --null_marker='\N' traduce la marca de nulo que usa pg_dump en formato CSV; sin esto acabarías con la cadena literal \N en las celdas.
• Pasar el esquema en un fichero JSON es preferible a --autodetect. La autodetección adivina, y adivinar con dinero es mala idea: es capaz de inferir FLOAT64 para una columna de importes o STRING para una fecha con un formato raro.

Comparación honesta de formatos:

Recomendación para AlpinaShop: Avro o Parquet en los procesos automáticos, porque llevan el esquema dentro y no hay ambigüedad de tipos ni sorpresas con las comas de los nombres de producto. CSV solo para lo que llega de terceros, como el fichero del transportista que veremos en 04-05.

Cuando el dato debe estar disponible en segundos —el panel de la campaña de otoño en tiempo real— se usa la Storage Write API, que sustituye a la antigua tabledata.insertAll y es más barata y con mejores garantías.

Dos advertencias importantes sobre el streaming:

1. Cuesta dinero por GB insertado, mientras que la carga por lotes es gratis. Si el dato puede esperar una hora, no lo transmitas en streaming: acumúlalo en el bucket y cárgalo por lotes. Es una de las optimizaciones de coste más rentables y más ignoradas.
2. Para AlpinaShop, la vía real no será este código en la aplicación Flask, sino Pub/Sub → BigQuery (04-04) o Pub/Sub → Dataflow → BigQuery (04-02). Escribir directamente a BigQuery desde la web acopla la tienda al almacén analítico: si BigQuery tiene una incidencia, no queremos que la tienda deje de vender.

A veces el dato ya está en alpinashop-catalogo y no compensa duplicarlo. Una tabla externa deja los ficheros donde están y BigQuery los lee en el momento de la consulta.

Ventajas: cero duplicación, cero coste de ingesta, el dato siempre refleja el bucket. Inconvenientes: consultas más lentas, sin partición ni clustering, y sin caché de resultados. Úsalas para datos consultados de vez en cuando o como zona de aterrizaje antes de una carga real.

BigLake es la evolución de las tablas externas: añade control de acceso fino —permisos a nivel de columna y de fila sobre datos que viven en el bucket— sin que el analista necesite permiso sobre el bucket. Se apoya en una conexión de BigQuery con su propia cuenta de servicio, que es quien accede a Cloud Storage. Para AlpinaShop, eso significa que Lucía podrá consultar los CSV de exportación sin tener storage.objectViewer sobre alpinashop-catalogo, lo que encaja con el mínimo privilegio de 03-04.

El histórico de pedidos vive en alpinashop-pedidos. Para traerlo hay una vía elegante: EXTERNAL_QUERY, la consulta federada, que ejecuta SQL directamente en PostgreSQL y devuelve el resultado a BigQuery como si fuera una tabla.

Primero, la conexión. La crea Marta una sola vez:

Fíjate en dos decisiones deliberadas:

• Apuntamos a la réplica de lectura alpinashop-pedidos-replica-informes, no a la instancia principal. Es exactamente para lo que se creó en 02-03: que los informes no toquen la base de datos que atiende las compras.
• Usamos el usuario informes_lectura, que solo tiene SELECT. La contraseña real debe salir de Secret Manager (db-password-catalogo es la del catálogo; para esto se creará su propio secreto), nunca de un fichero en el repositorio, como fijamos en 03-06.

Ahora la carga del histórico, en una sola sentencia:

Cómo leerlo:

• La cadena que va dentro de EXTERNAL_QUERY es SQL de PostgreSQL, no de BigQuery. Se ejecuta allí, con la sintaxis de allí. Las triples comillas evitan tener que escapar las comillas simples internas.
• Filtrar dentro de esa cadena (WHERE creado_en >= ...) es crítico: cuantas menos filas cruce la red, mejor. Filtrar fuera, en BigQuery, traería igualmente todo.
• El STRUCT(...) construye el bloque anidado envio a partir de las seis columnas planas que devuelve PostgreSQL. Aquí se ve la traducción entre los dos modelos.

Cuándo NO usar consultas federadas: para cargas grandes y repetidas. EXTERNAL_QUERY mete carga en la instancia de PostgreSQL y no paraleliza; sirve para el volcado inicial y para traer tablas pequeñas y frescas (el maestro de productos, por ejemplo). La sincronización diaria del histórico se hará con el patrón exportar → cargar orquestado en 04-06, o con CDC, que veremos en 04-05.

BigQuery usa GoogleSQL, un dialecto estándar ANSI con extensiones. Si sabes SQL, sabes el 90 %. Vamos con las preguntas reales.

El WHERE sobre fecha_pedido no es cosmética: es lo que activa la poda de particiones y lo que hace que require_partition_filter=TRUE no rechace la consulta. Sin él, BigQuery leería la tabla entera.

APPROX_QUANTILES calcula percentiles de forma aproximada pero muchísimo más barata que el cálculo exacto sobre millones de filas. Incluir la mediana junto a la media no es un capricho estadístico: si un pedido corporativo de 4.000 € entra en marzo, la media se dispara y la mediana no se inmuta. Enseñar solo la media es cómo se engaña sin querer a un comité de dirección.

Cuidado con NOT IN y los nulos: si la subconsulta devolviera algún sku nulo, NOT IN devuelve cero filas sin avisar. En producción es más seguro LEFT JOIN ... WHERE l.sku IS NULL o NOT EXISTS.

Dos joyas aquí:

• OVER (PARTITION BY categoria) calcula sobre cada grupo sin colapsar las filas, que es justo lo que un GROUP BY no puede hacer.
• QUALIFY filtra por el resultado de una función de ventana directamente, sin necesidad de envolver todo en otra subconsulta. Es una extensión de GoogleSQL y ahorra muchísimo ruido.

UNNEST(eventos) convierte el array de eventos de cada sesión en filas, y la coma antes de él es un CROSS JOIN implícito con la fila padre: cada evento conserva acceso a sesion_id, pais y demás. Es local a cada worker, sin shuffle. El último campo responde directamente a la pregunta del carrito abandonado que traía Lucía desde el módulo 3, y NULLIF(..., 0) evita la división por cero cuando un día no hay pagos iniciados.

Este apartado vale por sí solo el precio de la lección. BigQuery es maravilloso y también es el servicio con el que más gente se lleva un susto en la factura.

Hay dos modelos de cómputo, y se pueden mezclar por proyecto:

Las ediciones actuales son Standard, Enterprise y Enterprise Plus, con reservas de slots que pueden ser de autoescalado (pagas los slots que se usan, con un mínimo) o comprometidas a uno o tres años con descuento. Cada una añade funciones: Standard cubre lo básico, Enterprise añade gobierno y CMEK, Enterprise Plus añade recuperación avanzada y residencia estricta.

Para AlpinaShop la decisión es bajo demanda, y hay que decirlo con sus números: un equipo de tres personas consultando unos pocos cientos de gigabytes al mes gasta unos pocos euros. Reservar slots tendría un coste fijo mensual muy superior. La regla práctica del sector es migrar a capacidad cuando el gasto bajo demanda supera de forma estable el coste de la reserva equivalente, algo que suele ocurrir a partir de decenas de terabytes consultados al mes.

Ahora, lo que de verdad hay que hacer todos los días.

Devuelve algo como:

428 MB. A ~5 $/TB, unos 0,002 $. Sin problema. Pero el mismo cálculo sobre una consulta mal escrita puede devolver 900 GB y costar 4,50 $ cada vez que alguien pulse ejecutar. Diez analistas refrescando un panel cada cinco minutos convierten eso en una factura de cuatro cifras al mes.

En BigQuery Studio no hace falta el comando: la interfaz muestra arriba a la derecha, en tiempo real mientras escribes, "Esta consulta procesará X". Enséñale a mirar ahí a todo el que reciba acceso. Es la costumbre más rentable que puedes instalar en un equipo de datos.

Se paga por los bytes de las columnas leídas. SELECT * sobre pedidos lee las catorce columnas; SELECT pedido_id, total_pedido lee dos. Diferencia habitual: entre cinco y veinte veces.

LIMIT no reduce el coste. Es el malentendido número uno. Para inspeccionar datos usa bq head o la pestaña Vista previa de la consola: leen directamente el almacenamiento y no cuestan nada.

Y una utilidad que sí ayuda cuando quieres muchas columnas menos una:

Ya declaramos partición y clustering al crear las tablas. Ahora midamos qué compran exactamente.

Partición: divide la tabla en trozos por el valor de una columna (fecha, rango entero, o el tiempo de ingesta). BigQuery descarta particiones enteras sin leerlas si el WHERE lo permite.

Clustering: ordena físicamente los datos dentro de cada partición por hasta cuatro columnas. Permite saltarse bloques dentro de la partición.

El experimento, con una tabla de pedidos de dos años (supongamos 40 GB):

De 3 GB a 4 MB: 750 veces menos. Y no ha cambiado ni una letra del SQL, solo la definición física de la tabla. A escala de un año de consultas diarias, esa diferencia es la que separa una factura de tres euros de una de dos mil.

El clustering no aparece en el --dry-run porque su ahorro solo se conoce al ejecutar (el planificador no sabe de antemano cuántos bloques podrá saltar). Se mide en el resultado real:

Guía de decisión rápida:

Un matiz sobre el orden en CLUSTER BY estado, canal: el orden importa. El clustering ordena primero por estado y dentro por canal. Un filtro solo por canal aprovecha mucho menos el clustering que un filtro por estado. Pon primero la columna por la que más filtras.

Tres mecanismos más para pagar menos, en orden de esfuerzo creciente.

Si ejecutas exactamente la misma consulta sobre datos que no han cambiado, BigQuery devuelve el resultado cacheado: coste cero y respuesta inmediata, durante unas 24 horas. Se invalida al modificar cualquier tabla implicada.

Se rompe sin querer con más facilidad de la que parece: basta con que la consulta use CURRENT_TIMESTAMP() o funciones no deterministas, o que el texto cambie en un carácter. Si un panel usa WHERE fecha >= CURRENT_DATE() - 7, nunca cacheará bien. Conviene fijar fechas explícitas cuando el informe lo permita.

Una vista es SQL guardado: no ocupa espacio y se ejecuta —y se paga— entera cada vez.

Una vista materializada guarda el resultado precalculado y BigQuery lo refresca de forma incremental cuando cambia la tabla base. Además, y esto es lo mejor, el optimizador la usa automáticamente aunque tú consultes la tabla original.

El panel de Looker Studio que construirá Lucía en 04-07 leerá unos pocos megabytes de esta vista materializada en vez de escanear la tabla de líneas cada vez que alguien abra el informe. Limitaciones a conocer: solo admite un subconjunto de SQL (agregaciones sí; JOIN con restricciones y ventanas no), y el refresco incremental consume cómputo, así que no crees veinte.

Se pueden imponer límites duros de bytes procesados, por proyecto y por usuario:

Y a nivel de sesión o de consulta individual:

Para AlpinaShop la política es: cuota de proyecto en 2 TB/día, require_partition_filter en las tablas grandes, y una alerta de presupuesto en Facturación (01-04) a 50 € mensuales sobre la etiqueta centro-coste:analitica. Tres redes de seguridad independientes, ninguna cara.

El almacenamiento tiene su propio modelo, y desde hace unos años se puede elegir cómo se factura por dataset.

El precio por GB en modo físico es aproximadamente el doble, pero los GB suelen ser entre 4 y 10 veces menos porque BigQuery comprime muy bien las columnas repetitivas. Para datos como los de AlpinaShop —categorías, estados, países que se repiten millones de veces— el modo físico suele salir claramente más barato. Hay que medirlo antes de cambiar:

Además existe el precio de larga duración: una partición que no se modifica durante 90 días consecutivos baja automáticamente de precio, alrededor de la mitad. Es automático, no hay que hacer nada, y no afecta al rendimiento ni a la disponibilidad. Como la mayor parte del histórico de AlpinaShop no se toca nunca, buena parte del almacenamiento acabará a esa tarifa reducida sola.

Cuidado con un detalle: cualquier UPDATE sobre una partición reinicia su contador de 90 días. Un proceso mal diseñado que reescriba el histórico entero cada noche mantiene toda la tabla en tarifa alta para siempre. Es otro argumento a favor de las cargas incrementales por partición.

Aquí se aplica todo lo de IAM (03-04), más dos capas que solo existen en BigQuery.

Los roles predefinidos relevantes:

El matiz que confunde a todo el mundo: dataViewer no basta para consultar. Ver los datos y ejecutar un trabajo son permisos distintos. Hace falta también jobUser en el proyecto donde se ejecuta la consulta. Si Lucía dice "veo la tabla pero no puedo consultarla", es esto el 90 % de las veces.

Como siempre desde 03-04: permisos a grupos, nunca a personas. Cuando entre otro analista, basta con meterlo en gcp-datos@.

Recordemos también el rol personalizado analistaCatalogo que se creó en 03-04 en alpinashop-datos. Ahora tiene sentido completarlo con los permisos analíticos mínimos:

Aviso de RGPD. email_cliente es un dato personal. Su tratamiento con fines analíticos exige base legal, minimización y limitación del acceso. Lo que sigue es un control técnico, no un dictamen jurídico: cualquier tratamiento de datos personales reales debe revisarlo un profesional de compliance o el DPO antes de ponerse en producción. Todos los datos de este curso son ficticios.

El control se hace con etiquetas de política de Data Catalog. La idea: se etiqueta la columna, y solo quien tenga el rol Lector detallado sobre esa etiqueta puede leerla.

Y se aplica a la columna:

A partir de ese momento, si Lucía ejecuta SELECT * FROM pedidos, la consulta falla entera con un error de acceso a email_cliente. Debe escribir SELECT * EXCEPT(email_cliente) o listar columnas. Es un efecto secundario deseable: refuerza la costumbre de no usar SELECT *, que ya sabemos que además es cara.

Para AlpinaShop, la recomendación completa es no traer el email en crudo al almacén analítico. Lucía necesita saber cuántos clientes distintos compraron, no quiénes. Un identificador seudonimizado sirve igual:

El sal debe venir de Secret Manager (03-06) y no estar escrito en el SQL como aquí; sin sal, un hash de email es reversible por fuerza bruta y sigue siendo dato personal. En 04-07 veremos la herramienta específica para esto, Sensitive Data Protection.

Una política de acceso a filas filtra qué filas ve cada identidad. Útil si mañana AlpinaShop abre filial en Francia y cada equipo comercial solo debe ver su mercado:

El filtro se aplica de forma transparente e ineludible: el usuario escribe su SELECT normal y solo obtiene las filas de España, sin saber que existe la política.

Si quieres dar acceso al resultado pero no a la tabla base, se usa una vista autorizada: se concede permiso sobre la vista, la vista tiene permiso sobre la tabla, y el usuario no. Es el mecanismo limpio para exponer datos agregados a marketing sin abrirles el detalle de pedidos.

BigQuery se observa a sí mismo. INFORMATION_SCHEMA son vistas de solo lectura con metadatos y con el historial de trabajos. Esta consulta debería ejecutarse una vez por semana en cualquier equipo serio:

El precio de 6,25 está puesto a mano como orden de magnitud: sustitúyelo por el vigente en tu región y verifícalo en la documentación oficial, porque cambia.

Otras consultas útiles del mismo sitio:

Este último es el equivalente analítico de la limpieza de discos huérfanos de 02-01: en todo almacén de datos con un año de vida hay tablas _backup_final_v2 que nadie recuerda y que se pagan cada mes.

BigQuery incluye BigQuery ML, que permite entrenar modelos con sintaxis SQL: CREATE MODEL ... OPTIONS(model_type='linear_reg'), y luego ML.PREDICT. Se puede hacer regresión, clasificación, series temporales con ARIMA_PLUS, k-means, factorización matricial para recomendaciones e incluso invocar modelos de Vertex AI desde SQL.

Para AlpinaShop es una vía muy atractiva: previsión de demanda por SKU antes de la campaña de otoño, o segmentación de clientes, sin sacar el dato de BigQuery ni montar infraestructura.

Pero eso es módulo 5. Allí veremos Vertex AI, AutoML y los modelos de recomendación con el rigor que merecen: cómo se separan los datos de entrenamiento y validación, cómo se evalúa un modelo y por qué una métrica buena en pruebas puede ser inútil en producción. Aquí solo queda anotado que la puerta existe y que está a un CREATE MODEL de distancia.

Crear el dataset en US por descuido. Es la opción por defecto de la consola y es irreversible. Además de impedir los JOIN con europe-west1, saca datos personales de clientes europeos fuera de la UE. Comprueba siempre la ubicación antes de cargar el primer byte, y fija --location=europe-west1 en la configuración del equipo.

Creer que LIMIT abarata la consulta. No lo hace: se leen los mismos bytes. Para mirar datos, bq head o la vista previa, que son gratis.

Usar SELECT * por costumbre. En un motor columnar es entre cinco y veinte veces más caro. Escribe las columnas, o usa SELECT * EXCEPT(...).

Olvidar el filtro de partición. Sin WHERE fecha_pedido ..., una tabla particionada se lee entera y la partición no sirve de nada. Activa require_partition_filter=TRUE y deja que el motor te proteja.

Usar FLOAT64 para importes. Los errores de redondeo aparecen justo en el informe que ve dirección. NUMERIC siempre para dinero.

Hacer UPDATE y DELETE como en PostgreSQL. BigQuery los admite, pero reescriben particiones enteras, son caros y reinician el contador de larga duración. Para actualizaciones masivas, MERGE o reescritura de la partición completa con WRITE_TRUNCATE. Y para corregir un dato de un pedido, hazlo en Cloud SQL y vuelve a sincronizar.

Escribir en BigQuery desde la aplicación web. Acopla la tienda al almacén analítico. Publica en Pub/Sub (04-04) y que sea otro proceso quien escriba. La tienda debe poder vender aunque la analítica esté caída.

Dar dataViewer y olvidar jobUser. Es el ticket de soporte más repetido del mundo BigQuery.

Poner LIMIT a una consulta que ordena. ORDER BY sobre millones de filas obliga a un ordenamiento global que puede agotar los recursos con el error Resources exceeded. Agrega primero, ordena después; o usa funciones de ventana con QUALIFY.

Consejo: usa etiquetas en los trabajos. bq query --label=proceso:panel-direccion permite después separar en INFORMATION_SCHEMA cuánto cuesta cada consumidor de datos. Cuando alguien pregunte "¿cuánto nos cuesta el panel de dirección?", tendrás el número.

Consejo: guarda el DDL en Git. Las sentencias CREATE TABLE de esta lección son código. Deben estar versionadas junto al resto del proyecto, no solo dentro de BigQuery. En 06-07 las convertiremos en Terraform.

Crea en alpinashop-datos un dataset de pruebas llamado alpinashop_ejercicios en europe-west1 cuyas tablas caduquen a los 3 días. Dentro, crea una tabla opiniones con: opinion_id (STRING, obligatorio), sku (STRING, obligatorio), fecha (DATE, obligatorio), puntuacion (INT64), texto (STRING), pais (STRING). Debe estar particionada por fecha, clusterizada por sku y rechazar consultas sin filtro de partición. Después inserta tres opiniones de ejemplo y comprueba con --dry-run cuántos bytes cuesta consultar las de un único día.

Con las tablas de alpinashop_analitica, escribe una única consulta que devuelva, para cada mes de 2026 y solo para pedidos no cancelados ni devueltos: el mes, el número de pedidos, la facturación total, el ticket medio, la categoría más vendida de ese mes y el porcentaje que esa categoría representa sobre el total del mes. Ordena por mes. Antes de ejecutarla, estima su coste con --dry-run.

Marta recibe la alerta de presupuesto: alpinashop-datos lleva gastados 180 € este mes cuando el histórico eran 12 €. Nadie ha cargado datos nuevos. Escribe las consultas de INFORMATION_SCHEMA que te permitan (a) identificar al usuario o cuenta de servicio responsable, (b) aislar la consulta concreta y cuántas veces se ha ejecutado, y (c) determinar si aprovecha la caché. Después propón tres medidas correctoras concretas, ordenadas de la más inmediata a la más estructural.

Solución 1

El resultado será de unos pocos cientos de bytes: con tres filas, es casi todo metadatos. Lo interesante es el hábito, no la cifra. Y si quitas el WHERE fecha, la consulta no será cara: fallará, porque require_partition_filter=TRUE la rechaza. Ese error es exactamente el comportamiento deseado.

Solución 2

Las claves de la solución:

• Los CTE (WITH) parten el problema en pasos legibles. BigQuery los evalúa como parte del plan; no crean tablas ni cuestan aparte.
• QUALIFY ROW_NUMBER() OVER (...) = 1 se queda con la categoría líder de cada mes en una sola pasada. ROW_NUMBER y no RANK porque queremos exactamente una fila aunque haya empate.
• El SUM(...) OVER (PARTITION BY mes) calcula el total del mes sin colapsar las filas, lo que permite dividir para obtener la cuota.
• Los filtros de fecha están en las dos tablas particionadas. Omitirlos en lineas_pedido haría que el JOIN escaneara la tabla completa: la consulta daría el mismo resultado y costaría veinte veces más.
• NULLIF(..., 0) protege de la división por cero en un mes sin ventas.

El --dry-run sobre un histórico de dos años debería dar unos cientos de megabytes: céntimos. Sin los filtros de partición, decenas de gigabytes.

Solución 3

(a) Identificar al responsable:

(b) Aislar la consulta y contar ejecuciones:

(c) Comprobar el aprovechamiento de caché:

Diagnóstico típico y esperable: el culpable no es una persona, sino un cuadro de mando que se autorrefresca cada 5 minutos ejecutando SELECT * FROM lineas_pedido sin filtro de fecha. Un pct_cache cercano a cero lo confirma: si la consulta lleva CURRENT_TIMESTAMP() o la tabla recibe escrituras continuas, la caché nunca sirve. 288 ejecuciones al día × 2 GB × 30 días ≈ 17 TB ≈ 100 €.

Tres medidas correctoras, de lo inmediato a lo estructural:

1. Hoy mismo (contención): aplicar --maximum_bytes_billed al usuario o a la cuenta de servicio del panel y fijar la cuota diaria del proyecto en 2 TB. La sangría se detiene en minutos aunque nadie toque el panel.
2. Esta semana (corrección): reescribir la consulta del panel con las columnas explícitas y filtro de partición, y bajar el refresco de 5 minutos a 1 hora. Suele bastar para dividir el coste por cien.
3. Este mes (estructural): crear una vista materializada con la agregación que el panel necesita y apuntar el cuadro de mando a ella; activar require_partition_filter=TRUE en las tablas grandes para que el problema no pueda repetirse; y programar la consulta de auditoría semanal con una alerta si algún usuario supera un umbral de TB.

La medida 3 es la única que impide la reincidencia. Las dos primeras compran tiempo.

AlpinaShop ya tiene almacén de datos. En esta lección has entendido la diferencia real —no la de eslogan— entre OLTP y OLAP: no es cuestión de tamaño, sino de forma de acceso, y esa forma es la que justifica el almacenamiento columnar, la separación de almacenamiento y cómputo, y la ejecución distribuida en slots que hace que una consulta sobre ochocientos millones de filas termine en segundos.

Has creado el dataset alpinashop_analitica en alpinashop-datos, en europe-west1, sabiendo que esa ubicación es una decisión irreversible con implicaciones de cumplimiento y de capacidad de cruzar datos. Has definido las tablas pedidos, lineas_pedido, productos y visitas con tipos correctos —NUMERIC para el dinero, siempre—, con STRUCT para el bloque de envío y con un ARRAY<STRUCT<...>> de eventos dentro de cada sesión, entendiendo por qué la desnormalización, que en PostgreSQL sería un error, aquí es la forma de evitar el shuffle que es lo verdaderamente caro en un motor distribuido.

Has cargado datos por las cuatro vías y sabes cuál usar: lotes desde Cloud Storage —gratis— para el volumen, streaming solo cuando los segundos importan, tablas externas y BigLake para lo que no compensa duplicar, y EXTERNAL_QUERY contra la réplica alpinashop-pedidos-replica-informes para el volcado inicial del histórico, apuntando deliberadamente a la réplica y con el usuario informes_lectura de solo lectura.

Has escrito el SQL que responde a las preguntas que Lucía llevaba tres módulos acumulando: ventas por categoría y mes, ticket medio con su mediana al lado para no engañar a nadie, productos que no venden, ranking por categoría con funciones de ventana y QUALIFY, y el embudo de conversión completo con UNNEST sobre los eventos anidados, que por fin pone número al 30 % de carritos abandonados.

Y, sobre todo, has aprendido a no arruinarte: --dry-run antes de ejecutar, SELECT * desterrado, LIMIT desenmascarado como falso ahorro, particionado por fecha que convirtió 3 GB en 4 MB, clustering ordenado por la columna que más filtras, require_partition_filter como cinturón de seguridad, vistas materializadas para los paneles, caché de resultados que es gratis si no la rompes, cuotas por proyecto y por consulta, almacenamiento físico frente a lógico medido con datos propios, y INFORMATION_SCHEMA como la herramienta que convierte "la factura ha subido" en "esta consulta, este usuario, 288 veces al día". Has cerrado el acceso con roles a grupos, has recordado que dataViewer sin jobUser no consulta nada, y has protegido email_cliente con una etiqueta de política —con la advertencia expresa de RGPD y la recomendación de no traer el email en crudo al almacén, sino un identificador seudonimizado con sal de Secret Manager.

Queda un hueco evidente. Todo lo que hemos cargado es histórico: una foto de lo que ya pasó, traída de PostgreSQL de una vez. Pero AlpinaShop no para de vender. Ahora mismo, mientras lees esto, hay clientes navegando el catálogo, añadiendo mochilas al carrito y confirmando pedidos, y ninguno de esos hechos llega a alpinashop_analitica. Sincronizar a mano cada noche es un parche que ya se rompe cuando alguien pide "quiero ver las ventas de la campaña hoy, no mañana".

En 04-02, Cloud Dataflow, construiremos la tubería que falta. Verás qué es un pipeline de datos y por qué un script en una VM no basta; aprenderás el modelo de Apache Beam, que describe con el mismo código un proceso por lotes y uno en tiempo real; escribirás en Python un pipeline que lee el histórico del bucket alpinashop-catalogo, lo limpia, lo agrega y lo escribe en las tablas que acabas de crear; y entrarás en el territorio realmente interesante del streaming —tiempo del evento frente a tiempo de proceso, marcas de agua, ventanas y datos tardíos— para dejar preparado el pipeline que consumirá el topic pedidos-nuevos en cuanto lo creemos en 04-04. Cuando termines esa lección, los datos dejarán de llegar cuando alguien se acuerda y empezarán a llegar solos.