Una función definida por el usuario en CPU puede interrumpir una consulta de Apache Spark acelerada por GPU. En general, el complemento cuDF no puede traducir código UDF arbitrario: convierte los datos columnares en filas, ejecuta la función en la CPU y vuelve a convertir el resultado. La guía de NVIDIA del 13 de octubre describe habilidades de agente para reescribir una UDF como Spark SQL, una opción columnar RapidsUDF o una RapidsUDF respaldada por CUDA. La pregunta útil para un ingeniero de datos es si una reescritura produce las mismas respuestas, permanece en la GPU en el plan pertinente y mejora el trabajo real.

Esta guía se basa en documentación. BIG CHANGE no ejecutó las habilidades, probó una UDF ni midió una carga de trabajo de Spark.

El gran cambio

  • Qué cambió: NVIDIA publicó un flujo de trabajo por etapas para generar pruebas de UDF, convertir una función, evaluar la conversión, comparar las versiones de CPU y GPU y, de forma opcional, optimizar una implementación con cuDF.
  • A quién ayuda: A ingenieros con una canalización Spark RAPIDS/cuDF compatible con GPU y una UDF concreta en CPU que la interrumpe.
  • Qué verificar: Que los resultados coincidan en casos límite representativos, que el plan de ejecución no incluya la alternativa en CPU que se quiere eliminar y que el rendimiento del trabajo sea repetible en el hardware previsto.

Antes de empezar

Elige una UDF que tengas autorización para compartir con el agente de programación. No incluyas credenciales, filas de entrada sensibles ni conjuntos de datos propietarios en la instrucción, salvo que el agente y su entorno estén aprobados para ello. Proporciona el código fuente de la UDF, su registro y punto de llamada, los esquemas pertinentes, el comportamiento previsto ante valores nulos y errores, y un conjunto de pruebas pequeño y autorizado. Registra el plan y el tiempo del trabajo Spark actual para tener una referencia de comparación.

El README de habilidades es el punto de partida versionado del flujo de trabajo. Pide Maven y un JDK para compilar UDF, además de una pila compatible de Spark/RAPIDS/cuDF/CUDA y una GPU. Antes de instalar nada, comprueba la guía actual de compatibilidad del complemento con tu distribución de Spark, versión de Scala, controlador, compilación de CUDA y GPU. Una GPU en la nube es una alternativa al hardware local, pero el proveedor cobra el tiempo de la instancia y el almacenamiento. El uso del agente o del modelo también puede tener un coste. El README ofrece una estructura de proyecto y ejemplos, pero no demuestra la compatibilidad ni el rendimiento en tu clúster.

Reescribe y comprueba una función

  1. Fija primero el comportamiento original. Pide al agente que use udf-gen-test en la UDF seleccionada y revisa tú mismo las pruebas generadas. Añade casos reales del contrato: valores nulos, cadenas o colecciones vacías, entradas malformadas, límites, precisión numérica, orden y comportamiento ante errores, según corresponda. Ejecuta la UDF original con ellos. El resultado esperado es una suite de referencia que pase, no una reescritura todavía. La función de temperatura de ejemplo de NVIDIA devuelve explícitamente null para una entrada null; la reescritura en SQL solo sirve si ese comportamiento también se mantiene con tus tipos de datos y configuración de Spark.
  2. Elige el objetivo compatible más sencillo. Si la lógica puede expresarse con Spark SQL o expresiones de DataFrame, pide udf-convert-to-sql. Así la expresión queda expuesta al planificador de Spark, y el complemento puede sustituir operaciones compatibles por equivalentes en GPU. Si SQL no permite expresar bien la lógica requerida, pide udf-convert-to-cudf: su RapidsUDF.evaluateColumnar recibe vectores de columnas de GPU y combina operaciones de cuDF. Reserva udf-convert-to-cuda para lógica que requiera un kernel personalizado mediante JNI y cuyo coste adicional de implementación y mantenimiento esté justificado. Son opciones que se deben evaluar, no una promesa de que todas las operaciones se ejecutarán en GPU.
  3. Revisa la conversión antes de aceptarla. Compara la implementación reescrita con la original y ejecuta ambas con los mismos casos de prueba aprobados. El repositorio también incluye udf-judge-conversion para revisar por separado las carencias de las pruebas y los errores de conversión. Comprueba los tipos, la propagación de null, el redondeo, las excepciones, el orden y la gestión de recursos. En una reescritura con cuDF, revisa la vida útil de las columnas y los escalares temporales; el ejemplo de Scala del tutorial usa recursos con alcance definido y devuelve la columna resultante. Una suite de pruebas generada que pasa aporta evidencia útil, pero una persona debe decidir si cubre el contrato de la función.
  4. Inspecciona el plan ejecutado. Ejecuta la consulta modificada con el complemento cuDF habilitado y revisa el plan y los diagnósticos de RAPIDS para el operador objetivo y las conversiones cercanas. La descripción general del complemento de NVIDIA indica que las operaciones SQL no compatibles vuelven a ejecutarse en la CPU de Spark. Si el plan sigue mostrando la UDF o los operadores circundantes en CPU, identifica la expresión o el tipo no compatible y reconsidera el objetivo. Conserva los planes anterior y posterior junto con el resultado de las pruebas. Una clase llamada RapidsUDF por sí sola no demuestra que todo el trabajo se ejecute en GPU.
  5. Mide el trabajo que piensas ejecutar. Usa udf-benchmark para comparar la implementación original y la modificada con las mismas entradas, tamaño de clúster, configuración y método de medición. Registra el tiempo total del trabajo, el tamaño de entrada, la equivalencia de resultados y el uso de recursos de GPU/CPU. Repite las ejecuciones para detectar efectos de arranque, caché o contención. El resultado esperado es una comparación reproducible, aunque la reescritura salga perdiendo. Si una versión correcta con cuDF es lenta, el repositorio ofrece udf-optimize-cudf para perfilarla y revisarla; vuelve a comprobar la corrección y el plan después de cada cambio.

Cómo es un resultado satisfactorio

La propuesta está lista para una revisión de código normal cuando la UDF elegida produce los resultados que documenta en los casos aprobados, el plan ejecutado ya no contiene la alternativa de CPU objetivo y una medición representativa muestra una mejora integral que merece la pena. Si falla alguna comprobación, conserva la implementación original, reduce la reescritura a la expresión problemática y repite esa etapa. Una discrepancia semántica importa más que una medición más rápida; si el plan no cambia, no se ha demostrado la ruta prevista por GPU.

NVIDIA informa de un ejemplo de producción en el que una UDF habilitada para cuDF redujo el tiempo de un operador de 274,55 a 12,78 horas en una carga de 600.000 millones de filas. Son tiempos de operador comunicados por el proveedor para esa carga, no una previsión para otra UDF ni el resultado integral de un trabajo. La afirmación más amplia de 22 veces debe leerse en ese contexto. La capacidad de GPU, el movimiento de datos, las operaciones no compatibles, la revisión del código y los costes de nube pueden cambiar el resultado de tu canalización.

Fuentes y lecturas adicionales

  • NVIDIA Technical Blog, 13 de octubre de 2026: explica la alternativa en CPU, las opciones de SQL/cuDF/CUDA, las cuatro etapas del flujo y el único ejemplo de rendimiento citado por la empresa. Las cifras son las comunicadas por el proveedor.
  • Habilidades de cuDF Spark de NVIDIA, revisión fijada del repositorio: punto de entrada versionado para la estructura de proyecto y las habilidades individuales. La página fijada de GitHub no estaba disponible a través de nuestra vía de recuperación; los detalles del flujo se contrastaron con el tutorial de NVIDIA y el README de habilidades accesible en la rama principal del repositorio.
  • Descripción general del complemento cuDF para Apache Spark: información actual sobre instalación y compatibilidad, además de la regla explícita de que las operaciones no compatibles se ejecutan en la CPU de Spark. Comprueba la lista de compatibilidad específica de la versión antes de implementarlo.