O blog da AWS

Integrando o Amazon EMR com o Amazon Redshift

Antigamente dados analíticos eram analisados com base nas técnicas de Business Intelligence (BI) utilizando bases relacionais, pois basicamente os sistemas provedores ou sistemas fontes como são conhecidos em BI (sistemas que a empresa usa para controle de estoque, financeiro, CRM, etc) são armazenados em bases relacionais e esta era a única forma de analise. As bases de “Data Warehouse” (DW), como são conhecidos estes tipos de ambiente, concentram todos os dados da empresa formando assim uma visão única do negócio e dando o poder de analisar o todo. A escala de dados deste tipo de ambiente gira em torno de Terabytes (TB) e sua manutenção e escala em ambientes on premises é complexa dada quantidade de máquinas que são necessárias para armazenar esta quantidade de dados. O consumo destes dados se dá em sua maioria a partir de ferramentas de visualização de BI em relatórios pré definidos ou também, para um grupo menor de usuários, o acesso via consultas SQL.

Atualmente além dos dados relacionais, visando enriquecer a análise, usamos dados não relacionais, como dados de sensores e logs, e dados semi estruturados que normalmente não faziam parte do DW da companhia, como por exemplo dados de clima, demografia, censo e redes sociais. Estes dados não faziam parte deste ambiente por serem dados muito complexos de adquirir e carregar nas bases relacionais.

Este conceito de análise mais ampla que utiliza diversas fontes é chamado de Data Lake que se tornou comum atualmente dada a facilidade de aquisição, tratamento e execução que os ambientes de Big Data trouxeram para as empresas. Outra coisa que os Data Lakes trouxeram foi a possibilidade de utilizar dados próximos ao tempo real, criando assim um ambiente completo, ágil e muito útil no auxílio à tomada de decisão, na criação de campanhas e etc.

Com isso, ambientes de Data Lakes são conhecidos por armazenarem Exabytes (EB) até Petabytes (PB) de dados e também por adicionar novos motores analíticos baseados em Hadoop, Spark, Hive, Presto e etc que permitem o acesso e tratamento destes dados. Porém engana-se quem pensa que os ambientes de DW deixaram de existir com a chegada dos Data Lakes. Na verdade, estes ambientes são complementares e a união destes conceitos forma uma a visão ainda mais completa da empresa e entregando aos tomadores de decisão relatórios ainda mais completos e em menos tempo.

Se ambientes de DW on premises já são considerados complexos e caros por conta de todo licenciamento e em sua manutenção dos servidores, imagine ambientes de Data Lakes que têm uma escala muito maior. Neste post vamos mostrar como a AWS auxilia os clientes a manter ambientes complexos com um custo reduzido.

A AWS fornece um portfólio de serviços abrangente, seguro, escalável e econômico que permite que os clientes criem seu data lake na nuvem e analisem todos os seus dados com o mais amplo conjunto de abordagens analíticas. Como resultado, há mais organizações executando seus data lakes e análises na AWS do que em qualquer outro lugar, confiando na AWS para executar suas cargas de trabalho de dados analíticos. Você pode conferir alguns cases clicando aqui.

Entre os itens do portfólio analítico da AWS estão o Amazon EMR (Elastic Map Reduce) que é a plataforma de Hadoop gerenciado da AWS e o Amazon Redshift, uma base colunar específica para cargas de trabalho de DW e é sobre eles que vamos falar neste post.

Amazon EMR

O Amazon EMR é uma plataforma de Hadoop gerenciado pela AWS que permite a criação de clusters Hadoop sem que você tenha necessidade de conhecer a fundo a instalação dos componentes do cluster pois os templates do EMR possibilitam que você possa escolher para instalação os itens mais comuns utilizados em clusters Hadoop e assim que o cluster estiver no ar todos os itens escolhidos estarão instalados e prontos para o uso.

Características Importantes:

  • Os templates são mantidos pela AWS e atualizados constantemente e você pode escolher entre as várias versões conforme sua necessidade.
  • Possibilidade de instalar pacotes diferentes dos presentes no template (com o cluster no ar ou por bootstrap (ingestão de um script para instalação) durante a criação do cluster.
  • Escolher a quantidade de nodes master, garantindo o failover do mesmo em caso de falha.
  • Cluster transiente, ou seja, só esteja ligado pelo tempo que tiver que existir evitando que você tenha que pagar por um cluster que não precisa ficar ligado o tempo todo. Para isso duas coisas são fundamentais:
    • Uso do catálogo de metadados do Glue (ficando livre para que você escolha usa-lo no Hive, Spark ou Presto);
    • Possibilidade de ler e escrever dados no Amazon S3;
  • Durante a configuração, também é possível escolher se o cluster ficará ativo até que você o termine ou se ele terá termino automático ao final de uma execução (Steps), isto é, servirá apenas para a execução de uma carga de trabalho específica (Ex: um ETL ou uma transformação agendada) e em seguida este cluster é terminado garantindo que você pague apenas pelo tempo de execução.

Veja abaixo algumas das opções de inicialização do cluster EMR:

Outros itens que tangem a melhor utilização dos recursos computacionais e com isso um melhor aproveitamento do seu orçamento são a escalabilidade automática do cluster, que permite que seu cluster aumente e diminua automaticamente os recursos computacionais (quantidades de nodes) baseado em políticas definidas por você garantindo que os picos de utilização serão absorvidos e que quando não houver uma utilização expressiva você pode manter o mínimo do seu cluster gerando economia em seu orçamento.

Também é possível utilizar instâncias reservadas com economia de até 75% no preço final (com contratos de 1 ou 3 anos) ou mesmo usando instâncias Spot, que são capacidades computacionais não utilizada que a AWS oferece com descontos de até 90% sobre o preço regular. O uso combinado destas duas formas de pagamento possibilitam o melhor custo total de operação (TCO).

Resumindo, com o Amazon EMR você pode:

  • Clusters transientes ou de longa duração;
  • Escalabilidade baseadas em políticas pré-definidas ou manualmente;
  • Suporte Hadoop e Spark incluídos;
  • Uso de instâncias Spot;
  • Os dados podem utilizar o HDFS do cluster ou usar a integração com o S3 para acesso aos dados e persistência de resultados (ou ambos ao mesmo tempo);
  • Integração com catálogo de metadados do Glue (para Spark, Hive e/ou Presto);
  • Monitore o desempenho seu cluster via Amazon Cloudwatch e audite via AWS Cloudtrail.
  • Monitoramento automatizado para substituição automática de nós em caso de problemas;
  • Criptografia em repouso e em trânsito;
  • Isolamento de rede via VPC (Virtual Private Cloud);
  • Controle acessos e permissões via IAM (Identity and Access Management), integração com Microsoft AD ou Kerberos.

Amazon Redshift

O Amazon Redshift é uma base de dados colunar específica para cargas de trabalho analíticas. Considerado como uma arquitetura MPP (Massive Parallel Processing) ou Shared Nothing (onde as cargas de trabalho de um nó de não influem nos outros), o Redshift divide a carga de trabalho entre os nós e com isso alcança escalas de Exabytes de dados com extrema performance. A arquitetura abaixo mostra a arquitetura interna do Redshift.

O Leader Node recebe as conexões, armazena os metadados das tabelas, estatísticas das mesmas e cria os planos de execução das consultas. Ele é o orquestrador do ambiente do Redshift que repassa aos Compute Nodes as tarefas do plano de execução. Apenas os Compute Nodes são cobrados e contados como nodes do cluster, ou seja, o Leader Node não conta como processamento e por isso não é cobrado.

Outra característica do Amazon Redshift é que através do Redshift Spectrum é possível acessar dados que estejam no Amazon S3 e que estejam catalogados no catálogo de metadados do Glue. Com isso, o Redshift tem acesso aos mesmos dados que acessamos via Athena ou mesmo EMR (desde que esteja usando o catálogo de metadados do Glue) mantendo assim uma única visão dos dados de seu Data Lake no Amazon S3 evitando duplicidade dos mesmos e gerando economia.

Com o Redshift Spectrum é possível acessar os dados de seu Data Lake no Amazon S3 e também colocar os dados históricos do seu cluster de Redshift no Amazon S3 e acessá-los quando necessário, mantendo o seu cluster com apenas os dados que realmente importam e com isso gerar economia na sua conta AWS.

Resumindo, o Amazon Redshift oferece:

  • Cargas de dados analíticas de extrema performance;
  • Desde Gigabytes até Exabytes de dados;
  • Arquitetura MPP (aumento de performance linear com o aumento de nodes no cluster);
  • Acesso aos dados do seu Data Lake em S3 e acesso ao armazenamento de dados históricos no S3 através do Redshift Spectrum;
  • Redshift Spectrum suporta arquivos Parquet, ORC, AVRO, Grok ou CSV;
  • Manutenção Inteligente com Auto Analyze (coleta de estatísticas), Auto Vacuum (recuperação de espaço em disco) e Auto WLM (Workload Management – gerenciamento automático decargas de trabalho);
  • Concurrency Scaling – escala seu cluster automaticamente para resolver picos de processamento resolvendo filas de consultas. Para cada 24h que seu cluster fica ligado você tem direito a 1h de uso do Concurrency Scaling de forma gratuita.
  • Redimensionamento Elástico – para quando você precisa aumentar ou diminuir seu cluster em poucos minutos;
  • Execução de Stored Procedures em PL/PgSQL.

Formas de integrar o Amazon EMR, Amazon Redshift e o Amazon S3

Integração através do comando “Copy”:

O comando copy carrega na base de dados do Redshift dados de diversas fontes de dados como Amazon S3, Amazon EMR (HDFS), Amazon DynamoDB ou mesmo de algum servidor remoto via SSH para o Amazon Redshift, materializando estes dados em tabelas do Amazon Redshift. São necessários basicamente 3 parâmetros para realizar um comando copy:

  • Nome da tabela;
  • Endereço da fonte de dados (Amazon S3, Amazon EMR (HDFS), Amazon DynamoDB ou SSH);
  • Autorização, como função de acesso (IAM_ROLE) ou usando as chaves (ACCESS KEY e SECRET KEY).

Exemplo de sintaxe do comando copy:

copy <nome_da_tabela>
from ‘s3://<fonte_de_dados>‘
iam_role ‘arn:aws:iam::<aws-account-id>:role/<role-name>‘;

Integração por catálogo de metadados do Glue:

Conforme já citado anteriormente, os dados que estão catalogados nos metadados do Amazon Glue podem ser visualizados tanto pelo Amazon EMR, Amazon Athena e também pelo Amazon Redshift. Abaixo segue uma arquitetura de referencia que ilustra este conceito.

E com relação à migração, quais opções temos?

Algumas ferramentas de mercado ou mesmo ferramentas nativas (incluídas na licença de seu banco de dados) podem ajudar na migração para a AWS. Caso você não disponha deste tipo de ferramenta/licenciamento, oferecemos um serviço chamado AWS Database Migration Service (DMS) que ajuda você a migrar e/ou replicar continuamente (CDC) com facilidade e segurança os dados de seus bancos de dados e/ou data warehouses para a AWS com simplicidade e baixo custo.

Com relação ao esquema do banco de dados (tabelas, procedures, etc), temos uma ferramenta chamada AWS Schema Conversion Tool (SCT) que ajuda na conversão suas bases de dados relacionais e/ou data warehouses para bases de dados open-source ou serviços nativos da AWS, como Amazon Aurora e Redshift. Em alguns casos a migração é simples e direta e em outros o SCT gera um relatório que ajuda muito a se preparar e saber quais os desafios que existirão nesta jornada.

Um exemplo de uso dessas ferramentas pode ser visto abaixo:

Informações complementares podem ser obtidas nas documentações do Amazon EMR, Amazon Redshift, Amazon S3, Amazon Athena, Amazon Glue, AWS Database Migration Service (DMS) e AWS Schema Conversion Tool (SCT).

Se deseja conhecer ainda mais assista nosso Webinar On-Demand sobre Amazon Redshit e Amazon EMR em nossa página de Weninars 2019, onde você pode encontrar também outros webinars On-Demand além de se inscrever para os que virão.

Autor:

Ricardo Serafim, Specialist Solutions Architect: Analytics