Tech Challenge 2 - Pipeline Batch Bovespa

Introdução

Este projeto faz parte do Tech Challenge Fase 2 e tem como objetivo construir um pipeline de dados para extrair, processar e analisar dados do pregão da B3 utilizando serviços da AWS, como o S3, Glue, Lambda e Athena.

Este README detalha as etapas necessárias para configurar e executar o pipeline, bem como os entregáveis esperados.

---

Arquitetura

A arquitetura do pipeline segue o diagrama abaixo:

1. Scraping de Dados: Extrai os dados do site da B3 e realiza o upload em um bucket S3.
2. Bucket Raw: Os dados brutos são enviados para o bucket Raw no Amazon S3 em formato Parquet e particionados por data.
3. Trigger de Lambda: O upload de arquivos aciona uma função Lambda.
4. ETL com Glue: A Lambda dispara um job Glue que realiza transformações nos dados.
5. Dados Refinados: Os dados processados são salvos no bucket Refined em formato Parquet, particionados por data e abreviação da ação.
6. Catálogo no Glue: O Glue cataloga os dados automaticamente e cria uma tabela.
7. Consulta no Athena: Os dados estão disponíveis para consulta no Athena.

Links Importantes

• Página Oficial da B3 para Scraping: https://www.b3.com.br
• Documentação do AWS CLI: https://docs.aws.amazon.com/cli
• Documentação do Terraform: https://developer.hashicorp.com/terraform
• Guia do AWS Glue: https://docs.aws.amazon.com/glue
• Consulta Athena: https://docs.aws.amazon.com/athena

Requisitos do Projeto

Os seguintes requisitos devem ser atendidos:

1. Realizar scraping de dados do site da B3.
2. Armazenar os dados brutos no bucket Raw em formato Parquet.
3. Configurar um bucket S3 que acione uma função Lambda ao receber novos arquivos.
4. Implementar uma função Lambda que dispare um Glue Job.
5. Configurar o Glue Job para realizar as seguintes transformações:
   • Agrupamento numérico e sumarização de dados.
   • Renomear duas colunas do dataset.
   • Realizar cálculos com campos de data.
6. Salvar os dados refinados no bucket Refined em formato Parquet, particionados por data e abreviação da ação.
7. Configurar o Glue Catalog para criar tabelas automaticamente.
8. Permitir consultas SQL no Athena utilizando os dados refinados.
9. Garantir que os buckets tenham o versionamento habilitado.

Pré-requisitos

Antes de iniciar, certifique-se de ter:

• AWS CLI instalado e configurado.
• Terraform instalado.
• Permissões de acesso à sua conta AWS.

Instalação do AWS CLI

sudo apt update && sudo apt upgrade -y
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
aws --version

Instalação do Terraform

sudo apt update && sudo apt upgrade -y
curl -fsSL "https://releases.hashicorp.com/terraform/X.Y.Z/terraform_X.Y.Z_linux_amd64.zip" -o terraform.zip
unzip terraform.zip
sudo mv terraform /usr/local/bin/
terraform --version

Configuração do AWS CLI

Configure suas credenciais AWS:

aws configure

Para esse processo é necessário fornecer:

• Access Key ID
• Secret Access Key
• Região padrão (ex.: us-east-1)

Configuração e Execução do Pipeline

1. Clone este repositório.
2. Use o Terraform para criar os recursos AWS necessários:

   terraform init
   terraform apply
   

3. Certifique-se de que os buckets, funções Lambda e Glue Jobs foram criados corretamente.

Scraping de Dados

Descrição

Esta etapa é responsável por extrair dados da B3 utilizando a API disponível executar a limpeza dos dados e fazer o upload para o bucket Raw no S3. O processo foi construindo utilizando a linguagem Python e as bibliotecas: boto3, pandas, selenium, pydantic.

Dependências

• boto3
• pandas
• selenium
• pydantic

Instale as dependências com:

pip install boto3 pandas selenium pydantic

Fluxo do Scraping

1. Configuração do WebDriver: Utiliza o ChromeDriver gerenciado automaticamente com a biblioteca webdriver_manager.

2. Extração dos Dados: Realiza o download de arquivos parquet diretamente do site da B3.

3. Processamento Inicial: Limpeza de dados para remover linhas mescladas e padronizar o conteúdo.

4. Validação com Pydantic: Garante a integridade dos dados utilizando modelos de validação.

5. Validação com Pydantic: Garante a integridade dos dados utilizando modelos de validação.

Lambda Function

• Descrição: Responsável por acionar o Glue Job ao detectar novos arquivos no bucket Raw.
• Transformações:
  • Agrupamento e sumarização de dados utilizando funções de Spark SQL.
  • Renomeação de colunas e reorganização do esquema.
  • Cálculos avançados baseados em campos de data.
• Automação: Configurado para ser acionado via eventos S3.

Glue Job

• Descrição: Não foi feito no modo visual e será explicado melhor nas observações.
• Transformações: Atende os requisitos de agrupação, renomeação de colunas e cálculos de data.

S3 Buckets

• Raw: Armazena os dados brutos enviados pelo scraping.
• Refined: Armazena os dados processados e otimizados para consulta.

Athena

• Descrição: Permite consultas SQL nos dados refinados.
• Configurações: Utiliza o Glue Catalog como metadados.

Decisão de Implementação para Função AWS Lambda com Dependências Excedendo 250MB

Contexto

Ao desenvolver uma solução para executar uma função AWS Lambda, nos deparamos com uma limitação do tamanho das layers. O limite máximo permitido para layers descompactadas é de 250 MB, e nossas dependências ultrapassaram esse limite.

Diante dessa restrição, analisamos diferentes opções para contornar o problema e garantir que a função pudesse ser executada conforme o esperado. Abaixo estão as opções avaliadas e a decisão final adotada.

Opções Consideradas

1. Criar Múltiplas Layers

Descrição:

Dividir as dependências em mais de uma layer, mantendo cada layer dentro do limite de 250 MB.

Prós:

• Solução suportada nativamente pelo AWS Lambda.
• Reutilização das layers em diferentes funções Lambda.

Contras:

• Requer um gerenciamento mais complexo das layers.
• Potencial aumento no tempo de carregamento da função Lambda devido à necessidade de carregar múltiplas layers.

---

2. Usar Imagem Docker

Descrição:

Criar uma imagem Docker contendo o código e as dependências necessárias. O AWS Lambda suporta imagens de até 10 GB, o que resolveria o problema de limitação de tamanho.

Prós:

• Restrição de tamanho significativamente maior (10 GB).
• Ambiente controlado e consistente, com todas as dependências incluídas.
• Flexibilidade para gerenciar o ambiente com maior granularidade.

Contras:

• Introduz complexidade adicional ao pipeline de desenvolvimento e implantação.
• Requer manutenção de um repositório de imagens (como o Amazon ECR).

3. Instalar Dependências Durante a Execução

Descrição:

Configurar a função Lambda para instalar as dependências necessárias durante a execução.

Prós:

• Implementação simples e direta.
• Nenhum impacto no tamanho da layer ou necessidade de criar uma imagem Docker.

Contras:

• Aumenta o tempo de execução da função Lambda, especialmente na primeira chamada (cold start).
• Pode impactar a eficiência geral dependendo do número de chamadas concorrentes.

Decisão Final

Optamos por instalar as dependências durante a execução da função Lambda (Opção 3). Embora essa abordagem tenha o contrapeso de um maior tempo de execução inicial, foi considerada a solução mais simples de implementar, dado que o SLA da função é diário e não exige resposta em tempo real.

Motivação

• Simplicidade: A solução elimina a necessidade de criar e gerenciar layers ou imagens Docker.

• Flexibilidade: Permite adicionar ou atualizar dependências sem necessidade de alterar layers ou imagens.

• Adequado ao SLA: O impacto no tempo de execução inicial é irrelevante dado que a função é executada apenas uma vez por dia.

Implementação

Etapas para Instalar Dependências Durante a Execução:

• Adicionar um script para instalar as dependências no runtime.

• Configurar a função Lambda para acessar o repositório ou local de instalação (como o PyPI).

• Verificar o desempenho e ajustar conforme necessário para garantir que o tempo de execução esteja dentro dos limites aceitáveis.

Monitoramento e Ajustes

A abordagem adotada será continuamente monitorada para identificar possíveis gargalos de desempenho. Caso o SLA ou requisitos mudem no futuro, a solução poderá ser revisada e adaptada para atender às novas demandas.

Essa decisão reflete o equilíbrio entre simplicidade, funcionalidade e os requisitos atuais do projeto'