Projeto de sprint da Pós-graduação em Data Science & Analytics (PUC-Rio) focado em engenharia de dados e arquitetura Lakehouse.
Projeto desenvolvido como parte da sprint de Engenharia de Dados do programa de Pós-graduação em Data Science & Analytics da PUC-Rio, pensado para compor o portfólio com um caso completo de pipeline analítico em ambiente de Data Lakehouse. O MVP simula o pipeline transacional da 100cep Gateway, cobrindo ingestão, processamento, conciliação e chargebacks, com foco em boas práticas de modelagem, governança e observabilidade de dados.
Este repositório demonstra:
- Arquitetura Lakehouse com camadas Bronze → Silver → Gold.
- Construção de um esquema estrela para análise de risco, antifraude e receita.
- Documentação técnica (catálogo, ETL, análises, autoavaliação) em formato pronto para portfólio.
Organização do repositório:
📁 100cep-gateway
├── 📁 .databricks
│ └── 📁 pipeline
│ ├── 📁 html # contém os arquivos databricks em formato .html
│ └── 📁 notebooks # contém os arquivos databricks em formato .ipynb
├── 📁 datasets
│ ├── 📁 ai_dataset # contém o dataset gerado pelo modelo OpenAI 5.0
│ └── 📁 olist_dataset # contém os datasets Brazilian E-Commerce Public Dataset by Olist
├── 📁 dbdiagram # contém o código realizado no dbdiagram.io
├── 📁 images
│ ├── 📁 databricks # evidências do databricks
│ ├── 📁 dbdiagram # schema do dbdiagram.io
│ └── 📁 logo # logo da 100cep Gateway
A 100cep Gateway é uma empresa fictícia de infraestrutura de pagamentos borderless, criada como cenário de negócio para este MVP de Engenharia de Dados.
O foco da 100cep não é apenas “processar pagamentos”, mas entender o risco, o comportamento de chargebacks e a saúde da operação transacional em métodos de pagamento, regiões e perfis de clientes.
No contexto deste projeto, a 100cep Gateway é posicionada como uma plataforma que:
- intermedia pagamentos de e-commerce entre clientes, sellers e provedores financeiros;
- monitora indicadores críticos como taxas de aprovação, faturamento e principalmente taxas de chargeback;
- utiliza dados históricos de pedidos, pagamentos, logística e reclamações para orientar decisões de risco, antifraude e estratégia comercial.
O nome “100cep” reforça a ideia de uma operação sem fronteiras — sem cidade, estado ou país limitando o fluxo de pagamentos — e justifica a presença de dimensões de geolocalização e análises por região e método de pagamento na camada analítica.
Este projeto foi desenvolvido no contexto da pós-graduação em Data Science & Analytics (PUC-Rio), com foco em engenharia de dados aplicada.
Objetivos principais:
- Pipeline transacional: Simular o fluxo de uma adquirente/gateway, ingerindo e organizando dados de pedidos, pagamentos, itens, clientes e sellers.
- Visões analíticas de risco: Criar camadas analíticas para monitorar chargebacks, GMV, ticket médio e métricas por método de pagamento, seller e localização.
- Portfólio técnico: Entregar código + documentação, evidenciando decisões de arquitetura, qualidade de dados e modelagem dimensional.
- Plataforma de dados: Databricks (Spark, Delta Lake, Unity Catalog).
- Linguagem: Python e SQL.
- Processamento: Apache Spark (SQL / DataFrames) e Pandas para análises pontuais.
- Modelagem: Arquitetura Medallion (Bronze, Silver, Gold) e esquema estrela.
- Visualização: Seaborn, Matplotlib e Geopandas.
Os dados são baseados no Brazilian E-Commerce Public Dataset by Olist, amplamente utilizado em estudos de ciência e engenharia de dados. O projeto também utiliza um dataset sintético de chargebacks para simular risco e fraude, sem qualquer dado sensível real.
Fluxo de ingestão:
- Download dos arquivos CSV a partir do Kaggle.
- Upload para Unity Catalog Volumes no Databricks, compondo a área de staging antes da Bronze.
⚠ Nenhum dado pessoal identificável (PII) real é utilizado.
⚠ Escopo 100% educacional e de portfólio.
Fluxo de ingestão: 02_download
O projeto adota um modelo Lakehouse em Databricks, estruturado na arquitetura Medallion (Bronze, Silver, Gold), com governança via Unity Catalog.
- CSVs armazenados em Delta quase “como chegaram”.
- Foco em auditabilidade e possibilidade de reprocessamento.
- Leitura dos CSV a partir do Volume do Unity Catalog.
- Persistência em tabelas Delta
*_raw. - Normalização básica de nomes de tabelas.
- Padronização de tipos e normalização de chaves.
- Tratamento de nulos e deduplicação.
- Criação de tabelas temáticas (pedidos, pagamentos, clientes, itens).
- Criação de relacionamentos entre pedidos, pagamentos, itens, clientes e sellers.
- Dimensões: clientes, vendedores, pagamentos, data, geolocalização, chargebacks.
- Fato:
fato_transacoes, consolidando pedidos, valores, status e vínculo com chargebacks. - Modelagem dos dados em Star Schema, conforme indicado na imagem abaixo criada no site dbdiagram.io.
Regras detalhadas de transformação: Documentação do ETL
Código do diagrama: Dbdiagram Schema
O projeto inclui um Data Catalog documentando:
- Nome e tipo de cada coluna.
- Domínio esperado, faixas de valores e categorias.
- Descrição funcional e camada de origem.
Arquivo de referência: Catálogo dos Dados
Ajuste nomes de catálogo/schema e caminhos conforme o seu workspace Databricks.
Necessidade de upload manual da tabela chargebacks_dataset no volume imdb.
-
Configurar ambiente
- Criar o catálogo
100cep_gateway(ou adaptar nos scripts). - Configurar Unity Catalog e Volumes para staging.
- Criar o catálogo
-
Rodar os scripts em ordem
-
Explorar análises
- Abrir 06_qualidade para explorar a análise de qualidade.
- Abrir 07_perguntas para responder às perguntas de negócio.
-
Explorar Comentários
- Abrir 08_catalogo para adicionar comentários nas tabelas de todas as camadas.
A camada Gold foi desenhada para responder perguntas típicas de risco, antifraude e receita em um gateway de pagamentos.
- Qual o método de pagamento mais utilizado pelos clientes da 100cep Gateway?
- Qual o histórico de faturamento do ano de 2017?
- Qual a proporção de pedidos com e sem solicitação de chargeback?
- Quais métodos de pagamento apresentam maior risco de chargeback?
- Quais estados apresentam as maiores taxas de chargeback?
Detalhes das análises: Perguntas de Negócio
Como parte da sprint, o projeto inclui uma autoavaliação com reflexões técnicas e acadêmicas.
- O que foi cumprido dentro do escopo da sprint.
- Principais desafios (performance, modelagem, ferramentas).
- Próximos passos;
Arquivo: Autoavaliação
Felipe Pinheiro
Dataset: Brazilian E-Commerce Public Dataset by Olist — Olist & André Sionek.
DOI: 10.34740/kaggle/dsv/195341 — Licença CC BY-NC-SA 4.0.