La primera vez que alguien lanza una consulta en BigQuery suele hacer la misma pregunta: «¿pero dónde está el clúster?». No lo hay, y esa es precisamente la gracia. Vamos a ver por qué, y cómo el particionado y el clustering de tablas son las dos palancas más importantes para que esa arquitectura no te salga cara.
Serverless de verdad: cómputo y almacenamiento separados
BigQuery separa físicamente dos capas: el almacenamiento de los datos y el motor de cómputo que ejecuta las consultas. Cada capa escala de forma independiente sin afectar a la disponibilidad ni al rendimiento de la otra, algo que en un motor de base de datos tradicional (donde disco y proceso viven en la misma máquina) simplemente no es posible. En la práctica, esto significa que no reservas servidores ni discos: subes los datos y lanzas SQL, y es Google quien decide cuántos recursos de cómputo dedicar a esa consulta concreta en ese instante.
Por debajo, BigQuery se apoya en el motor de ejecución distribuido de Google (el mismo linaje técnico que dio lugar a Dremel), capaz de repartir una consulta entre miles de nodos en paralelo para escanear terabytes en segundos. Pero para quien escribe SQL a diario, todo eso es invisible: solo hay una tabla, una consulta y una factura al final del mes basada en los bytes procesados.
Ahí está la clave de este artículo: si el coste depende de los bytes procesados, la forma más directa de ahorrar no es optimizar el SQL a mano, es reducir la cantidad de datos que la consulta necesita tocar. Para eso existen el particionado y el clustering.
Particionado: dividir la tabla en trozos
Una tabla particionada se divide en segmentos más pequeños llamados particiones. BigQuery admite tres formas principales de particionar:
Por tiempo de ingesta: BigQuery asigna automáticamente cada fila a una partición según el momento en que se cargó, con granularidad horaria, diaria, mensual o anual.
Por columna de fecha: usando una columna DATE, TIMESTAMP o DATETIME ya existente en la tabla (por ejemplo, la fecha del pedido).
Por rango entero: definiendo un valor inicial, uno final y un intervalo sobre una columna INTEGER.
Cuando una consulta filtra por la columna de particionado, BigQuery puede saltarse por completo las particiones que no coinciden y escanear solo las relevantes. Una tabla de eventos particionada por día, con un filtro WHERE fecha = '2026-09-01', no toca el resto del histórico.
Clustering: ordenar dentro de cada partición
El clustering va un paso más allá: organiza los bloques de almacenamiento según los valores de hasta cuatro columnas definidas por el usuario. BigQuery ordena los datos según esas columnas y, al ejecutar una consulta con un filtro sobre ellas, puede saltarse los bloques que no contienen valores relevantes (lo que la documentación llama block pruning). El orden en que se definen las columnas de clustering importa: la primera es la que más peso tiene a la hora de decidir qué bloques se descartan.
Particionado y clustering no son alternativas, se combinan: una práctica habitual es particionar por fecha y, dentro de cada partición, aplicar clustering por una columna de alta cardinalidad como id_cliente o pais.
| Particionado | Clustering |
|---|---|
| Divide la tabla en segmentos físicos independientes | Ordena los datos dentro del almacenamiento en bloques |
| Normalmente por fecha o rango entero | Hasta 4 columnas, cualquier orden de prioridad |
| Permite estimar el coste antes de ejecutar la consulta | El coste estimado puede ser aproximado, no exacto |
| Buena elección cuando las particiones superan varios GB | Útil sobre todo cuando hay muchas particiones pequeñas o alta cardinalidad |
Si tuviera que quedarme con una sola idea de este artículo, sería esta: en BigQuery, diseñar bien el esquema de particionado y clustering de una tabla es tan importante para el coste como para el rendimiento. No es un ajuste fino de última hora, es una decisión que conviene tomar desde el primer CREATE TABLE.
Si todavía no tienes claro de dónde vienen esos datos antes de llegar a BigQuery, echa un vistazo a cómo se organiza un data lake sobre Cloud Storage.
Leer sobre el data lake en Cloud Storage