El incidente se originó durante la actualización de una pipeline crítica de sessionization en Netflix, manifestándose como errores Out-Of-Memory (OOM) y fallos en tareas Spark. La causa raíz principal fue la combinación de data skew en los datos de entrada y el uso del operador collect_list de Spark. Sesiones atípicas y muy largas generaban 'event bags' masivos que, al ser bufferizados completamente en memoria por collect_list, excedían la capacidad de los executors. Este problema se agravó por el 'Option boxing' de campos Scala y la inclusión de atributos de string innecesariamente grandes, inflando el tamaño de cada evento individual.
Las salvaguardas estándar fallaron porque el problema solo se reproducía a escala de producción completa, no con datos muestreados. El 'data skew' extremo, donde algunas sesiones generaban decenas de miles de eventos mientras la mayoría solo unos pocos, significaba que las muestras pequeñas no capturaban los casos de borde que causaban los fallos. Esto impidió una iteración rápida y efectiva en entornos de prueba más pequeños, prolongando el tiempo de depuración.
Además, se descubrieron interacciones complejas con la gestión de memoria de Spark. El adelgazamiento de filas, paradójicamente, podía aumentar la presión de memoria al cambiar el planificador de consultas a 'broadcast joins', que fijan tablas en la memoria del executor. La Adaptive Query Execution (AQE) también contribuyó al problema al acumular múltiples 'broadcast joins' simultáneamente, excediendo los límites de memoria. Finalmente, el operador Window de Spark, al bufferizar sesiones completas antes de aplicar filtros, también causaba OOMs en sesiones grandes, incluso si el resultado final era pequeño. Estos factores combinados crearon un escenario de agotamiento de recursos complejo y difícil de diagnosticar sin un entorno de prueba a gran escala.
La solución implicó un enfoque multifacético: optimización de la estructura de datos eliminando 'Option boxing' y campos innecesarios, capping de sesiones antes de la etapa Window para limitar el buffering, y un ajuste quirúrgico del umbral de 'broadcast join' de AQE. Sin embargo, el análisis final subraya que estas son optimizaciones que compran tiempo; el modelo de datos subyacente que permite un crecimiento ilimitado de filas eventualmente requerirá un cambio arquitectónico para una escalabilidad sostenible.