dbt
Nivel medioModelos incrementales de dbt: cuándo «incremental» se convierte en silencio en un full refresh
Todo el sentido de un modelo incremental es procesar solo filas nuevas o modificadas. Un par de disparadores comunes lo convierten en silencio en una reconstrucción completa, en cada ejecución, sin ningún error.
dbt decide si ejecutar un modelo de forma incremental o como full refresh en base a unas cuantas condiciones - y más de una puede cambiar en silencio después de meses de que el modelo funcionara sin problemas.
Cómo decide dbt entre incremental y full refresh
Más allá de un flag explícito --full-refresh, dbt recurre a una reconstrucción completa si
la tabla destino todavía no existe, o - dependiendo de tu configuración de on_schema_change -
si el conjunto de columnas del modelo cambió desde que se creó la tabla. on_schema_change: "fail"
detiene la ejecución de inmediato ante un desajuste; "ignore" (el valor por defecto) o un
"append_new_columns"/"sync_all_columns" mal configurado pueden en cambio
disparar en silencio una reconstrucción completa según lo que realmente haya cambiado.
Por qué es silencioso: sin error, solo una ejecución mucho más larga
Un full refresh no es un estado de fallo desde el punto de vista de dbt - la ejecución sigue en
verde. Lo que cambia es el execution_time en run_results.json, saltando muy por
encima de su rango normal, y una línea en la factura del warehouse que no coincide con «solo agregamos
un día de datos». Nadie recibe una alerta por un éxito lento.
Cómo detectarlo antes que la factura
Compara el execution_time de cada modelo incremental contra su propio promedio
histórico, no contra un umbral fijo - un modelo que normalmente tarda 40 segundos y de repente tarda 25
minutos es la señal, sin importar qué se considere «aceptable» para otro modelo del mismo proyecto.
Un modelo al que le pasa esto no está roto - su configuración simplemente está haciendo
exactamente lo que le indicaste, bajo una condición que no esperabas encontrar. El arreglo casi
siempre está en on_schema_change o en lo que sea que haya cambiado el conjunto de
columnas más arriba, no en el SQL del modelo en sí.
Mira cómo se ve esto en tu propio pipeline.
Sube un event log real de Spark, un run_results.json de dbt, o una exportación de
métricas de Flink, y recibe recomendaciones concretas que requieren tu aprobación - no otra regla
general.