BanVic 360 — Como foi feito (9 stacks passo a passo)

A ideia

O que é o BanVic 360?

A maioria dos cursos de dados ensina uma ferramenta e pronto. Mas no mercado real, você precisa escolher a ferramenta certa para o momento certo. Às vezes o time é pequeno e só sabe SQL. Às vezes precisa de automação. Às vezes os dados são enormes demais para um só computador.

Então criei um banco fictício chamado BanVic — o Banco Vitória — com clientes, transações, agências, propostas de crédito e dados econômicos. Em seguida, defini 8 perguntas que qualquer gestor de banco faria:

As 8 perguntas (KPIs) que todo projeto precisa responder:
Saldo por agência · Volume de transações · Status das propostas de crédito · Ranking de agências · Carteira por colaborador · Segmentação de clientes por faixa etária · Correção monetária pelo IPCA · Taxa de conversão de propostas.

Cada projeto abaixo usa um caminho diferente para chegar nas mesmas respostas. A "cola" que valida tudo é o gabarito.json — um arquivo com os números certos. Se o projeto chegar nos mesmos números, está aprovado.

3,7M

linhas na Bronze

9

projetos distintos

8/8

KPIs aprovados em cada

64

testes automáticos (dbt)

A fundação

Bronze, Silver e Gold — o mesmo caminho em 9 ferramentas

Todos os 9 projetos seguem a mesma arquitetura por baixo — chamada de arquitetura medallion. Funciona como um processo de refino de minério:

Arquitetura BanVic 360 com fontes, Bronze, Silver, Gold, Fabric e Power BI — Mapa visual do projeto completo: dados originais, sintéticos, externos, camadas medallion e entrega no Fabric/Power BI.

Bronze — os dados brutos

Os CSVs são carregados sem nenhuma modificação. São 35 tabelas com mais de 3,7 milhões de linhas. Nada foi mudado — é o dado como ele "chegou do sistema".
Silver — dados limpos

Remove duplicatas, ajusta tipos de dados (datas viram datas de verdade, valores viram números) e une os dados originais com os sintéticos. Aqui os dados ficam confiáveis.
Gold — modelo para análise

O Star Schema: tabelas de dimensão (clientes, agências, tempo, canais) + tabelas de fato (transações, contas, propostas). É daqui que saem os 8 KPIs validados.

Os 9 caminhos

Escolha um projeto para ver como funciona

PostgreSQL Window Functions CTEs Índices Star Schema

A pergunta

Até onde SQL puro consegue ir? Dá para fazer um pipeline completo — Bronze, Silver, Gold e 8 KPIs — sem usar Python, sem ferramenta extra, só o banco de dados?

A analogia

Imagina um armário gigante com gavetas bagunçadas. SQL puro é você organizando tudo na mão, com etiquetas bem feitas. Não tem robô ajudando. Mas você tem controle total — sabe onde cada item está e pode buscar em milissegundos.

Preencher as dimensões — 01_populate_dims.sql

Cria as 6 dimensões do Gold. Usa Window Functions (ROW_NUMBER OVER PARTITION BY) para pegar só o registro mais recente de cada cliente, sem duplicatas.
Preencher as tabelas fato — 02_populate_fatos.sql

Une as dimensões com os dados transacionais. Cria as 3 tabelas fato: fato_transacoes, fato_contas e fato_propostas_credito.
Criar 17 índices — 03_indices.sql

Índice é como o índice de um livro: em vez de ler o livro inteiro para achar uma palavra, você vai direto na página. O KPI 1 (saldo por agência) cai de segundos para ~5 ms no dataset completo (2,7M transações).
Calcular e validar os KPIs — 04_kpis_analyze.sql

Usa CTEs e EXPLAIN ANALYZE para calcular cada KPI e medir o tempo de resposta. O validador automático compara com o gabarito e imprime "APROVADO".

Código real — Window Function: pegar o registro mais recente de cada cliente:

WITH ranked AS (
  SELECT *,
    ROW_NUMBER() OVER (
      PARTITION BY cod_cliente   -- agrupa por cliente
      ORDER BY updated_at DESC   -- mais recente primeiro
    ) AS rn
  FROM bronze.clientes
)
INSERT INTO gold.dim_cliente
SELECT cod_cliente, nome, data_nascimento, faixa_etaria, score
FROM ranked
WHERE rn = 1;  -- só o mais recente de cada um

Resultado

8/8 KPIs aprovados. KPI 1 em ~5 ms. KPI 2/3 em ~4 s (2,7M transações).

Ponto forte

Zero dependências extras. Qualquer pessoa que sabe SQL entende e modifica.

Limitação

Sem agendamento, sem retry automático, sem testes formais de qualidade.

Python pandas SQLAlchemy PostgreSQL

A pergunta

Quando Python faz melhor do que SQL puro? O resultado final é o mesmo — mas o caminho permite coisas que SQL não consegue fazer facilmente, como calcular faixas etárias ou inspecionar os dados no meio do processo.

A analogia

Se SQL puro é organizar o armário na mão, Python é contratar um assistente que recebe ordens em português e aciona o armário por você. Você pode dar ordens mais complexas: "separa os clientes por faixa etária, calcula a média de saldo de cada grupo e manda pro banco". Em Python, isso é natural.

silver.py — 10 transformações com pandas

Lê cada tabela Bronze com pd.read_sql(), aplica limpeza (remove duplicatas, converte datas, calcula faixas etárias com pd.cut()) e salva de volta com df.to_sql(). Você pode usar df.head() para inspecionar os dados no meio do processo.
gold_dims.py e gold_fatos.py — carga dimensional

Faz df.merge() entre DataFrames para construir as chaves surrogate e popular as tabelas Gold. É como um INNER JOIN, mas em Python — você vê cada passo e pode pausar para verificar.
pipeline.py — orquestra tudo

Chama cada etapa na ordem certa. Permite rodar só uma parte com --etapa silver para debugar sem repetir o processo inteiro.

Código real — faixa etária em Python (muito mais simples do que em SQL):

# pd.cut divide os valores em faixas automaticamente
df["faixa_etaria"] = pd.cut(
    df["idade"],
    bins=[0, 24, 34, 44, 54, 64, 999],
    labels=["18-24", "25-34", "35-44", "45-54", "55-64", "65+"]
)

# Inspecione no meio do processo — impossível em SQL
print(df["faixa_etaria"].value_counts())

# Salva direto no banco
df.to_sql("clientes_clean", engine, schema="silver", if_exists="replace")

Resultado

8/8 KPIs aprovados. Código dividido em módulos testáveis separadamente.

Ponto forte

Debug fácil. Funções reutilizáveis. Integra naturalmente com Machine Learning.

Limitação

Mais lento que SQL puro para volumes muito grandes. Requer Python instalado.

Apache Hop ETL Visual Docker Pipeline .hpl Workflow .hwf

A pergunta

Quando uma ferramenta visual faz mais sentido do que escrever código? E se parte do time não é programadora, mas precisa entender e modificar o pipeline?

A analogia

Já montou algo com LEGO? No Apache Hop você faz isso na tela — pega blocos prontos ("ler CSV", "executar SQL", "salvar no banco") e conecta um no outro. O Hop cuida de executar na ordem certa. Você não precisa saber programar para entender como o pipeline funciona.

Pipelines .hpl — as transformações em blocos

Três arquivos visuais: 01_silver.hpl (12 blocos), 02_gold_dims.hpl (8 blocos), 03_gold_fatos.hpl (5 blocos). Cada bloco é um passo de transformação visível na tela do Hop.
Workflow .hwf — o maestro

00_banvic_pipeline.hwf chama os pipelines na ordem. Se qualquer bloco falhar, o workflow para e registra exatamente onde aconteceu o problema — com seta vermelha na tela.
Docker — zero instalação

Um único run.bat (Windows) ou run.sh (Linux) sobe o Hop em Docker e executa o pipeline. Não precisa instalar o Hop no computador — só o Docker.

Saída real da execução — 18 segundos do início ao fim, com log de cada etapa:

2026/06/12 13:59:37 - Starting action [01 Silver]
2026/06/12 13:59:39 - 01_silver - Pipeline duration : 1.659 seconds  ✓
2026/06/12 13:59:39 - Starting action [02 Gold Dims]
2026/06/12 13:59:49 - 02_gold_dims - Pipeline duration : 10.683 seconds  ✓
2026/06/12 13:59:50 - Starting action [03 Gold Fatos]
2026/06/12 13:59:54 - 03_gold_fatos - Pipeline duration : 4.274 seconds  ✓
2026/06/12 13:59:54 - Starting action [Sucesso]
2026/06/12 13:59:54 - Workflow duration : 18.195 seconds

Resultado

8/8 KPIs aprovados. Pipeline completo em 18 segundos.

Ponto forte

Visual, auditável. Times mistos (devs + analistas) conseguem manter.

Limitação

Transformações pesadas com Python ou ML precisam de outra ferramenta.

Docker docker-compose PostgreSQL 15 pgAdmin Healthcheck

A pergunta

Como fazer o pipeline rodar exatamente igual no meu computador, no computador do colega e num servidor na nuvem?

A analogia

Docker é uma marmita. Em vez de preparar a comida na cozinha do amigo (que tem ingredientes errados e fogão diferente), você traz a marmita de casa com tudo pronto. Em qualquer lugar que você abrir, a comida é a mesma. No Docker: em vez de comida, você empacota o banco de dados, a versão exata do sistema, as configurações — tudo junto.

docker-compose.yml — a receita da marmita

Define: PostgreSQL 15 na porta 5433 + pgAdmin na 5051. O arquivo init/01_setup.sql roda automaticamente na primeira vez — cria schemas e extensões sem nenhuma intervenção manual.
Healthcheck — dependência real, não tempo fixo

O pgAdmin só sobe quando o banco está realmente aceitando conexões. Sem isso, o pgAdmin tentaria conectar antes do banco estar pronto — e falharia.
Volume nomeado — dados que sobrevivem ao reinício

Os dados ficam num volume Docker independente do container. Se o servidor reiniciar, os dados continuam. Para apagar tudo: docker compose down -v.
pgAdmin pré-configurado via servers.json

Abre localhost:5051, faz login e o banco já aparece conectado — sem preencher host, porta e senha manualmente.

Saída real — ambiente sobe do zero em ~5 minutos, 3,7M linhas carregadas:

[1/6] Iniciando containers (postgres + pgadmin)...
[2/6] Aguardando banco ficar pronto...      banco pronto
[3/6] Criando DDL Bronze...
[4/6] Carregando ~3.7M linhas (pode demorar 3-5 min)...
      Bronze: 3,723,595 linhas em 9.4s  |  erros: 0
[5/6] Transformando Silver e populando Gold...
[6/6] Validando KPIs...

  KPI 1: OK   KPI 2_3: OK   KPI 4: OK
  KPI 5: OK   KPI 6: OK     KPI 7: OK   KPI 8: OK

pgAdmin: http://localhost:5051  (admin@banvic.com / admin)

Resultado

8/8 KPIs aprovados. Ambiente isolado, sem conflito com outros projetos.

Ponto forte

Reprodutibilidade total. Funciona igual em Windows, Linux, Mac e servidor cloud.

Limitação

Requer Docker instalado. Não substitui orquestração automática (isso é o Airflow).

Apache Airflow DAG Python Docker PostgresHook

A pergunta

O que muda quando o pipeline precisa rodar todo dia, sozinho, e te avisar quando algo falha?

A analogia

Imagina uma cozinha de restaurante. Nos projetos anteriores, você mesmo vai lá e cozinha. No Airflow existe um chefe de cozinha: sabe que o pão precisa ficar pronto antes do sanduíche, que o café deve ligar às 6h, que se um cozinheiro falhar, ele tenta de novo ou chama o gerente. Cada cozinheiro é uma "tarefa", a ordem é a "DAG".

DAG — o mapa de 13 tarefas

O arquivo banvic_pipeline.py define 13 tarefas e suas dependências. As 7 tarefas Silver rodam em paralelo — o Airflow detecta que não dependem umas das outras e as executa ao mesmo tempo, acelerando o pipeline.
Interface visual em localhost:8080

Cada tarefa fica colorida em tempo real: cinza = esperando, amarelo = rodando, verde = sucesso, vermelho = falha. Você clica numa tarefa e vê os logs completos.
Retry automático e senha segura

Se uma tarefa falhar, o Airflow tenta 2 vezes (com 3 minutos de intervalo) antes de alertar. A senha do banco não fica no código — fica como variável de ambiente e o Airflow lê com PostgresHook(postgres_conn_id="banvic_pg").

Fluxo real da DAG — Silver em paralelo, Gold em sequência:

[Verificar Bronze]
       ↓
[Preparar ambiente]
       ↓
┌──── Silver: 7 tarefas ao mesmo tempo ──────┐
│ clientes · contas · transações             │
│ agências · colaboradores                   │
│ propostas · dados externos                 │
└──────────────────┬─────────────────────────┘
                   ↓
              [Índices]
                   ↓
     [Gold: Dimensões → Fatos]
                   ↓
         [Validar KPIs]

Resultado

13 tarefas concluídas. 8/8 KPIs aprovados. Agendável por cron (schedule="0 6 * * *").

Ponto forte

Retry, histórico, paralelismo e alertas por e-mail — tudo nativo.

Limitação

Overhead operacional para pipelines simples. Requer time com perfil DevOps.

dbt SQL Testes automáticos Lineage Graph Docker

A pergunta

Como trabalhar em transformações SQL em equipe sem virar uma bagunça? Como garantir automaticamente que os dados estão corretos?

A analogia

Imagina um caderno de receitas organizado por categoria, em vez de papeizinhos espalhados. Cada receita tem nome, sabe de quais ingredientes depende, e tem uma lista de verificação automática ("o bolo tem açúcar? está no ponto?"). No dbt, cada transformação SQL é uma "receita", as dependências são declaradas, e os testes rodam sozinhos.

21 models — cada transformação num arquivo SQL

Silver (6 arquivos) + Gold (5 dimensões + 3 fatos + 2 marts). Cada arquivo usa {{ ref('nome') }} para declarar de onde vêm os dados — o dbt descobre a ordem de execução sozinho.
64 testes automáticos — qualidade garantida

Você declara no YAML: "a coluna cod_cliente nunca pode ser nula, nunca pode repetir". O dbt test verifica automaticamente. Se falhar, você vê exatamente qual linha quebrou a regra.
Lineage Graph — mapa visual do pipeline

dbt docs serve abre um site em localhost:8081 com o grafo completo: você vê cada tabela, de onde ela vem, quem depende dela e quais testes ela tem. Documentação gerada automaticamente do código.

Código real — testes declarados em YAML (mais simples do que parece):

# schema.yml — você descreve, o dbt testa
models:
  - name: silver_clientes
    columns:
      - name: cod_cliente
        tests:
          - not_null      # nunca pode ser nulo
          - unique        # nunca pode repetir
      - name: canal
        tests:
          - accepted_values:
              values: ['App', 'Agência', 'Internet', 'ATM', 'Telefone']

# Resultado: dbt test
# PASS=64 WARN=0 ERROR=0 SKIP=0 TOTAL=64

Resultado

21 models criados. 64 testes aprovados. 8/8 KPIs validados.

Ponto forte

Testes, documentação e rastreabilidade automáticos. Ideal para times SQL.

Limitação

Só transforma — não move dados para o banco (não substitui a ingestão Bronze).

Databricks PySpark Delta Lake ACID Time Travel

A pergunta

O que muda quando o dado não cabe mais em um computador? Quando são 100 milhões de transações por dia, não 70 mil?

A analogia

Os projetos anteriores são uma cozinha de casa: um fogão, um cozinheiro, funciona para 10 pessoas. O Databricks é uma fábrica de alimentos: 100 cozinheiros trabalhando ao mesmo tempo, cada um com sua parte. O Spark distribui o trabalho automaticamente entre vários computadores em paralelo.

Upload dos CSVs para o DBFS (sistema de arquivos na nuvem)

Os dados vão para o Databricks File System via interface visual ou CLI. Os mesmos CSVs do projeto local — a diferença é onde ficam: na nuvem, acessíveis por qualquer notebook do workspace.
6 Notebooks PySpark (executar em ordem)

00_setup → 01_bronze → 02_silver → 03_gold_dims → 04_gold_fatos → 05_validar_kpis. O código usa spark.read.csv() e spark.write.format("delta"). O Spark distribui o processamento automaticamente.
Delta Lake — o diferencial

Os dados são salvos em formato Delta: tem ACID (ou salva tudo ou não salva nada), Time Travel (consulta como a tabela estava ontem, ou na versão 3) e Schema Enforcement (rejeita dados com formato errado).

Código real — Time Travel: veja como a tabela estava antes de qualquer mudança:

# Consultar a versão 0 — antes de qualquer modificação
df_original = (spark.read.format("delta")
               .option("versionAsOf", 0)
               .table("banvic_bronze.transacoes"))

# Ver todo o histórico de mudanças
spark.sql("DESCRIBE HISTORY banvic_bronze.transacoes").show()

# Resultado da validação:
# KPI1: saldo R$ 87.826.703,29 — exatamente o gabarito
# 8/8 KPIs APROVADOS

Resultado

8/8 KPIs aprovados. 3 schemas no Unity Catalog com 35 tabelas Delta.

Ponto forte

Escala para petabytes. Delta Lake + Time Travel + MLflow integrado.

Limitação

Pago (cloud). Para 70k transações do BanVic, é canhão para matar mosca.

n8n Automação Visual Docker Workflows JSON PostgreSQL

A pergunta

O que muda quando qualquer pessoa do time precisa entender e modificar o pipeline — não só o engenheiro de dados?

A analogia

Já brincou de montar um circuito elétrico de brinquedo? No n8n você conecta blocos na tela — "consultar o banco", "comparar com o gabarito", "enviar e-mail se falhar". Enquanto roda, cada bloco fica verde (sucesso) ou vermelho (erro) em tempo real. É um painel de controle visual do pipeline.

run_automacao.py — sobe tudo em um comando

Um script Python faz tudo: sobe PostgreSQL (porta 5434) + n8n (porta 5678), carrega o Bronze, configura o n8n, importa os workflows e dispara a execução automaticamente.
Workflow 1 — Pipeline ETL completo (28,4 segundos)

Bronze → Silver → Gold → KPI1. Os blocos Execute Command chamam os mesmos arquivos SQL do Projeto 1 — o n8n orquestra o SQL que já funciona, sem reescrever nada.
Workflow 2 — Validação de KPIs (0,74 segundos)

Executa KPI1, KPI2, KPI4 e KPI7 em paralelo. Um bloco JavaScript compara cada resultado com o gabarito. Um bloco IF roteia para "aprovado" ou "falhou" com setas separadas.

Lição importante — o n8n não reescreve o SQL: ele é um orquestrador.

A pergunta certa não é "vou reescrever tudo no n8n?", mas "como faço esse código que já funciona rodar automaticamente e ser monitorado por qualquer pessoa do time?"

Resultado

8/8 KPIs aprovados. ETL em 28,4s, validação em 0,74s.

Ponto forte

Time misto (devs + analistas + operações) consegue entender e modificar.

Limitação

Não é ideal para DAGs com centenas de tarefas complexas — use Airflow nesse caso.

Microsoft Fabric OneLake PySpark Delta Lake Power BI Direct Lake

A pergunta

Como transformar toda a massa de dados do BanVic em decisões práticas para gestores, numa única plataforma? E como preparar o caminho para o Power BI ler as tabelas Delta pelo Direct Lake, sem exportar CSV nem depender de planilhas intermediárias?

A analogia

Os projetos anteriores são como ter o banco, a cozinha e o restaurante em prédios separados. O Microsoft Fabric é o apartamento integrado: a cozinha (Spark para engenharia), a despensa (OneLake para armazenamento) e o restaurante (Power BI) ficam no mesmo ecossistema. O objetivo é reduzir transporte manual entre ferramentas e deixar o dado pronto para consumo executivo.

Criar Workspace + Lakehouse no Fabric

Acesse app.fabric.microsoft.com (conta Microsoft gratuita, trial 60 dias). Crie workspace BanVic360 e Lakehouse BanVic. O Lakehouse tem dois painéis: Files (CSVs) e Tables (Delta tables).
Upload dos CSVs para o OneLake

Faça upload das pastas banvic/, sintetico/ e external_data/ pela interface visual. Os mesmos CSVs dos outros projetos — a diferença é onde ficam: no armazenamento da Microsoft.
6 Notebooks Spark — Bronze ao Gold

01_bronze → 02_silver → 03_gold_dims → 04_gold_fatos → 05_validar_kpis → 06_metricas_executivas. O notebook 05 mostra os 8/8 KPIs aprovados. O 06 cria tabelas vw_* prontas para o Power BI.
Pipeline Data Factory — orquestração dos notebooks

Orquestra os 6 notebooks em sequência. A configuração do pipeline foi preparada para Bronze, Silver, Gold, validação e métricas executivas; o agendamento final depende do workspace Fabric usado na publicação.
Power BI via Direct Lake — consumo direto do Lakehouse

O modelo foi desenhado para o Power BI ler as tabelas Delta do Lakehouse. Isso evita exportações manuais e reduz a dependência de refresh tradicional; os prints finais do dashboard ainda estão sendo atualizados.

Resultado real (15/06/2026) — validação dos 8 KPIs no Microsoft Fabric:

============================================================
  BanVic 360 - Projeto 9 (Microsoft Fabric)
============================================================
  [OK] KPI1 APROVADO → Saldo: R$ 87.833.946,97
  [OK] KPI2 APROVADO → Volume: R$ 4.835.541.814,68
  [OK] KPI3 APROVADO
  [OK] KPI4 APROVADO
  [OK] KPI5 APROVADO
  [OK] KPI6 APROVADO
  [OK] KPI7 APROVADO → 50.997 clientes segmentados
  [OK] KPI8 APROVADO
============================================================
  Resultado: 8/8 KPIs APROVADOS
============================================================

Resultado

8/8 KPIs aprovados no core. 3.479.623 linhas no Bronze. Gold ampliado implementado nos notebooks.

Ponto forte

Engenharia + BI no ecossistema Microsoft. Direct Lake reduz cópia manual entre Lakehouse e relatório.

Limitação

Trial de 60 dias. Requer organização Microsoft 365 para produção; dashboard final está em atualização visual.

Placar final

9 stacks, 9 aprovações

Todos chegaram nos mesmos 8 KPIs. O que muda não é a resposta — é o caminho, o esforço de manutenção, o perfil do time e o custo de infraestrutura.

#	Stack	KPIs	Quando usar
01	SQL Puro	8/8 ✓	Time pequeno que sabe SQL, pipeline simples, zero dependências extras
02	Python + PostgreSQL	8/8 ✓	Regras complexas, debug fácil, integração com Machine Learning
03	Apache Hop	8/8 ✓	Times mistos sem programadores, auditoria visual, múltiplos bancos
04	Docker	8/8 ✓	Reprodutibilidade total: mesmo ambiente em qualquer máquina
05	Apache Airflow	8/8 ✓	Pipeline recorrente, retry automático, histórico de execuções
06	dbt	8/8 ✓	Times SQL com warehouse, testes e documentação automáticos
07	Databricks	8/8 ✓	Volume acima de 100 GB, ACID em data lake, ML integrado
08	n8n	8/8 ✓	Time misto, integrações com APIs/e-mail/Slack, pipelines médios
09	Microsoft Fabric	8/8 ✓	Org Microsoft 365, Power BI Direct Lake, plataforma unificada

Recursos

Código completo e estudo de caso

O repositório no GitHub contém os 9 projetos completos com código real, README detalhado em cada pasta, scripts de execução (run.bat / run.sh) e o gabarito de validação.

Repositório GitHub Estudo de caso

Todos os projetos Entre em contato