Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 5 de 5
UDF, Pandas UDF y serialización
Evita barreras entre Python y el motor usando expresiones nativas y reserva UDFs para lógica que la plataforma no puede expresar.
- Duración
- 17 min aprox.
- Objetivo
- Evita barreras entre Python y el motor usando expresiones nativas y reserva UDFs para lógica que la plataforma no puede expresar.
- Siguiente paso
- Continuar con el laboratorio
Ver detalles del módulo
Tuning avanzado de Spark
Optimiza con evidencia del plan y las métricas, no con recetas globales ni más cómputo por defecto.
- Diagnosticar skew y spill
- Ajustar joins y particiones
- Evaluar UDF, Pandas UDF y funciones nativas
05Decisión de diseñoUDF, Pandas UDF y serialización
Evita barreras entre Python y el motor usando expresiones nativas y reserva UDFs para lógica que la plataforma no puede expresar.
+
UDF, Pandas UDF y serialización
Evita barreras entre Python y el motor usando expresiones nativas y reserva UDFs para lógica que la plataforma no puede expresar.
Las funciones SQL y PySpark nativas permanecen visibles para Catalyst y pueden beneficiarse de Photon, generación de código, pushdown y simplificación de expresiones. Una UDF escalar de Python serializa datos entre JVM y Python, oculta parte de la lógica al optimizador y puede provocar fallback de Photon. Antes de crearla, busca funciones integradas para arrays, mapas, strings, fechas y tipos complejos.
Cuando la lógica no existe, una pandas UDF o APIs basadas en Arrow pueden procesar lotes y reducir el coste por fila, pero siguen requiriendo medición, tipos explícitos y pruebas de nulos. La optimización correcta incluye mantenibilidad: una expresión nativa legible suele ser más fácil de gobernar y portar que una UDF opaca.
Modelo mental
Catalyst sólo puede optimizar lo que entiende. Una expresión nativa forma parte del árbol lógico: el motor conoce tipos, nulabilidad y operadores, puede plegar constantes, empujar filtros y ejecutar con Photon cuando hay soporte. Una UDF de Python se parece a una caja negra situada al otro lado de una frontera de proceso; Spark debe serializar columnas, transferir lotes o filas y aceptar que no puede razonar sobre la lógica interna. Esto no hace ilegítimas las UDF, pero cambia la carga de prueba. Primero se buscan funciones SQL, funciones de orden superior y operaciones de tipos complejos; sólo la necesidad funcional justifica perder visibilidad y añadir contrato explícito.
Nodo tipado del plan lógico que representa una operación conocida por el optimizador.
Permite simplificación, pushdown y elección de operadores nativos o Photon.Transferencia y serialización entre el proceso que ejecuta Spark y un worker Python.
Añade coste por lote o fila y oculta la semántica interna al optimizador.Función nativa que transforma o filtra elementos de arrays y mapas mediante expresiones lambda SQL.
Resuelve lógica compleja manteniéndola visible y optimizable, a menudo evitando UDFs.from pyspark.sql import functions as F
normalized = customers.withColumn(
"email_domain",
F.lower(F.element_at(F.split(F.trim("email"), "@"), -1)),
).withColumn(
"is_company_email",
~F.col("email_domain").isin("gmail.com", "outlook.com", "yahoo.com"),
)La expresión queda disponible para el plan; prueba explícitamente emails nulos, sin arroba y con espacios.
Puntos clave
- Prefiere funciones nativas porque el optimizador conserva visibilidad de la expresión.
- Comprueba en Query Profile o Spark UI si una UDF provoca fallback de Photon.
- Si necesitas Python, vectoriza por lotes y define contratos de tipos y nulos.
Evita
- Crear una UDF para operaciones ya cubiertas por `when`, `transform`, `regexp_extract` o funciones de fecha.
- Sustituir una UDF escalar por pandas UDF sin medir serialización, tamaño de lote y presión de memoria.
Recuerdo activo