Construindo um pipeline de dados near real time na AWS

Nesse post, a arquitetura de dados implementada na Kovi bem como as necessidades que motivaram essas escolhas vão ser apresentadas visando te ajudar a entender como escolher a abordagem e ferramentas adequadas para seu problema e como construir um pipeline para tratamento e processamento de dados near real time na nuvem do zero, utilizando a stack da AWS.

Aqui na Kovi, quem tem os dados tem a razão e desde a operação até a diretoria consumimos e utilizamos dados para que as melhores decisões sejam sempre tomadas. Por isso, optamos por construir uma arquitetura que entregue os dados near real time.

O pipeline discutido aqui provê suporte para todos os estágios do ciclo de vida dos dados, desde sua extração até a análise. Passaremos por cada uma dessas etapas detalhando todo o processo de construção visando contribuir para a comunidade com nosso case. Então vamos lá!

A arquitetura

O pipeline de dados da Kovi está dividido em 4 principais etapas:

Etapas do data lake da Kovi

Ingestão

O primeiro passo do pipeline é a ingestão dos dados. Essa etapa é a porta de entrada da arquitetura, ela é responsável por extrair os dados das diferentes fontes e carregá-los no data lake.

Arquitetura de ingestão de dados

Hoje na Kovi, temos 3 formas diferentes de implemetação da ingestão.

1. A primeira delas é via DMS. Essa é a forma que utilizamos para extrair dados de nossos bancos. O DMS é um serviço da AWS que replica todas as mudanças que ocorreram nessas bases para nossa arquitetura.
2. A segunda forma de ingestão é utilizada para extrair dados de eventos oriundos dos nossos serviços de streaming.
3. A terceira forma é através de uma API de ingestão que construímos aqui na Kovi e vamos falar dela em breve em um próximo post. Essa API é responsável por extrair os dados das fontes dos nossos parceiros. Hoje a Kovi lida com mais de 20 parceiros diferentes e realizar essas ingestões estava se tornando um serviço moroso. Com essa API, criamos um mecanismo reutilizável e modularizado onde temos lambdas com responsabilidades únicas que são reaproveitadas e tanto trabalhan de forma ativa, fazendo requisições nas APIs, quanto de forma passiva, recebendo dados via webhook.

Assim que os dados são ingeridos, eles são salvos no S3 na nossa primeira camada de dados, a raw. Nessa camada os dados estão em sua forma original e é a partir dela que reprocessamos os dados em caso de falhas.

Uma vez que os dados são ingeridos, além de serem salvos na RAW, eles são enviados para um Kinesis data stream que vai propagar os dados para a próxima etapa.

Transformação

Essa etapa é onde tratamos os dados da Kovi. Aqui resolvemos problemas de padronização e schema, garantindo que ao final dessa etapa os dados estão prontos para consumo.

A arquitetura de transformação dos dados funciona da seguinte forma:

Arquitetura de transformação

Assim que as informações são recebidas pelo Kinesis, ele propaga essas informações a etapa de transformação. Aqui nas transforms, assim como na IngestionAPI, utilizamos módulos reaproveitáveis com responsabilidades específicas de modo que quando uma nova fonte precisa ser tratada tenhamos o mínimo de trabalho e reescrita de código. A diferença aqui é que na IngestionAPI utilizamos Lambdas de fato, já aqui a lógica das transformações ocorre em uma lib que criamos e as Lambdas são criadas por fonte somente orquestrando o fluxo, ou seja, importando os recursos (transforms) necessários da lib. Vamos ter um outro post detalhando esse processo em breve também o/ .

Após tratados, os dados são salvos na nossa segunda camada: a trusted. Aqui os dados já estão prontos para serem consultados e explorados via Athena e Data Warehouse.

Enriquecimento

Essa etapa é responsável por incrementar os dados, ou seja, aqui trazemos informações relevantes sobre determinado domínio e deixamos esse dados já pronto na tabela para facilitar a vida do usuário que vai consumir essa informação.

Por exemplo, digamos que você tenha uma tabela de usuários que traz o id, email e endereço. Mas imagine que a empresa também precise saber o score do Serasa desse usuário, ou o churn dele. Essa etapa vai ser responsável por calcular essas informações e adicionar à tabela de forma que agora ela traga as colunas id, email, endereco, serasa_score, churn.

Essa etapa é representada pela imagem abaixo e da origem ao terceiro estágio de dados: enriched. Cada um desses estágios citados estão armazenados em um bucket específico no S3 com seu próprio particionamento e lifetime.

Arquitetura de enriquecimento de dados

Disponibilização

A última etapa consiste em disponibilizar os dados para serem consumidos pela empresa. Realizamos a disponibilização dos dados de duas formas:

1. Base histórica: uma vez na trusted, os dados da Kovi são disponibilizados via external schema no DW. Como a base histórica é uma base grande, por conter todas as modificações ocorridas, criar essas tabelas externas se torna uma solução cost efficient por poupar a necessidade de ter um cluster com mais armazenamento uma vez que os dados ficam armazenados no S3. Esse é um recurso proporcionado pelo Redshift Spectrum e uma das vantagens de se utilizar o Redshift.
2. Última foto: esse tipo de schema é usado para representar o último estado de cada record, uma "cópia" do banco original. Uma vez que os dados são tratados e salvos na trusted, eles são armazenados em uma tabela no DynamoDB. Uma Lambda que roda a cada 2 minutos lê os records dessa tabela e replica as mudanças na tabela correspondente no DW.

O desenho dessa etapa da arquitetura é mostrado abaixo:

Por fim, o Data Warehouse está conectado nas ferramentas de visualização Metabase e Tableau de onde os usuários finais consomem as informações.

Próximos passos

Uma vez implementado o data lake ainda temos muito chão pela frente. Agora trabalhamos no monitoramento das informações para garantir que os serviços estejam rodando corretamente e que os dados estejam corretos.

Outras frentes como disaster recovery e multi cloud deployment também entraram no nosso radar e devem ser os próximos pontos a serem atacados.

Concluindo

Espero que esse post tenha sido proveitoso e que a arquitetura de dados da Kovi tenha te inspirado. Obrigada por ler até aqui e se você tiver alguma pergunta ou sugestão me envie e ficarei feliz em discutir sobre isso com você :)