Avanzado 3 min de lectura

Estrategias de Optimización de Costos

Técnicas prácticas para reducir el gasto en Snowflake: right-sizing de warehouses, eliminación de queries costosas, caching y buenas prácticas de ingeniería.

Las 5 palancas de optimización

La reducción de costos en Snowflake se logra en 5 áreas:

  1. Warehouse sizing — usar el tamaño correcto
  2. Tiempo de actividad — auto-suspend agresivo
  3. Eficiencia de queries — escanear menos datos
  4. Almacenamiento — limpiar lo que no se usa
  5. Serverless — elegir bien qué servicios usar

1. Right-sizing de Warehouses

El error más común: warehouses sobredimensionados.

-- Identificar warehouses subutilizados (bajo load pero mucho cómputo)
SELECT
    warehouse_name,
    ROUND(AVG(avg_running), 2) AS avg_queries_ejecutando,
    ROUND(AVG(avg_queued_load), 3) AS avg_queries_en_cola,
    ROUND(SUM(credits_used), 2) AS creditos_total_mes
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_LOAD_HISTORY
WHERE start_time >= DATEADD('month', -1, CURRENT_TIMESTAMP())
GROUP BY 1
HAVING avg_queries_en_cola < 0.01   -- casi nunca hay cola
ORDER BY creditos_total_mes DESC;

Si avg_queries_en_cola es casi 0 y tienes un warehouse LARGE, considera bajarlo a MEDIUM o SMALL.

2. Auto-suspend óptimo

-- Para BI/consultas ad-hoc: suspensión rápida
ALTER WAREHOUSE bi_warehouse SET AUTO_SUSPEND = 60;

-- Para ingesta/ETL continuo: puede ser más largo
ALTER WAREHOUSE etl_warehouse SET AUTO_SUSPEND = 300;

-- Verificar warehouses que nunca se auto-suspenden
SELECT name, auto_suspend
FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()))
WHERE auto_suspend = 0 OR auto_suspend IS NULL;

3. Optimización de Queries

Usar Cluster Keys

-- Tabla con muchos filtros por fecha → cluster key
ALTER TABLE ventas CLUSTER BY (fecha_venta, region);

Evitar SELECT *

-- MAL: escanea todas las columnas
SELECT * FROM tabla_grande WHERE fecha = '2026-01-01';

-- BIEN: solo las columnas necesarias
SELECT id, monto, producto FROM tabla_grande WHERE fecha = '2026-01-01';

Aprovechar el Result Cache

Los resultados de queries se cachean por 24 horas. Si la misma query se ejecuta de nuevo con los mismos datos, no consume cómputo.

-- Verificar si una query usó el cache
SELECT query_id, query_text, execution_status,
       CASE WHEN execution_time = 0 THEN 'CACHE' ELSE 'COMPUTE' END AS fuente
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE user_name = CURRENT_USER()
ORDER BY start_time DESC
LIMIT 20;

4. Limpiar Almacenamiento

-- Tablas con mucho espacio en Time Travel que podrían reducirse
SELECT
    table_schema,
    table_name,
    ROUND(active_bytes / 1024 / 1024 / 1024, 2) AS active_gb,
    ROUND(time_travel_bytes / 1024 / 1024 / 1024, 2) AS time_travel_gb,
    ROUND(failsafe_bytes / 1024 / 1024 / 1024, 2) AS failsafe_gb,
    data_retention_time_in_days
FROM SNOWFLAKE.ACCOUNT_USAGE.TABLE_STORAGE_METRICS
WHERE table_schema != 'INFORMATION_SCHEMA'
ORDER BY (time_travel_bytes + failsafe_bytes) DESC
LIMIT 20;

-- Reducir retención en tablas transitorias o de staging
ALTER TABLE staging.raw_events SET DATA_RETENTION_TIME_IN_DAYS = 0;

5. Resumen: Quick Wins

AcciónAhorro típicoComplejidad
Bajar auto_suspend a 60s20-40% en warehouses idleMuy baja
Right-sizing warehouses30-50% en WH sobredimensionadosBaja
Agregar cluster keys en tablas grandes40-80% en queries de rangoMedia
Reducir DATA_RETENTION en staging10-20% en storageBaja
Usar tipos de tabla TRANSIENT en staging15-25% en storageMedia

Conclusión

FinOps en Snowflake es un proceso continuo. Las organizaciones maduras revisan ACCOUNT_USAGE semanalmente, tienen Resource Monitors por equipo, y hacen chargeback mensual con Query Tags.

#finops #optimizacion #costos #right-sizing #caching