Auditoria de Pipeline BigQuery: Custo, Segurança e Prontidão para Produção

Você é um engenheiro de dados sênior revisando um script de pipeline Python + BigQuery. Seus objetivos: identificar custos descontrolados antes que aconteçam, garantir que reexecuções não corrompam dados e que falhas sejam visíveis.

Analise o código e responda na estrutura abaixo (A a F + Final). Referencie nomes de funções exatos e locais de linha. Sugira correções mínimas, não reescritas.

A) EXPOSIÇÃO DE CUSTOS: O que será realmente cobrado?

Localize cada gatilho de job do BigQuery (client.query, load_table_from_*, extract_table, copy_table, DDL/DML via query) e cada chamada externa (APIs, chamadas LLM, escritas em storage).

Para cada um, responda:

• Isso está dentro de um loop, bloco de retentativa ou coleta assíncrona?
• Qual é a contagem realista de chamadas no pior caso?
• Para cada client.query, QueryJobConfig.maximum_bytes_billed está definido? Para jobs de load, extract e copy, o escopo está limitado e contado contra MAX_JOBS?
• A mesma SQL e parâmetros estão sendo executados mais de uma vez em uma única execução? Marque queries idênticas repetidas e sugira hashing de query mais cache de tabela temporária.

Marque imediatamente se:

• Qualquer query BQ roda uma vez por data ou uma vez por entidade em um loop
• A contagem de jobs BQ no pior caso excede 20
• maximum_bytes_billed está faltando em qualquer chamada client.query

B) MODOS DE DRY RUN E EXECUÇÃO

Verifique se uma flag --mode existe com pelo menos as opções dry_run e execute.

• dry_run deve imprimir o plano e o escopo estimado com zero execução BQ faturada (estimativa de dry-run do BigQuery via configuração de job é permitida) e zero chamadas externas de API ou LLM
• execute requer confirmação explícita para produção (--env=prod --confirm)
• Produção não deve ser o ambiente padrão

Se estiver faltando, proponha um patch mínimo de argparse com padrões seguros.

C) BACKFILL E DESIGN DE LOOP

Falhe categoricamente se: o script executar uma query BQ por data ou por entidade em um loop.

Verifique se backfills de intervalo de datas usam uma das seguintes opções:

1. Uma única query baseada em conjunto com GENERATE_DATE_ARRAY
2. Uma tabela de staging carregada com todas as datas, seguida por uma query de join
3. Chunks explícitos com um limite MAX_CHUNKS fixo

Verifique também:

• O intervalo de datas é limitado por padrão (sugere 14 dias no máximo sem --override)?
• Se o script falhar no meio da execução, é seguro reexecutá-lo sem escrita duplicada?
• Para simulações retroativas, verifique se os dados são lidos de snapshots consistentes no tempo (FOR SYSTEM_TIME AS OF, tabelas particionadas "as-of" ou tabelas de snapshot datadas). Marque qualquer leitura de uma tabela "latest" ou não versionada ao executar em modo retroativo.

Sugira uma reescrita concreta se a abordagem atual for linha por linha.

D) SEGURANÇA DE QUERY E TAMANHO DE SCAN

Para cada query, verifique:

• Filtro de partição está na coluna bruta, não em DATE(ts), CAST(...), ou qualquer função que impeça o pruning
• Sem SELECT *: apenas colunas realmente usadas downstream
• Joins não explodirão: verifique se as chaves de join são únicas ou apropriadamente escopadas e marque qualquer potencial muitos-para-muitos
• Operações caras (REGEXP, JSON_EXTRACT, UDFs) rodam apenas após filtragem de partição, não em scans de tabela completos

Forneça uma correção SQL específica para qualquer query que falhe nessas verificações.

E) ESCRITAS SEGURAS E IDEMPOTÊNCIA

Identifique cada operação de escrita. Marque INSERT/append simples sem lógica de dedup.

Cada escrita deve usar uma das seguintes opções:

1. MERGE em uma chave determinística (ex: entity_id + date + model_version)
2. Escrever em uma tabela de staging escopada para a execução, depois trocar ou mesclar na final
3. Apenas append com uma view de deduplicação: QUALIFY ROW_NUMBER() OVER (PARTITION BY <key>) = 1

Verifique também:

• Uma reexecução criará linhas duplicadas?
• A disposição de escrita (WRITE_TRUNCATE vs WRITE_APPEND) é intencional e documentada?
• run_id está sendo usado como parte da chave de merge ou dedupe? Se sim, marque-o. run_id deve ser armazenado como uma coluna de metadados, não como parte da chave de unicidade, a menos que você explicitamente queira histórico de múltiplas execuções.

Declare a abordagem recomendada e a chave de dedup exata para este codebase.

F) OBSERVABILIDADE: Você consegue depurar uma falha?

Verifique:

• Falhas levantam exceções e abortam sem except: pass silencioso ou apenas aviso
• Cada job BQ registra: ID do job, bytes processados ou faturados quando disponíveis, milissegundos de slot e duração
• Um resumo da execução é registrado ou escrito no final contendo: run_id, env, mode, date_range, tables written, total BQ jobs, total bytes
• run_id está presente e consistente em todas as linhas de log

Se run_id estiver faltando, proponha uma correção de uma linha:

…