dbt
JuniorComo faço deploy do dbt para ele realmente rodar em um horário em produção?
O dbt em si não tem scheduler - dbt run só roda uma vez e termina. Fazer ele rodar automaticamente, de forma confiável, em um horário, é inteiramente uma decisão que você toma fora do dbt.
Rodar `dbt build` do seu laptop prova que o projeto funciona. Fazer ele rodar toda manhã às 6h, tentar de novo em erros transitórios do warehouse, e alertar alguém quando não funcionar - isso é deploy, e o dbt é deliberadamente neutro sobre como você faz isso.
As três opções reais, e o que cada uma cuida
O dbt Cloud cuida do scheduler, histórico de execuções, e lógica de retry inteiramente - você configura um horário na interface dele e ele cuida do resto, ao custo de rodar dentro da infraestrutura da dbt Labs em vez da sua. Um orquestrador auto-hospedado (Airflow, Dagster, Prefect) trata uma execução do dbt como uma task em um DAG maior - a escolha certa quando dbt é um passo entre vários (extração, carga, transformação dbt, exportação downstream) que precisam ser sequenciados e dependem uns dos outros, não só disparados em um relógio. cron simples mais um runner de CI (um workflow agendado do GitHub Actions, um cron job em uma VM) é a opção mais simples e completamente adequada para um projeto sem dependências entre ferramentas - só não recorra a isso quando você realmente precisar de retries, alertas, ou dependências no nível de DAG, que ele não dá de graça.
Pelo que você é responsável não importa qual escolher
Duas coisas que o dbt genuinamente não cuida para você em nenhuma dessas configurações. Primeiro,
credenciais - o profiles.yml (ou a config de conexão do dbt Cloud) ainda precisa de
credenciais reais do warehouse disponíveis onde a execução realmente acontece, seguindo o mesmo padrão de
env_var()-e-não-hardcoded independente do scheduler. Segundo, notificação de falha - um
dbt build que falha sai com código diferente de zero, mas ninguém é acionado a menos que o
orquestrador ao redor esteja configurado para checar esse código de saída e alertar. O dbt Cloud tem isso
embutido; Airflow/Dagster precisam configurar isso como parte do DAG; cron simples precisa disso
parafusado explicitamente (um script wrapper que checa $? e chama o Slack/PagerDuty, ou
similar).
O erro que esta seção existe para prevenir: um cron job que silenciosamente para de rodar (uma
VM redesplantada sem o crontab, um arquivo de workflow de CI desabilitado por acidente) não produz erro
nenhum - não uma execução falha, simplesmente nenhuma execução. Checagens de freshness nas tabelas que
deveria ter atualizado (veja o artigo de freshness do sources.yml) são o que realmente pega
isso, não o scheduler em si.
Onde o opti-pipe entra, e onde não entra
Nenhuma dessas escolhas de scheduling muda o que o opti-pipe lê - o motor de regras olha para o
run_results.json, que qualquer uma dessas opções produz da mesma forma, já que é a própria
saída do dbt não importa o que disparou a execução. O que ele não consegue dizer é se a execução aconteceu
ou não, ou no horário - isso é inteiramente trabalho da camada de deploy, e vale a pena verificar
independentemente (um painel, uma checagem de freshness, um alerta de verdade) em vez de assumir que
silêncio significa que está tudo bem.
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 antes de aplicar - não mais uma regra geral.