El proyecto Apache Spark publicó el 30 de octubre la versión 4.3.0, la primera entrega que llega bajo el nuevo calendario de versiones del motor. Junto a la release salieron también las de mantenimiento 4.2.1, 4.1.4 y 4.0.5, fechadas el 27 de octubre, de modo que la semana deja actualizadas todas las ramas vivas del proyecto.
El cambio de calendario es tan relevante como la lista de funciones. A partir de esta versión, las entregas de funcionalidad pasan a publicarse cada tres meses y las versiones mayores, una vez al año; la ventana de mantenimiento ordinaria queda en seis meses. La política de versiones del proyecto reserva la etiqueta de soporte a largo plazo, con dieciocho meses de mantenimiento, para la última entrega de cada línea mayor. En la línea 4.x esa release no es la 4.3.0, sino la futura 4.5.0, un detalle que importa a quien planifique sobre qué versión fijar un entorno productivo: actualizar a la 4.3.0 hoy significa aceptar una ventana de seis meses, no de dieciocho.
En el plano funcional, la incorporación más esperada por los equipos de ingeniería es ASOF JOIN, la unión temporal que empareja cada fila con el registro más cercano en el tiempo de la otra tabla. Es la operación habitual al cruzar series temporales —una cotización con la última referencia disponible, una lectura de sensor con el estado vigente de la máquina— y hasta ahora obligaba a resolverla con funciones de ventana y subconsultas que había que reescribir en cada proyecto. La documentación del motor precisa que solo admite las formas INNER, que es la predeterminada, y LEFT OUTER.
El resto de novedades apunta en la misma dirección: menos código auxiliar para tareas que se repiten. Llega JSON_TABLE, la función estándar de SQL que convierte un documento JSON en filas y columnas sin pasar por una explosión manual de estructuras anidadas; se pueden modificar valores de tipo VARIANT en el sitio, sin reconstruir el valor completo; y las funciones definidas por el usuario en Python más sencillas pueden compilarse a expresiones SQL nativas, lo que evita el salto de proceso que penaliza su rendimiento. En Spark Declarative Pipelines, el marco declarativo de construcción de tuberías, aparece el mantenimiento automático de dimensiones de variación lenta de tipo 2: declarando stored_as_scd_type=2 la tabla conserva el histórico completo de cada clave y permite reconstruir cómo era una fila en cualquier momento del pasado.
Para un equipo de datos, el interés práctico está en cuánta lógica propia deja de ser necesaria. El histórico de dimensiones y la unión temporal son dos de los patrones que más veces se reimplementan a mano en un almacén, y cada implementación propia es código que hay que probar, documentar y mantener. Que el motor los resuelva de forma nativa reduce superficie de mantenimiento, aunque obliga a revisar si el comportamiento estándar coincide exactamente con el que la implementación casera venía aplicando.
La recomendación razonable es la de siempre con una entrega de funcionalidad: probarla en un entorno de ensayo, comprobar el comportamiento de las funciones definidas por el usuario que se compilan a SQL y, si lo que se busca es estabilidad a largo plazo en producción, esperar a la 4.5.0, que será la versión con soporte extendido de esta línea.
Más en Dataprix: sección de integración de datos de Dataprix
Fuente: Apache Spark (anuncio oficial)
Contenido elaborado con asistencia de inteligencia artificial — Equipo Editorial Dataprix. Verifica la información antes de tomar decisiones.