**Breve sumário 

**Motivação da Solução 

A esteira realiza o processamento contrato a contrato utilizando mensageria Kafka.  Algumas etapas se tornavam mais problemáticas se tratando de processamento via evento:  

Obter o mesmo contrato que passou, porém com a data anterior para calcular delta. 

Utilizando DynamoDB para guardar a “foto” de cada dia dos contratos. 

Acabou gerando um custo muito grande de read/write na tabela 

Realizar cálculo de acúmulo contrato a contrato. 

Realizado toda vez que uma foto do contrato era salva em uma tabela Dynamo 

Lambda que “escutava” o evento de read e realizava as devidas tratativas 

Alto custo de Dynamo e descasamento de informações, caso o contrato passasse mais de uma vez na esteira (passível de ocorrer, pensando em eventos) 

Agrupar os dados para gerar relatórios. 

Ao fim da esteira, os dados precisavam ser processados para gerar relatórios para a área usuária 

A primeira solução foi utilizar o Glue para consumir uma tabela Dynamo e gerar os relatórios (caro e lento) 

Após isso, utilizamos o Glue para realizar o “Sink” dos dados para o S3 a fim de serem catalogados, facilitando o reprocessamento dos relatórios caso necessário (caro, lento para extrair, porém mais fácil para manipular os dados posteriormente) 

Após isso, utilizamos o Kinesis e Firehose para realizar o streaming dos dados diretamente quando os mesmos fossem salvos na tabela Dynamo (menos caro que o Glue, extração praticamente online) 

Depois, evoluímos a fim de remover a tabela dynamo, enviando os dados diretos para o stream do Kinesis (solução mais barata e ainda assim praticamente online) 

Porém, na jornada de redução de custos para processamento de dados e geração desses relatórios, foi alinhado com a equipe funcional a possibilidade de agrupar os dados em certa parte da esteira, realizando um processamento em batch que poderia eliminar as disfunções citadas acima; 

Para o momento que iria acontecer essa transição de evento para batch, construímos uma peça que consome os dados do tópico Kafka (contrato a contrato) e já os salva em parquet particionados para o nosso padrão de acesso. 

No primeiro momento, a solução para os cálculos foi pensada usando apenas Glue: Uma série de Jobs que executariam um após o outro tratando os dados. Esses, estariam no formato Parquet e catalogados em Tabelas Glue para cada etapa. Ao desenvolver e executar o Job que faz a primeira parte do processo (agrupamento), percebemos que o volume de dados que iriamos trabalhar seria bem menor que o esperado.  

Pensand