Comprendiendo el procesamiento de esas consultas complejas en plataformas SQL

Hoy en dia existe una gran «guerra» en el mundo de los datos donde destacan aparte de las plataformas Cloud otras como Snowflake y Databricks.

Aunque en su mayoria estos sistemas que pueden manejar consultas de cientos de líneas con rapidez, sus enfoques tecnológicos son distintos.

Para entender este panorama en 2026, debemos ver cómo gestionan principalmente el cómputo y el almacenamiento:

1. Snowflake: El motor SQL «Puro»

Snowflake es un Data Warehouse diseñado desde cero para SQL.

• Arquitectura: Utiliza Multi-Cluster Shared Data. El almacenamiento y el cómputo están totalmente separados.
• Velocidad en consultas complejas: Es extremadamente rápido para SQL porque su motor es propietario. Snowflake sabe exactamente cómo están organizados sus datos (micro-particiones), lo que le permite aplicar optimizaciones automáticas que en Spark tendrías que configurar a mano.
• Facilidad: No tienes que elegir cuánta memoria o CPU necesita cada consulta; Snowflake lo gestiona solo.

2. Databricks (Spark SQL): El motor «Híbrido»

Databricks nació del mundo Spark (Big Data y procesamiento de archivos).

• Arquitectura: Se basa en el concepto de Lakehouse. Procesa datos que suelen estar en formatos abiertos (como Parquet o Delta Lake) en una nube externa (S3, Azure Blob).
• Velocidad en consultas complejas: Históricamente, Spark era más lento para SQL que Snowflake, pero con el motor Photon (lanzado y perfeccionado hacia 2026), Databricks ha igualado o incluso superado a Snowflake en ciertos procesos de gran volumen.
• Flexibilidad: Databricks es mejor si tu consulta de 500 líneas incluye lógica que el SQL no puede manejar bien y necesitas saltar a Python o Scala en medio del proceso.

Comparativa Directa

Característica	Snowflake	Databricks (Spark SQL)
Optimizador	El mejor de su clase. Decide por ti el mejor camino.	Muy bueno, pero a veces requiere «pistas» del usuario.
Manejo de Window Functions	Altamente optimizado para analítica financiera y de negocio.	Excelente para volúmenes masivos (Petabytes), pero puede ser más complejo de configurar.
Gobernanza	Todo ocurre dentro de Snowflake, es muy seguro y cerrado.	Más abierto, pero requiere más gestión de seguridad externa.
Perfil de usuario	Analistas de Datos y BI (SQL puro).	Ingenieros de Datos y Científicos de Datos (SQL + Python).

Consideremos las expresiones de tabla comunes (CTE)

Las Expresiones de Tabla Comunes (o CTE, por sus siglas en inglés Common Table Expressions) son conjuntos de resultados temporales y con nombre que puedes usar dentro de una consulta SQL más grande.
En Snowflake, se definen utilizando la cláusula WITH. Piensa en ellas como «vistas temporales» que solo existen durante la ejecución de esa consulta específica.

Sintaxis Básica

WITH mi_tabla_temporal AS (
    SELECT columna1, columna2
    FROM tabla_original
    WHERE condicion = true
)
SELECT * 
FROM mi_tabla_temporal; -- Aquí usas la CTE como si fuera una tabla normal

¿Para qué sirven? (Ventajas principales)

1. Legibilidad: Permiten dividir consultas largas y complejas en bloques lógicos más pequeños y fáciles de entender.
2. Reutilización: Puedes referenciar la misma CTE varias veces en la consulta principal (por ejemplo, en diferentes JOIN o UNION), evitando repetir subconsultas complicadas.
3. Sustitución de Subconsultas: Son una alternativa mucho más limpia que las subconsultas anidadas (las que van dentro de paréntesis en el FROM).
4. Recursividad: Snowflake permite crear CTEs recursivas, que son esenciales para consultar datos jerárquicos (como organigramas de empleados o categorías de productos).

Ejemplo Práctico en Snowflake

Si quisieras calcular primero las ventas por pizza y luego filtrar solo las que superan un promedio:

WITH ventas_por_pizza AS (
    SELECT pizza_id, SUM(price) AS total
    FROM pizzas
    GROUP BY pizza_id
)
SELECT * 
FROM ventas_por_pizza 
WHERE total > 500;

Diferencia clave con una Tabla Temporal

• CTE: Se define al inicio de la consulta y desaparece inmediatamente después de que la consulta termina. No se guarda en la base de datos.
• Tabla Temporal (TEMPORARY TABLE): Se guarda en la base de datos durante toda tu sesión de Snowflake. Puedes consultarla varias veces en distintas ventanas o scripts hasta que cierres la sesión.

¿Qué tan complejas pueden ser estas consultas?

En el mundo del análisis de datos profesional y el Data Warehousing (donde reina Snowflake), las consultas de «cientos de líneas» no solo son comunes, sino que son el estándar para los procesos de negocio.

La complejidad no viene de que el SQL sea «difícil», sino de la cantidad de pasos lógicos que deben ocurrir antes de obtener el número final. Aquí te detallo qué las hace tan grandes:

1. Transformación de datos (ETL/ELT)

A menudo, los datos en las tablas no están listos para usarse. Una consulta compleja puede incluir:

• Limpiar textos (quitar espacios, corregir nulos).
• Convertir monedas de diferentes países a una sola base.
• Aplicar reglas de negocio (ej: «si el cliente compró hace más de 30 días y es de categoría Gold, aplica un 15% de descuento, pero solo si no es época de rebajas»).

2. Múltiples niveles de agregación

Imagina que quieres un reporte que compare las ventas de hoy contra el promedio de los últimos 6 meses. Eso requiere:

• CTE 1: Ventas de hoy.
• CTE 2: Ventas históricas diarias.
• CTE 3: Promedio móvil de esas ventas.
• Consulta Final: Unión de todas las anteriores para calcular la diferencia porcentual.

3. El fenómeno de los «Mega-Joins»

En Snowflake, es normal unir (JOIN) 10, 15 o 20 tablas en una sola sentencia. Por ejemplo, para un reporte de ventas podrías necesitar:

• Pedidos + Detalles + Productos + Categorías + Proveedores + Almacenes + Empleados (vendedores) + Clientes + Geografía + Promociones.
  Cada JOIN añade líneas de código y condiciones de filtrado.

4. Funciones de Ventana (Window Functions)

Estas funciones (como RANK(), PARTITION BY, LEAD(), LAG()) son muy potentes pero ocupan mucho espacio. Se usan para:

• Saber cuál fue el producto más vendido por cada ciudad sin perder el detalle de los demás productos.
• Calcular el «tiempo transcurrido» entre la primera y la segunda compra de cada usuario único.

5. Ejemplo de estructura de una consulta real:

WITH ventas_limpias AS ( ... 50 líneas de limpieza ... ),
     metricas_clientes AS ( ... 80 líneas de cálculos de comportamiento ... ),
     comparativa_anual AS ( ... 60 líneas de comparaciones temporales ... ),
     prediccion_basica AS ( ... 40 líneas de lógica estadística ... )

SELECT * 
FROM comparativa_anual
JOIN prediccion_basica USING (id_cliente)
WHERE region = 'LATAM'
ORDER BY 1;

¿Por qué Snowflake maneja esto tan bien?

Snowflake utiliza una arquitectura de procesamiento paralelo masivo (MPP). Esto significa que cuando tú lanzas una consulta de 500 líneas, Snowflake descompone ese «monstruo» en pequeñas tareas que ejecutan cientos de servidores al mismo tiempo. Lo que a una base de datos antigua le tomaría horas, Snowflake lo resuelve en segundos.

Por eso, los desarrolladores prefieren escribir consultas largas y legibles (con muchas CTEs) en lugar de consultas cortas pero «comprimidas» que nadie puede entender meses después. Snowflake Documentation ofrece guías sobre cómo estructurar estas consultas complejas de manera eficiente.

¿Quién gana en consultas complejas?

• Gana Snowflake si tu complejidad es lógica de negocio: muchas CTEs, muchas funciones de ventana (RANK, LEAD, AVG OVER), y uniones de muchas tablas. La experiencia de escribir y ejecutar es más «fluida» y el motor está afinado específicamente para ese comportamiento humano.
• Gana Databricks si tu complejidad es volumen técnico: si esas 500 líneas de SQL deben procesar datos no estructurados (JSONs gigantes, imágenes, logs crudos) o si necesitas integrar modelos de Machine Learning dentro de la misma consulta.

En resumen, en 2026, para un analista que escribe SQL avanzado, Snowflake suele sentirse más rápido y «mágico» porque elimina la necesidad de pensar en la infraestructura. Databricks es el «tanque» potente que usas cuando el volumen de datos es tan absurdo que necesitas el control total del motor Spark.

Para profundizar en cómo Snowflake optimiza estas consultas, puedes revisar su documentación sobre el Query Optimizer.

About the Author

AlbertBL

Administrator

Author's website Author's posts