Estágio 3 — Bronze → Silver Técnica

Objetivo da camada

A etapa Bronze → Silver Técnica transforma o histórico bruto padronizado em uma camada limpa, tipada, deduplicada, validada e tecnicamente confiável.

A Bronze preserva o que chegou.A Silver Técnica organiza o que pode ser usado com segurança técnica.

A regra principal desta camada é:

A Silver Técnica é a primeira camada confiável para consumo interno refinado, mas ainda não é obrigatoriamente a camada final de negócio.

1. Definição do estágio

O que

Transformar dados brutos padronizados em dados tecnicamente tratados, limpos e confiáveis.

Quando

Depois que o lote Bronze foi processado com sucesso:

status = BRONZE_PROCESSED

Onde

Na camada:

silver_tecnica.<dominio>.<entidade>

ou, de forma genérica:

silver_technical.<domain>.<entity>

Como

Com tipagem, padronização, deduplicação, normalização, validações técnicas, contratos de dados, controle de schema, qualidade técnica e quarentena.

2. Papel da Silver Técnica na arquitetura

A Silver Técnica deve ser a camada onde o dado deixa de ser apenas bruto e passa a ter confiabilidade técnica.

Ela responde:

• os tipos de dados estão corretos?

• as datas foram interpretadas corretamente?

• os nomes de colunas estão padronizados?

• os registros duplicados técnicos foram tratados?

• os campos obrigatórios técnicos existem?

• os dados fora do contrato foram bloqueados?

• o schema está compatível?

• os metadados foram preservados?

• o lote pode avançar para a Silver Analítica?

A Silver Técnica ainda não precisa resolver todas as regras de negócio. O foco é garantir que o dado está tecnicamente usável e consistente.

3. Entrada da Silver Técnica

A entrada principal vem da Bronze.

Critérios mínimos:

status = BRONZE_PROCESSED
bronze_table existe
manifesto vinculado
schema_hash registrado
record_count bronze registrado
metadados técnicos disponíveis

Entradas válidas:

• registros Bronze append-only;

• arquivos/tabelas Bronze padronizados;

• metadados de ingestão;

• contratos técnicos da entidade;

• schema snapshot;

• manifesto da carga;

• lote aprovado para transformação técnica.

Entradas bloqueadas:

• lote sem manifesto;

• Bronze sem metadados mínimos;

• schema incompatível;

• origem desconhecida;

• record_count divergente;

• dados sem batch_id;

• lote já processado sem permissão de reprocessamento.

4. Transformações permitidas na Silver Técnica

Aqui já podemos aplicar transformações técnicas mais fortes.

Permitido

• renomear colunas para padrão técnico;

• converter tipos de dados;

• tratar encoding;

• padronizar datas;

• padronizar números e decimais;

• normalizar strings;

• remover caracteres inválidos;

• aplicar deduplicação técnica;

• tratar nulos técnicos;

• criar hashes técnicos;

• aplicar chave técnica quando necessário;

• validar schema;

• validar contrato;

• separar registros inválidos;

• preservar rastreabilidade com a Bronze.

Não recomendado ainda

• criar KPI final;

• agregar indicadores de negócio;

• criar estrela dimensional final;

• aplicar regra analítica complexa;

• misturar muitos domínios sem critério;

• gerar camada de consumo final;

• descartar registros sem rastreabilidade.

5. Padronização técnica

A Silver Técnica deve aplicar um padrão consistente de nomenclatura, tipos e metadados.

Exemplos de padronização

Nomes de colunas

Data de Cadastro     → data_cadastro
CPF/CNPJ             → cpf_cnpj
Valor da Parcela     → valor_parcela
Código Cliente       → codigo_cliente

Tipos

string → date
string → timestamp
string → decimal
string → boolean
string → integer

Valores textuais

"  ATIVO " → "ATIVO"
"ativo"   → "ATIVO"
"Ativo"   → "ATIVO"

Datas

"2026-07-10 00:00:00" → date/timestamp
"10/07/2026"          → date

6. Deduplicação técnica

A Silver Técnica deve remover duplicidades técnicas, não necessariamente duplicidades de negócio.

Duplicidade técnica é quando o mesmo registro chegou repetido por problema de carga, arquivo, replay ou lote.

Critérios comuns:

source_system
entity
business_key técnica
source_file_hash
batch_id
updated_at
_metadata_ingestion_at

Estratégia recomendada:

Last Record Wins técnico

Exemplo lógico:

particionar por chave técnica
ordenar por data_atualizacao desc, ingestion_at desc, batch_id desc
manter row_number = 1

O importante é que a regra seja explícita, documentada e reprodutível.

7. Contratos da Silver Técnica

Cada entidade deve ter um contrato técnico.

Exemplo conceitual:

domain: financeiro
entity: clientes
source_layer: bronze
target_layer: silver_tecnica

primary_key:
  - codigo_cliente

required_columns:
  - codigo_cliente
  - nome_cliente
  - data_cadastro

data_types:
  codigo_cliente: string
  nome_cliente: string
  data_cadastro: date
  valor_limite: decimal

deduplication:
  keys:
    - codigo_cliente
  order_by:
    - data_atualizacao desc
    - _metadata_ingestion_at desc

on_invalid_record: quarantine
on_schema_drift: block

Esse contrato define:

• colunas esperadas;

• tipos esperados;

• chaves técnicas;

• regras de deduplicação;

• comportamento em schema drift;

• comportamento em erro;

• destino dos registros inválidos.

8. Validações da Silver Técnica

As validações aqui são mais fortes que na Bronze.

Validações estruturais

colunas obrigatórias existem
tipos estão corretos
schema é compatível
chaves técnicas existem
metadados foram preservados

Validações de conteúdo técnico

data válida
número convertível
boolean válido
string não corrompida
campo obrigatório não nulo
hash técnico calculado

Validações de carga

record_count entrada x saída
quantidade de rejeitados
percentual de erro aceitável
lote já processado
batch_id rastreável

9. Quarentena técnica na Silver

A Silver Técnica deve mandar para quarentena registros ou lotes que não atendem às regras técnicas.

Motivos comuns:

campo obrigatório técnico ausente
tipo inválido
data inválida
decimal inválido
schema incompatível
chave técnica ausente
duplicidade técnica não resolvível
metadados ausentes
erro de transformação
percentual de rejeição acima do limite

A quarentena precisa guardar:

batch_id
source_system
domain
entity
record_original
record_normalizado_parcial
erro_detectado
campo_com_erro
regra_violada
data_processamento
status
reprocess_flag

Exemplo de status:

SILVER_TECH_QUARANTINED
SILVER_TECH_FAILED
SILVER_TECH_REPROCESS_REQUESTED
SILVER_TECH_REPROCESSED

10. Reprocessamento Bronze → Silver Técnica

O reprocessamento precisa ser controlado e idempotente.

Tipos principais:

Reprocessamento por batch

Reprocessar um batch_id específico da Bronze para Silver Técnica

Reprocessamento por entidade

Reprocessar toda uma entidade técnica

Reprocessamento por janela

Reprocessar registros de uma janela de ingestão ou atualização

Reprocessamento por regra alterada

Reprocessar porque uma regra técnica mudou

Reprocessamento de quarentena

Reprocessar registros corrigidos da quarentena técnica

Rebuild controlado

Reconstruir a Silver Técnica a partir da Bronze histórica

Esse último é importante: se a Bronze é bem construída, a Silver Técnica pode ser reconstruída.

11. Idempotência na Silver Técnica

A execução da Silver Técnica deve ser segura.

Regras práticas:

mesmo batch_id não deve gerar duplicidade
mesma chave técnica deve respeitar regra de deduplicação
reprocessamento deve registrar parent_batch_id
rebuild deve ser controlado por versão de execução

Campos úteis:

_metadata_batch_id
_metadata_parent_batch_id
_metadata_source_record_hash
_metadata_silver_hash
_metadata_transformation_version
_metadata_is_reprocess
_metadata_processed_at

12. Hashes técnicos

Na Silver Técnica, os hashes são muito úteis.

Tipos comuns:

Hash do registro bruto

Vem da Bronze:

_metadata_source_record_hash

Hash do registro tratado

Criado na Silver:

_metadata_silver_row_hash

Hash de diferença técnica

Usado para detectar mudança:

hash_diff

Em uma arquitetura bem padronizada:

SK técnica       → pode usar hash determinístico ou surrogate controlada
BK / hash_diff   → SHA-256

O importante é separar claramente:

• chave técnica;

• chave de negócio;

• hash de comparação;

• hash de rastreabilidade.

13. Escrita na Silver Técnica

A forma de escrita depende da entidade.

Para entidades snapshot ou full

Pode usar:

overwrite controlado
merge
replace por partição

Para entidades incrementais

Pode usar:

merge incremental
append + dedup
upsert técnico

Para histórico técnico

Pode usar:

SCD1 técnico
SCD2 técnico
append versionado

A escolha depende da natureza da tabela.

Regra geral:

A estratégia de escrita deve estar no contrato da entidade, não escondida no código.

14. Tipos de tabela na Silver Técnica

Tabela técnica SCD1

Mantém o estado mais recente tecnicamente válido.

Boa para:

cadastros atuais
status atual
entidades de referência simples

Tabela técnica SCD2

Mantém histórico de alterações.

Boa para:

cadastros com histórico
contratos
produtos
status evolutivo
atributos mutáveis

Tabela append tratada

Mantém eventos ou movimentos tratados.

Boa para:

transações
logs
eventos
movimentações

Tabela técnica deduplicada

Mantém uma versão única por chave técnica.

Boa para:

arquivos replicados
cargas com sobreposição
snapshots recorrentes

15. Tabela de controle Silver Técnica

Recomendo uma tabela operacional:

control_silver_technical_loads

Campos sugeridos:

silver_tech_load_id
bronze_load_id
batch_id
parent_batch_id
source_system
domain
entity
bronze_table
silver_table
load_type
write_strategy
status
record_count_bronze
record_count_silver
record_count_quarantine
schema_hash_input
schema_hash_output
transformation_version
quality_score
started_at
finished_at
duration_seconds
is_reprocess
reprocess_reason
error_message

Status possíveis:

PENDING_SILVER_TECH
SILVER_TECH_RUNNING
SILVER_TECH_PROCESSED
SILVER_TECH_FAILED
SILVER_TECH_QUARANTINED
SILVER_TECH_REPROCESS_REQUESTED
SILVER_TECH_REPROCESSED

16. Saída da Silver Técnica

A saída esperada é:

dados tipados
dados deduplicados tecnicamente
schema padronizado
metadados preservados
registros inválidos isolados
qualidade técnica registrada
status operacional atualizado
base pronta para Silver Analítica

Status final esperado:

SILVER_TECH_PROCESSED

ou, em caso de erro:

SILVER_TECH_FAILED
SILVER_TECH_QUARANTINED

17. Critérios para avançar para Silver Analítica

Só deve avançar quando:

status = SILVER_TECH_PROCESSED

Condições mínimas:

schema técnico válido
tipos convertidos
deduplicação aplicada
metadados preservados
record_count reconciliado
quarentena dentro do limite aceito
quality_score técnico aprovado
contrato técnico atendido

18. Resumo visual do estágio

BRONZE
  ↓
CONTRATO TÉCNICO
  ↓
PADRONIZAÇÃO
  ↓
TIPAGEM
  ↓
DEDUPLICAÇÃO
  ↓
VALIDAÇÕES TÉCNICAS
  ↓
QUARENTENA TÉCNICA, se necessário
  ↓
SILVER TÉCNICA
  ↓
SILVER_TECH_PROCESSED

Em caso de falha:

VALIDAÇÃO / TRANSFORMAÇÃO TÉCNICA
  ↓
QUARENTENA TÉCNICA
  ↓
CORREÇÃO
  ↓
REPROCESSAMENTO CONTROLADO
  ↓
SILVER TÉCNICA

Definição final do estágio

A camada Bronze → Silver Técnica é onde o dado passa por sua primeira grande elevação de maturidade.

Ele deixa de ser apenas histórico bruto e passa a ser:

limpo, tipado, padronizado, deduplicado, rastreável, validado tecnicamente e confiável para refinamento interno.

Essa camada é essencial porque protege a arquitetura contra um erro comum: deixar regras técnicas espalhadas em camadas analíticas ou de consumo.

A Silver Técnica centraliza o tratamento técnico e cria uma base sólida para que a Silver Analítica possa focar em regras de negócio, domínios, entidades conformadas e reutilização analítica.