dbt
Nivel medio¿Cómo acelero los modelos de dbt y reduzco el costo de cómputo en Snowflake/BigQuery?
En un proyecto de dbt, el tiempo de ejecución y la factura del warehouse son casi la misma métrica con dos nombres distintos — arreglar uno suele arreglar el otro.
A diferencia de un clúster de Spark que tú mismo aprovisionas, un proyecto de dbt corriendo sobre Snowflake/BigQuery te cobra por tiempo de cómputo del warehouse — así que un modelo lento no es solo una molestia, es un costo directo. Eso hace que la lista de diagnóstico sea más corta y accionable de lo que parece.
Empieza con elapsed_time vs. execution_time, por modelo
El propio run_results.json de dbt (escrito después de cada dbt run/build) ya tiene ambos: tiempo total transcurrido de la invocación, y tiempo de ejecución por modelo. Un modelo cuyo tiempo de ejecución es pequeño respecto al tiempo total no es el problema — algo río arriba (encolamiento del warehouse, orden de dependencias) sí lo es. Un modelo cuyo tiempo de ejecución realmente domina la corrida es donde conviene mirar primero.
La elección de materialización suele ser la palanca individual más grande
Un modelo materializado como view y consultado por muchos modelos río abajo efectivamente re-ejecuta su propia lógica cada vez que se le referencia — convirtiendo lo que debería ser un costo único en uno repetido. Cambiar una transformación costosa y frecuentemente referenciada a table o incremental suele reducir drásticamente el cómputo total del warehouse, a costa de algo de almacenamiento y un poco de desactualización.
Los modelos incrementales mal hechos cuestan más que un full refresh
Un modelo incremental con un unique_key mal elegido o un filtro is_incremental() que en realidad no acota el alcance (escaneando la tabla fuente completa cada corrida "incremental") te da toda la complejidad de la materialización incremental sin ninguno de sus ahorros. Vale la pena verificar explícitamente: ¿la corrida incremental realmente escanea menos datos que un full refresh, según el propio perfil de consulta del warehouse?
El paralelismo (la configuración threads de dbt) tiene un techo
Más threads significa más modelos corriendo concurrentemente contra el warehouse — hasta el punto en que todos compiten por los mismos slots de cómputo del warehouse, momento en el cual más threads solo significa más cola, no más throughput real. Este techo depende del tamaño del warehouse, así que un valor copiado de la configuración de otro proyecto no necesariamente es correcto para el tuyo.
Lo que opti-pipe lee de una corrida de dbt: tiempo total transcurrido y tiempo de ejecución por modelo directamente del run_results.json — nunca tu SQL, nombres de modelo o rutas de archivo — para marcar qué modelos están realmente impulsando el costo de la corrida, el mismo enfoque de "mirar los números reales, no adivinar" que las reglas de Spark de arriba.
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 para aprobar — no otra regla general más.