É exatamente para estruturar esse fluxo que existem frameworks arquiteturais como o Medallion (Bronze, Silver, Gold) e o modelo SOR, SOT, SPEC. Na prática, ambos descrevem a mesma jornada de amadurecimento do dado, mas com origens e focos ligeiramente diferentes.

A Arquitetura Medallion (Bronze, Silver, Gold)

O conceito foi introduzido pela equipe da Databricks (liderada por nomes como Ali Ghodsi, CEO e cofundador) por volta de 2020 junto com o conceito de Data Lakehouse, a arquitetura Medallion foca no estado de qualidade e refinamento dos arquivos e tabelas dentro de um pipeline de Big Data.

A analogia é simples: o dado entra bruto e vai sendo “lapidado” até virar ouro.

Camada Bronze (Raw / Bruta): É a zona de aterrissagem. Os dados chegam aqui exatamente no mesmo formato dos sistemas de origem (APIs, ERPs, CRMs, logs), sem nenhuma alteração.

Objetivo: Manter o histórico imutável. Se houver um erro no processamento futuro, você sempre pode voltar à camada Bronze e reprocessar o dado original.

Camada Silver (Cleansed / Conformed): É onde a faxina acontece. Os dados da Bronze são lidos, filtrados, padronizados (ex: transformar todas as datas para o formato YYYY-MM-DD), desduplicados e têm seus tipos de dados corrigidos.

Objetivo: Criar uma base de dados limpa, integrada e confiável que representa a operação da empresa, pronta para exploração por analistas e cientistas de dados.

Camada Gold (Curated / Aggregated): É a camada de negócio. Aqui, os dados da Silver são agregados, somados e cruzados para responder a perguntas específicas (ex: “Total de vendas por região por mês”).

Objetivo: Entregar dados altamente otimizados e prontos para consumo por ferramentas de BI (Tableau, Power BI, Metabase) ou modelos de Machine Learning.

O Modelo SOR, SOT e SPEC

Enquanto o Medallion nasceu no mundo do Big Data e processamento em nuvem, a nomenclatura SOR, SOT e SPEC tem raízes mais profundas na Governança de Dados clássica e em arquiteturas de Data Warehousing (como as de Ralph Kimball e Bill Inmon). O termo ganhou força com Bill Inmon (conhecido como o “Pai do Data Warehouse. O foco aqui é a confiabilidade e o propósito do dado.

SOR (System of Record – Sistema de Registro): É a origem do dado. Em arquitetura de dados, representa a camada onde a informação é armazenada de forma bruta e fidedigna ao sistema transacional que a gerou.

Equivalência: É a representação lógica da camada Bronze.

SOT (Source of Truth / Single Source of Truth – Fonte Única da Verdade): É o coração da governança. É a camada onde as discrepâncias entre diferentes sistemas foram resolvidas. Se o sistema de Vendas diz que o cliente é “João S.” e o sistema de Entregas diz “João Silva”, a SOT resolve esse conflito e consolida o dado oficial da empresa.

Equivalência: É a representação lógica da camada Silver.

SPEC (Specific / System of Engagement – Específico): São as visões de dados criadas para propósitos específicos de um departamento ou caso de uso. O RH não quer ver a base inteira da empresa; ele quer um conjunto de dados focado em métricas de contratação e turnover (um Data Mart).

Equivalência: É a representação lógica da camada Gold.

Qual a diferença real entre eles?

A diferença não está na tecnologia ou no fluxo (ambos usam pipelines de extração, limpeza e agregação), mas sim na filosofia e no vocabulário adotado pela equipe.

Na prática das empresas modernas, esses termos frequentemente se misturam. Um Arquiteto de Dados pode perfeitamente desenhar um pipeline dizendo: “Vamos usar a camada Silver do nosso Data Lake como a nossa Source of Truth (SOT) corporativa”.

Se você abrir o banco de dados de uma empresa madura, a tabela que o engenheiro chama de “Silver” é a exata mesma tabela que o time de governança chama de “SOT” (Source of Truth).

A diferença não está na tecnologia ou no fluxo dos dados. A diferença está na perspectiva de quem está olhando e no vocabulário usado para resolver problemas diferentes.

Pense nisso como duas “lentes” para olhar o mesmo funil de dados: a lente da Engenharia e a lente do Negócio/Governança.

Lente 1: Medallion (A Visão da Engenharia)

O Medallion (Bronze, Silver, Gold) foca no estado de processamento e qualidade do dado. É o vocabulário de quem “põe a mão na massa” (Engenheiros de Dados, Arquitetos Cloud).

• A pergunta que ele responde: “O quanto de código, limpeza e transformação nós já rodamos nesse dado?”
• Na prática: Você usa esses termos em reuniões técnicas.
  • Exemplo: “A pipeline deu erro porque o arquivo JSON que chegou na Bronze veio corrompido, então o script do Spark não conseguiu limpar e jogar para a Silver.”

Lente 2: SOR, SOT, SPEC (A Visão do Negócio e Governança)

O SOR/SOT/SPEC foca na confiabilidade, auditoria e autoridade do dado. É o vocabulário de quem consome o dado e toma decisões de negócio (Diretores, Analistas de Negócio, Auditores, Data Stewards).

• A pergunta que ele responde: “Eu posso confiar nesse número para apresentar para o conselho diretivo? Quem é o dono dessa informação?”
• Na prática: Você usa esses termos em reuniões de alinhamento estratégico ou resolução de conflitos.
  • Exemplo: “O dashboard de Vendas e o de Finanças estão mostrando faturamentos diferentes. Precisamos definir que a tabela X do Data Warehouse será a nossa SOT (Fonte Única da Verdade) para o faturamento global da empresa.”

Quando usar um vocabulário no lugar do outro?

Aqui está a regra de ouro para o seu dia a dia profissional: Você não escolhe um modelo em detrimento do outro, você os usa simultaneamente dependendo com quem está falando.

Veja como os dois mundos se mapeiam perfeitamente na mesma infraestrutura:

Resumo:

• Você fala Bronze, Silver e Gold quando está discutindo com outro desenvolvedor sobre como o código vai transformar o arquivo.
• Você fala SOR, SOT e SPEC quando o Diretor pergunta: “De onde veio esse número e por que eu deveria confiar nele?”.

O post Arquitetura Medallion (Bronze, Silver, Gold) x Modelo SOR, SOT e SPEC apareceu primeiro em Data Universe.

• Concorrência é sobre a composição de processos independentes (lidar com múltiplas coisas ao mesmo tempo).
• Paralelismo é sobre a execução simultânea (fazer múltiplas coisas ao mesmo tempo). Um sistema pode ser concorrente sem ser paralelo (ex: um único núcleo de CPU alternando tarefas), mas o paralelismo real exige hardware capaz de multitarefa simultânea.

Concorrência e Paralelismo sob diferentes óticas

Sob a Ótica da Engenharia de Software

Na programação de aplicações, a Concorrência resolve problemas de latência e responsividade. Ocorre quando duas ou mais tarefas podem iniciar, rodar e completar em períodos de tempo sobrepostos.

O sistema operacional utiliza o Context Switching (troca de contexto) para alternar o uso da CPU entre tarefas, criando a ilusão de simultaneidade.

O Paralelismo ocorre quando tarefas são literalmente executadas no mesmo instante físico, exigindo arquiteturas Multi-Core.

Sob a Ótica da Engenharia de Dados

Na Engenharia de Dados, a escala muda de uma única máquina para clusters distribuídos.

• Concorrência em Dados: Refere-se à capacidade de um orquestrador (como o Airflow) gerenciar centenas de DAGs (Directed Acyclic Graphs) ativos. O scheduler decide qual task deve ser enviada para a fila, lidando com dependências e prioridades, mesmo que não haja slots suficientes para rodar tudo instantaneamente.
• Paralelismo em Dados: Refere-se ao processamento distribuído (ex: Apache Spark ou Databricks). Um arquivo de 1TB é dividido em 1000 partições. 1000 núcleos de CPU (espalhados por vários nós) processam essas partições exatamente ao mesmo tempo. É a base do paradigma MPP (Massively Parallel Processing).

Qual a sua importância?

A aplicação correta destes conceitos não é apenas uma questão de velocidade, mas de robustez sistêmica e eficiência econômica.

Tolerância a Falhas e Isolamento

Sistemas concorrentes bem projetados isolam falhas. Se você processa 1 milhão de registros em um único loop sequencial e o registro 999.000 falha, todo o processo para.

Ao utilizar concorrência, cada “worker” opera de forma independente. Se um falha, apenas aquela unidade de trabalho é perdida ou reprocessada (retry), sem derrubar todo o pipeline.

Consistência de Dados

Em ambientes concorrentes, múltiplos processos podem tentar ler ou escrever o mesmo dado (Race Condition). Mecanismos de controle de concorrência (como Locks, semáforos ou controle via MVCC – Multiversion Concurrency Control em bancos de dados) garantem que transações financeiras ou atualizações de estoque mantenham as propriedades ACID, impedindo corrupção de dados.

Redução de Custos Operacionais

• Recursos Ociosos: Processos sequenciais frequentemente deixam CPU ociosa enquanto esperam I/O (leitura de disco/rede). A concorrência preenche esses vazios com outras tarefas, maximizando o uso do hardware alugado na nuvem.
• Tempo de Cluster: O paralelismo reduz o tempo total de execução (wall-clock time). Em nuvem, onde você paga por “segundo de cluster ligado”, reduzir um job de 10 horas para 1 hora (usando 10x mais máquinas) custa teoricamente o mesmo, mas entrega valor ao negócio muito mais rápido.

Exemplo Prático Real (Engenharia de Dados)

Cenário: Uma empresa de logística recebe telemetria de 50.000 caminhões a cada 30 segundos. O objetivo é ingerir, limpar e armazenar esses dados no Data Lake.

Principais Métodos de Implementação

Analise a tabela abaixo para compreender as diferenças de implementação técnica:

Exemplo de Código: Threading vs Multiprocessing (Python)

import time
import threading
import multiprocessing

# Simulação de tarefa I/O Bound (Ex: Request API)
def task_io():
    time.sleep(1)

# Simulação de tarefa CPU Bound (Ex: Cálculo Hash)
def task_cpu():
    sum([i**2 for i in range(10**6)])

# Implemente Threading para I/O (Concorrência)
# Útil para quando o gargalo é esperar resposta externa
t1 = threading.Thread(target=task_io)
t2 = threading.Thread(target=task_io)
t1.start(); t2.start() # Iniciam "juntas"

# Implemente Multiprocessing para CPU (Paralelismo Real)
# Útil para cálculos pesados que travam a CPU
p1 = multiprocessing.Process(target=task_cpu)
p2 = multiprocessing.Process(target=task_cpu)
p1.start(); p2.start() # Rodam em núcleos diferentes

import time
import threading
import multiprocessing

# Simulação de tarefa I/O Bound (Ex: Request API)
def task_io():
    time.sleep(1)

# Simulação de tarefa CPU Bound (Ex: Cálculo Hash)
def task_cpu():
    sum([i**2 for i in range(10**6)])

# Implemente Threading para I/O (Concorrência)
# Útil para quando o gargalo é esperar resposta externa
t1 = threading.Thread(target=task_io)
t2 = threading.Thread(target=task_io)
t1.start(); t2.start() # Iniciam "juntas"

# Implemente Multiprocessing para CPU (Paralelismo Real)
# Útil para cálculos pesados que travam a CPU
p1 = multiprocessing.Process(target=task_cpu)
p2 = multiprocessing.Process(target=task_cpu)
p1.start(); p2.start() # Rodam em núcleos diferentes

Desafios e Considerações

1. Race Conditions (Condições de Corrida): Ocorrem quando a saída depende da sequência ou tempo de outros eventos incontroláveis. Em ETLs, isso gera dados duplicados ou inconsistentes.
2. Deadlocks: O Processo A espera o recurso do Processo B, e o Processo B espera o recurso do Processo A. O sistema trava indefinidamente.
3. Complexidade de Debug: Erros em sistemas paralelos são frequentemente não-determinísticos. Um bug pode aparecer apenas 1 vez a cada 100 execuções (“Heisenbugs”), dificultando a reprodução.

Melhores Práticas

Siga estas 5 diretrizes para mitigar riscos ao implementar concorrência e paralelismo:

1. Arquitetura “Shared Nothing” (Nada Compartilhado): Projete tarefas que não compartilhem estado (memória ou variáveis globais). Cada worker deve receber seus dados, processar e salvar o resultado sem precisar “conversar” com outros workers. Isso elimina Locks complexos.
2. Idempotência é Obrigatória: Garanta que, se uma tarefa paralela falhar e for reexecutada (concorrência), o resultado final seja o mesmo. Use chaves primárias ou upserts ao invés de append cego.
3. Prefira Imutabilidade: Dados imutáveis não sofrem de Race Conditions porque não são alterados, apenas lidos. Crie novas tabelas/arquivos ao invés de atualizar os existentes (Write-Once-Read-Many).
4. Use Ferramentas de Alto Nível: Evite gerenciar threads e locks manualmente em Python se possível. Utilize frameworks que abstraem essa complexidade, como Apache Spark ou Dask, que gerenciam a distribuição e tolerância a falhas nativamente.
5. Particionamento Inteligente: O paralelismo só funciona se os dados puderem ser divididos uniformemente (evite Data Skew). Garanta que suas chaves de partição distribuam o volume de dados de forma equilibrada entre os nós.

O post Concorrência e Paralelismo apareceu primeiro em Data Universe.

Imagine que você está em um elevador e aperta o botão do 5º andar. Se você apertar esse mesmo botão dez vezes seguidas, o elevador ainda te levará para o 5º andar, certo? Ele não vai somar os cliques e te levar para o 50º andar.

Isso é idempotência. No mundo da Engenharia de Dados, esse conceito é um dos pilares para construir sistemas confiáveis e à prova de falhas.

O que é Idempotência? (Definição e Óticas)

Em resumo: Idempotência é a propriedade de poder realizar a mesma ação várias vezes e obter o mesmo resultado que se tivesse realizado apenas uma vez.

A. Ótica da Engenharia de Software (APIs)

Imagine um botão de “Chamar Elevador”. Você pode apertá-lo uma vez ou vinte vezes seguidas impacientemente. O sistema entende: “O elevador foi chamado”. Ele não manda 20 elevadores para o seu andar.

Em APIs REST:

• POST geralmente não é idempotente (cria um novo recurso a cada chamada).
• PUT e DELETE devem ser idempotentes (se eu deletar o usuário ID 10 duas vezes, na segunda vez o resultado final é o mesmo: o usuário não existe).

B. Ótica da Engenharia de Dados

Aqui é onde o jogo muda. Idempotência em pipelines de dados significa que você pode reprocessar um arquivo, uma mensagem ou um lote de dados inteiro sem gerar duplicidade no destino final.

Se o seu script Python falhar na metade e você rodá-lo de novo:

• Pipeline Não-Idempotente: Você terá metade dos dados duplicados no banco.
• Pipeline Idempotente: O sistema detecta o que já foi processado, atualiza o que mudou ou simplesmente sobrescreve o destino de forma segura, garantindo integridade.

Qual a sua importância?

Por que devemos exigir idempotência idealmente em todos os projetos de dados?

1. Tolerância a Falhas (Fault Tolerance): Redes caem. Servidores reiniciam. Em um sistema distribuído, a estratégia padrão de recuperação é o Retry (tentar novamente). Se o seu processo não for idempotente, você não pode usar retries automáticos sem corromper o banco.
2. Consistência de Dados: Garante a semântica de Exactly-Once (Exatamente uma vez). O analista de BI ou o Cientista de Dados na ponta final confiará que o número de vendas é real, e não inflado por reprocessamentos.
3. Redução de Custos Operacionais: Imagine o custo de horas de engenharia para escrever scripts de “limpeza” (Deduplication) toda vez que um job falhar. Com a idempotência, a recuperação é apenas “rodar o job de novo”.

Exemplo Prático Real (Engenharia de Dados)

Cenário: O E-commerce “TechVendas”

Você é responsável por ingerir as vendas do dia anterior no Data Warehouse para o relatório financeiro.

• Input: Arquivo vendas_2023-10-27.csv com 1 milhão de linhas.
• O Evento: O job começa a rodar às 03:00 AM. Ele insere 500.000 linhas no banco de dados. Às 03:15 AM, a conexão cai e o script quebra.

Principais Métodos de Implementação

Como você escreve isso no código? Aqui estão as três abordagens clássicas:

1. DELETE-WRITE (Sobrescrita de Partição)

É a abordagem mais simples e robusta para processamento em lote (Batch).

Lógica: Antes de escrever, apague tudo que existe para aquele período/partição específica.

Exemplo SQL:

-- Passo 1: Limpa a "mesa" para o dia específico
DELETE FROM tabela_vendas WHERE data_venda = '2023-10-27';

-- Passo 2: Escreve os dados novos limpos
INSERT INTO tabela_vendas SELECT * FROM arquivo_staging;

-- Passo 1: Limpa a "mesa" para o dia específico
DELETE FROM tabela_vendas WHERE data_venda = '2023-10-27';

-- Passo 2: Escreve os dados novos limpos
INSERT INTO tabela_vendas SELECT * FROM arquivo_staging;

2. UPSERT (Merge)

Ideal quando você não pode apagar dados (ex: atualizações de status de pedidos). O banco verifica linha a linha.

Lógica: Se a chave (ID) existe -> Atualiza (Update). Se não existe -> Insere (Insert).

Exemplo (Conceitual Python/Pandas):

# Não faça append cego!
# Lógica de Merge pseudo-código
for row in dataframe:
    if database.exists(row.id):
        database.update(row)
    else:
        database.insert(row)

# Não faça append cego!
# Lógica de Merge pseudo-código
for row in dataframe:
    if database.exists(row.id):
        database.update(row)
    else:
        database.insert(row)

3. Tabela de Controle (Watermarking)

Você mantém uma tabela auxiliar que registra quais arquivos já foram processados.

• Lógica: O script verifica: “O arquivo X já foi processado com sucesso?”. Se sim, pula. Se não, processa e marca como concluído no final.

Desafios e Considerações

Nem tudo são flores. Implementar idempotência tem um custo:

Performance (Overhead):

• Fazer um INSERT direto (append) é extremamente rápido.
• Fazer um UPSERT exige que o banco leia o índice para ver se o ID existe antes de escrever. Isso é mais lento e consome mais CPU.

Complexidade de Design:

Você precisa definir muito bem suas Chaves Primárias (Primary Keys). Se seus dados não tiverem um ID único confiável, a idempotência fica quase impossível.

Janelas de Tempo (Late Arriving Data):

No método Delete-Write, se chegar um dado atrasado de 3 dias atrás, você precisa reprocessar a partição daquele dia antigo, não a de hoje.

Melhores Práticas (Diretrizes de Ouro)

• Defina uma Chave Única (Natural Key): Nunca confie apenas em IDs gerados automaticamente pelo banco (auto-increment). Tente usar algo do negócio (ex: NumeroPedido ou uma combinação Data + ID_Cliente + SKU).

• Particionamento é Vida: Sempre que possível, trabalhe com partições (por data é o mais comum). É muito mais barato apagar e reescrever uma partição de um dia (DELETE WHERE date = X) do que fazer Upsert na tabela inteira.

• Imutabilidade na Origem: Nunca modifique o arquivo bruto (Raw Data). Se precisar reprocessar, a fonte original deve estar intocada.

• Use Transações (Atomocidade): Em bancos relacionais, envolva suas operações de limpeza e escrita em uma transação. Se a escrita falhar, o DELETE inicial é desfeito (rollback), evitando que você perca dados se o script quebrar no meio.

• Teste a Falha: Não teste apenas o “Caminho Feliz”. Force o erro no meio do script e rode de novo. Se duplicar dados no ambiente de desenvolvimento, seu design falhou.

O post Idempotência apareceu primeiro em Data Universe.