1. Características dos Dados na Camada Silver¶

Os dados processados e armazenados nesta camada devem ser: * Limpos e Padronizados: É aqui que ocorre a conversão correta de tipos de dados (casting, como transformar um texto em DATE ou BIGINT), o tratamento de valores nulos (ex: COALESCE), a padronização de strings (TRIM, LOWER) e a correção de encodings. * Validados (Data Quality): Aplicação de regras de negócio para garantir a qualidade, como a desduplicação de registros (geralmente usando funções de janela como ROW_NUMBER()). * Orientados a Assunto: Em vez de manter um espelho de dezenas de tabelas de um sistema legado, os dados são consolidados em assuntos centrais do negócio, como "Clientes", "Produtos" ou "Vendas". * Integrados: Tabelas que fazem sentido juntas na origem são unidas nesta fase (exemplo: unir pedidos com itens_pedido).

2. Modelagem de Dados (Dimensões Conformadas)¶

Um erro de arquitetura muito comum é tentar criar um "tabelão" (uma tabela altamente desnormalizada com tudo misturado) logo na camada Silver. O "tabelão" é papel exclusivo da camada Gold.

Em vez disso, a Silver utiliza uma abordagem de "baixa normalização" para criar o que chamamos de Dimensões Conformadas. A modelagem segue um Esquema Estrela Lógico (Logical Star Schema), onde você cria tabelas de fatos (fato_) e dimensões (dim_) separadas, limpas e bem integradas.

Por que não fazer um tabelão na Silver? A Silver precisa ser flexível para atender a múltiplos propósitos. O time de BI pode querer cruzar Vendas com Clientes, enquanto o time de Finanças pode querer cruzar Vendas com Pagamentos. Manter as entidades separadas e limpas garante reuso e facilita muito a manutenção.

3. Tratamento de Exceções e Datas Inválidas¶

A camada Bronze apenas armazena os dados "como vieram", mesmo com sujeira. É a Silver a responsável por corrigir anomalias, como datas de nascimento em 1890, datas no futuro ou registros criados antes do início do negócio. Você deve aplicar regras explícitas que definam a ação corretiva: transformar o valor em NULL, truncar para um limite válido, ou isolar os registros problemáticos em uma zona de quarentena (ex: silver/_quarantine/...). É recomendável também gerar métricas e flags de qualidade de dados (DQ) para rastreabilidade.

4. Nomenclatura Focada no Negócio¶

Enquanto a nomenclatura na camada Bronze foca no sistema de origem (ex: bronze_mysql_ecommerce_customers), a camada Silver deve ser focada no Domínio de Negócio, pois os analistas pensam em termos de entidades, e não de sistemas fontes. O padrão recomendado é: silver_<domínio_negócio>_<tipo_objeto>_<entidade_negócio>. * Exemplo para dimensões: silver_clientes_d_clientes (ou dim_cliente). * Exemplo para fatos: silver_vendas_f_pedidos.

5. Particionamento Inteligente¶

Se na camada Bronze o particionamento pode adotar a data de ingestão operacional, na camada Silver você deve particionar pelas datas de negócio (ex: data_atendimento, data_pedido ou ano_nascimento). Se as buscas por idade forem frequentes em ferramentas de BI, particionar a tabela Silver auxiliar pelo ano de nascimento tornará a consulta incrivelmente rápida e eficiente.

6. Implementação Técnica¶

Na prática, o fluxo de construção da Silver envolve: 1. Ler os dados (geralmente em formato Parquet) da camada Bronze no Google Cloud Storage (GCS). 2. Processá-los usando ferramentas como Polars, Spark, ou SQL diretamente no BigQuery via External Tables. 3. Salvar os resultados limpos e agregados de volta no GCS em novos arquivos Parquet particionados, que depois são catalogados como tabelas externas da camada Silver para consumo.