Para a Fase 5 do nosso curso na FIAP, colocamos a mão na massa no desenvolvimento de duas entregas obrigatórias envolvendo as disciplinas de Machine Learning e Computação em Nuvem.
O principal objetivo prático desta entrega de Machine Learning foi aplicar conhecimentos de Ciência de Dados e usar regressores supervisionados para propor um sistema sustentável de exploração e análise de dados agrícolas (Crop Yields). O intuito é prever o rendimento em safras levando em consideração variáveis ambientais essenciais, como precipitação, umidade e temperatura.
Todo o passo a passo da nossa solução foi desenvolvido, testado, documentado e detalhadamente comentado dentro do Jupyter Notebook interativo contido neste mesmo repositório.
Você pode acessá-lo clicando no link abaixo: 👉 HenriqueSilva_rm567102_pbl_fase5.ipynb
Lá, descrevemos de maneira aprofundada o raciocínio aplicado a cada etapa solicitada pelo desafio do PBL:
- Análise Exploratória de Dados (EDA): Verificando distribuições, traçando histogramas, boxplots, correlacionando variáveis com mapas de calor (heatmap) e plotando análises das features da base de dados fornecida.
- Clusterização & Identificação de Outliers: Achados das características ocultas usando K-Means para separar as faixas de comportamento das produções e identificando variações bruscas ("cenários anômalos") na produção com o auxílio do Isolation Forest.
- Modelagem Preditiva Supervisionada: Procedimentos de pré-processamento (One-Hot Encoding, StandarScaler) para que pudéssemos instanciar, treinar e testar exaustivamente 5 algoritmos distintos de regressão (Regressão Linear, Árvore de Decisão, Random Forest, Máquinas de Vetores de Suporte e Gradient Boosting).
- Resumo Narrativo e Conclusões: Discussão sobre o processo, comparação do desempenho dos algoritmos pelas métricas pertinentes ao problema (R², RMSE e MAE) e também uma visão geral sobre os pontos fortes e limitações do estudo de caso elaborado.
O notebook incluído em nossa entrega já contém todas as saídas (gráficos e logs do terminal) persistidas no cache e não precisa ser re-executado para leitura das conclusões.
Porém, caso você possua interesse de rodar o código localmente do zero ou testar os algoritmos sob seus próprios critérios de fine-tuning para novas variações do conjunto de dados crop_yield.csv, instale os pré-requisitos:
# Recomendamos o uso de um venv ou ambiente conda
pip install pandas numpy matplotlib seaborn scikit-learn jupyterApós instalar e executar o jupyter a partir da inicialização via comando jupyter notebook em seu terminal, ou utilizando editores como Visual Studio Code ou Google Colab, todo o fluxo será executável de cima a baixo.
Para a Entrega 2, fomos desafiados a realizar uma estimativa de custos utilizando a calculadora da AWS, comparando as regiões de São Paulo (sa-east-1) e Virgínia do Norte (us-east-1).
O cenário proposto exige a configuração de uma máquina Linux simples, sem uso de instâncias exclusivas. Para uma melhor otimização de custos, adotamos o modelo Compute Savings Plans (1 ano sem adiantamento), contemplando os seguintes recursos para hospedar uma API receptora de dados de sensores e o modelo de Machine Learning:
- 2 CPUs (vCPUs)
- 1 GiB de memória RAM
- Até 5 Gigabit de rede
- 50 GB de armazenamento (EBS gp3) com rotina de backups via Snapshots (2x ao dia)
A instância que melhor atende esse requisito na família de uso geral é a t3.micro (que possui as 2 vCPUs e 1 GiB de RAM exigidos). Abaixo demonstramos a comparação de custos baseada em um mês (aproximadamente 730 horas) segundo os dados da estimativa oficial em PDF (AWS Pricing Calculator).
| Serviço / Recurso (Savings Plans 1yr) | 🇺🇸 us-east-1 (N. Virgínia) | 🇧🇷 sa-east-1 (São Paulo) |
|---|---|---|
Instância EC2 Linux (t3.micro) |
~$5,48 / mês | ~$8,10 / mês |
| Armazenamento (50 GB EBS gp3 + Snapshots) | ~$10,99 / mês | ~$17,10 / mês |
| Total Mensal Estimado | ~$16,47 / mês | ~$25,20 / mês |
Como podemos observar pela estimativa oficial, os custos operacionais de infraestrutura na região da Virgínia do Norte (EUA) continuam sendo cerca de 34% mais baratos (economia de ~$8,73/mês) do que na de São Paulo para a configuração apresentada.
Pergunta: Suponha também que você precisa acessar rapidamente os dados dos sensores e que há restrições legais para armazenamento no exterior. Qual opção você escolheria? Justifique.
Nossa Escolha: Região de São Paulo (sa-east-1).
Justificativa:
Mesmo que a região norte-americana (us-east-1) conte com custos substancialmente menores, a soberania de dados nos obriga a eleger a região sa-east-1. Se existem restrições legais e contratuais estabelecidas (como adequações específicas em auditorias da LGPD para dados do agronegócio nacional), armazenar, rotear ou processar a base de dados nos Estados Unidos causaria um grave compliance risk e violaria a legislação impositiva, inviabilizando o negócio juridicamente.
Além do cumprimento do requisito legal, a premissa sistêmica de “acessar rapidamente os dados dos sensores” aponta para a necessidade de extrema baixa latência. Os sensores (físicos, alocados nas plantações brasileiras) dependem do constante uso da rede para ingestão contínua. Enquanto conexões entre instâncias locais (Brasil) ao data center de São Paulo resultam num intervalo (ping) natural de 10 a 20 ms, fluxos internacionais do Brasil à N. Virgínia enfrentam delays comuns de 110 a 160+ ms. Ao hospedar a API e a modelagem Machine Learning de forma regional (sa-east-1), viabilizamos um acesso otimizado em quase tempo-real — essencial para algoritmos de clima e produtividade de safra —, mantendo total regularidade legal no armazenamento nacional das tabelas operacionais e logs do projeto.