Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 2 de 5
Query Profile y operadores
Usa Query Profile para serverless y SQL warehouses, separando cola, planificación, pruning y ejecución por operador.
- Duración
- 17 min aprox.
- Objetivo
- Usa Query Profile para serverless y SQL warehouses, separando cola, planificación, pruning y ejecución por operador.
- Siguiente paso
- Continuar con la siguiente lección
Ver detalles del módulo
Spark UI, Query Profile y system tables
Combina señales de ejecución, plataforma y datos para reducir el tiempo de diagnóstico.
- Localizar cuellos en Spark UI y Query Profile
- Consultar historial de Jobs y auditoría
- Usar CLI y REST para automatizar diagnóstico
02ImplementaciónQuery Profile y operadores
Usa Query Profile para serverless y SQL warehouses, separando cola, planificación, pruning y ejecución por operador.
+
Query Profile y operadores
Usa Query Profile para serverless y SQL warehouses, separando cola, planificación, pruning y ejecución por operador.
Query Profile visualiza el DAG de operadores y métricas como filas, tiempo, memoria y I/O. El resumen distingue wall-clock de task time agregado: el segundo puede ser mayor porque suma trabajo paralelo. Los top operators revelan scans completos, joins explosivos y agregaciones caras; los indicadores de pruning muestran si el layout evita leer datos irrelevantes.
En serverless no hay Spark UI, por lo que Query Profile y query history son la ruta principal. Una consulta servida desde cache puede no disponer de perfil; cambia de forma inocua la consulta para una medición controlada. Usa CAN MONITOR en el warehouse o propiedad de la consulta, y concede acceso al mínimo grupo operativo necesario.
Modelo mental
Query Profile es el mapa de tiempo y movimiento de una consulta en compute administrado. La latencia total se descompone en cola, preparación y ejecución; dentro de la ejecución, cada operador consume filas, bytes, CPU y tiempo y produce otros. Esa separación es esencial: escalar un warehouse no arregla una expresión ineficiente si el cuello está en ejecución, y reescribir SQL no elimina una cola causada por concurrencia. El perfil permite seguir el flujo desde scan y pruning hasta joins, aggregations y write, observar Photon y detectar explosiones de cardinalidad. El operador con más tiempo no siempre es la causa original: puede procesar el exceso generado por un join anterior.
Intervalo en que una consulta espera capacidad antes de comenzar su ejecución.
Se corrige con concurrencia y capacidad, no necesariamente cambiando el SQL.Aumento inesperado de filas provocado por joins no únicos, explode u otra operación multiplicativa.
Hace costosos todos los operadores posteriores y puede apuntar a un error de semántica.Identificador único de una ejecución de sentencia en el historial de consultas.
Une evidencia de system tables, interfaz, alertas y diagnóstico reproducible.-- incident: INC-2041 | variant: filtered-before-join
WITH recent_orders AS (
SELECT order_id, customer_id, net_amount
FROM prod.gold.orders
WHERE order_date >= current_date() - INTERVAL 7 DAYS
)
SELECT c.segment, SUM(o.net_amount) AS revenue
FROM recent_orders o
JOIN prod.gold.customers c USING (customer_id)
GROUP BY c.segment;Guarda statement ID, variante y ventana de datos; compara las mismas métricas y concurrencia.
Puntos clave
- Wall-clock y task time agregado miden fenómenos distintos.
- Top operators y DAG localizan el operador dominante.
- Pruning e I/O validan layout mejor que una sensación de rapidez.
Evita
- Interpretar task time agregado como duración percibida por el usuario.
- Optimizar el operador más vistoso sin comprobar si está en la ruta crítica.
Recuerdo activo