¿Cómo reduzco mi factura de Databricks/EMR/Glue sin romper nada?

Las facturas de infraestructura de datos en la nube rara vez suben por un gran error — se acumulan a partir de una docena de pequeños que eran razonables en su momento y nunca se revisaron. La buena noticia: la mayoría de los arreglos baratos también son los seguros.

Riesgo bajo, hazlos primero

• Ajusta el número de instancias según la utilización real, no el pico para el que aprovisionaste una vez. Si la utilización promedio de CPU entre los executors de un job está por debajo del 40%, muy probablemente estás sobreaprovisionado — esto es casi gratis porque no cambia la lógica del job en absoluto.
• Activa el autoescalado si no lo has hecho. Un tamaño de clúster fijo significa pagar la capacidad pico las 24 horas. La mayoría de las plataformas Spark gestionadas (Databricks, EMR) lo soportan de forma nativa con configuración mínima.
• Mueve las cargas batch elegibles a instancias spot/preemptible. Un job batch reintentable y con checkpoints (no un job de streaming stateful de larga duración) suele ser un buen candidato, a menudo con 60-90% de descuento sobre el precio on-demand.

Riesgo medio, prueba primero

• Reduce el número de shuffle partitions si está configurado con margen defensivo excesivo. Menos particiones, más grandes, significa menos overhead de programación de tareas, pero ir demasiado lejos reintroduce los problemas de presión de memoria que ese número alto probablemente buscaba evitar — verifica contra el tiempo de GC y los bytes de spill después de cambiar, no solo el tiempo total.
• Consolida jobs pequeños y frecuentes en menos corridas, más grandes. El tiempo de arranque/calentamiento del clúster es overhead fijo que se paga en cada corrida; un job que corre cada 5 minutos paga ese overhead 12 veces más seguido que el mismo trabajo agrupado por hora.

Riesgo más alto, necesita validación real

• Cambiar de familia de instancia (por ejemplo, de optimizada para memoria a propósito general) cambia la proporción memoria-por-núcleo contra la que tu job estaba implícitamente ajustado — una victoria de costo en el papel puede convertirse en una regresión de rendimiento u OOM en la práctica.
• Cambios agresivos de TTL/lifecycle en almacenamiento intermedio ahorran en almacenamiento pero pueden romper silenciosamente cualquier cosa río abajo que asumiera que esos datos seguirían ahí.