Mini pipeline incremental com CTEs, deduplicacao e validacao

Quando alguem diz que “sabe SQL para ETL”, o que eu espero ver nao e uma query longa cheia de joins. O que eu espero ver e capacidade de organizar um fluxo.

Fluxo significa transformar um lote cru em uma tabela confiavel, com etapas legiveis e validações claras.

Neste artigo, vamos montar um mini pipeline incremental usando um raciocinio simples que cabe tanto em ambiente de estudo quanto em um projeto real pequeno.

O problema

Imagine uma tabela de pedidos recebida diariamente por API. O lote pode trazer:

• pedidos novos;
• pedidos antigos com status atualizado;
• registros duplicados;
• linhas com campos vazios ou categorias mal preenchidas.

O objetivo e manter uma tabela final de pedidos pronta para analise.

O desenho minimo

Vamos separar o pipeline em quatro blocos:

1. staging bruta;
2. staging tratada;
3. escrita incremental;
4. validacao pos-carga.

Esse desenho ja melhora muito a clareza do processo.

Etapa 1: staging bruta

A staging bruta recebe o lote como ele vem. Aqui, a regra e interferir o minimo possivel. O objetivo principal e manter o dado de entrada acessivel para debugar.

Exemplo de colunas:

• pedido_id
• cliente_id
• status
• valor
• updated_at
• canal

Se a fonte vier suja, voce quer conseguir voltar nela sem depender da memoria do que aconteceu.

Etapa 2: staging tratada com CTEs

Agora sim comeca o tratamento.

As CTEs ajudam a organizar cada decisao em um bloco legivel:

WITH base AS (
  SELECT
    pedido_id,
    cliente_id,
    status,
    valor,
    updated_at,
    COALESCE(canal, 'desconhecido') AS canal
  FROM staging_pedidos_bruta
),
deduplicada AS (
  SELECT *
  FROM (
    SELECT
      *,
      ROW_NUMBER() OVER (
        PARTITION BY pedido_id
        ORDER BY updated_at DESC
      ) AS rn
    FROM base
  ) t
  WHERE rn = 1
),
validada AS (
  SELECT
    pedido_id,
    cliente_id,
    status,
    valor,
    updated_at,
    canal
  FROM deduplicada
  WHERE pedido_id IS NOT NULL
)
SELECT *
FROM validada;

Repare na logica:

• base padroniza campos;
• deduplicada guarda a versao mais recente por pedido;
• validada elimina linhas sem chave.

Cada CTE responde uma pergunta especifica. Isso faz muita diferenca quando o pipeline precisa ser revisado depois.

Etapa 3: escrita incremental

Com a staging tratada pronta, voce pode aplicar a logica de UPSERT.

MERGE INTO pedidos_final AS destino
USING validada AS origem
  ON destino.pedido_id = origem.pedido_id
WHEN MATCHED THEN
  UPDATE SET
    cliente_id = origem.cliente_id,
    status = origem.status,
    valor = origem.valor,
    updated_at = origem.updated_at,
    canal = origem.canal
WHEN NOT MATCHED THEN
  INSERT (
    pedido_id,
    cliente_id,
    status,
    valor,
    updated_at,
    canal
  )
  VALUES (
    origem.pedido_id,
    origem.cliente_id,
    origem.status,
    origem.valor,
    origem.updated_at,
    origem.canal
  );

O MERGE aqui nao e o protagonista. Ele so executa a decisao que ja foi preparada nas etapas anteriores.

Etapa 4: validacao pos-carga

Esse e o bloco que muita gente pula. Nao pule.

Depois da escrita final, rode pelo menos estas checagens:

1. Duplicidade por chave

SELECT pedido_id, COUNT(*)
FROM pedidos_final
GROUP BY 1
HAVING COUNT(*) > 1;

O esperado, em uma tabela uma linha por pedido, e zero retorno.

2. Quantidade total

Veja se o volume da tabela final esta coerente com o historico e com o lote recebido.

3. Taxa de nulos em colunas criticas

Exemplo:

SELECT
  AVG(CASE WHEN cliente_id IS NULL THEN 1 ELSE 0 END) AS pct_cliente_nulo
FROM pedidos_final;

4. Metrica de controle

Some uma metrica relevante, como valor total, e compare com um intervalo esperado.

O que esse padrao ensina

Mesmo em um pipeline pequeno, voce ja pratica quase tudo o que importa:

• separar ingestao de tratamento;
• deduplicar com criterio claro;
• preservar chave e granularidade;
• escrever incrementalmente;
• validar resultado.

Isso vale mais para carreira do que decorar vinte comandos soltos.

Onde muita gente complica cedo demais

E facil achar que pipeline so fica serio quando envolve orchestration, YAML, dezenas de jobs e nomenclatura sofisticada. Nao e verdade.

Serio e o pipeline que:

• deixa claro o que uma linha representa;
• trata duplicidade antes de consolidar;
• tem regra explicita para recencia;
• valida o resultado final.

Se isso esta bem feito, voce ja esta pensando como quem constroi dado para outras pessoas usarem.

Resumo direto

Um mini pipeline incremental nao precisa ser grande para ser profissional.

Com staging, CTEs, deduplicacao, MERGE e validacao pos-carga, voce cria um fluxo pequeno, mas com mentalidade correta de ETL.

E essa mentalidade vale mais do que qualquer query impressionante sem controle.