Observabilidad

Spark UI es la herramienta de detalle para compute clásico. Empieza por la timeline y el job más largo, entra en su stage crítico y compara tareas. Scheduling delay señala falta de slots o overhead; shuffle read/write muestra movimiento; spill, GC y duración extrema orientan a memoria o skew. Los executors permiten comprobar si el trabajo se distribuyó y si hubo pérdidas.

No conviertas cada métrica en una receta. Un stage con 90 % de tiempo en una tarea no mejora con más workers; una etapa I/O-bound puede necesitar mejor layout o pruning. Conserva IDs de job, stage y run, captura percentiles y anota el plan o commit analizado para que otra persona reproduzca el diagnóstico.

spark.sparkContext.setJobGroup(
    "daily-margin-2026-07-21",
    "Daily margin aggregation · release 4f2c9ab",
)

result = build_daily_margin(spark.table("prod.silver.order_lines"))
result.write.mode("overwrite").saveAsTable("prod.gold.daily_margin")

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.

-- 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;

`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;

El compute event log explica creación, cambios, escalado y terminación. Driver stdout/stderr/log4j contiene excepciones de planificación y aplicación; los worker/executor logs ayudan cuando una tarea concreta falla. Spark UI conserva detalle del runtime activo, pero reiniciar compute puede perder la vista histórica; configura entrega de logs cuando la política de soporte exige retención externa.

El acceso depende del modo de compute. En standard, los usuarios no ven todos los logs de executor y sólo admins acceden a ciertos driver logs; en dedicated, el principal asignado obtiene más visibilidad. No registres payloads, secretos o tokens para facilitar depuración. Usa correlation IDs y métricas estructuradas que permitan unir el fallo con job/run sin exponer datos.

import json
import logging

logger = logging.getLogger("orders_pipeline")
logger.setLevel(logging.INFO)

logger.info(json.dumps({
    "event": "quality_gate_completed",
    "run_id": dbutils.widgets.get("run_id"),
    "table": "prod.silver.orders",
    "invalid_rows": invalid_count,
    "contains_customer_data": False,
}))

La CLI ofrece comandos `jobs get-run`, `get-run-output`, `list-runs` y `repair-run`; el grupo `api` sirve para endpoints aún no envueltos. Una captura de incidente debe conservar run ID, estado, timestamps, configuración efectiva y enlaces a perfiles, no ejecutar reparaciones en el mismo paso. Usa OAuth para automatización y perfiles separados, nunca tokens pegados en scripts o notebooks.

Las respuestas pueden paginarse y algunos outputs de tareas tienen límites. Diseña el script como lectura idempotente, almacena JSON en un volumen gobernado con retención y redacta campos sensibles. Después de formular una hipótesis, la reparación se convierte en una acción aprobada con evidencia antes/después.

databricks jobs get-run 987654321 --output json > run-987654321.json
databricks jobs get-run-output 987654321 --output json > output-987654321.json

# Inspecciona antes de cualquier repair-run.
# La autenticación procede de OAuth o de un perfil seguro, no del script.