CS-02 — Arquitectura y rendimiento · Plataformas de datos · Arquitectura cloud
Optimización de rendimiento y costes en Snowflake
Optimización de numerosos informes y de los procesos diarios en C# que precalculan sus datos con consultas avanzadas, combinando PostgreSQL y Snowflake según la necesidad de cómputo; incluye pruning, joins, tipos de datos, columnas VARIANT y análisis de costes de warehouses y almacenamiento.
- Mi papel
- Senior Data Engineer (Wizeline), a cargo de las optimizaciones e investigaciones descritas.
- Periodo
- No documentado
- Divulgación
- Detalles anonimizados
- Tecnologías
- SnowflakePostgreSQLSQLC#.NETAmazon S3AWS
- Última revisión
- 13 de noviembre de 2026
Contexto
Algunos procedimientos almacenados de analítica regional tenían tiempos de ejecución excesivos, con impacto en informes y, en algunos casos, en timeouts de la aplicación. En paralelo se revisaba el coste de la plataforma: uso de warehouses, tiempo ocioso y almacenamiento en S3.
Retos
- 01Consultas largas y procedimientos almacenados ineficientes.
- 02Escaneo excesivo de micro-particiones por falta de pruning efectivo.
- 03Joins entre valores derivados de JSON y columnas enteras que impedían el pruning.
- 04Coste de warehouses, tiempo ocioso y almacenamiento.
- 05Procesos diarios que precalculan los datos de los informes con consultas complejas.
Solución y arquitectura
Optimización de numerosos informes y de los procesos diarios desarrollados en C# que calculan datos precalculados para los informes con consultas avanzadas, ejecutando cada cálculo en PostgreSQL o en Snowflake según la necesidad de cómputo. Análisis de query profiles y planes de ejecución, reescritura de predicados, conversiones de tipo explícitas en los joins con valores derivados de JSON/VARIANT, mejora de joins y comparación de resultados entre entornos. En costes, revisión de utilización y tiempo ocioso de warehouses, clases de almacenamiento en S3 y planificación de cargas.
Decisiones clave
D-01
Ajustar tipos de datos y predicados antes de escalar el warehouse
El cuello de botella era el pruning, no la capacidad de cómputo; más warehouse habría costado más sin resolver la causa.
D-02
PostgreSQL o Snowflake según la necesidad de cómputo
No todos los cálculos necesitan un warehouse; los que lo requieren van a Snowflake y el resto se resuelve en PostgreSQL.
Compromisos
Aún no documentado
Resultados
Reducción sustancial del tiempo de ejecución de procedimientos de analítica complejos en un benchmark de desarrollo.
Aprendizajes
- Un tipo de dato mal alineado en un join puede anular el pruning de micro-particiones y dominar el tiempo de ejecución.
Este trabajo refleja una forma de entender la ingeniería en la que fiabilidad, mantenibilidad y eficiencia económica se consideran juntas. Los nombres de procedimientos, estructuras de consulta del cliente y cifras de benchmark no se publican.
Pregunta sobre este caso de estudio
Las preguntas de aquí se responden con el caso de estudio «Optimización de rendimiento y costes en Snowflake» como contexto.