Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 1 de 5
Photon y ejecución vectorizada
Entiende dónde Photon acelera el plan, cómo detecta un fallback y por qué medir precio/rendimiento importa más que comparar DBU por hora.
- Duración
- 17 min aprox.
- Objetivo
- Entiende dónde Photon acelera el plan, cómo detecta un fallback y por qué medir precio/rendimiento importa más que comparar DBU por hora.
- Siguiente paso
- Continuar con la siguiente lección
Ver detalles del módulo
Photon, data skipping y liquid clustering
Diseña layout y mantenimiento de tablas según patrones de consulta que cambian con el tiempo.
- Interpretar data skipping y pruning
- Elegir liquid clustering
- Explicar deletion vectors, Photon y predictive optimization
01Modelo mentalPhoton y ejecución vectorizada
Entiende dónde Photon acelera el plan, cómo detecta un fallback y por qué medir precio/rendimiento importa más que comparar DBU por hora.
+
Photon y ejecución vectorizada
Entiende dónde Photon acelera el plan, cómo detecta un fallback y por qué medir precio/rendimiento importa más que comparar DBU por hora.
Photon es el motor vectorizado nativo de Databricks. Catalyst sigue generando el plan, mientras Photon ejecuta operadores compatibles en lotes columnares y usa un runtime C++ que reduce costes de JVM. Está habilitado en serverless y SQL warehouses, y por defecto en compute clásico moderno; acelera scans, joins, agregaciones, shuffles y escrituras compatibles sin exigir reescribir SQL o DataFrames.
No toda consulta mejora igual. UDFs, RDDs, APIs Dataset y operaciones no compatibles pueden ejecutar partes en Spark, y consultas subsegundo suelen estar dominadas por planificación. En Spark UI los operadores Photon se distinguen en el DAG; en Query Profile se observa el porcentaje de tiempo. Evalúa duración, task time, datos leídos y coste total, no sólo que la casilla esté activada.
Modelo mental
Photon no es otro clúster ni una base separada: es un motor vectorizado nativo que ejecuta operadores compatibles dentro del plan de Spark y SQL. Procesa valores por lotes con código optimizado y mejora especialmente scans amplios, joins, agregaciones y escrituras; un plan puede alternar operadores Photon y runtime Spark sin cambiar resultados. Por eso activar Photon no garantiza una aceleración uniforme. La métrica correcta es precio/rendimiento del workload completo y porcentaje de tiempo realmente ejecutado por Photon. Una UDF, una API RDD o una operación no soportada crea fallback; las consultas de menos de unos segundos pueden estar dominadas por latencia fija y no mostrar beneficio material.
Procesamiento de lotes de valores mediante operaciones nativas eficientes en lugar de interpretar fila a fila.
Aumenta rendimiento de CPU y aprovecha mejor memoria para operadores analíticos compatibles.Ejecución transparente de un operador con el runtime Spark cuando Photon no lo soporta.
El resultado sigue siendo correcto, pero una sección costosa puede limitar la aceleración total.Coste monetario o de uso por una unidad completa de trabajo útil y correcta.
Permite comparar motores aunque difieran tarifa horaria y duración.SELECT
order_date,
customer_segment,
SUM(net_amount) AS net_revenue,
COUNT(DISTINCT order_id) AS orders
FROM prod.gold.sales
WHERE order_date >= current_date() - INTERVAL 30 DAYS
GROUP BY order_date, customer_segment;Revisa el Query Profile para confirmar pruning, operadores más caros y tiempo en Photon; no infieras el resultado sólo por la sintaxis.
Puntos clave
- Photon cambia la ejecución física, no la semántica ni el plan lógico de Catalyst.
- Localiza fallbacks con Spark UI o Query Profile.
- Compara coste por trabajo terminado, no tarifa aislada de DBU.
Evita
- Atribuir toda mejora a Photon sin controlar caché, volumen y concurrencia entre pruebas.
- Mantener una UDF evitable y concluir que Photon no aporta valor al workload.
Recuerdo activo