Selo de estado:
Preview(teto atual do produto) · Curso ACD-230 — Operação: orquestração, falhas e recuperação · Aula 5 de 8 · Atualizado em 2026-10-04.
Objetivo#
Ao final desta aula você vai declarar de quem cada transformação depende e prever a ordem de execução, entendendo por que a camada seguinte não roda quando a origem falhou na mesma execução.
Vídeo#
Identificador no manifesto: acd-230-05-dependencias-entre-pipelines · duração-alvo 6 min · tela do produto: /dags.
Roteiro (5 capítulos):
| # | Minutagem-alvo | Capítulo | Rota do produto |
|---|---|---|---|
| 1 | 0:00–0:45 | Uma execução não é uma lista: é um grafo. Bronze lê a fonte, Silver lê a Bronze, Gold lê a Silver (ou várias). | /dags |
| 2 | 0:45–2:15 | Onde a dependência é declarada: a etapa Transformações do assistente de pipeline, e a revisão mostrando <tabela> depende de: …. | /sources/[id] |
| 3 | 2:15–3:45 | A porta de dependência: a origem falhou nesta execução → a camada seguinte não executa, com o motivo escrito. Por que antes ela "passava" com dado velho. | /dags/[id] |
| 4 | 3:45–5:10 | Como o nome é resolvido: identidade, apelido, ambíguo, inexistente — e por que apelido nunca sobrepõe identidade. | /sources/[id] |
| 5 | 5:10–6:00 | O caso Gold que lê duas Silver; a aba Grafo; os três erros do curso; o "faça você mesmo". | /dags/[id] |
Conteúdo#
A camada seguinte NÃO roda quando a origem falhou
Se a Bronze de vendas falhou nesta execução, a Silver que depende dela não executa — mesmo que a tabela Bronze exista no datalake com a carga de ontem. Antes dessa regra, a Silver "passava" lendo dado velho e reportava um número que não correspondia à carga do dia. Agora ela aparece como não executada, com o motivo: "Não executada: a origem … falhou nesta execução. Executar mesmo assim leria dado de execução anterior e reportaria um sucesso que não corresponde à carga."
O conceito: declarar a dependência é o que permite não fingir sucesso
Uma execução ordena tarefas porque alguém declarou quem lê o resultado de quem. Esse grafo serve a dois propósitos — e o segundo é o que importa nesta aula:
- Ordenar: a Silver só começa depois que a Bronze concluir.
- Não fingir: se a Bronze falhou, a Silver é bloqueada por dependência em vez de passar com o dado da execução anterior.
O segundo ponto nasceu de um defeito real observado em produção: a Bronze falhava (uma data sem horário recusada pelo BigQuery) e a Silver, que lê aquela Bronze, fechava como sucesso na mesma execução — porque a tabela estava lá, com o dado de ontem. Uma execução "verde" com número errado é pior do que uma execução vermelha: ninguém vai investigar. A regra vale para os dois executores (a execução agendada e a execução manual), porque mora num único módulo — não há duas semânticas conforme o caminho.
Onde a dependência é declarada, e as telas reais
Na etapa Transformações do assistente de pipeline (/sources/[id]), cada etapa Silver/Gold declara de quem depende. A referência é a tabela de destino da tarefa anterior (por exemplo bronze:tb_vendas) — não o nome do arquivo nem o nome da tabela de origem. Na Revisão, antes de publicar, o produto imprime a declaração em texto: <tabela> depende de: <lista> (ou nenhuma). E ele recusa publicar o que não fecha: "… depende de "X", que não existe na definição — referência inválida impede publicar" e "… depende de si mesma — há um ciclo no grafo". Ler essa linha na revisão é mais rápido do que descobrir o problema numa execução às 06:00.
Na página da execução (/dags/[id]), a aba Grafo mostra as tarefas e as setas entre elas, com Modo amplo para pipelines grandes; a Grade mostra quem rodou e quem não rodou. Uma tarefa não executada por dependência não é uma falha dela: é uma consequência registrada, com o motivo.
Como o nome é resolvido (as quatro respostas)
A transformação referencia a origem por uma referência crua; a tarefa é identificada pela tabela de destino. Traduzir é obrigatório — mas traduzir "removendo pedaços até casar" casaria nomes que não são o mesmo objeto. A regra é esta:
| Resposta | Quando | O que acontece |
|---|---|---|
| Identidade | a referência é exatamente a tabela de destino da Bronze (sem acento, sem caixa) | é a dependência; falhou → bloqueia |
| Apelido | a referência casa uma forma derivada da origem (o nome do arquivo, com ou sem extensão) e aponta para uma única Bronze | é a dependência; falhou → bloqueia |
| Ambíguo | o mesmo apelido casa duas Bronzes (clientes.csv e clientes.json) | o produto não escolhe: bloqueia se qualquer uma falhou e registra a ambiguidade |
| Inexistente | nenhuma Bronze casa | a tarefa não é bloqueada (não há origem falhada), mas a execução registra que a dependência declarada não existe — corrija a declaração |
Apelido nunca sobrepõe identidade
E no caso ambíguo o produto não decide por ordem de iteração — escolher "o último inserido" foi exatamente o jeito como a porta deixou passar antes. Se você quer previsibilidade total, declare sempre pela tabela de destino e dê destinos distintos a origens de nome parecido (tb_clientes_crm, tb_clientes_erp).
Exemplo: a Comércio Aurora
A Aurora tem duas extrações Bronze — bronze:tb_vendas (do ERP) e bronze:tb_filiais (de uma planilha) — duas Silver que as limpam, e uma Gold de receita por filial que lê as duas Silver. Maria declara as duas dependências na Gold; a revisão imprime gold:receita_por_filial depende de: silver:vendas_limpas, silver:filiais_limpas.
Na execução da terça, o ERP está fora e bronze:tb_vendas falha. A Silver de vendas não executa — motivo registrado. A Gold também não executa, porque uma das suas origens não foi recarregada nesta execução. Já bronze:tb_filiais e a sua Silver rodam normalmente: o grafo bloqueia o ramo afetado, não o pipeline inteiro. O painel de receita continua mostrando o número de segunda, com a data de segunda — honesto. Se a porta não existisse, a Gold teria rodado lendo a Bronze de vendas de segunda e entregado um "número de terça" que nunca existiu.
Para recuperar, Maria trata a falha a partir da Bronze: reexecutar só a Gold não traria dado novo. Falha a montante é falha do dia.
Erros comuns
| Sintoma | Causa provável | Próxima ação |
|---|---|---|
| Silver/Gold "não executada" sem erro próprio | Bloqueio por dependência: a origem falhou nesta execução | Corrija e recupere a partir da Bronze |
| Dependência declarada "não existe" na execução | Referência pelo nome de origem em vez da tabela de destino | Declare pela tabela de destino |
| Dois destinos, um apelido só | clientes.csv e clientes.json geram o mesmo apelido | Dê destinos distintos (tb_clientes_crm, tb_clientes_erp) |
| Publicação recusada | depende de "X", que não existe ou ciclo no grafo | Corrija a declaração; não invente dependência para avançar |
| Reexecutei e duplicou linhas | Recuperou pelo pipeline inteiro quando só o ramo falhou | Use o escopo mínimo e leia a prévia (aula 4) |
| Confundi pausar com executar | Pausar não religa um ramo bloqueado | Bloqueio por dependência se resolve corrigindo a montante (aula 1) |
| Log não bate com o erro | Lido o log da tarefa bloqueada em vez do da tarefa que falhou | A causa está na origem, não na tarefa bloqueada (aula 2) |
Estado do produto
A porta de dependência e a resolução de nomes são puras e isomórficas: o mesmo código roda nos dois executores e é testável sem nuvem e sem banco — o teste chama a mesma função que a produção executa, não uma reimplementação paralela. O teto da plataforma segue Preview: a execução real em nuvem é NÃO MEDIDO, sem SLA. Declarar dependências e ler o grafo custa R$ 0.
Faça você mesmo#
No workspace de treino Aurora Varejo (abra /dags no console), como dono. Meta: uma Gold que depende de duas Silver.
- Em
/sources/[id], abra um pipeline de treino com pelo menos duas extrações Bronze e duas transformações Silver. - Crie (ou edite) uma transformação Gold que leia as duas Silver e declare as duas dependências pela tabela de destino.
- Vá até a Revisão e leia a linha
… depende de: …. Confirme que as duas origens aparecem. - Teste a recusa de propósito: troque uma dependência por um nome que não existe na definição e confirme que o produto impede publicar, dizendo qual referência é inválida. Desfaça.
- Publique e execute. Na aba Grafo da execução, confirme que a Gold só começa depois das duas Silver.
- Provoque uma falha numa das Bronzes (credencial inválida, ou coluna inexistente) e execute de novo.
- Na Grade, confirme que a Silver daquele ramo e a Gold ficaram não executadas, com o motivo citando a origem falhada — e que o outro ramo rodou normalmente.
- Corrija a origem e recupere a partir da Bronze (aula 4), conferindo a contagem no destino.
Você terminou quando a Gold tiver duas dependências declaradas e visíveis na revisão, você tiver visto o bloqueio por dependência com o motivo na tela, e conseguir explicar por que reexecutar só a Gold não resolveria.
Checagem rápida#
Três perguntas no final da aula, corrigidas no servidor. A aula só conta como concluída depois da checagem.
Documentação relacionada#
Capacidades ensinadas#
(conceitual — sem capacidade específica da matriz) — o selo exibido na aula é sempre o estado mais conservador entre as capacidades citadas; nada aqui é "GA".