Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLecció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.
17 min aprox.
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.
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.
¿Qué ocurre cuando Photon encuentra una operación no compatible?
Profundiza
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.Resumen
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.