Saltar al contenido
Lakehouse LabLakehouse LabPreparación Databricks Data Engineer
Módulo 21 · Lección

Alertas, webhooks y ownership

Contenido abierto

Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.

Lección 5 de 5

Alertas, webhooks y ownership

Un backfill reutiliza el mismo Job parametrizado que producción para ejecutar intervalos históricos, con concurrencia y publicación controladas.

Duración
17 min aprox.
Objetivo
Un backfill reutiliza el mismo Job parametrizado que producción para ejecutar intervalos históricos, con concurrencia y publicación controladas.
Siguiente paso
Continuar con el laboratorio
Ver detalles del módulo

Triggers, alertas, backfills y operación

Opera pipelines según disponibilidad real del dato y recupera ventanas históricas sin romper producción.

Al terminar podrás
  • Elegir trigger por evento o calendario
  • Diseñar backfills seguros
  • Crear alertas accionables y SLOs
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Professional
Ruta relacionada
pipelines
Dominios blueprint
Monitoring and Alerting · Orchestration
Estado
Revisión editorial interna
Fuentes principales
Automate jobs with schedules and triggers · Databricks · Trigger jobs when new files arrive · Databricks
Reportar un error
05
Decisión de diseño

Alertas, webhooks y ownership

Un backfill reutiliza el mismo Job parametrizado que producción para ejecutar intervalos históricos, con concurrencia y publicación controladas.

Mostrar prerrequisitos
Dificultad
Professional
Prerrequisitos
m20
Reportar un error en esta lección

Lakeflow Jobs puede generar múltiples runs para un rango e intervalo y pasar parámetros de backfill. El código usa `process_date` o límites temporales explícitos y escribe idempotentemente la partición correspondiente. Mantener una ruta de código distinta para históricos provoca divergencia justo cuando más se necesita fiabilidad.

Antes de lanzar noventa días se calcula número de runs, volumen, coste, capacidad de origen y colisión con producción. Puede reducirse concurrency, escribir en una tabla sombra y promover por lotes. La validación compara conteos y totales por día, y el rollback conoce exactamente qué particiones tocó.

Modelo mental

Un backfill es una ejecución histórica del mismo contrato de transformación, delimitada por parámetros reproducibles y aislada de la publicación corriente. No debería requerir copiar un notebook y cambiar fechas manualmente. El Job acepta `start`, `end`, versión de código y modo, lee una fuente durable y escribe staging o particiones deterministas. La granularidad equilibra paralelismo y overhead; For each por día puede servir para meses, mientras millones de claves pertenecen a Spark. El backfill coexiste con producción mediante rangos no solapados o un paso serial de reconciliación. Debe cubrir inserts, updates y deletes, no solo añadir filas faltantes. Una vez validado, un `MERGE`, replaceWhere controlado o cutover publica el resultado. El checkpoint streaming de producción no se rebobina, y los efectos externos permanecen deshabilitados o idempotentes durante historia.

Intervalo cerrado-abierto

Rango temporal que incluye su inicio y excluye su final, permitiendo concatenar particiones sin huecos ni doble conteo fronterizo.

Hace deterministas backfills por día u hora y evita duplicar eventos exactamente en medianoche.
Backfill id

Identificador único de la campaña histórica que acompaña staging, métricas, logs, approvals y acciones de publicación asociadas.

Permite auditar, reparar y revertir una corrección sin mezclarla con runs normales o campañas anteriores.
Punto de corte

Versión u instante hasta el cual se reconstruye historia antes de reconciliar cambios nuevos que producción continúa generando.

Evita carreras y pérdida de updates durante una reconstrucción larga que convive con el flujo activo.
SQLTransformación idempotente por fecha
MERGE INTO main.silver.orders_daily AS target
USING (
  SELECT *
  FROM main.bronze.orders
  WHERE event_date = :process_date
) AS source
ON target.order_id = source.order_id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

El parámetro del run delimita el rango, mientras `MERGE` permite reintentar el mismo día sin duplicar claves.

Puntos clave

  • Backfill y ejecución ordinaria comparten artefacto y contrato.
  • Parámetros temporales deben ser explícitos y usar límites no solapados.
  • Coste, concurrencia y reconciliación se estiman antes de crear cientos de runs.

Evita

  • Crear un notebook especial para backfill que ya no comparte validaciones ni lógica de producción.
  • Lanzar todos los días con máxima concurrencia y degradar el workload diario o la fuente.

Recuerdo activo

¿Qué evita que reintentar un día de backfill duplique filas?

Borrador privado · solo en este navegador
5 lecciones pendientes

Fuente revisada · vista externa

Databricks Free Declarative Pipelines

Databricks Free Declarative Pipelines · commit a515370

docs/3-2-building-bronze-sql.md

Lectura en GitHub

Este notebook se abre desde su fuente revisada

El repositorio no permite republicar su contenido dentro de Lakehouse Lab. Conservamos la misma experiencia lateral, la ruta exacta y el commit auditado, y dejamos la lectura en GitHub para respetar la autoría.

Autor
andkret
Licencia
No verificada
Formato
project
Ver notebook en GitHub