Muito se fala em Data Lakes e seus benefícios para análise de dados nos últimos anos. Mas, quais as práticas que serão decisivas para o sucesso dessa arquitetura? Como construir os chamados “Future-proof Data Lakes”? A flexibilidade para armazenar os dados em storage distribuído como S3 e HDFS, pode ser um “tiro no pé” quando não se tem governança dos dados armazenados. Sem mecanismos que garantam manutenção de metadados, problemas como: mapeamento dos dados e a falta de visibilidade serão inevitáveis. Esses problemas afetam diretamente a credibilidade da solução e são os principais argumentos para que o projeto seja descontinuado dentro das empresas.

Neste artigo vamos apresentar uma funcionalidade muito interessante do serviço AWS Glue. Através de exemplos reais, mostrar como ele pode ajudar no gerenciamento de metadados para Data Lakes que usam o cloud storage S3.

Imagine uma tabela de eventos no banco de dados de produção, vamos chamá-la de: chatclub.events_users. Os dados sendo extraídos em CSV de forma incremental, compactados em formato gzip e enviados de hora em hora para o armazenamento do

S3.aws s3 ls s3://movile-data-lake/chatclub/events_users/2018/01/01/
 
2018-01-01 01:10 878430 data_events_users_20180101_00.csv.gz
2018-01-01 02:10 794392 data_events_users_20180101_01.csv.gz
2018-01-01 03:10 682514 data_events_users_20180101_02.csv.gz
2018-01-01 04:10 554772 data_events_users_20180101_03.csv.gz
2018-01-01 05:10 445256 data_events_users_20180101_04.csv.gz
2018-01-01 06:10 317237 data_events_users_20180101_05.csv.gz
2018-01-01 07:10 236152 data_events_users_20180101_06.csv.gz
2018-01-01 08:10 177058 data_events_users_20180101_07.csv.gz
2018-01-01 09:10 154010 data_events_users_20180101_08.csv.gz
2018-01-01 10:10 164315 data_events_users_20180101_09.csv.gz
2018-01-01 11:10 264474 data_events_users_20180101_10.csv.gz
2018-01-01 12:10 337594 data_events_users_20180101_11.csv.gz
2018-01-01 13:10 480577 data_events_users_20180101_12.csv.gz
2018-01-01 14:10 606479 data_events_users_20180101_13.csv.gz
2018-01-01 15:10 586493 data_events_users_20180101_14.csv.gz
2018-01-01 16:10 815496 data_events_users_20180101_15.csv.gz
2018-01-01 17:10 844243 data_events_users_20180101_16.csv.gz
2018-01-01 18:10 704873 data_events_users_20180101_17.csv.gz
2018-01-01 19:10 691475 data_events_users_20180101_18.csv.gz
2018-01-01 20:10 737410 data_events_users_20180101_19.csv.gz
2018-01-01 21:10 773941 data_events_users_20180101_20.csv.gz
2018-01-01 22:10 751738 data_events_users_20180101_21.csv.gz
2018-01-01 23:10 782241 data_events_users_20180101_22.csv.gz
2018-01-02 00:10 878613 data_events_users_20180101_23.csv.gz
2018-01-02 00:10 2110 data_events_users_manifest

Até o momento, são arquivos salvos no S3 apenas para backup.

Agora vamos “brincar” um pouco com o AWS Glue e sua funcionalidade de gerenciamento de catálogo. Resumidamente, vamos configurar o Glue para:

  • Descobrir dados através de crawlers;
  • Identificar, interpretar e classificar arquivos;
  • Gerenciar alterações através de versionamento.

Catalogando dados automaticamente através de crawlers

Acessando o console do AWS Glue. No item “Crawlers” do menu lateral, adicione um novo crawler com as seguintes propriedades:

1) Nome do crawler:

Captura de Tela 2018-03-12 às 17.06.11

2) Tipo de armazenamento e caminho do S3. Neste passo estamos ignorando o arquivo de MANIFEST, que é importante para facilitar a carga dos dados no Redshift, por exemplo:

Captura de Tela 2018-03-12 às 17.06.34

3) Definir uma role AWS que será utilizada pelo crawler. Essa role deve ser criada através do IAM, contendo políticas de acesso ao serviço Glue (baseada na política AWSGlueServiceRole) e acesso ao bucket S3 (baseada na política AmazonS3ReadOnlyAccess):

Captura de Tela 2018-03-12 às 17.06.45

4) Definir o agendamento. Neste caso, o crawler será iniciado no minuto 15 de cada hora. Considerando que os dados são enviados para o S3 no minuto 10, em alguns minutos teremos os dados catalogados:

Captura de Tela 2018-03-12 às 17.06.56

5) Definir o banco de dados de metadados do Glue. Neste passo é possível criar um novo banco de dados ou listar existentes:

Captura de Tela 2018-03-12 às 17.07.10

Após um resumo da configuração, o crawler será criado. Mesmo com o agendamento é possível rodá-lo sob demanda:

Captura de Tela 2018-03-12 às 17.07.22

Concluída a execução do crawler, vamos analisar os metadados.

Ajustando os metadados pelo Glue

No menu lateral, selecionando “Tables”, teremos a tabela chatclub_events_users no database data-lake-metadata:

Captura de Tela 2018-03-12 às 17.07.32Ao selecionar a tabela, todo o metadado identificado pelo crawler é listado:

Captura de Tela 2018-03-12 às 17.07.48Captura de Tela 2018-03-12 às 17.07.58

Observe que os últimos 3 campos foram criados pelo Glue para definir as partições por ano, mês e dia, seguindo a estrutura dos arquivos no S3. Porém, cabe um pequeno ajuste no nome e no tipo dos campos para facilitar a análise dos dados.

Nessa mesma tela, podemos modificar os nomes e tipos dos campos no botão “Edit Schema”, no canto superior direito.

Versionamento de alterações do metadado

Após a modificação, conseguimos validar fazendo um comparativo de versões do metadado, em “Compare Versions”:

Captura de Tela 2018-03-12 às 17.15.10.png

Com os dados no Data Lake e metadados bem definidos, podemos consultar os dados de diferentes maneiras. Dentre os mais conhecidos recursos podemos citar Hive, Presto, Athena e Redshift Spectrum.

Neste artigo vamos consultar os dados do S3 através do AWS Athena e Redshift Spectrum.

Consultando o Data Lake através do AWS Athena

O Athena é um serviço que lê o catálogo gerado pelo Glue e possui um console para execução de queries sobre os dados do S3.

Captura de Tela 2018-03-12 às 17.15.26

Podemos observar no menu lateral que o banco de dados e a tabela aparecem automaticamente no Athena. No momento da consulta os dados foram interpretados corretamente (schema on read).

Consultando o Data Lake através do Redshift Spectrum

O Redshift Spectrum também utiliza a base de metadados do Glue. Para utilizar é preciso criar um SCHEMA com referência ao banco de dados criado no Glue:

CREATE EXTERNAL SCHEMA IF NOT EXISTS "data-lake-metadata"
FROM DATA CATALOG
DATABASE 'data-lake-metadata'
iam_role 'arn:aws:iam::3216722291010:role/movile-redshift-glue'
CREATE EXTERNAL DATABASE IF NOT EXISTS;

É preciso criar uma role para o Redshift, com permissões para o S3 e Glue.

Com o schema criado no Redshift, para ter o mesmo resultado da consulta do Athena, foi necessária apenas uma alteração na função que interpreta JSON:

SELECT event,json_extract_path_text(params, 'Page Name') AS page_name,params
FROM "data-lake-metadata"."chatclub_events_users" 
WHERE year = 2018
AND month = 01
LIMIT 10;

As partições passam a ser consideradas colunas comuns da tabela. Para melhor desempenho é fundamental filtrar pelas partições.  

Nos próximos tutoriais vamos ver na prática como criar jobs de ETL através do Glue, otimizar o acesso aos dados do S3 convertendo o CSV para um tipo de dado colunar.

Lembrando que a Movile estará presente no QCon 2018 com a palestra “Data Lake além da buzzword“, onde vou falar do AWS Glue e outras ferramentas do universo de Data Lake, compartilhando as lições aprendidas durante a arquitetura e execução do projeto.

Consultor em banco de dados com 10 anos de experiência em ambientes open source OLTP e OLAP. Atualmente como Líder Técnico da área de Data Engineering na Movile. Nos últimos 2 anos atuando com arquitetura e implementação de diversas tecnologias do universo Big data.

Posted by:Matheus Espanhol

Consultor em banco de dados com 10 anos de experiência em ambientes open source OLTP e OLAP. Atualmente como Líder Técnico da área de Data Engineering na Movile. Nos últimos 2 anos atuando com arquitetura e implementação de diversas tecnologias do universo Big data.

Deixe seu comentário