dbt
Nível médioComo acelero modelos dbt e reduzo o custo de computação no Snowflake/BigQuery?
Em um projeto dbt, tempo de execução e conta do warehouse são quase a mesma métrica com dois nomes diferentes — corrigir um geralmente corrige o outro.
Diferente de um cluster Spark que você mesmo provisiona, um projeto dbt rodando sobre Snowflake/BigQuery cobra por tempo de computação do warehouse — então um modelo lento não é só um incômodo, é um custo direto. Isso torna a lista de diagnóstico mais curta e acionável do que parece.
Comece com elapsed_time vs. execution_time, por modelo
O próprio run_results.json do dbt (escrito depois de cada dbt run/build) já tem os dois: tempo total decorrido da invocação, e tempo de execução por modelo. Um modelo cujo tempo de execução é pequeno em relação ao tempo total não é o problema — algo upstream (fila do warehouse, ordem de dependências) é. Um modelo cujo tempo de execução realmente domina a execução é onde vale olhar primeiro.
A escolha de materialização costuma ser a maior alavanca isolada
Um modelo materializado como view e consultado por muitos modelos downstream efetivamente reexecuta a própria lógica toda vez que é referenciado — transformando o que deveria ser um custo único em um custo repetido. Trocar uma transformação cara e frequentemente referenciada para table ou incremental costuma cortar drasticamente a computação total do warehouse, ao custo de algum armazenamento e um pouco de desatualização.
Modelos incrementais malfeitos custam mais que um full refresh
Um modelo incremental com um unique_key mal escolhido ou um filtro is_incremental() que na prática não reduz o escopo (varrendo a tabela fonte inteira a cada execução "incremental") te dá toda a complexidade da materialização incremental sem nenhuma de suas economias. Vale checar explicitamente: a execução incremental realmente varre menos dados que um full refresh, segundo o próprio profile de query do warehouse?
O paralelismo (a configuração threads do dbt) tem um teto
Mais threads significa mais modelos rodando simultaneamente contra o warehouse — até o ponto em que todos disputam os mesmos slots de computação do warehouse, momento em que mais threads só significa mais fila, não mais throughput real. Esse teto depende do tamanho do warehouse, então um valor copiado da configuração de outro projeto não é necessariamente certo para o seu.
O que o opti-pipe lê de uma execução dbt: tempo total decorrido e tempo de execução por modelo direto do run_results.json — nunca seu SQL, nomes de modelo ou caminhos de arquivo — para sinalizar quais modelos estão realmente puxando o custo da execução, a mesma abordagem de "olhar os números reais, não adivinhar" das regras de Spark acima.
Veja como isso fica no seu próprio pipeline.
Envie um event log real do Spark, um run_results.json do dbt, ou uma exportação de métricas do Flink, e receba recomendações concretas para aprovar — não mais uma regra de bolso.