Arquiteturas de Dados na AWS

Ao longo do ano passado, fiz alguns posts no LinkedIn sobre os serviços da AWS que trabalham com dados e alguns conceitos relacionados. Neste artigo, veremos como esses serviços se combinam para servir uma plataforma de dados: desde os aspectos de ingestão e armazenamento em data lake e data warehouse, até o consumo com a ideia de gerar valor por meios de analytics, business intelligence e machine learning.

Armazenamento

O primeiro passo é definir onde nossos dados serão armazenados. Vamos usar tanto um data lake quanto um data warehouse. A nossa estratégia será usar o lake como um repositório central de dados, onde teremos todos os dados armazenados. No warehouse, apenas os dados relevantes do ponto de vista da gestão estratégica.

Data Lake

Há diversas formas de se implementar um lake na AWS usando os mais diversos serviços. EMR com Spark, RedShift, um cluster EC2 com EFS. A opção com melhor custo-benefício é o S3.

Como o lake é descrito como um repositório central, podemos pensar nele como se fosse uma única coisa, mas na verdade ele é composto de camadas. Algumas arquiteturas no mercado usam 5 camadas: raw, standardized, cleansed, trusted e sandbox. A nossa será simples e terá duas:

• Raw — também chamada de Landing ou Ingestion Layer, armazenará os dados brutos, no seu formato nativo e sem nenhum tipo de transformação. Essa camada permite uma rápida ingestão, sem termos que nos preocupar com o processamento dos dados, e também nos habilita a recuperar os dados no seu formato de origem. Geralmente é uma camada que não é muito acessada, então dependendo da estratégia da companhia, faz sentido ter um uma política de lifecycle colocando os dados desse bucket no S3 Infrequent Access ou Glacier/Glacier Deep Archive.
• Cleansed — também chamada de Curated ou Conformed, é a camada de consumo para os usuários. Terá os dados tratados e processados num formato otimizado para armazenamento ou processamento, como o Parquet. A transformação dos dados entre a Raw e a Cleansed pode ser feita por um Lambda, que é disparado com um evento do S3 sempre que chegar um dado novo na Raw, ou também o Lambda combinado a um Job do Glue. A combinação Lambda + Glue tende a ser uma opção melhor porque evita a limitação de execução de 15 minutos do Lambda e o Glue permite a execução nativa tecnologias mais eficientes para um volume expressivo de dados, como o PySpark.

Com isso, nosso desenho fica assim:

Vamos adicionar também um componente importante que vai interagir com as camadas: o catálogo de dados do Glue. Nas palavras da própria AWS:

“O catálogo de dados do AWS Glue é um repositório central para armazenamento de metadados estruturais e operacionais de todos os ativos de dados. Para um determinado conjunto de dados, é possível armazenar a definição da tabela, a localização física e atributos relevantes para os negócios, bem como rastrear as alterações dos dados ao longo do tempo”

Além disso, a definição da tabela vai ajudar na integração com outros serviços: o Athena, o RedShift e o EMR. Isso vai ser feito usando um Crawler do Glue. O Crawler cataloga o esquema da tabela no Catálogo de Dados. Como o formato e a natureza dos dados variam, normalmente temos diferentes Crawlers associados a diferentes objetos armazenados nos buckets.

Um ponto importante também associado ao catálogo são as partições. O processo de particionamento no S3 limita o volume de dados escaneados numa consulta, automaticamente melhorando a velocidade e reduzindo custos.

As chaves (pastas) que contém os objetos armazenados no S3 são entidades físicas. Elas são mapeadas para partições, que são entidades lógicas, no catálogo de dados do Glue. O Athena e o RedShift Spectrum interpretam essas partições no catálogo e, assim, sabem quais diretórios são relevantes para uma consulta.

Existem diversas formas de se particionar um dado e boas práticas que guiam esse processo, mas na prática, a criação da partição é simples. Um exemplo:

s3://nome-bucket/nome-projeto/anomesdia=20210901/

O Glue interpreta essa estrutura e quando o dado for consultado no Athena, existirá uma coluna anomesdia com o valor 20210901 para todos os dados contidos dentro desse bucket

A arquitetura desse data lake possui uma beleza que você talvez ainda não tenha notado: ela é completamente serverless! Não é preciso provisionar ou gerenciar servidores!

Data Warehouse

Para encerrar a seção de armazenamento, vamos adicionar uma pseudocamada: o RedShift, como data warehouse. Em termos acadêmicos, o data lake contém diferentes tipos de dados que podem não ser amigáveis para o usuário, diferente de um data warehouse que armazena apenas dados estruturados e é consultado com SQL.

O data lake da nossa solução não tem esse problema, uma vez que os dados são convertidos para formato colunar (Parquet) na camada cleansed e ela pode ser consultada com SQL pelo Athena.

No entanto, o Athena e o RedShift atendem necessidades diferentes. O Athena foi projetado para rodar queries ad hoc, pontuais e simples. O RedShift é uma melhor solução para cenários de BI, onde temos tabelas muito grandes, queries complexas e com muitas junções que vão gerar um relatório corporativo — ele foi otimizado especialmente para trabalhar nesse tipo de cenário.

Os dados são transferidos para o RedShift usando a combinação que já vimos: Lambda + Glue Job.

Por fim, é possível usar o RedShift para consultar no S3 sem que seja necessário carregar dados nele, com o RedShift Spectrum. Essa é uma maneira de estender as consultas do RedShift a todo o universo do Data Lake sem se preocupar com o transporte dos dados. Importante apenas frisar que o Spectrum apresenta custo maior e perfomance pior em relação ao RedShift padrão.

Ingestão de dados

Agora que temos bem definido onde os dados repousarão e como serão organizados e gerenciados, precisamos pensar em como eles deverão chegar lá.

Há diversas maneiras de se ingerir um dado, vamos discutir alguns cenários:

• Big Data em tempo real
• SGBDs — Bancos de dados
• APIs externas
• Transferência de arquivos
• Carga histórica de volume de alta magnitude
• Cloud híbrida

Big Data em tempo real

Para esse cenário, vamos supor que queremos coletar dados de uma rede de casas inteligentes — as chamadas Smart Home, onde as luzes, o ar-condicionado, as portas, e todos os dispositivos eletrodomésticos e eletrônicos são interligados. Esse cenário representa bem os 3V’s do Big Data, com os dados sendo gerados a todo instante, num alto volume e com grande variabilidade do data set.

Os produtores de dados são dispositivos IoT. E para gerenciar tais dispositivos, a AWS oferece o IoT Core. Os dispositivos IoT poderão enviar dados em tempo real para o IoT Core e ele, também em tempo real, enviará os dados para o Kinesis Data Streams.

O Kinesis Data Streams captura esses dados e os envia para o Kinesis Data Firehose que, por fim, ingere os dados em nossa camada raw do Data Lake com performance near real-time.

Vale comentar que o Firehose poderia ter um Lambda associado para fazer algum processamento em tempo real. Se o nosso desenho fosse algum fluxo transacional que precisasse de regras de negócio aplicadas, ou nosso modelo de ingestão admitisse que os dados fossem ingeridos diretamente na camada cleansed, essa integração seria muito útil.

Essa arquitetura é simples, serverless e near real time.

SGBDs — Bancos de dados

Uma das principais fontes de dados para um lake ou warehouse, são bancos de dados transacionais. Esse também é um cenário simples de ingestão, por meio do DMS. Ele funciona com bancos de dados relacionais e bancos de dados noSQL.

Uma boa prática no processo de ingestão de um SGBD, é conseguir capturar os dados que foram inseridos ou atualizados. Isto é, uma vez que eu tenha feito a ingestão da carga histórica, eu não preciso ingeri-la novamente sempre que houverem novos registros, basta ingerir apenas o que for novo.

Isso pode ser obtido por meio de um CDC. Outra opção é escrever uma query no DMS com base em uma coluna que consiga sinalizar se são dados novos ou não. Dependendo da complexidade, o Glue pode ser usado.

Um case prático em que já tive que usá-lo: um conjunto de tabelas só estariam para captura quando uma tabela de controle emitisse um status. O Glue atendeu bem essa solução por dar mais liberdade de código do que o DMS.

APIs externas

Fornecedores de dados externos podem gerar dados via API. Vamos capturar esses dados usando um Lambda, que vai fazer a transferência para o S3. A periodicidade das consultas na API será tratada pelo EventBridge. Nosso Lambda pode, inclusive, receber do EventBridge os eventos que servirão de parâmetro para fazer a consulta na API.

Mas Lucas, essa ideia não vale também para APIs internas?

Vale! Mas se a origem de dados for a nossa própria companhia, faz sentido ir atrás da verdadeira fonte dos dados — por exemplo, um banco de dados.

Além das APIs, outra forma de se disponibilizar dados que está na moda é a fila de eventos, como o Kafka ou o RabbitMQ. A arquitetura para esse tipo de consumo pode ser pensada de duas formas:

1. Dados massivos em tempo real — cai numa solução como a primeira apresentada, usando Kinesis
2. Menor fluxo de dados — mantemos o Lambda . Porém, não é necessário o EventBridge, basta consumir o evento da fila.

Transferência de arquivos

Um cenário simples e direto: o AWS Transfer Family permite a transferência de arquivos para o S3 ou EFS usando os protocolos FTP, FTPS ou SFTP.

Carga histórica de volume de alta magnitude

Um cenário que pode ser desafiador, é a transferência do histórico de dados de um volume massivo de um ambiente on-premises. Nesse cenário, há duas estratégias factíveis:

Transferência on-line, por meio do DirectConnect

O DirectConnect, resumidamente, é uma conexão de rede dedicada e privada entre o ambiente AWS e um datacenter fora dele. É uma conexão direta, sem os vários intermediários que existem na conexão pela Internet. Isso proporciona maior taxa de transferência em uma rede que pode chegar até 100 Gbps

Transferência off-line, com a Snow Family

A Snow Family são dispositivos físicos que a AWS envia. Conectamos no nosso datacenter, transferimos os dados e enviamos de volta a AWS, que conectará em seus servidores e realizará a transferência para nosso ambiente cloud. É um cenário viável quando não é possível estabelecer a conexão do DirectConnect ou quando não temos interesse nesse tipo conexão — por exemplo, quando precisamos realizar apenas uma carga pontual.

Cloud híbrida

Em situações de cenário híbrido, quando parte da nossa infraestrutura está tanto na cloud quanto na AWS, e também durante a fase de migração para a cloud, há uma maneira atraente de se conectar nossa infraestrutura de armazenamento on-premises no S3: o Storage Gateway.

Por meio do Storage Gateway, um usuário — seja ele sistêmico ou humano, armazena e acessa um arquivo da AWS através de um ambiente on-premises sem perceber. Como queremos que o arquivo seja tratado como um objeto do S3, tendo os mesmos recursos como lifecycles e eventos, o tipo de gateway ideal é o File Gateway, que funciona com os protocolos SMB e NFS.

Uma outra possibilidade, já mencionada, seria ter o DirectConnect estabelecido. As operações não seriam tão transparentes como no Storage Gateway, mas também é uma opção viável.

Consumo dos dados

O desenho está praticamente completo: temos os caminhos pelos quais diferentes dados podem entrar e temos as estruturas que armazenarão e suportarão o uso desse dado. Agora falta a parte final, que é a que realmente gera valor para o negócio: o consumo.

Criação de dashboards

Duas formas de consumo já foram abordadas. O consumo direto pelo RedShift, criando fluxos de BI para gerar relatórios corporativos, e o consumo pelo Athena para consultas interativas mais simples — ambos em SQL. O resultado dessas consultas pode alimentar dashboards, como o Tableau ou o Quicksight, se quisermos ter a solução toda na AWS.

Data Science

Se na seção anterior vimos como os dados podem ser consumidos para analytics descritivo, aqui veremos com eles podem ser usados em técnicas mais avançadas, como machine learning, usando o SageMaker.

Usando um componente chamado SageMaker Data Wrangler, os dados podem ser importados do S3 (nosso Data Lake), do RedShift (nosso Data Warehouse) e do Athena (nossas consultas ad hoc). O Data Wrangler carrega, agrega e exibe automaticamente os dados não tratados. A partir daí, é possível usar os dados para criar um série de modelos usando os demais serviços contidos no SageMaker.

À critério de curiosidade, eu vou incluir na arquitetura um desenho que permite a criação de modelos de aprendizado supervisionado, tais como regressão, redes neurais e árvores de decisão, com o RedShift ML:

1. O Redshift exporta os dados de treino num bucket do S3
2. O SageMaker Autopilot automaticamente pré processa os dados.
3. O Redshift ML treina o modelo via SageMaker.
4. O SageMaker Autopilot procura e recomenda tanto o algoritmo de machine learning, quanto os parâmetros que otimizam as métricas avaliadas.
5. O Redshift ML armazena a saída do modelo com uma função SQL dentro do cluster do Redshift.
6. Essa função de machine learning poderá ser usada em uma consulta SQL!

A literatura é categórica ao dizer que os principais consumidores de um data lake, devido a sua natureza desestruturada, são usuários técnicos, especialmente os cientistas de dados. Portanto, esse é um público que, em alguns cenários, precisa ter acesso a camada Raw para trabalhar com os dados brutos.

APIs

O último case de consumo apresentado é a exposição de APIs. Essa forma de consumo é muito útil quase queremos restringir que o usuário acesse diretamente os dados — por exemplo, um usuário externo. Ele não terá a liberdade de criar as consultas, nem saber como as tabelas estão estruturadas. Em vez disso, ele acessará os métodos disponibilizados na API.

No nosso desenho, vamos criar dois paradigmas de API: RESTful e GraphQL.

Uma função Lambda invoca, programaticamente, a API do Athena, que realiza as consultas SQL na camada cleansed. O resultado pode ser exposto pelo API Gateway para fornecer um endpoint RESTful e também pode ser exposto pelo AppSync, gerando um endpoint GraphQL

Ambas as abordagens são completamente serverless.

Comentários finais

Nesse artigo criamos do zero a arquitetura para uma plataforma de dados na AWS. Abordamos algumas possibilidades de ingestão de dados, cobrindo desde pipelines de dados modernos para ingestão de fluxo massivo em real time, até pipelines on-premises para suportar estratégias híbridas ou de migração. Os dados repousam numa camada armazenamento, gestão e processamento de dados composta por um data lake e um data warehouse. E em último lugar, vimos maneiras em que esses dados podem ser consumidos para geração de valor.

Esse artigo é a parte 3 de uma série sobre arquiteturas na AWS. Confira as outras!

1. Arquiteturas clássicas na AWS
2. Arquiteturas serverless na AWS