Cómo elijo la cadencia de un pipeline incremental

La mayoría de las discusiones sobre pipelines empiezan mal. Alguien pide “casi tiempo real”, un dashboard se ve vacío sin los números de hoy, y el schedule termina en */15 * * * *. Quince minutos suena responsable. A menudo solo es caro.

La cadencia no es una preferencia de orquestación. Es una afirmación sobre cuándo cambiaría de verdad una decisión. Si nadie actúa sobre la tabla entre corridas, un job más frecuente es sobre todo costo y una fuente de fallos.

Empieza por la decisión, no por el warehouse

Escribo una frase: quién usa esto, para hacer qué, para cuándo. Un supervisor de cobranza que revisa promesas de pago a las 9:00 no es el mismo consumidor que un modelo que puntúa conversaciones al cerrarse. El primero puede vivir en un batch matutino. El segundo puede necesitar minutos — pero solo en las tablas que alimentan el score, no en todos los marts.

Esa frase también nombra el grain. Si la decisión es “a qué cuentas llamar hoy”, el grain es la cuenta en el día operativo, no cada evento del log. Frescura a nivel evento se desperdicia si el producto piensa en cuentas diarias.

La frescura tiene factura

Cada corrida paga escaneo, shuffle, slots y — si no hay cuidado — refrescos completos disfrazados de incrementales. En warehouses que cobran por bytes leídos, un job de 15 minutos que barre una tabla cruda ancha 96 veces al día puede superar a un build diario bien particionado, aunque “haya llegado poca” data.

Antes de tocar el scheduler hago tres preguntas de costo:

1. ¿Cuál es el predicado incremental (updated_at, _partitiontime, timestamp de CDC)? Si no existe, no hay pipeline incremental. Hay una carga completa frecuente.
2. ¿Qué tan ancha es la lectura? Particionar y clusterizar solo ayudan si el filtro coincide con el layout.
3. ¿Qué falla si la corrida llega tarde? Si la respuesta es “el dashboard se ve viejo hasta las 10:00”, eso no es un incidente.

Mide antes de optimizar: registra bytes, duración y filas insertadas durante dos semanas en una cadencia conservadora. Después discute velocidad con números, no con ansiedad.

Una escalera simple

Casi nunca salto de diario a subhorario. La escalera se ve así:

Diario. Default para marts con forma financiera, reporting ejecutivo y cualquier cosa reconciliada a un día operativo. Idempotente, barato de repetir, fácil de explicar.

Unas cuantas veces al día. Útil cuando operaciones tienen una corrección a mediodía (archivos tardíos, un segundo extracto). Sigue siendo batch. Más simple que un micro-batch de verdad.

Horario. Razonable cuando el producto tiene un loop por hora — staffing, ajustes, outreach del mismo día — y el incremento es barato. No es razonable porque “horario suena moderno”.

Cada 15 minutos (o menos). Reservado para una ruta de serving delgada: las tablas que un sistema en vivo sí consulta, con clave incremental estricta, lookback acotado y un dueño que va a recibir la alerta. Todo lo demás sigue más lento.

El streaming existe, pero es otro contrato: watermarks, datos tardíos, semántica exactly-once o at-least-once. No uso una plataforma de streaming para que un mart batch se sienta de moda.

Los datos tardíos son el problema oculto de la cadencia

Un job de 15 minutos que solo lee “los últimos 15 minutos” va a perder eventos tardíos en silencio. Los datos de cobranza y mensajería están llenos de ellos: un reintento de webhook, un cliente que sincroniza de noche, un archivo de partner que llega después del SLA.

Si necesitas actualizaciones frecuentes, también necesitas una ventana de lookback (reprocesar las últimas N horas) o un cursor de CDC que no asuma que el tiempo de llegada es el tiempo del evento. Esa ventana es parte de la decisión de cadencia. Un schedule de 15 minutos con lookback de 24 horas suele ser más honesto — y más caro — de lo que se admite. A veces una corrida horaria con 36 horas de lookback es más barata y más correcta.

La confiabilidad gana a un schedule ingenioso

El ingenio aquí se ve así: intervalos dinámicos, backfills “inteligentes” al mediodía, un DAG que se abre en veinte micro-jobs para que cada uno sea pequeño. Esos diseños fallan de formas difíciles de explicar un lunes.

Prefiero:

• Una clave de incremento clara.
• Un lookback documentado.
• Un camino de full refresh que puede ser lento.
• Alertas de volumen y SLOs de frescura alineados a la decisión, no a “el job duró más de 4 minutos”.

Si un consumidor necesita algo más rápido, prefiero servir una tabla más pequeña en una cadencia más corta que acelerar todo el grafo. Los sistemas ganan a las herramientas: Airflow, Composer y un cron son intercambiables frente a una clave incremental incorrecta.

Una lista que sí uso

Antes de fijar schedule_interval:

• Nombra la decisión y a la persona dueña.
• Nombra el grain de la tabla de salida.
• Demuestra el filtro incremental con una query, no con un comentario.
• Dimensiona el lookback para datos tardíos.
• Estima el escaneo diario a la frecuencia propuesta.
• Escribe el SLO en tiempo de negocio (“listo a las 08:30 local”, no “corre cada 15 minutos”).

Si esas líneas están vacías, el pipeline no debería correr cada 15 minutos. Debería correr cuando podamos defenderlo — casi siempre más lento que el primer pedido, y mucho más fácil de confiar.