Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLección 3 de 5
System tables de workflows
Convierte system tables y señales de Data Quality Monitoring en una línea de tiempo común para ejecución, coste y salud del dato.
17 min aprox.
03OperaciónSystem tables de workflows
Convierte system tables y señales de Data Quality Monitoring en una línea de tiempo común para ejecución, coste y salud del dato.
+
System tables de workflows
Convierte system tables y señales de Data Quality Monitoring en una línea de tiempo común para ejecución, coste y salud del dato.
`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.
Un run `SUCCESS` no demuestra que el activo esté fresco o completo. Data Quality Monitoring añade anomaly detection de freshness/completeness y data profiling de distribución/drift sin modificar el job productor. Correlaciona sus incidentes con IDs y ventanas de despliegue/run, y conserva expectations o reconciliaciones para reglas que deban aplicar acciones. Construye vistas restringidas y no fuerces joins cuando no exista identificador común.
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.
¿Por qué una vista dinámica es preferible a compartir directamente `system.query.history`?
Profundiza
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.Resumen
Puntos clave
- Respeta ámbito regional y retención de cada señal.
- Distingue salud del run de frescura, completitud y drift del dato.
- 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.