Simple Serveless Data Lake
Autores
Introdução
Dados são a estrutura fundamental para a maior parte das empresas na atualidade. São neles que os insights de negócio vivem e são por eles que as empresas se destacam no mercado agressivo que domina nosso mundo. Nesse cenário, ser data-driven deixou de ser um diferencial para ser um essencial para empresas, desde startups até grandes enterprises multinacionais. A questão que reside é: Como ter uma abordagem voltada a dados de forma estruturada? Nesse artigo apresentamos a base para uma boa utilização de data analytics para o core de uma empresa.
Dor de Negócio
Muitas vezes, aplicações distintas vivem em ambientes substancialmente diferentes, contendo arquiteturas de dados próprias. Assim, existe uma dor quando necessita-se analisar dados de aplicações diferentes onde as arquiteturas do banco de dados dessas aplicações não são compatíveis entre si. Além disso, ao criar dashboards, visualizações de dados e demais operações analíticas em bancos transacionais, é gerado um crescimento (potencialmente exponencial) do uso desses bancos, necessitando um escalonamento horizontal por meio de réplicas de leitura, encarecendo a estrutura e reduzindo a sua eficiência.
Nesse cenário, como justificar um foco maior em dados quando estruturas de BI e analytics geram um peso operacional e financeiro mais agressivo do que o potencial retorno desse investimento?
A resposta para essa pergunta vem com uma estrutura apartada e dedicada para resolver esses desafios, centralizando os dados em um local único e permitindo uma descarga de responsabilidades de um banco transacional. Essa estrutura é chamada Data Lake!
Solução
O Data Lake é a estrutura responsável por centralizar fontes de dados distintas, tratar os dados, realizar transformações e provê-los para operações analíticas. Um Data Lake comumente é dividido em camadas, onde o dado navega sendo transformado e atingindo níveis distintos de refinamento. Na solução abordada nesse artigo, iremos explorar as camadas:
- Raw: nessa camada o dado está em seu formato puro, assim como foi ingerido da fonte de dados original. O intuito dessa camada é ter o dado não transformado para potenciais necessidades futuras, onde esse dado necessitaria ser consultado em seu formato original. Existem diferentes técnicas de ingestão de dados que dependem da necessidade do consumo dos mesmos, podendo ser real time (streaming) ou near real time ou até mesmo em batches (grupos de dados prefixados por tamanho ou tempo).
- Stage: nessa camada o dado passa por processos de limpeza, a fim de formatar a estrutura do dado e remover inconsistências que sejam danosas ao Data Lake e às transformações que ocorrerão nesse dado. O intuito da camada stage é ser uma camada intermediária onde o dado incrementalmente é higienizado e preparado para consultas analíticas.
- Clean: nessa camada o dado já limpo é validado por processos de Data Quality para assegurar que as técnicas aplicadas no processo de limpeza deixaram o dado confiável e bem formatado para consultas analíticas. Nessa camada, ferramentas de BI já podem conectar no Data Lake para consultas e visualizações.
- Analytics: nessa camada o dado passa por processos de transformações (ETL) que o deixam no formato final de consumo. Assim, dados na camada analytics não precisam passar por processos de transformação e modelagem dentro da ferramenta de BI para serem consumidos, melhorando a performance dessas soluções.
Ao passar pelas camadas, o dado é ingerido, limpo, validado, transformado e servido a aplicações analíticas. Dessa maneira, aplicações que demandam apenas de transações de leitura podem deixar de acessar a fonte de dados original e passar a acessar uma estrutura dedicada para isso. Finalmente, o Data Lake pode ter inúmeras fontes de dados distintas sendo ingeridas por métodos e formatos distintos.
Arquitetura
Existem diversas formas de implementar um Data Lake, variando da necessidade de consumo, volumetria de dados, preferências de arquitetura, dentre outros fatores. Uma abordagem muito comum é o desenvolvimento de uma arquitetura em um provedor de cloud, onde o provisionamento e gestão de recursos são simplificados e abstraídos. Nesse artigo, iremos abordar uma arquitetura AWS, que é provedor de cloud líder de mercado, possuindo um grande catálogo de serviços que suportam esse tipo de estrutura. Pensando em trazer uma melhor experiência de usuário, criamos uma arquitetura de Data Lake que preza pela simplicidade de utilização (apesar da complexidade da estrutura) e pela independência de servidores (serverless). Abaixo temos uma figura que ilustra essa arquitetura utilizando-se dos serviços AWS e modularizada em 3 partes.
Módulo de Ingestão
Esse módulo é responsável por realizar a ingestão e armazenamento dos dados na camada Raw. Para isso, o Amazon EventBridge é utilizado como trigger de ingestão indicando quando os dados devem ser consumidos em batch do database de origem. Toda a ingestão é orquestrada pelo Amazon Step Functions, que inicia disparando uma Função Lambda que lê os parâmetros de ingestão do banco NoSQL Dynamo DB, responsável por persistir parâmetros e metadados de ingestão, que também são replicados no Amazon S3. Em um segundo momento, o orquestrador dispara o DMS para criar a instância de replicação de dados, assim como a tarefa responsável por ingerir os dados do database de origem. O DMS utiliza os metadados do S3 para definir a tarefa de replicação de dados e utiliza o Secrets Manager para armazenar as credenciais de acesso do banco de origem de maneira segura. Finalmente, as instâncias de replicação são criadas dentro de uma VPC para garantir a privacidade e segurança dos dados. Uma vez que os dados são ingeridos para a camada Raw no S3, o orquestrador dispara um tópico SNS que notifica aplicações da atualização dos dados nessa camada.
Módulo de Limpeza e Qualidade de Dados
Esse módulo é responsável por aplicar técnicas de Data Quality e Data Cleaning nos dados ingeridos na camada Raw. Novamente, todo o sistema é orquestrado no Amazon Step Functions, que inicia disparando um job de Data Quality pelo Amazon Glue nos dados da camada raw, extraindo métricas e validando se o dado foi ingerido corretamente e no formato esperado. Em seguida, o dado é limpo por meio de uma Função Lambda de maneira incremental, sendo salvo na camada temporária Stage. O terceiro passo é disparar um novo job no Amazon Glue para verificar a qualidade de dados pós-limpeza, gerando mais informações de qualidade de dados no S3. Uma vez que as validações sejam aprovadas, o dado é movido por Função Lambda para a camada Clean. Essa camada é catalogada por um crawler do Amazon Glue, gerando um catálogo de dados. Finalmente, erros e inconsistências de qualidade de dados são reportados via SNS e são salvos no sistema de mensageria SQS para validações humanas. Todos os processos descritos são parametrizados no Dynamo DB.
Módulo de ETL
Esse módulo é responsável por extrair o dado da camada Clean, transformá-lo de acordo com regras de negócio e carregá-lo na camada Analytics. Para isso, um EventBridge realiza o trigger do processo de transformações por meio de um job no Amazon Glue, que utiliza os parâmetros de ETL do Dynamo DB. O job realiza a carga do dado na camada Analytics, onde ele é catalogado por um crawler, assim como na camada anterior.
Consumo
Em termos de consumo de dados, o Amazon Athena é utilizado para a realização de queries ad-hoc no S3 através do catálogo do Glue, realizando consultas SQL baseado em Presto nos arquivos armazenados. Essas queries podem ser consumidas dessa maneira ou conectados no Amazon Quicksight como ferramenta de BI.
Benefícios
O maior benefício de uma estrutura de Data Lake é a remoção de sobrecarga de responsabilidades do seu banco de dados transacional, permitindo que o mesmo seja usado primariamente para escritas e receba apenas leituras que sejam urgentes dentro do contexto das aplicações que o acessam. Além disso, ter os dados centralizados em um único ponto permite que insights de negócio sejam realizados sobre fontes distintas consolidadas em uma estrutura central. Finalmente, um Data Lake permite a democratização e governança dos dados, permitindo que equipes tenham acesso a informações sem precisar de ter acesso a bancos sensíveis.
Uma vez que construído com a arquitetura apresentada aqui, o Data Lake possui outros benefícios técnicos, como a alta escalabilidade por operar com serviços serverless, sem necessidade de gestão e provisionamento de máquinas. Dentro da AWS, essa arquitetura utiliza de serviços “pay as you go”, onde apenas é cobrado o uso de fato do serviço e não o seu provisionamento.
Customizações
A estrutura apresentada possui um forte embasamento no Serverless Data Lake Framework da AWS, adaptando a estrutura para abstrair e simplificar a utilização de um Lake sem a necessidade de um time especialista em engenharia de dados. Assim, os serviços apresentados são totalmente serverless para dar essa maior facilidade de gestão, entretanto, necessidades específicas levariam a adaptações da arquitetura para o melhor atendimento das dores de negócio. Seguem algumas possibilidades de customizações:
- Glue ou Elastic Map Reduce (EMR) no Data Clean: em alta escala, o Lambda não consegue atender pela limitação de memória RAM de processamento, nesses casos, esse componente pode ser facilmente substituído por um ETL em Glue ou EMR.
- EMR no ETL: assim como no caso anterior, o Glue não é um serviço muito indicado para casos de Big Data, assim, o EMR pode ser substituído pelo Glue nessa estrutura para comportar melhor ETLs massivos.
- Data Warehouse: outra modificação buscando maior escala (dessa vez em consultas de dados), seria a utilização do Redshift como Data Warehouse para dados quentes. Essa estrutura seria um complemento à camada Analytics com dados prontos para consumo, mas em escala massiva ou necessidade de consulta frequente.
- Delta Lake: em casos de bancos extensos com atualizações frequentes de dados, o Delta Processing seria essencial para evitar a carga completa de tabelas grandes a cada ingestão. Essa estrutura pode ser feita via Glue com ferramentas de mercado como Delta Lake, Hudi ou Iceberg. Assim, existe a necessidade de uma nova camada no Data Lake, sendo a “landing”, onde as atualizações de dados são enviadas.
A principal intenção do Data Lake criado é a modularização para permitir essa adaptabilidade sem ter que criar uma estrutura totalmente nova.
Conclusão
Atualmente, informação é um dos recursos mais valiosos para empresas, entretanto, somente dados não possuem valor se não for possível extrair informação deles de forma eficiente e de baixo custo. A solução do Data Lake permite essa análise de dados trazendo diversos benefícios como escalabilidade, custos baixos, centralização de dados e governança. Finalmente, a nuvem AWS prove uma suíte de serviços extensa para dar suporte à construção dessa arquitetura.
