Data Lake: o que é e quando construir.

O termo data lake tem se popularizado bastante nos últimos anos. Se mostrando uma estratégia extremamente acertada para centralização e distribuição de dados de diversos contextos para grandes empresas, mas afinal de contas o que é um data lake? Quais são os ganhos com a estrutura? Como devo estruturar um data lake?

O data lake não é uma tecnologia ou algo que você consiga pegar em uma prateleira, ele é um conceito de como os dados devem ser armazenados e distribuídos. Então, cada caso de implementação deve ser analisado e adequado à necessidade da empresa. A implementação pode variar, e muito, para cada necessidade, mas alguns pilares são essenciais para obter uma melhor performance da tecnologia.

Etapas e definições

Nesse primeiro parte do artigo será explicado quais critérios e estratégias guiaram um case de desenvolvimento de um data lake e como esses pilares com o auxílio de diversas tecnologias nos ajudaram a efetuar um trabalho que atendeu os requisitos solicitados.

Coleta dos dados

A forma como você deve extrair os dados para o data lake vai diferenciar da fonte e da periodicidade, mas temos critérios extremamente importantes sobre esse pilar. Deve ser fácil, seguro, escalável, possível de monitorar todas as etapas de extração, e o mais importante, agnóstico a fonte, ou seja, a estratégia definida para extração dos dados não pode considerar o dado em si para a extração.

Então, sendo um banco estruturado ou sem estrutura alguma, a sua metodologia de extração precisa atender a qualquer uma dessas necessidades. O output do formato dos dados é uma questão que deve ser considerada, mas isso vai depender um pouco da sua estratégia de inserção.

Inserção dos dados

Durante a implementação teremos diversos formatos de dados, imagens, vídeos, csvs, banco de dados, etc. A forma de fazer a inserção desses dados pode ser complexa, isso porque você não tem uma estrutura definida nos dados ou um schema de como esses serão inseridos.

Sua estratégia de inserção e persistência dos dados precisa ser flexível o suficiente para diversos formatos de dados, mas sem perder a integridade. Seja sua forma de persistência um banco de dados colunar ou estruturas nosql, o critério de integridade e facilidade de inserção e consulta deve ser atendido.

Segurança

Deve se atentar a forma como os dados são extraídos e inseridos. Vamos supor que tenhamos uma fonte de dados, por exemplo o google bigquey, em que é armazenado diversas informações sobre a navegação em nosso site e app. Caso seja necessário extrair essas informações, o script de extração precisará de credenciais para consulta dos dados no bigquery e credenciais para escrita dos dados no data lake. Nesse caso será preciso armazenar somente duas credenciais, mas quando falamos de uma estrutura em um cenário real, teremos centenas de credenciais com rotatividade e níveis diferentes de autenticação. Isso pode virar um caos caso não esteja bem definida a estratégia de fornecer e revogar credenciais para os scripts.

O mesmo se correlaciona as credenciais de consumo dos dados. É necessário criar um sistema de policies e um controle de como e o que pode ser acessado por determinada credencial, e até em alguns casos bilhetagem e demais controles.

Segurança é um dos pilares mais importantes na construção da estratégia de um data lake.

Tecnologias e Cloud

Como demonstrado, existem muitos problemas para se considerar na concepção e desenvolvimento de um data lake. Nessa parte do artigo iremos abordar mais a fundo tais problemas e demonstrar as possíveis soluções.

Quando falamos em escalabilidade e volume, automaticamente pensamos em cloud e as soluções que a mesma pode nos prover. Nesse intuito, e analisando as ferramentas de mercado, optamos por utilizar AWS e o ecossistema que ela nos fornece com alguns serviços essenciais para a arquitetura que demonstro abaixo:

Serviço de ETL e Secret Manager

Como expliquei na primeira parte deste artigo, segurança é um requisito essencial para obtenção de dados. Com isso em mente optamos por utilizar um serviço da AWS chamado secret manager. O secret manager é utilizado para gestão de credenciais, ou seja, para que nosso script seja capaz de coletar informações das nossas fontes, como bancos de dados, storages e etc. Ele precisa de ter, inicialmente, uma credencial IAM capaz de obter os valores do secret que o mesmo necessita. Com todas as credenciais necessárias o nosso script estará apto a executar e coletar as informações que necessitamos das fontes alvo.

Bom, como nosso script necessita de um ambiente de execução que consigamos monitorar e controlar cada instância de execução, seja ela diária, semanal ou mensal, e visando atender os controles necessários para um ambiente saudável e seguro de execução. Optamos por utilizar um cluster de kubernetes e convertemos nossos scripts em jobs do cluster. Com isso, conseguimos programar, criar métricas e logs das execuções de forma segura e escalável.

Uma vez nosso script em um ambiente controlado e seguro de execução é atrelado a pod de execução as credenciais com permissões de escrita no nosso bucket S3. O bucket S3 é utilizado para centralizar os dados extraídos por nosso jobs. É nele que escrevemos nossos csvs, parquets e etc. Em um ambiente controlado e seguro para os nossos dados, após a extração entra em cena uma ferramenta fantástica disponibilizada pela AWS o glue.

AWS GLUE

O serviço do glue nos auxilia a fazer a extração, transformação e carga dos dados de forma simples e extremamente performática. Uma vez que já disponibilizamos o dado no nosso bucket s3 é necessário a criação do que o glue chama de crawlers.

Os crawlers são responsáveis por mapear os nossos dados e fazer análises de tipagem e estrutura, criando assim metadados para facilitar a inserção em outras estruturas. Nesse caso optamos pelo Amazon RedShift.

Amazon RedShift é uma estrutura de banco de dados colunar baseado em postgres que oferece uma performance esmagadora e de alta escalabilidade para aplicações que demandam um alto volume de dados e de consultas. Com o cluster do RedShift conseguimos fazer nossa carga de dados utilizando o glue+s3 para uma estrutura que irá nos possibilitar consultas massivas de dados permitindo um alto consumo e utilização.

Para potencializar ainda mais a capacidade de consulta dos nossos dados, alheio ao amazon RedShift, utilizamos o serviço do amazon service elastic cloud. Com ele conseguimos disponibilizar uma api rest para toda a estrutura do nosso data lake e com isso evitamos que seja necessário a criação de views ou outras estruturas conectadas ao RedShift. Evitando, também, que usuários que necessitam de consumo os dados ali persistidos não tenham acesso a nossa base de dados central. Além disso, disponibilizando uma interface amigável para consumo dos dados em uma api e uma dashboard super amigável com o kibana.

Resumo

A estratégia por trás do armazenamento e consumo dos dados irá variar de acordo com a necessidade e com o tipo dos dados que você deseja armazenar e processar, mas alguns pilares são inerentes a qualquer um desses detalhes. Tendo em mente que segurança, escalabilidade e custo devem ser analisados a qualquer estratégia de arquitetura em cloud, a definição de tecnologias ou de como seus dados irão ser disponibilizados se torna mais fácil.

Alguns detalhes mais técnicos sobre a implementação em si ficaram resumidos para mantermos o artigo não tão massante, os mesmos serão detalhados e explicados em artigos futuros. Continue acompanhando!