¿Por qué mi pipeline funciona bien en dev pero falla o se vuelve lento en producción?

Esto es menos un solo bug y más una categoría de bugs, y casi todas sus instancias se remontan a una de un puñado de formas específicas en que dev y producción divergen.

Volumen de datos, obviamente — pero también la forma de los datos

La brecha más obvia es el volumen: una muestra de dev de 10,000 filas no ejercita el spill de shuffle, el skew ni la presión de memoria como lo hacen 500 millones de filas. Menos obvio: la forma de los datos también difiere — una muestra de dev a menudo se toma de forma uniforme o reciente, lo que puede evitar accidentalmente justo la distribución de claves sesgada o la columna cargada de nulls que tiene la data de producción. Las diferencias de volumen se ven como lentitud; las diferencias de forma se ven como jobs que fallan directamente ante patrones de datos que dev nunca contuvo.

Contención de clúster que los entornos de dev no tienen

Un clúster de dev suele estar dedicado a una persona corriendo un job. Los clústeres de producción suelen ser compartidos, multi-tenant, o sujetos a efectos de "vecino ruidoso" de otros jobs compitiendo por los mismos recursos. Un job que recibe una asignación completa y sin contención de executors en dev puede ver un rendimiento significativamente degradado en producción solo por la contención de recursos, sin relación alguna con la lógica propia del job.

Deriva de configuración entre entornos

La memoria del executor, las shuffle partitions y el número de instancias suelen ajustarse a mano una vez para una prueba a escala de dev, y nunca se revisan para el despliegue a escala de producción — o al revés, la configuración de producción se copia innecesariamente a dev. En cualquier caso, la configuración que "funcionó" nunca se validó realmente contra las características reales del otro entorno.

Cómo cerrar esta brecha de verdad antes de desplegar

El enfoque más confiable: extrapolar, no adivinar. Toma métricas reales de una corrida de dev — duración de tareas, volumen de shuffle, uso de memoria por fila procesada — y escálalas linealmente (o con tus propios factores no lineales conocidos, como que el costo de shuffle escala peor que linealmente con el número de filas) hasta el volumen estimado de producción, antes de la primera corrida en producción. Esto convierte "lo descubriremos en producción" en una predicción comprobable que puedes validar contra lo que realmente sucede.