Introdução à Arquitetura de Dados usando AWS
Introdução:
Ter uma Arquitetura de Dados justa para o caso de uso é essencial para empresas que desejam tomar decisões estratégicas com base em informações precisas e atualizadas. A AWS (Amazon Web Services) é uma plataforma de computação em nuvem que oferece diversas ferramentas e serviços para a criação de uma Arquitetura de Dados eficiente. No entanto, para tirar o máximo proveito dessas ferramentas é ideal aplicar as boas práticas que foram sendo desenvolvidas e aprimoradas ao longo do tempo.
Neste artigo, discutiremos algumas práticas de Arquitetura de Dados e como seria um modelo para implementá-las na AWS. Começaremos explorando alguns padrões e depois para a escolha do serviço certo para cada necessidade identificada.
Padrões Populares de Arquitetura de Dados
Lambda Architecture
Lambda Architecture é uma arquitetura de processamento de dados distribuída que visa combinar as vantagens do processamento em batch e em tempo real para lidar com grandes volumes de dados em tempo real. Ela é composta por três camadas: Batch Processing Layer, Speed (Real-Time) Layer e Serving Layer, que permitem que os dados sejam processados e entregues para consumo de forma eficiente e precisa.
⚠ Lambda Architecure não é a mesma coisa que uma Arquitetura beaseada em AWS Lambda. Nesse caso, os nomes não ajudam muito na diferenciação.
A Lambda Architecture é útil para casos de uso em que a velocidade e a precisão dos dados são fundamentais e, por algum motivo, não são alcançáveis ao mesmo tempo, ou pelo menos não de uma forma eficiente do ponto de vista de custo. Se não fosse isso, não seria preciso fazer essa divisão.
Por exemplo, imagine um app de aluguel de motos. Por um lado, gostaríamos de saber em tempo real a localização da moto. Essa informação é especialmente útil para acompanhar as rotas e sugerir mudanças em tempo real, além da segurança da motocicleta e do motociclista. Por outro lado, precisamos também gerar as agregações semanais para emitir a geração de relatórios das motocicletas, bem como corrigir erros de envio de dado, duplicações, etc.
Nesse modelo, usar uma estrutura robusta o suficiente para suportar os dois casos de uso pode ser muito complexo e custoso, levando a um cenário onde a Lambda Architecture poderia ser utilizada para desacoplar as estruturas e maximizar o uso de cada ferramenta, especializando cada fluxo com ferramentas específicas.
Kappa Architecture
Kappa Architecture é uma arquitetura de processamento de dados distribuída que visa simplificar o fluxo de processamento de dados em tempo real, eliminando a necessidade da camada Batch Processing Layer, que vimos anteriormente no Lambda Architecture. Em vez disso, a Kappa Architecture utiliza apenas uma camada de processamento em tempo real (Real-Time Processing Layer) e um armazenamento de logs, por exemplo:
Suponha que uma empresa de comércio eletrônico deseja monitorar e analisar o comportamento do usuário em tempo real para identificar padrões e tendências em suas compras e usam um pipeline de dados baseado na Kappa Architecture para processar, armazenar e analisar esses dados em tempo real.
O pipeline começa com a ingestão de dados brutos, como registros de eventos do servidor da web e dados do carrinho de compras. Esses dados são enviados para um cluster de processamento de stream em tempo real, como o Apache Kafka, onde são armazenados em um tópico de streaming.
Em seguida, os dados são processados por meio de um mecanismo de processamento de fluxo em tempo real, como o Apache Flink ou o Amazon Kinesis Data Analytics for Apache Flink. Isso permite que a empresa analise os dados em tempo real e gere insights imediatos. Por exemplo, o sistema pode monitorar o comportamento do usuário para identificar padrões de compra e recomendar produtos relevantes com base nesses padrões, disparando por exemplo um webhook.
Veja uma exemplo de arquitetura Kappa utilizando Apache Kafka apresentada pelo Uber, responsável por processar mais de 4 Trilhões de mensagens por dia em 2021. Essa arquitetura passa por essas etapas de geração, tópico do Apache Kafka, processamento por várias ferramentas consumidoras, evitando a duplicação de código que geralmente acontece no Lambda Architecute:
Data Lake
Com os padrões Lambda Architecture e Kappa Architecture em mente, vamos dar um próximo passo nos padrões e falar sobre o Data Lake, talvez o mais comentado padrão de arquitetura de dados dos últimos anos.
Um Data Lake é um repositório centralizado de dados brutos e estruturados e não estruturados de várias fontes, incluindo dados de transações. Ele é projetado para armazenar dados em seu formato original e permitir que eles sejam acessados e processados por usuários e aplicativos, sem a necessidade de transformação prévia ou esquematização.
O objetivo de um Data Lake é fornecer uma fonte única de confiança de dados para análises de negócios e tomada de decisões. Possibilitando a agilidade no sentido de conseguir receber dados de fontes sem esquematização prévia, separação da estrutura de processamento e de armazenamento, além de ser compatível com diversas ferramentas de processamento de dados e análise.
As três camadas clássicas do Data Lake tem diversos nomes, dependendo da literatura seguida, como Raw, Clean, Curated ou Bronze, Prata e Ouro, etc. Nesse caso, o importante não é muito o nome da camada escolhida e sim o que elas representam.
Uma primeira camada é responsável por ser permissiva no sentido de suportar a escrita de fontes, para dar agilidade e também suporte. A primeira camada também costuma ter algumas características que não permitem a deleção, com objetivo de salvar fielmente todos os dados que em algum momento passaram por ela. Os casos de uso de deleção envolvem normalmente economia de custos, o que não é recomendado muito devido à possibilidade de armazenamento muito barato na nuvem voltado para arquivamento, e também quando a exclusão precisa ser feita por questões legais, como na LGPD. Nesse último caso, algumas técnicas podem ser utilizadas para alcançar tal comportamento.
A segunda camada de um Data Lake tem como principal propósito a organização e a preparação dos dados para serem utilizados em análises e tomadas de decisão. Nessa camada, é realizada a limpeza, transformação e integração dos dados provenientes de diferentes fontes, permitindo que os mesmos sejam consolidados e estruturados de forma padronizada e coerente. Costumo dizer que é a camada onde a empresa estrutura o seu padrão unificado, e dali pra frente, o esquema é mais controlado. Além disso, a segunda camada também é responsável por garantir a qualidade dos dados, por meio da verificação de integridade, validação e enriquecimento das informações.
A terceira camada de um data lake tem como propósito a análise avançada e extração de valor dos dados. Nesta camada, são aplicadas técnicas de processamento de dados mais sofisticadas, como machine learning, inteligência artificial e modelagem estatística, com o objetivo de descobrir padrões, tendências e insights relevantes para o negócio. A terceira camada é utilizada para estruturar os dados de modo a serem analisados em um banco de dados específico, como Data Warehouse, Data Mart ou banco de dados para análise de grafos e séries temporais. Além disso, é possível utilizar a terceira camada para disponibilizar os dados para ferramentas de visualização de dados e dashboards interativos.
Utilizando AWS para Arquitetura de Dados
Para implementar ambos os modelos na AWS, é possível utilizar uma combinação de serviços serverless e aproveitar o modelo pay-as-you-go. Por exemplo, o Amazon Kinesis pode ser usado para a ingestão de dados em tempo real, ou até mesmo o Amazon Managed Streaming for Apache Kafka (MSK). O Amazon S3 é o serviço principal utilizado para o armazenamento de dados, sendo o coração da maioria das implementações de arquitetura de dados. Para o processamento em tempo real, o Amazon Kinesis Data Analytics ou mesmo o Amazon Kinesis Data Analytics for Apache Flink podem ser usados, ainda tendo a possibilidade de utilizar o AWS Lambda para o processamento de alguns eventos e mensagens. Temos ainda o AWS Glue e Amazon EMR para o processamento de dados distribuídos com Apache Spark. Para fechar a lista, temos o Amazon Redshift como o banco de análise de dados e também o Amazon QuickSight para criar painéis e relatórios personalizados.
Para o próximo passo, veja como ficaria a Lambda Architecture na AWS:
Nesse caso, utilizamos o Kinesis Data Firehose para receber os dados em streaming e enviar simultaneamente para dois destinos: o Amazon S3, para compor a Batch Processing Layer, e um Amazon Kinesis Data Firehose, para iniciar a Speed (Real-Time) Layer.
Olhando para a Batch Processing Layer, o próximo passo seria executar jobs em Apache Spark utilizando o AWS Glue, que podem ser executados em uma frequência de tempo (1 em 1 hora, 6 em 6 horas, 12 em 12 horas, 1 vez por dia, etc.). Depois disso, os dados são armazenados no Amazon S3 e, em seguida, são carregados no Amazon Redshift para a realização da contabilização, limpeza e ajuste dos dados que serão visualizados pelo Amazon Quicksight.
Já a Speed (Real-Time) Layer, que inicia com o Amazon Kinesis Data Analytics for Apache Flink, permite a execução de transformações em tempo real utilizando o Apache Flink. Esse processo entrega de volta os dados para o Amazon Kinesis Data Firehose, que faz automaticamente o processo de salvar os dados no Amazon S3 e já envia o comando COPY para o Amazon Redshift carregar os dados e atualizar as tabelas oriundas da Speed (Real-Time) Layer. Nesse cenário, estamos considerando atualizações de dados no Amazon Redshift em milissegundos.
Para finalizar os componentes da Serving Layer, o Amazon Redshift foi utilizado nesse modelo por ser um banco de dados especializado em análise de dados, disponibilizando os dados via SQL para construção de dashboards no Amazon Quicksight.
Usando a mesma ideia, alguns ajustes podem ser feitos para transformar essa arquitetura em um formato de Kappa Architecture.
Exemplo de Kappa Architecture com serviços AWS: Nesse cenário, o Amazon Kinesis Data Stream envia os dados para o Amazon EMR, que utiliza o Apache Spark Streaming para processar os dados e enviá-los para o Amazon Redshift, que também será utilizado como fonte SQL para o Amazon Quicksight.
Para garantir o armazenamento dos logs, os dados brutos são enviados para o Amazon Kinesis Data Firehose, que automatiza o envio dos dados para o Amazon S3.
Já o padrão mais conhecido e utilizado, o Data Lake, tem uma lógica mais simples e pode ser implementado com o Amazon S3 para armazenamento, algum serviço de processamento de dados, o Amazon Redshift e o Amazon Quicksight para servir os dados, semelhante ao que foi descrito anteriormente.
Nesse caso, utilizamos um cluster do Amazon EMR para fazer o processamento entre as camadas do Data Lake. Ao final do processamento, o comando COPY é executado para enviar os dados para o Amazon Redshift. Por meio do Amazon Quicksight, as consultas são realizadas e as visualizações de dados são criadas.
Conclusão
A AWS oferece diversos serviços para implementar as arquiteturas mostradas aqui, desde a ingestão de dados em tempo real até a criação de dashboards personalizados. É importante destacar que nenhum serviço apresentado é uma solução definitiva para todos os cenários. Recomendo fortemente a realização de estudos, PoC’s e análises de custos e desempenho para escolher qual seria mais adequado para cada cenário específico. Dessa forma, é possível tornar essas soluções econômicas e escaláveis.
Em resumo, a Lambda Architecture permite a visualização de informações atualizadas em milissegundos. A Kappa Architecture é uma variação da Lambda Architecture que utiliza apenas serviços de processamento em tempo real. O Data Lake resolve o problema de armazenamento e processamento de grandes volumes de dados de diferentes fontes, utilizando o Amazon S3 como coração da arquitetura. Esses modelos podem ser adaptados às necessidades específicas de cada empresa, tornando a arquitetura de dados na nuvem uma solução flexível e eficiente para lidar com grandes volumes de informações.
Em futuros artigos, serão explorados tópicos importantes como Data Warehouse, Data Event-Driven Architecture, Data Mesh Architecture, entre outros. Caso haja interesse em aprender mais sobre algum tópico específico, deixe um comentário. Até a próxima!
Me Siga!
- Instagram: https://www.instagram.com/obernardo.costa
- LinkedIn: https://www.linkedin.com/in/obernardocosta
Recomendações de Estudo:
- Lambda Architecture: https://www.databricks.com/glossary/lambda-architecture
- Kappa Architecture: https://hazelcast.com/glossary/kappa-architecture/
- Kappa Architecture is Mainstream Replacing Lambda: https://www.kai-waehner.de/blog/2021/09/23/real-time-kappa-architecture-mainstream-replacing-batch-lambda/
- Lambda Vs Kappa Architecture: https://nexocode.com/blog/posts/lambda-vs-kappa-architecture/#:~:text=Lambda%20architecture%20uses%20two%20separate,to%20handle%20complete%20data%20processing.
- Como a AWS pode ajudar a coletar e processar grandes volumes de dados: https://medium.com/@bernardo.costa/como-a-aws-pode-ajudar-a-coletar-e-processar-grandes-volumes-de-dados-5e25ca3f858
- Documentação oficial da AWS sobre Engenharia de Dados: https://aws.amazon.com/pt/data-engineering/
- Tutorial da AWS sobre como criar um pipeline de dados com o AWS Glue: https://aws.amazon.com/pt/getting-started/hands-on/build-etl-pipeline-glue-databrew-sagemaker/
