Procedure e agendamento nativo no BigQuery ou orquestrador?

Thread Uma dúvida de um cliente essa semana me lembrou de algo que muita gente aprende tarde em engenharia de dados. "Se o BigQuery tem procedure e agendamento nativo, por que vocês não usam?" A pergunta é boa. Arquitetura é definir padrões consistentes O objetivo é criar um sistema que continue funcionando de forma organizada quando crescer, e não simplesmente sair usando todos os recursos disponíveis porque existem haha. Sou a Prof Artemísia, física, engenheira, líder de projetos de dados/ML.

Quando decidimos que os agendamentos passam por um orquestrador, existe um motivo. Quando definimos que publicações passam por revisão e versionamento, existe um motivo. Quando uma camada só pode ser alterada via CI/CD, também existe um motivo.

Todas essas decisões ajudam a responder perguntas importantes. Quem executou isso? Quando executou? Quem aprovou? O que mudou? Por que falhou?

O problema das exceções é que elas raramente ficam sozinhas. Uma procedure criada fora do padrão parece inofensiva, depois aparece outra, depois surge um notebook no Colab. Depois alguém cria um agendamento em outra ferramenta (ex tão usando airflow e por não ter handover um começa a orquestrar no databricks pipelines direto) por fim um script roda numa VM esquecida por Deus. Entende? Decisões de arquitetura é sobre decidir sobre como vamos lidar com efeitos acumulados

De repente existem cinco formas diferentes de publicar dados,três formas diferentes de agendar processos, vários pontos distintos de manutenção. 0% visão centralizada d¢ observabilidade, coitada dela.

Conteúdo da publicação 6/7.

Conteúdo da publicação 7/7.

---