Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 2 de 5
Hipótesis y evidencia
Triangula rendimiento con tres capas: plan y datos, recursos de ejecución y demanda/concurrencia del servicio.
- Duración
- 30 min aprox.
- Objetivo
- Triangula rendimiento con tres capas: plan y datos, recursos de ejecución y demanda/concurrencia del servicio.
- Siguiente paso
- Continuar con la siguiente lección
Ver detalles del módulo
Proyecto de fiabilidad y coste
Recupera un workload degradado equilibrando SLA, capacidad, layout, código y presupuesto.
- Resolver un incidente con método
- Demostrar mejora con métricas
- Definir prevención y alertas
02ImplementaciónHipótesis y evidencia
Triangula rendimiento con tres capas: plan y datos, recursos de ejecución y demanda/concurrencia del servicio.
+
Hipótesis y evidencia
Triangula rendimiento con tres capas: plan y datos, recursos de ejecución y demanda/concurrencia del servicio.
Una regresión puede provenir de cambio de código, crecimiento o distribución de datos, estadísticas/layout, compute o concurrencia. Compara el último run sano con el primero degradado usando la misma ventana: plan, top operator, bytes leídos, shuffle, spill, workers y cola. Un diff de bundle o historial de tabla acota cambios sin especular.
Formula hipótesis falsables: 'la clave nula genera skew' se prueba con distribución y tareas; 'el warehouse se satura' con cola y concurrencia; 'faltan estadísticas' con pruning y plan. Prioriza la prueba barata y reversible que más reduce incertidumbre. No redimensiones hasta saber si la etapa puede utilizar capacidad adicional.
Modelo mental
El rendimiento percibido es la composición de tres capas. La capa de plan y datos decide cuánto trabajo existe: scans, cardinalidad, shuffles, skew y layout. La capa de recursos decide con qué velocidad se ejecuta: CPU, memoria, I/O, red, spill y fallos. La capa de servicio decide cuándo puede comenzar y cuánto compite: colas, concurrencia, autoscaling y límites externos. Una métrica aislada pertenece sólo a una capa. CPU alta no demuestra código ineficiente; cola alta no se arregla con liquid clustering; bytes leídos bajos no excluyen un join explosivo. Triangular significa formular una hipótesis que prediga señales coherentes en las tres capas y descartarla si una de ellas contradice el relato.
Método que combina evidencia independiente de plan, recursos y demanda para aceptar o refutar una explicación causal del rendimiento.
Reduce diagnósticos basados en correlaciones parciales y dirige la mitigación hacia la capa que realmente limita el SLA.Métrica producida antes del operador lento que explica por qué éste recibió más trabajo, como una explosión de cardinalidad.
Corregir la causa temprana evita optimizar repetidamente operadores posteriores que sólo procesan el exceso generado.Comparación que modifica una sola palanca relevante mientras mantiene entrada, resultado y condiciones restantes suficientemente equivalentes.
Permite atribuir una mejora a la acción realizada y no a caché, demanda o variación de volumen.SELECT
DATE_TRUNC('day', start_time) AS day,
statement_type,
percentile(total_duration_ms, 0.95) AS p95_duration_ms,
SUM(read_bytes) AS read_bytes,
COUNT(*) AS executions
FROM system.query.history
WHERE start_time >= current_timestamp() - INTERVAL 14 DAYS
AND statement_type IN ('SELECT', 'MERGE')
GROUP BY day, statement_type
ORDER BY day DESC;Ajusta nombres de métricas al esquema disponible en tu región; conserva statement IDs para abrir el perfil concreto.
Puntos clave
- Compara un run sano y uno degradado con volumen controlado.
- Distingue plan/datos, recursos y concurrencia.
- Prueba una hipótesis a la vez con métrica de aceptación.
Evita
- Comparar runs con ventanas de datos o caché diferentes.
- Tratar correlación temporal entre dos eventos como causa demostrada.
Recuerdo activo