Hace un par de años me quejaba del muro físico que suponen los servidores tradicionales y lo complejo que es mantener un clúster de Hadoop on-premise. Pues bien, el mercado ha dictado sentencia: el hardware propio está muerto. Todos se mudan a la nube.

Durante este último muchos están en plena migración. Unos usan Amazon Redshift y otros, Google BigQuery. Aunque ambos se venden como "Cloud Data Warehouses", sus filosofías técnicas son opuestas.

Redshift: El poder gestionado

Redshift fue el primero en democratizar el modelo MPP (Massively Parallel Processing) columnar en la nube. Está basado en un fork antiguo de PostgreSQL (ParAccel).

Con Redshift, tú sigues siendo un administrador de bases de datos. Tienes que levantar un clúster, elegir cuántos nodos quieres (por ejemplo, cuatro nodos dc2.large) y pagas por ese clúster esté encendido o no. Tienes que gestionar las claves de distribución (DISTKEY) para que los datos se repartan bien entre los nodos y hacer operaciones de VACUUM regularmente para desfragmentar el disco.

La ingesta de datos es potentísima si la haces desde S3 usando el comando nativo:

-- Ingesta masiva hiper-optimizada en Redshift desde un bucket de S3
COPY fact_ventas 
FROM 's3://mi-bucket-corporativo/datos-ventas/' 
CREDENTIALS 'aws_access_key_id=AKI...;aws_secret_access_key=xyz...' 
FORMAT AS PARQUET;

BigQuery: Tecnología alienígena "Serverless"

Luego probé BigQuery (basado en el paper Dremel de Google), y mi cerebro de DBA hizo cortocircuito. En BigQuery no hay servidores. No eliges nodos, no configuras RAM, no hay índices. Simplemente tienes una caja de texto web donde pegas una consulta SQL y le das al play.

Por debajo, Google asigna dinámicamente miles de CPUs en su red óptica para barrer tu tabla (que puede tener Petabytes) y te devuelve el resultado en segundos. El modelo de precios no es por hardware, es por volumen de datos consultado (unos 5 dólares por Terabyte leído).

-- Un SELECT simple en BigQuery con tipos de datos anidados (Arrays)
SELECT 
  fecha,
  usuario.id,
  ARRAY_LENGTH(usuario.compras) AS numero_compras
FROM `mi-proyecto.dataset_ventas.fact_eventos_web`
WHERE fecha >= '2017-01-01'

Reflexión: El nuevo rol del Ingeniero de Datos

Trabajar con BigQuery me ha hecho darme cuenta de cómo está cambiando nuestro trabajo. Con Redshift sigo haciendo tuning técnico, pero en BigQuery la infraestructura es totalmente opaca.

Esto trae un nuevo peligro: el coste económico directo del mal código. Antes, un SELECT * FROM tabla_gigante mal tirado solo ralentizaba el servidor y cabreaba a tus compañeros. Hoy, lanzar ese mismo query en BigQuery sin usar particiones puede costarle a la empresa 100 dólares en un solo clic. El trabajo del ingeniero de datos ya no es parchear servidores Linux, sino optimizar la arquitectura de tablas para no arruinar a la compañía a final de mes.