Os bancos de dados relacionais tradicionais são muito úteis para o armazenamento de informações, porém chega um momento onde dar um próximo passo é necessário.
Quando a diversidades de fontes e o volume de dados cresce, o uso de Data Lakes representa uma evolução importante.
Esse processo pode parecer complicado no começo, por isso resolvemos compartilhar o que aprendemos na nossa jornada, com um passo a passo e dicas para criação de um Data Lake na AWS.
Introdução
Com o avanço das nossas operações e o aumento do volume de diferentes fontes de dados, problemas no armazenamento começaram a surgir, seja pela constante mudança do esquema, pela adição ou remoção de atributos, ou ainda pela mudança de formatação desses atributos. Rapidamente, tornou-se necessária a migração do modelo tradicional (Data Warehouse), até então adotado, para um esquema sem restrição ou estrutura (Data Lake).
O objetivo desse artigo é mostrar como fizemos isso, utilizando as ferramentas que a AWS disponibiliza. A ideia não é explicar detalhadamente cada serviço, por isso é ideal que você esteja familiarizado com os termos e ferramentas, sendo elas:
- Lake Formation
- S3
- AWS EMR
- AWS IAM
- AWS Glue
- AWS Athena
Se você, sua empresa ou startup está passando por desafios parecidos, esse artigo pode ser bem útil!
Data Warehouse vs Data Lake
Importante destacar que a utilização dos dois modelos não é mutuamente excludente.
Em um modelo de Data Warehouse dados de diferentes fontes são armazenados de maneira estruturada e estática, de modo que essa estrutura é pensada, a priori, com base no tipo de análise que será feita. Com o surgimento do Big Data, em que existem uma gama maior de fontes de dados, tais como mídias sociais, logs, sensores, bancos de dados externos, e tudo isso em um grande volume, a definição do tipo de análise que será feita para o armazenamento desses dados em um modelo estruturado é extremamente complexo de ser realizado de início.
É neste cenário que surge o Data Lake. Um repositório de dados que busca armazená-los de maneira bruta onde a utilização dos dados será definida posteriormente. Por não haver restrição de esquema ou estrutura, as análises que podem ser feitas por meio de um Data Lake tornam-se muito mais flexíveis.
Entretanto, é importante destacar que a utilização dos dois modelos não é mutuamente excludente, é comum que os dados depois de serem processados dentro do Data Lake, sejam transferidos para um Data Warehouse para serem armazenados de maneira permanente.
Como criar um Data Lake usando a AWS
Para esta tarefa usamos um serviço na AWS chamado Lake Formation. Todos os passos para a criação do Data Lake através desse serviço estão documentados de maneira completa nos manuais criados pela Amazon que serão citados ao decorrer desse artigo.
Entretanto, alguns detalhes importantes da implementação serão destacados para guiar a busca pela documentação oficial da AWS de maneira mais ágil. Destacaremos também pontos de como fizemos para o nosso caso em específico e alguns detalhes que devemos nos atentar na documentação.
1. Criar um bucket no S3 para armazenamento dos dados.
O primeiro passo é a criação dos buckets em que os dados serão armazenados. Os diferentes buckets criados representam diversas etapas de processamento dos dados, desde a aquisição dos dados brutos, até a disponibilização da forma pronta para consumo das aplicações, de forma que as mudanças possam ser monitoradas e toda a base de dados possa ser reconstruída a partir de qualquer ponto.
É bastante comum a criação de três buckets para organizar o fluxo de dados dentro do Data Lake. O primeiro é criado para os dados crus, que são inseridos direto da fonte sem nenhum processamento. Um segundo bucket é criado para que esses dados sejam processados e convertidos para o formato mais adequado (Como o Apache Parquet). Por fim, o terceiro bucket serve para os dados prontos que serão utilizados em produção.
No nosso caso criamos apenas dois buckets: um para os dados crus e outro para os dados processados. A função do terceiro bucket é cumprida por um banco de dados relacional (Aurora), que armazena os dados que serão utilizados em nossas aplicações.
Além disso, também é interessante criar uma política de ciclo de vida para os dados armazenados nos buckets. A criação dessas políticas é crucial em cenários de grande massa de dados para que aqueles menos acessados sejam armazenados de maneira menos custosa no S3.
Não utilizar “.” para separação de palavras no nome do bucket e nem no nome das colunas da tabela, pois o AWS Athena não consegue lidar com essa pontuação, exemplo: Usar teste-lake ou teste_lake ao invés de teste.lake para nomear o bucket.2. Migrar os dados históricos a partir do antigo Banco de Dados Relacional.
Como no nosso caso já existia um processo de armazenamento, que foi substituído pelo Data Lake, tivemos que trazer os dados históricos para o novo modelo.
Todos os dados históricos que já foram inseridos no antigo banco foram transferidos para o S3. Para isso, utilizamos um blueprint do Lake Formation, que nada mais é que um workflow pré-escrito que facilita a ingestão de dados de outras fontes, como um banco de dados ou dados do CloudTrail para os buckets desejados.
Os dados foram inseridos originalmente no bucket destinado aos dados processados. Entretanto, antes da realização do ETL, uma cópia dos dados sem nenhuma modificação foi criada dentro do bucket destinado aos dados crus, caso o Data Lake precise ser reconstruído.
Para trazer os dados, seguir o tutorial da AWS do capítulo “Tutorial: Creating a Data Lake from a JDBC Source in Lake Formation”, antes de dar prosseguimento ao tutorial, se atente às seguintes informações:No passo 2, o formato do link JDBC para o MySQL é jdbc:mysql://xxx-cluster.cluster-xxx.us-east-1.rds.amazonaws.com:3306/employee, sendo employee o schema da conexão, para mais informações sobre conexões do glue, ler este documento.No passo 3 e 4, o bucket registrado será o bucket previamente criado para armazenamento dos dados processados.As informações sobre VPC utilizadas durante a criação da conexão no passo 2 foram escolhidas em consonância com as configurações do banco já existente:
Antes de seguir para o passo 5, ler o capítulo “Lake Formation Personas and IAM Permissions Reference” e em seguida o capítulo “Setting Up AWS Lake Formation”, principalmente subseção “Create an IAM Role for Workflows” que mostra o passo a passo de criar o IAM Role responsável por executar todos os processos necessários para inserção dos dados.Antes de executar o workflow recém criado no passo 8, é necessário realizar duas configurações de VPC.
3. Criar um endpoint para o S3 na VPC
Para acessar o S3 de dentro da VPC é necessário criar um endpoint para este serviço. Para mais informações sobre endpoints ler esta documentação.
- Dentro do console de VPC da AWS no menu VIRTUAL PRIVATE CLOUD à direita da tela, selecionar Endpoints, logo abaixo de Managed Prefix Lists.
- Selecionar o botão azul Create Endpoint na parte superior da tela, ao lado do botão Actions.
- Em Service Category verifique se a opção AWS services está selecionada, caso não esteja, selecione e procure por S3 na barra de busca do Service Name.
Em seguida, selecionar a VPC usada na conexão do AWS Glue e selecionar a check box de route tables.
Por último, na seção de políticas, deixe a opção Full Access selecionada. O AWS Glue cria alguns buckets temporários no S3 para o armazenamento dos scripts do workflow, e para armazenar dados temporários durante a sua execução. Portanto, caso sejam dadas permissões apenas para os dois buckets criados para dados crus e dados processados, a execução do workflow retornará acesso negado ao S3.
4. Configurar os acessos do AWS Glue à VPC
Além de criar um endpoint, também é necessário configurar a VPC para que o AWS Glue consiga acessar o banco de dados, para isso, seguir este tutorial. O caminho até a tela de configuração está um pouco diferente, portando seguir o referido tutorial a partir do passo 5, para chegar até a tela indicada no tutorial:
- Na tela inicial do AWS RDS, selecionar DB Instances dentro do painel Resources.
- Selecione o banco de dados que será utilizado pelo AWS Glue.
- Dentro do painel Connectivity & security na seção de Security, clicar no link do grupo de segurança sendo utilizada pelo banco de dados em VPC security groups.
- Dentro do console de Security Groups, trocar a aba de Details para a aba Inbound rules na parte inferior da tela.
- Clicar no botão Edit inbound rules no canto superior direito do painel.
- Seguir o tutorial citado anteriormente, de maneira normal.
Para obter o s3-prefix-list-id citado no passo 8 do tutorial, executar o seguinte comando do AWS CLI no CMD do Windows ou no Terminal do Linux: aws ec2 describe-prefix-lists.5. Criar políticas de acesso aos buckets
Para executar o processamento e a transferência dos dados entre os buckets, é necessário conceder permissões de leitura e escrita para os serviços que acessarão os buckets criados.
É importante que as permissões sejam concedidas seguindo o princípio de permissões mínimas da AWS, ou seja, que sejam concedidas apenas as permissões pontuais e mínimas necessárias para o correto funcionamento de todo o processo.Neste caso, serão criadas políticas de acesso aos buckets. Para que as funções lambda e o airflow consigam ler e escrever os dados necessários, no bucket com dados crus, temos a seguinte política:
{
"Version": "2012-10-17",
"Id": {ID},
"Statement": [
{
"Sid": {Sid},
"Effect": "Allow",
"Principal": {
"AWS": {ARN AIRFLOW ECS ROLE},
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::{s3 bucket name}",
"arn:aws:s3:::{s3 bucket name}/*"
]
},
{
"Sid": {Sid},
"Effect": "Allow",
"Principal": {
"AWS": "LAMBDA FUNCTION ARN"
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::{s3 bucket name}",
"arn:aws:s3:::{s3 bucket name}/*"
]
}
]
}Para o bucket com os dados já processados, temos a seguinte política:
{
"Version": "2012-10-17",
"Id": {ID},
"Statement": [
{
"Sid": {Sid},
"Effect": "Allow",
"Principal": {
"AWS": {ARN AIRFLOW ECS ROLE}
},
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::{s3 bucket name}",
"arn:aws:s3:::{s3 bucket name}/*"
]
}
]
}6. Criar Crawler dos dados no AWS Glue
Para que os dados sejam acessados pelo AWS Athena, e querys possam ser feitas sobre os dados armazenados nos buckets é necessária a criação de um crawler no AWS Glue. Esse crawler irá escanear os dados dentro do bucket apontado e gerará um catálogo que será acessado posteriormente pelo AWS Athena.
Sempre que houver alguma mudança da estrutura dos dados, o crawler deverá ser executado novamente, para que as alterações sejam detectadas e transmitidas ao AWS Athena. O crawler pode ser construído da seguinte maneira:
- Dentro do console, no menu a direita da tela, dentro de Data Catalog, selecionar a opção Crawlers.
- Clicar no botão azul Add crawler na parte superior da tela, ao lado dos botões Run crawler e Actions.
- Adicionar o nome desejado para o crawler.
- Caso o crawler deva ser executado a partir de um catalogo de dados já existente, selecionar Existing catalog tables, do contrário, caso o crawler vá ser executado a partir de um bucket, selecionar Data stores.
- Caso tenha sido selecionada a opção Data Stores no passo anterior, selecionar a fonte de dados e o caminho dos dados, caso tenha sido selecionada a opção Existing catalog tables, adicionar as tabelas que devem ser rastreadas.
- Selecionar a IAM Role que foi utilizada pelo workflow durante a inserção dos dados do banco para s3.
- Selecionar a frequência de execução desejada do crawler.
- Definir o comportamento de output do crawler (opcional), revisar todos os passos anteriores e criar o crawler.
Todos os arquivos abaixo do nível selecionado serão crawleados, por exemplo, caso o caminho escolhido seja s3://bucket-teste/dados-lake/ todas as subpastas e arquivos dentro da pasta dados-lake serão rastreados.Para executar o crawler, basta voltar para a tela de Crawlers acessada no primeiro passo, selecionar o crawler criado.
Para executar o crawler é necessário adicionar uma política de acesso ao bucket dentro da IAM Role selecionada durante a criação do crawler.Após a execução com sucesso e criação do catálogo de dados pelo AWS Glue, os dados já podem ser analisados utilizando o AWS Athena.
Conclusão
É sempre importante avaliar os problemas e adotar a estratégia que melhor se encaixa na sua solução. Apesar dos bancos relacionais tradicionais serem úteis, alguns desafios surgem quando as fontes e o volume de dados aumentam. Para o nosso caso, a inclusão de um novo modelo de armazenamento no processo foi o caminho mais adequado.
No geral, nossa arquitetura final para o Data Lake e processo de armazenamento conta com as seguintes etapas:
- Extração dos dados e armazenamento de forma bruta no s3
- Processo de transformação orquestrado pelo Airflow
- Armazenamento do dado processado em outro bucket no s3
- Armazenamento do dado pronto para ser consumido pelas aplicações num Data Warehouse
- Catalogação dos dados do s3 pelo AWS Glue
- Criação de um schema e tabela no Athena
Caso tenham alguma observação ou dúvida, não deixem de comentar ou entrar em contato conosco!
