Triggers e agendamento sem desperdício
Rodar mais vezes deixa o dado mais atualizado e gasta mais créditos. O jogo é achar a frequência que o negócio precisa e encadear o resto por evento.
- Equilibrar dado atualizado e custo em créditos
- Encadear query e notebook por evento, sem agendar tudo no relógio
- Economizar créditos com horário comercial, sync incremental e menos pipelines órfãos
Um trigger é o gatilho que dispara uma execução de pipeline. Ele pode ser por tempo (rode de hora em hora, todo dia às 6h) ou por evento (rode assim que a fonte de que eu dependo terminar de rodar). Cada disparo puxa o dado atualizado da fonte, passa pela transformação (uma query ou um notebook) e chega na tabela pronta que o time consome.
Parece detalhe de configuração, mas é aqui que se decide se o dado vai estar atualizado na hora da decisão e quanto isso vai custar em créditos. Duas escolhas, o mesmo botão.
O trade-off central: dado atualizado x custo
A regra é simples: quanto mais vezes o pipeline roda, mais atual o dado fica, e mais créditos ele gasta. Rodar de hora em hora deixa tudo quase em tempo real, mas multiplica as execuções (e a conta). Rodar uma vez por dia é barato, mas o dado pode estar até 24 horas atrasado. Dado atualizado e custo andam juntos, na mesma direção.
A curva sobe junto: mais frequência significa dado mais atual e conta mais alta, sempre na mesma direção. Não existe frequência "certa" no vácuo, existe a frequência que o negócio precisa. Um painel de vendas que o time olha de manhã não ganha nada rodando de hora em hora à noite. Já um alerta de fraude que precisa reagir rápido justifica o custo de rodar sempre.
Comece pela pergunta "com que atraso o negócio ainda toma a decisão certa?". Se a resposta é "de manhã já serve", agende para a madrugada, uma vez por dia. Suba a frequência só quando alguém sentir falta de dado mais atual, não por precaução.
Encadeamento por eventos: dispare no fim da execução, não no relógio
Uma source, ao terminar de rodar, pode disparar automaticamente uma query ou um notebook. Isso é o encadeamento por evento: em vez de marcar cada etapa no relógio, você diz "quando esta terminar, rode a próxima". A query só processa dado que acabou de chegar, e o notebook só roda depois que a query concluir.
A alternativa, agendar tudo por horário fixo (source às 6h, query às 6h05, notebook às 6h10), quebra no dia em que a source atrasa: a query roda em cima do dado velho e propaga o atraso para toda a cadeia. Ninguém percebe até o número sair errado. Encadeando por evento, a cadeia se ajusta sozinha se algo demora, e você nunca roda em cima de dado desatualizado.
Coloque a frequência num único lugar, na source, e deixe query e notebook por evento. Assim você controla o quão atual o dado fica num só ponto, e o resto da cadeia segue o ritmo naturalmente, sem horários mágicos para manter em sincronia.
Dicas de economia de créditos
Depois de escolher a frequência, dá para cortar créditos sem perder nada de valor. A maior parte do desperdício vem de rodar quando ninguém consome ou de reprocessar dado que não mudou.
| Dica | Por que economiza |
|---|---|
| Rode só em horário comercial | Se ninguém consulta o dado de madrugada, agendar de 22h às 6h só queima crédito sem ninguém ler o resultado. |
| Rode só em dias de semana | Um relatório que o time olha no expediente não precisa atualizar sábado e domingo. São dois dias de execuções cortados por semana. |
| Use sync incremental | Traz só o que mudou desde a última execução, em vez de reprocessar a base inteira toda vez. |
| Agrupe execuções | Concentre poucos disparos nos horários de consulta (início, meio e fim de expediente) em vez de espalhar rodadas ao longo do dia. |
| Encadeie por evento | Query e notebook rodam quando a source termina, não em janelas fixas. Nada dispara à toa esperando dado que ainda não chegou. |
| Desligue pipelines órfãos | Um sync que alimenta dashboard já desligado segue custando toda madrugada sem entregar nada. Pausar é crédito puro de volta. |
Um pipeline órfão é aquele que continua rodando na agenda, mas cujo resultado ninguém consome mais. A fonte foi trocada, o dashboard foi desligado, o projeto acabou, e o sync segue firme. Como cada um sozinho parece barato, eles se acumulam despercebidos. Para achar: liste as fontes e transformações com trigger ativo, pergunte para cada tabela pronta quem ainda lê (dashboard, MCP ou Data API) e, se ninguém consome a ponta da cadeia, pause o trigger que a alimenta sem apagar. Depois de um tempo sem reclamação, dá para arquivar com segurança.
Antes de desligar, confirme que a tabela não é insumo de outra transformação. Ela pode parecer sem consumo direto, mas alimentar outra tabela por encadeamento. Siga a cadeia até o fim antes de pausar qualquer trigger.
Decida agora
Um cliente rodava todas as fontes de hora em hora "por garantia", sete dias por semana, inclusive uma exportação financeira que só fechava o dia à meia-noite. Eram 24 execuções diárias para um dado que mudava uma vez. Baixamos essa fonte para 1x ao dia na madrugada de dia útil, ligamos sync incremental e encadeamos a query e o notebook por evento. O painel financeiro continuou pronto antes das 8h, e as execuções daquela cadeia caíram de mais de 160 por semana para 5.