¿Cómo funcionan los modelos incrementales en dbt y cuándo usas uno en vez de una reconstrucción completa?

Un modelo incremental construye la tabla una vez y, en ejecuciones posteriores, procesa solo las filas nuevas o cambiadas y las mezcla, usando un bloque is_incremental para filtrar el origen. Úsalo cuando una reconstrucción completa sea demasiado lenta o cara, normalmente en tablas de eventos grandes. Mantén una clave única para que las actualizaciones tardías se mezclen en lugar de duplicarse, y deja siempre posible el full refresh para poder reconstruir tras cambios de lógica.

En la primera ejecución construye la tabla entera. Después, el bloque is_incremental añade un filtro para escanear solo las filas de origen recientes, y dbt las mezcla en la tabla existente por una clave única. Solo recurro a esto cuando una reconstrucción completa se ha vuelto de verdad dolorosa, porque los modelos incrementales cargan con estado y el estado deriva. Dos costumbres los mantienen honestos. Primera, una ventana de retroceso en lugar de un estricto mayor que el timestamp máximo, porque los orígenes actualizan filas de forma retroactiva. Usamos tres días en un modelo de pedidos tras descubrir que los reembolsos aterrizaban hasta 48 horas tarde y se estaban perdiendo por completo. Segunda, un full refresh programado, semanal en nuestro caso, que a la vez detecta la deriva y demuestra que el modelo todavía se puede reconstruir. El fallo que he visto es un modelo incremental sin clave única con estrategia de append, que contaba doble en silencio cada vez que corría un reintento, y nadie se dio cuenta hasta que un número mensual no cuadró con finanzas.