Desafio de Engenharia de Dados

Seja bem vindo ao teste de Engenheiro de Dados.

Estrutura do projeto

.
├── analytics                             
│   ├── queries.py               # Contém as respostas das perguntas 1 a 5.
│   ├── visualization.ipynb      # Alguns gráficos para visualização de dados.
├── config
│   ├── dbconnection.py          # Configuração do banco de dados MySQL.
├── data                                        
│   ├── CSV Files...             # Todos os dados e seus respectivos arquivos CSV.
├── model
│   ├── structure.sql            # Scripts contendo apenas a estrutura da modelagem de dados.
│   ├── final.sql                               
│   ├── MER.mwb                                 
├── pipelines                    # Arquivos responsáveis pela carga de dados de cada entidade no banco de dados.
│   ├── customer.py
│   ├── person.py
│   ├── product.py
│   ├── sales_order_detail.py
│   ├── sales_order_header.py
│   ├── sales_special_offer_product.py
└── 

Considerações sobre a estrutura

A estrutura foi pensada a partir dos padroes arquiteturais e boas práticas da famosa Engenharia de Software.

analytics -> representa todo o conteúdo que se trata do fim, queries feitas em cima do banco de dados final carregado, e a visualização utilizando Jupyter Notebook e Matplotlib

config -> representa o conteúdo de configuração para o script, seja ele banco de dados, ou outro elemento que necessite de uma configuração

data -> está contido todos os arquivos CSV, Sales, Person, Product, sem nenhuma alteração.

model -> A estrutura da modelagem de dados relacional está contida nessa pasta, nos formatos SQL e .mwb (MER)

pipelines -> Cada arquivo dentro dessa pasta é responsável pelo carregamento dos dados da entidade referida no banco de dados destino, é nesses arquivos que são feitos os tratamento de dados também quando necessários.

• INFRAESTRUTURA
  • A plataforma da nuvem escolhida foi o Google Cloud Platform.
  • A instancia criada foi na ordem de SQL > MySQL, utilizando créditos do período trial.
  • A infraestrutura foi configurada utilizando o script de modelagem de dados, contido na pasta /model.
  • Escolhi usar GCP pelo fato de ter tido pouco contato anteriormente, aproveitei pra aprender mais.
  

• MODELAGEM DE DADOS
  • A modelagem foi criada utilizando MySQL, seguindo os nomes e tipos referentes de cada campo de cada arquivo CSV.
  • Todo o conteúdo referente a modelagem de dados está na pasta /model
  

• FLUXO DE DADOS
  • Os dados de cada entidade de cada arquivo CSV, é lida em memória, utilizando a biblioteca Pandas
  • Os dados carregados em memoria são transformados quando necessário, feito o tratamento de missing e missing ocultos.
  • Todo o fluxo é implementado utilizando a Linguagem Python e suas bibliotecas padroes
  • Cada arquivo .py de pipeline é responsável pelo fluxo de uma entidade (csv > python > mysql). Escolhi dividir dessa forma para manter a organização e deixar de facil entendimento e manutenção do código.
  • customer.py é responsavel pelos dados de Customer (Coleta, Transformação e Carga)
  • person.py é responsavel pelos dados de Person (Coleta, Transformação e Carga)
  • product.py é responsavel pelos dados de Product (Coleta, Transformação e Carga)
  • sales_order_detail.py é responsavel pelos dados de SalesOrderDetail (Coleta, Transformação e Carga)
  • sales_special_offer_product.py é responsavel pelos dados de SalesSpecialOfferProduct (Coleta, Transformação e Carga)
  • sales_order_header.py é responsavel pelos dados de SalesOrderHeader (Coleta, Transformação e Carga)
  • Os scripts detém de uma ordem de execução, para respeitar os relacionamento entre as entidades e se relacionarem da maneira correta
  • Ordem de execução: person -> customer -> product -> specialOfferProduct -> salesOrderDetail -> salesOrderHeader

• ANÁLISE DE DADOS
  • As queries de SELECT estão no arquivo analytics/queries.py, da pergunta 1 a 5, cada uma respondida em uma função
  • Alguns plots realizado com os dados extraidos do banco de dados estão no Notebook visualization.ipynb
  

E no futuro?

Aprenderia Apache Spark, pra solucionar o problema a partir de uma solução mais robusta.

Poderia utilizar um framework para o ETL, Pentaho, serviços da AWS, Azure. No qual o processo seria mais rápido e automatico se tornando incremental de maneira fácil.

Real Time Analytics, permitindo até criar modelagens no próprio fluxo de tratamento da informação pra ajudar na tomada de decisao, mas tudo depende do problema a ser resolvido.

Utilizaria um orquestrador de agendamento para automação agendada desse fluxo (Airflow)

Se os dados forem utilizados para análise exploratória, machine learning, e modelagem preditiva no geral, eu faria uma modelagem de dados diferente, assim como o tratamento de dados missing e pré processamento. (Orientado ao problema).

Obrigado!