Projetos
Desafio Lighthouse · Revisao Pos-Feedback

BanVic Analytics — Engenharia de Dados Completa

Versao revisada do Desafio Lighthouse 2024: desta vez com pipeline ETL em SQL (schema stg_banvic no PostgreSQL), camada de staging antes do Power BI, e integracao com dados externos de IPCA — o que faltou na primeira entrega.

Ano 2024 Papel Analytics Engineer Status Revisado Autor Jair Pereira da Silva Junior
Contexto

O desafio

O BanVic e um banco ficticio criado pela Lighthouse para o desafio de Engenharia de Analytics 2024. O objetivo: consolidar seis fontes de dados — clientes, colaboradores, agencias, contas, propostas de credito e transacoes — em uma visao analitica acionavel.

O desafio incluia o uso de dados externos para enriquecer a analise (o IPCA era explicitamente sugerido) e a implementacao de uma camada de staging antes do BI, garantindo governanca de dados.

A primeira versao foi reprovada por dois gaps: transformacoes feitas diretamente no Power Query sem ETL previo, e ausencia de dados externos. Esta versao corrige ambos.

O que foi corrigido

Da v1 a versao revisada

Gap 1 — Sem ETL: a primeira versao conectava o Power BI diretamente nos arquivos CSV, fazendo todas as transformacoes no Power Query. Em ambientes de producao isso cria dependencia da ferramenta de BI para governanca e dificulta o reaproveitamento dos dados. A versao revisada implementa um pipeline ETL Medallion (Bronze → Silver → Gold) em Python + Pandas, com parquet em cada camada, 8 data quality checks automatizados e logging estruturado. Os dados chegam ja tratados a dois caminhos de consumo: Power BI via stg_banvic (PostgreSQL) ou Dashboard Web V2 via JSON.

Gap 2 — Sem dado externo: o proprio enunciado do desafio sugeria o uso do IPCA para correlacionar comportamento dos clientes com variacoes macroeconomicas. A sub-pagina IPCA mostra essa analise: volume de saques vs. inflacao mensal, propostas de credito em periodos de alta inflacao, e juros do banco vs. IPCA acumulado (19,11% no periodo 2020–2022).

Bonus — dim_dates: a Gold tambem gera uma dimensao temporal derivada (trimestre, dia-da-semana, mes com/sem “R”, par/impar) usada na pagina de Padroes Temporais. E essa mesma logica que identifica o dump artificial de fim de 2022 (dias com mais de 200 transacoes) e o exclui das analises de sazonalidade.

Como funciona

Arquitetura

O banco em numeros

Metricas reais

998
clientes · 100% Pessoa Fisica
72 mil
transacoes · R$ 58,1 mi movimentados
2.000
propostas de credito analisadas
10
agencias no dataset
Sub-projetos

Aprofunde em cada frente

Cada frente de analise tem sua propria pagina com graficos, metricas e insights especificos.

Clientes
perfil · geografica · faixa etaria
Credito
propostas · taxas · aprovacao
Transacoes
volume · tipos · sazonalidade
IPCA ★
dado externo · correlacao macro
Padroes Temporais
dim_dates · trimestre · dia da semana
Dimensao de datas · Desafio

Analises temporais com dim_dates

O desafio pedia uma dimensao de datas (dim_dates) para sustentar o Data Warehouse. Construi a tabela (1 linha por dia — trimestre, mes, dia da semana, mes com/sem “R”, par/impar) e a usei para responder as perguntas de negocio.

Tratamento honesto: as transacoes de 29 e 30/12/2022 concentram um dump artificial de ~20 mil registros (vs. ~12/dia normais). Esses dias foram excluidos das analises de padrao temporal — senao Q4, dezembro e sexta-feira ficariam falsamente inflados.

Q1 · Trimestre
Q4 lidera em transacoes e volume
Q2 · Meses com “R”
Diferem (p=0,001), mas e sazonalidade — nao a letra
Q3 · Dia da semana
Quinta-feira tem a maior media
Q4 · Pares vs impares
Refutado: impares tem volume maior (p=0,022)
Ferramentas

Stack & decisoes

PostgreSQL · SQL Power BI · DAX Python · Pandas ETL · Staging Layer Star Schema IPCA · Dados Externos dim_dates Power Query Modelagem Dimensional