Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 3 de 5
System tables de workflows
Convierte system tables en una línea de tiempo común para consultas, jobs, compute y coste a escala de cuenta y región.
- Duración
- 17 min aprox.
- Objetivo
- Convierte system tables en una línea de tiempo común para consultas, jobs, compute y coste a escala de cuenta y región.
- 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
03OperaciónSystem tables de workflows
Convierte system tables en una línea de tiempo común para consultas, jobs, compute y coste a escala de cuenta y región.
+
System tables de workflows
Convierte system tables en una línea de tiempo común para consultas, jobs, compute y coste a escala de cuenta y región.
`system.query.history` registra statements de SQL warehouses y serverless con estado, duración, compute y métricas. `system.lakeflow.job_run_timeline` y `job_task_run_timeline` permiten analizar ejecuciones y tareas de jobs; `system.billing.usage` aporta consumo. Estas tablas son regionales en gran parte, tienen retenciones documentadas y están gobernadas por Unity Catalog.
Construye vistas restringidas para equipos en vez de conceder acceso amplio al catálogo `system`. Une usando IDs de job/run/statement disponibles y conserva intervalos temporales; no fuerces joins cuando la fuente no emite un identificador común. Una línea de tiempo fiable diferencia fallo de compute, cola, ejecución lenta y reintento posterior.
Modelo mental
Las system tables son el plano histórico de observabilidad de la cuenta. Cada esquema registra una perspectiva: billing describe consumo, query history sentencias, lakeflow jobs y tasks, compute configuraciones, access auditoría y lineage relaciones inferidas. Ninguna tabla cuenta por sí sola el incidente completo. El trabajo conceptual consiste en construir una línea de tiempo con identificadores, región y granularidad compatibles, y aceptar que algunas relaciones son opcionales o parciales. Son datos sensibles y gobernados dentro del catálogo system, con retención y disponibilidad propias. Una consulta selectiva por tiempo y workspace protege rendimiento; copiar todo fuera de la plataforma amplía superficie de riesgo y suele ser innecesario.
Unidad que representa cada fila, como uso horario, sentencia, tarea, evento o relación de linaje.
Unir granos incompatibles sin agregación duplica métricas y produce conclusiones falsas.Cobertura limitada a eventos o recursos de una región, a diferencia de tablas globales de cuenta.
Explica ausencias y obliga a consultar o consolidar regiones de forma explícita.Historial de versiones de atributos de una entidad a lo largo del tiempo.
Permite asociar un run con la configuración de compute vigente entonces, no con la actual.SELECT
workspace_id,
statement_id,
executed_by,
execution_status,
total_duration_ms,
compute.type AS compute_type,
error_message
FROM system.query.history
WHERE start_time >= current_timestamp() - INTERVAL 24 HOURS
AND (execution_status = 'FAILED' OR total_duration_ms > 600000)
ORDER BY start_time DESC;Expón esta información mediante una vista que filtre workspaces o equipos; los mensajes pueden contener detalles sensibles.
Puntos clave
- Respeta ámbito regional y retención de cada system table.
- Concede `USE` y `SELECT` mediante vistas de mínimo privilegio.
- Correlaciona por IDs y tiempo, declarando lag y huecos de telemetría.
Evita
- Asumir que una consulta desde otra región aparecerá en el metastore consultado.
- Dar `SELECT` amplio sobre auditoría y query history a todo el workspace.
Recuerdo activo