Una actualización con tres prioridades de validación
Databricks publicó el 21 de septiembre de 2026 una actualización de Runtime 19 que incorpora truncate y trim_array a SQL y a las API de DataFrame de Scala y Python. Según la información publicada por la compañía, también permite configurar variables de entorno por sesión para trabajadores de funciones definidas por el usuario en Python y activa auto-optimized shuffle v2 por defecto cuando no se establece un número fijo de particiones de shuffle.
Para los responsables de ingeniería de datos, la recomendación es dividir la evaluación en tres frentes: resultados de las transformaciones, configuración efectiva de las UDF y comportamiento del procesamiento distribuido. Las pruebas que siguen son una propuesta de validación editorial, no una descripción de fallos detectados en esta versión.
Transformaciones: comprobar resultados antes de sustituir código
La incorporación de truncate y trim_array abre una oportunidad para revisar transformaciones existentes. Conviene, sin embargo, separar dos decisiones: actualizar el runtime y reemplazar implementaciones propias por las nuevas funciones. Hacer ambos cambios a la vez dificultaría atribuir una diferencia al motor o al código modificado.
La batería de pruebas debería incluir valores habituales, nulos, colecciones vacías cuando corresponda y casos límite definidos por el contrato de cada función. Además del resultado, se recomienda contrastar tipos de datos, esquema y tratamiento de entradas no válidas. Si una misma regla está implementada en SQL, Scala y Python, conviene verificar su equivalencia en las interfaces que utilice el pipeline.
Como apoyo, PySpark ofrece utilidades para comparar DataFrames y esquemas. Sus opciones de comparación deben revisarse para que las tolerancias numéricas o el tratamiento del orden de las filas coincidan con los requisitos del proceso. Una prueba que acepta diferencias no autorizadas ofrece una seguridad engañosa. ([spark.apache.org](https://spark.apache.org/docs/latest/api/python/getting_started/testing_pyspark.html?utm_source=openai))
UDF en Python: verificar qué configuración llega al trabajador
La configuración de variables de entorno por sesión para trabajadores Python merece una prueba específica. La propuesta es comprobar el valor observado dentro de una UDF de diagnóstico, con variables no sensibles, en lugar de limitarse a revisar la configuración declarada por el proceso que lanza el trabajo.
El ensayo debería cubrir sesiones con valores distintos, ausencia de una variable y creación de nuevos trabajadores. También conviene evaluar qué ocurre al modificar la configuración durante la sesión, conforme al comportamiento documentado. El objetivo es detectar dependencias implícitas y confirmar el alcance efectivo de la configuración, sin presuponer cómo se propaga cada cambio.
Para facilitar la reproducción, se recomienda registrar la configuración esperada y los resultados de estas pruebas sin volcar credenciales ni otros valores sensibles en los registros.
Particiones: evaluar el nuevo valor por defecto con cargas representativas
El cambio de auto-optimized shuffle v2 tiene una condición relevante: pasa a utilizarse por defecto cuando no se fija el número de particiones de shuffle. Por eso, el primer paso propuesto es inventariar qué pipelines mantienen una configuración explícita y cuáles dejan esa decisión al runtime.
Como contexto, Apache Spark documenta que la ejecución adaptativa utiliza estadísticas obtenidas durante el procesamiento para ajustar el plan y puede agrupar particiones después del shuffle. Esa capacidad general no demuestra, por sí sola, una mejora de rendimiento para las cargas de una organización ni describe todos los detalles de la implementación de Databricks. ([spark.apache.org](https://spark.apache.org/docs/latest/sql-performance-tuning?utm_source=openai))
La comparación debería mantener equivalentes los datos de entrada, los recursos y las condiciones de ejecución. Se propone medir duración total, tiempos por etapa, distribución de tareas, uso de memoria y derrames a disco. Conviene incluir cargas pequeñas, picos de volumen y distribuciones desiguales de claves, además de repetir las ejecuciones para no decidir por un único resultado favorable.
Una aprobación basada en evidencia
Antes del despliegue, cada pipeline debería contar con criterios de aceptación definidos: resultados y esquemas correctos, configuración de UDF reproducible y rendimiento dentro de los límites operativos acordados. El consumo de recursos debe evaluarse junto con la duración, no como una variable secundaria.
La recomendación final es conservar una referencia de la versión anterior, desplegar primero en un conjunto acotado de procesos y preparar una reversión comprobada. Para Data Productiva, el valor de esta actualización debe juzgarse por su efecto medido sobre la confiabilidad y la productividad, no únicamente por la disponibilidad de nuevas funciones.