Regras de qualidade, deduplicação, rejeitados

Selo de estado: Preview (teto atual do produto) · Curso ACD-220 — Pipelines e medalhão Bronze/Silver/Gold · Aula 7 de 12 · Atualizado em 2026-10-04.

Objetivo#

Ao final desta aula você vai criar validação e ler rejeitados — decidir o que corrigir e o que descartar na passagem Bronze → Silver, e medir a perda em número, não em sensação.

Vídeo#

Identificador no manifesto: acd-220-07-silver-qualidade-dedup · duração-alvo 8 min · tela do produto: /sources.

Roteiro de gravação (5 capítulos):

Conteúdo#

Corrigir ou descartar: os sete tipos de regra

A validação de qualidade é o conjunto de regras aplicadas linha a linha na passagem Bronze → Silver. Cada tipo tem um efeito previsível:

Um detalhe que salva horas em dado brasileiro: o parse de preço aceita os dois formatos — 1.299,90 (BR) e 199.90 (US). Antes de culpar a regra, confira se o problema não é outro: separador decimal costuma estar certo.

Como isso se monta na tela

Na etapa Transformações, cada tabela Silver é montada num builder visual com tabela base, cruzamentos, colunas (com conversão de tipo e formato), coluna calculada e filtro — e prévia do SQL ao vivo. Há dois modos: Guiado (didático, campo a campo) e Avançado (SQL livre), e a lógica em código que o editor visual não representa não é apagada por você passar pela etapa.

As regras duras viram filtro (valor > 0, status <> 'cancelado'); as normalizações e derivações viram colunas com conversão e expressão calculada. A aula 8 detalha os passos pt-BR que compõem essas regras.

Deduplicação: três escolhas, não uma

Ligar a deduplicação exige responder três coisas, e cada uma muda o resultado:

1. Chave de duplicidade — quais colunas definem "a mesma linha" (a chave de negócio real, não o id técnico que a origem renumera).
2. Coluna de ordenação — qual campo decide a disputa (atualizado_em, _ingestao_em).
3. Direção — crescente ou decrescente, isto é: mantém o primeiro ou o último.

Na implementação de referência, a dedupe de vendas é por pedido_id mantendo a primeira ocorrência. Isso torna a Silver idempotente por chave mesmo que a origem mande a mesma linha duas vezes. Nas transformações declaradas por você, a escolha de manter: primeiro | último com uma coluna de desempate é explícita — e é ela que define se você fica com o cadastro antigo ou com a correção mais recente.

"Quarentena": o que existe de verdade

Aqui vale honestidade, porque o nome circula no mercado: não existe hoje uma tabela de quarentena separada para linhas reprovadas na Silver, com fluxo de correção e reenvio por linha. O que existe cumpre o mesmo papel em três peças:

1. Bronze verbatim guarda todas as linhas cruas — a retenção do que chegou;
2. o contador de rejeitadas torna a perda mensurável a cada execução;
3. o saneamento automático da carga preserva a linha problemática em vez de inventar dado (linha não-parseável é mantida como está).

Você não perde o dado rejeitado e sabe quanto rejeitou — mas não espere uma fila de correção por linha. E não confunda com a DLQ: ela é para execuções (jobs) que falham, não para linhas de dado.

Exemplo: a Comércio Aurora

Maria recebe sete linhas no Bronze de vendas:

pedido_id;data_pedido;uf;categoria;preco_unitario;quantidade;status
P-1001;2026-01-03;SP;Bebidas;12,90;3;pago
P-1001;2026-01-03;SP;Bebidas;12,90;3;pago     # duplicata → descarta a 2ª
P-1002;2026/01/03;RJ;Limpeza;29,90;1;pago     # data inválida → descarta
P-1003;2026-01-04;Minas;Bebidas;12,90;2;pago  # UF inválida → descarta
P-1004;2026-01-04;MG;;0;1;pago                # preço 0 → descarta
P-1005;2026-01-05;MG;;12,90;2;cancelado       # cancelado → descarta
P-1006;2026-01-05;SP;;12,90;2;pago            # categoria vazia → "Sem categoria" (mantém)

Resultado: 7 na Bronze, 2 na Silver (P-1001 na primeira ocorrência e P-1006 com categoria preenchida e receita = 25,80), 5 rejeitadas. Maria vê exatamente isso no registro de execução — e quando o contador salta de 5 para 400 na semana seguinte, ela sabe que algo mudou na origem antes de qualquer painel mostrar número errado.

Erros comuns

Faça você mesmo#

No workspace de treino Aurora Varejo, em vendas, com as sete linhas sintéticas do exemplo acima.

1. Carregue as sete linhas na Bronze (importe o CSV com delimitador ;) e confirme no Console de dados que a Bronze tem 7 linhas.
2. Em /sources, na etapa Transformações, crie a tabela Silver de vendas a partir da Bronze.
3. Acrescente o filtro valor > 0 (ou preco_unitario > 0, conforme o nome da sua coluna) e leia a prévia do SQL para ver onde ele entrou.
4. Acrescente a regra de domínio que descarta status = cancelado e a derivação receita = preco_unitario × quantidade.
5. Ligue a deduplicação: chave pedido_id, coluna de ordenação _ingestao_em, mantendo a primeira ocorrência.
6. Publique, rode a trilha completa e abra o registro da execução: anote Bronze, Silver e rejeitadas.
7. Confirme a conta rejeitadas = Bronze − Silver e identifique, olhando o cru na Bronze, qual regra reprovou cada linha descartada.
8. Mude a direção da dedupe para manter o último e rode de novo: observe se o contador muda e explique por quê.

Você terminou quando a Silver tem só as linhas válidas e sem duplicata, o contador de rejeitadas fecha a conta com a Bronze, e você consegue apontar a regra responsável por cada linha que ficou de fora.

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#

• data/tutoriais/criar-validacao-qualidade
• data/conceitos-qualidade-e-quarentena
• data/tutoriais/tratar-falha-dlq

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".