dbt
Junior¿Cómo despliego dbt para que realmente corra en un horario en producción?
dbt mismo no tiene scheduler - dbt run simplemente corre una vez y termina. Lograr que corra automáticamente, de forma confiable, en un horario, es enteramente una decisión que usted toma fuera de dbt.
Correr `dbt build` desde su laptop prueba que el proyecto funciona. Lograr que corra cada mañana a las 6am, reintente ante errores transitorios del warehouse, y alerte a alguien cuando no lo haga - eso es despliegue, y dbt es deliberadamente neutral sobre cómo lo hace.
Las tres opciones reales, y qué posee cada una
dbt Cloud posee el scheduler, el historial de corridas, y la lógica de reintentos por completo - usted configura un horario en su UI y maneja el resto, al costo de correr dentro de la infraestructura de dbt Labs en vez de la suya. Un orquestador auto-hospedado (Airflow, Dagster, Prefect) trata una corrida de dbt como una tarea en un DAG más grande - la elección correcta cuando dbt es un paso entre varios (extracción, carga, transformación dbt, exportación downstream) que necesitan secuenciarse y dependen entre sí, no solo dispararse en un reloj. cron simple más un runner de CI (un workflow programado de GitHub Actions, un cron job en una VM) es la opción más simple y completamente adecuada para un proyecto sin dependencias entre herramientas - solo no recurra a esto una vez que realmente necesite reintentos, alertas, o dependencias a nivel de DAG, que no le da gratis.
De qué es responsable sin importar cuál elija
Dos cosas que dbt genuinamente no maneja por usted en ninguna de estas configuraciones. Primero,
credenciales - profiles.yml (o la config de conexión de dbt Cloud) todavía necesita
credenciales reales del warehouse disponibles donde sea que la corrida realmente se ejecute, siguiendo el
mismo patrón de env_var()-no-hardcodeado sin importar el scheduler. Segundo, notificación de
fallo - un dbt build fallido termina con código distinto de cero, pero nadie recibe alerta a
menos que el orquestador alrededor esté conectado para verificar ese código de salida y alertar. dbt Cloud
tiene esto incorporado; Airflow/Dagster necesitan configurarlo como parte del DAG; cron simple necesita
agregarlo explícitamente (un script wrapper que verifica $? y llama a Slack/PagerDuty, o
similar).
El error que esta sección existe para prevenir: un cron job que silenciosamente deja de correr
(una VM redesplegada sin el crontab, un archivo de workflow de CI deshabilitado por accidente) no produce
ningún error en absoluto - no una corrida fallida, simplemente ninguna corrida. Las verificaciones de
freshness en las tablas que debería haber actualizado (vea el artículo de freshness de
sources.yml) son lo que realmente atrapa eso, no el scheduler mismo.
Dónde encaja opti-pipe, y dónde no
Ninguna de estas elecciones de scheduling cambia lo que lee opti-pipe - el motor de reglas mira
run_results.json, que cualquiera de estas opciones produce de la misma forma, ya que es la
propia salida de dbt sin importar qué disparó la corrida. Lo que no puede decirle es si la corrida ocurrió
en absoluto, o en horario - eso es enteramente trabajo de la capa de despliegue, y vale la pena verificarlo
independientemente (un dashboard, una verificación de freshness, una alerta real) en vez de asumir que el
silencio significa que todo está bien.
Vea cómo se ve esto en su propio pipeline.
Suba un event log real de Spark, un run_results.json de dbt o una exportación de métricas de Flink y obtenga recomendaciones concretas, que debe aprobar antes de aplicar - no otra regla general.