O blog da AWS

Parte 2: Executando um ETL baseado em Spark SQL com Amazon EMR no Amazon EKS

Melody Yang, Arquiteta de Soluções especialista de AWS,
Shiva Achari, Arquiteto Senior de laboratório de datos de AWS,
Igor Izotov,Arquiteto de Soluções empresariais de AWS,
Daniel Maldonado, Arquiteto de Soluções de AWS.

 

Introdução

Cada vez mais, o sucesso de uma empresa depende de sua agilidade para transformar dados em insights acionáveis, o que requer processos de dados eficientes e automatizados. No blog Parte 1: Criando um ETL baseado em SQL com Apache Spark no Amazon EKS, descrevemos um problema comum de produtividade em uma arquitetura de dados moderna. Para enfrentar o desafio, explicamos e demonstramos como usar a abordagem declarativa como o principal facilitador para melhorar a eficiência, resultando em um tempo de resposta mais rápido para as empresas.

De um modo geral, a gestão de aplicações declarativas no Kubernetes é uma prática recomendada amplamente adotada. Vemos clientes usando a mesma abordagem para construir e implantar seus aplicativos Spark com estruturas de código aberto ou de construção interna para alcançar o mesmo objetivo de produtividade.

Como exemplo, aproveitaremos a estrutura de processamento de dados de código aberto data processing framework Arc, para transformar um pipeline de dados normal em um trabalho “ETL como definição”. Isso significa que todas as etapas do pipeline de dados serão simplesmente expressas em um arquivo de definição declarativa (JSON) com scripts SQL de linguagem declarativa incorporada.

A definição de trabalho no Notebook Arc Jupyter é assim:

 

 

Essa representação torna o ETL muito mais fácil para uma gama mais ampla de pessoas: analistas, cientistas de dados e qualquer autor sql que possa expressar totalmente seus fluxos de trabalho de dados sem a necessidade de escrever código em uma linguagem de programação como python.

Neste blog, vamos explorar algumas das principais vantagens da mais recente opção de implantação Amazon EMR Amazon EMR on Amazon EKS para executar aplicativos Spark, explicar sua principal diferença em relação ao gerenciador de recursos Spark comumente usado – YARN e finalmente demonstrar como agendar um job  de ETL declarativo anterior com o Amazon EMR no EKS. Construir e testar a job em um Arc Jupyter kernel personalizado está fora do escopo desse post, você pode encontrar mais tutoriais no site da Arc.

 

Por que executar o Amazon EMR no Amazon EKS

Arquitetura simplificada unificando cargas de trabalho– o EMR no EKS nos permite executar cargas de trabalho Apache Spark no Amazon Elastic Kubernetes Service sem provisionar clusters EMR dedicados. Se você tem um ambiente EKS existente em sua organização, faz sentido unificar suas cargas de trabalho de análise com outros aplicativos baseados em Kubernetes no mesmo cluster EKS da Amazon. Melhora a utilização de recursos e simplifica significativamente a gestão da infraestrutura.

Mais recursos para compartilhar com um modelo de JVM menor: Uma diferença importante nesta opção de implantação é a mudança do gerenciador de recursos YARN baseado em JVM para Kubernetes, de um gerenciador de clusters Hadoop para um orquestrador de aplicativos genéricos em contêineres. Como mostrado abaixo, cada Spark executor funciona como um container YARN no Hadoop. De um modo geral, a YARN cria um JVM em cada contêiner solicitado por aplicações Hadoop, como o Apache HIVE. Enquanto quando você executa o Spark no Kubernetes, você mantém seu modelo JVM mínimo, para que o cluster EKS possa acomodar mais aplicativos, incluindo workloads JVM e não-JVM, resultando em mais recursos de sobra para suas cargas de trabalho de análise.

 

 

Compartilhamento eficiente de recursos levando à redução de custos: Com gerenciamento do cluster de YARN, se você quiser reutilizar o mesmo cluster EMR para jobs simultâneos da Spark para reduzir custos, você precisará comprometer o isolamento dos recursos. Além disso, você tem que pagar por recursos de computação que não são totalmente utilizados, como o nó master, porque esses recursos computacionais não utilizados podem ser alavancados apenas pelo EMR. Com o EMR no EKS, você pode desfrutar do recurso de alocação otimizada de recursos, compartilhando-os em todos os seus aplicativos, resultando em redução de custos.

Runtime do emr mais rápido para Apache Spark: Um dos principais benefícios de executar o Spark com o EMR no EKS é o tempo de execução emr mais rápido para o Spark. O runtime é otimizado para desempenho, que está disponível e ativado por padrão na versão EMR da Amazon 5.28.0 e posterior. Em nosso teste de desempenho com consultas de referência TPC-DS na escala de 3 TB, descobrimos que o tempo de execução emr para Apache Spark 3.0 fornece uma melhoria de desempenho de 1,7 vezes em média e melhor desempenho de até 8 vezes para consultas individuais sobre o código aberto Apache Spark 3.0.0. Isso significa que você pode executar seus aplicativos Apache Spark mais rápido e mais barato sem ter que fazer qualquer alteração em seus aplicativos.

Configuração zero para suportar multi-tenancy: Sem qualquer configuração de infraestrutura, você pode usar um único cluster EKS para executar aplicativos que requerem diferentes versões e configurações do Apache Spark, enquanto aproveita a alocação de recursos dinâmicos do Spark, o dimensionamento automático EKS, a alta disponibilidade com várias Zonas de Disponibilidade e o isolamento da carga de trabalho para casos de uso multi-tenancy, e assim por diante.

 

Eficácia de custos

O preço do EMR sobre o EKS é calculado com base nos recursos de memória e vCPU usados desde o momento em que você começa a baixar a imagem do aplicativo EMR até que o pod do EKS termine, arredondado para o segundo mais próximo. Veja o exemplo a seguir:

 

Exemplo: Custo na Região da Virgínia do Norte (us-leste-1)

 

Os preços anteriores do Amazon EMR são além dos preços do Amazon EKS e de quaisquer outros serviços usados com eks. Você paga $0,10 por hora por cada cluster EKS que você usa. No entanto, você pode aproveitar um único cluster EKS para executar vários aplicativos, aproveitando os namespaces do Kubernetes e as políticas de segurança do IAM.

 

Durante o tempo de execução do aplicativo, a funcionalidade de escala automática  do EKS aloca e exclui automaticamente recursos para eliminar o excesso de provisionamento ou subutilização desses recursos. Ele permite que você reduza custos pagando apenas pelos recursos que você usa.

 

Para reduzir ainda mais o custo de execução das jobs não críticos, um dos padrões comuns é agendar Spark executores em Instâncias Spot para economizar até 90% mais do que o preço sob demanda e executar o controlador em uma instância sob demanda. Porque o manipulador é responsável por solicitar novos executores para substituir os que falharam quando um evento inesperado ocorre. Se o motorista falhar, todos os componentes e executores ligados serão descartados.

 

Kubernetes vem com uma especificação YAML chamada de pod templates, que você pode usar para configurar os pods. Para reduzir o custo e atender à necessidade de confiabilidade acima, definimos as regras do nodeSelector  em templates de pod carregados no S3, a fim de executar pods controlador/executor spark em um tipo específico de nós EKS (instâncias de computação), que não é suportado pelas configurações do Spark. Finalmente, ao enviar a job, especifique duas propriedades Spark spark.kubernetes.driver.podTemplateFile  y  spark.kubernetes.executor.podTemplateFile para apontar os modelos de pod em S3.

 

 

por exemplo:

executor_pod_template.yaml:

apiVersion: v1

kind: Pod

spec:

nodeSelector:

eks.amazonaws.com/capacityType: SPOT

 

driver_pod_template.yaml:

apiVersion: v1

kind: Pod

spec:

nodeSelector:

eks.amazonaws.com/capacityType: ON_DEMAND

Envio de jobs do Spark:

aws emr-containers start-job-run \
--virtual-cluster-id ${EMR_EKS_CLUSTER_ID} \
--name spark-pi-pod-template \
--execution-role-arn ${EMR_EKS_ROLE_ARN} \
--release-label emr-5.33.0-latest \
--job-driver '{
    "sparkSubmitJobDriver": {
        "entryPoint": "s3://'${s3DemoBucket}'/someAppCode.py",
        "sparkSubmitParameters": "--conf spark.kubernetes.driver.podTemplateFile=\"s3://'${s3DemoBucket}'/pod_templates/driver_pod_template.yaml\" --conf spark.kubernetes.executor.podTemplateFile=\"s3://'${s3DemoBucket}'/pod_templates/executor_pod_template.yaml\" --conf spark.executor.instances=2 --conf spark.executor.memory=2G --conf spark.executor.cores=2"
	}
    }

 

Com as versões 5.33.0 do Amazon EMR e posteriores, o EMR no EKS suporta o recurso de template de pod baseado no S3. Se você estiver usando uma versão EMR sem suporte, também é possível aproveitar o mesmo recurso sem suporte ao S3. Certifique-se de que sua versão Spark é 3.0 ou posterior e copie os arquivos de modelo para sua imagem personalizada do Docker.   O script de submissão de job será alterado por isso:

"—conf
spark.kubernetes.driver.podTemplateFile=/local/path/to/driver_pod_template.
yaml"
"—conf
spark.kubernetes.executor.podTemplateFile=/local/path/to/executor_pod_templ
ate.yaml"

 

Opções de computação Serverless: AWS Fargate

A solução de exemplo será executada em um cluster EKS com AWS Fargate. Fargate é um mecanismo de computação sem servidor para contêineres que rodam no Amazon Elastic Kubernetes Service (EKS). Torna mais fácil focar na construção de aplicativos, eliminando a necessidade de provisionar e gerenciar servidores. Fargate executa cada tarefa/pod em seu próprio kernel, fornecendo seu próprio ambiente de computação isolado. Isso permite que o aplicativo tenha isolamento de recursos e segurança reforçada por design.

Com a AWS Fargate, você não precisa ser um especialista em operações kubernetes. Ele aloca automaticamente o número certo de processos, eliminando a necessidade de escolher instâncias e dimensionar a capacidade do cluster, de modo que o Cluster Autoscaler não é mais necessário para ajustar o nó de cluster EKS.

No nosso caso, cada executor ou controlador da Spark é provisionado usando um pod Fargate separado, para formar um cluster Spark dedicado a um pipeline ETL. Você só precisa especificar e pagar pelos recursos necessários para executar seu aplicativo, sem mais preocupações sobre o gerenciamento de clusters complexos, filas e trocas de isolamento.

 

Outras opções de EC2

Além da opção sem servidor, o EMR no EKS pode funcionar em todos os tipos de clusters EKS. Por exemplo, o Amazon EKS gerenciava grupos de nó com instâncias EC2 on-demand e spot-type.

Anteriormente, mencionamos colocar o pod do controlador Spark em uma instância sob demanda para reduzir o risco de interrupção. Para melhorar ainda mais a estabilidade do cluster, é importante entender a alta disponibilidade e reiniciar os recursos de política do Kubernetes. Isso permite novas possibilidades, não apenas na computação multi-tenancy, mas também na capacidade de auto-recuperar aplicativos, por exemplo, relançar o Spark Driver em instâncias spot ou on-demand. Confira o GitHub repo em nosso blog anterior para mais detalhes.

Quando escrevemos este blog, o resultado do nosso teste mostrou que um driver Spark ainda não pode ser reiniciado no caso de uma falha com o tipo de implantação EMR no EKS. Portanto, tenha em mente ao projetar um aplicativo Spark com o tempo mínimo de inatividade necessário, especialmente para tarefas criticas. As recomendações são:

Diversifique seus pedidos Spot

 Similar as instâncias EMR, o EMR no EKS permite que você implante um único aplicativo em vários tipos de instâncias para melhorar ainda mais a disponibilidade. Ao aproveitar as práticas recomendadas do AWS EC2 Spot, como o reequilíbrio de capacidade, você pode diversificar sua solicitação spot em vários tipos de instâncias dentro de cada Zona de Disponibilidade. Isso limita o impacto das paralisações do Spot na sua carga de trabalho se o EC2 reivindicar uma instância spot. Para obter mais informações, consulte o blog: Running cost optimized Spark workloads on Kubernetes using EC2 Spot Instances.

Aumentar a resiliência

A reinicialização repetida de um cluster Spark comprometerá o desempenho do aplicativo ou a duração do job, especialmente para processos de dados sensíveis ao tempo.  Recomendamos que você use as seguintes práticas recomendadas para aumentar a resiliência de sua aplicação:

  1. Certifique-se de que seu job é stateless para que ele possa ser recuperado sem esperar por uma dependência.
  2. Se for necessário um ponto de verificação, por exemplo, um ETL de streaming de Spark stateful, certifique-se de que o armazenamento de ponto de verificação seja dissociado do recurso de computação EKS, que pode ser destacado e anexado  ao cluster Kubernetes através de volume persistentes lo (PVC’s)ou simplesmente usar O Armazenamento em Nuvem S3.
  3. Execute o driver de Spark em uma instância sob demanda definida por um template de pod. Isso adiciona uma camada adicional de resiliência ao aplicativo Spark com EMR em EKS.

 

Segurança

O Amazon EMR no EKS herda as funções específicas do IAM para contas de IAM roles for service accounts, (IRSA), fornecidas pela Amazon EKS. Isso significa que o controle de acesso a dados não está mais no nível de instância de computação, mas é tão granular quanto o nível de contêiner/pod controlado por uma função IAM. A abordagem de autenticação baseada em tokens nos permite aproveitar um dos provedores de credenciais de credenciais padrão da AWS WebIdentityTokenCredentialsProvider para trocar token emitido por kubernetes para credenciais de papel IAM. Isso garante que nossos aplicativos implantados com EMR no EKS possam se comunicar com outros serviços da AWS em um canal seguro e privado, sem a necessidade de armazenar o par de credenciais AWS de longa duração como um segredo Kubernetes.

Para obter mais informações sobre detalhes de implantação, consulte o exemplo em nosso repositorio de Git GitHub repo.

 

Tutorial: Executando um ETL Declarativo com Amazon EMR no EKS

Neste exemplo, apresentamos um design reconhecido pela qualidade, uma estrutura de processamento de dados declarativo de código aberto Arc framework para abstrair a tecnologia Spark. Isso facilita o foco nos resultados dos negócios, não nas tecnologias.

Vamos levá-lo através das etapas para executar um trabalho de ETL arc predefinido com a abordagem EMR em EKS. Para obter mais informações, visite a solução no repositório de git aws-sample.

A solução de exemplo lançará um cluster EKS serverless, carregará os  registros de viagem de táxi verde TLC de um bucket S3 público, aplicará o esquema de conjunto de dados,   agregará os dados e eventualmente irá gerá-los em um bucket  S3 como um formato de arquivo Parquet. O aplicativo Spark amostra é definido como um Notebook Jupyter green_taxi_load.ipynb alimentado pela Arc,   e as informações de metadados são definidas em green_taxi_schema.json.

 

Diagrama 1:SQL baseado em Spark ETL com EMR em EKS

Introdução (versão EKS)

  1. Execute o seguinte comando para prover um novo cluster eks-cluster, apoiado pela Fargate. Em seguida, crie um cluster
  2. Abra o AWS CloudShell na região us-east-1: Link para AWS CloudShell  emr-on-eks-cluster:.

curl https://raw.githubusercontent.com/aws-samples/sql-based-etl-on-amazon-eks/main/emr-on-eks/provision.sh  | bash

 

Desenvolvimento do ETL de exemplo

  1. Após aproximadamente 20 minutos ao provisionar, envie o job de ETL de exemplo para EMR em EKS com um cluster virtual sem servidor chamado “emr-on-eks-cluster”:

curl https://raw.githubusercontent.com/aws-samples/sql-based-etl-on-amazon-eks/main/emr-on-eks/submit_arc_job.sh | bash

 

 

Basicamente, isso executa o seguinte comando AWS:

aws emr-containers start-job-run \
--virtual-cluster-id $EMRCLUSTERID  \
--name arc-job \
--execution-role-arn $ROLEARN \
--release-label emr-6.2.0-latest \
--job-driver '{
"sparkSubmitJobDriver": {

"entryPoint": "https://repo1.maven.org/maven2/ai/tripl/arc_2.12/3.6.2/arc_2.12-3.6.2.jar", "entryPointArguments":["--etl.config.uri=https://raw.githubusercontent.com/aws-samples/sql-based-etl-on-amazon-eks/main/emr-on-eks/green_taxi_load.ipynb "], 

"sparkSubmitParameters": "--packages com.typesafe:config:1.4.0 --class ai.tripl.arc.ARC --conf spark.executor.instances=10 --conf spark.executor.memory=4G --conf spark.driver.memory=2G --conf spark.executor.cores=2 –conf spark.kubernetes.driverEnv.ETL_CONF_ENV=test --conf spark.kubernetes.driverEnv.OUTPUT=s3://'$OUTPUTS3BUCKET'/output/ --conf spark.kubernetes.driverEnv.SCHEMA=https://raw.githubusercontent.com/aws-samples/sql-based-etl-on-amazon-eks/main/emr-on-eks/green_taxi_schema.json "}}' \

--configuration-overrides '{
 "monitoringConfiguration": {"cloudWatchMonitoringConfiguration": {"logGroupName": "/aws/eks/'$EKSCLUSTERNAME'/jobs", "logStreamNamePrefix": "arc-job"}
 }
}'
  1. Execute esses comandos para verificar o progresso e o status do dimensionamento automático:

kubectl get pod -n emr
kubectl get node --label-columns=topology.kubernetes.io/zone

  1. Como você solicitou 10 executores por trabalho, ele escala automaticamente o cluster Spark de 0 a 10 pods/executores no cluster EKS. O cluster Spark terminará automaticamente assim que o trabalho estiver concluído.

 

 

  1. Vá para o console EMR para visualizar o status do trabalho no Spark History Server:

 

 

5. Ou verifique os registros no AWS Cloudshell, assim que o Driver Spark estiver funcionando:

driver_name=$(kubectl get pod -n emr | grep "driver" | awk '{print $1}')

kubectl logs ${driver_name} -n emr -c spark-kubernetes-driver | grep 'event'

Limpar recursos

Para limpar seus recursos AWS criados anteriormente, execute:

curl https://raw.githubusercontent.com/aws-samples/sql-based-etl-on-amazon-eks/main/emr-on-eks/deprovision.sh | bash

Regiões suportadas

No momento deste blog, o Amazon EMR na Amazon EKS está disponível nas regiões dos EUA. Leste (Virgínia do Norte), Oeste dos EUA (Oregon), Oeste dos EUA (Norte da Califórnia), EUA Leste (Ohio), Canadá (Central), Europa (Irlanda, Frankfurt e Londres) e Ásia-Pacífico (Mumbai, Seul, Cingapura, Sydney e Tóquio). Se você quiser usar o EMR no EKS em uma região que ainda não está disponível, consulte de código aberto no Spark no blog parte 1.  A solução de  exemplo pode ser implantada em sua região, desde que o Amazon EKS esteja disponível. Migrar de uma carga de trabalho spark em EKS para o EMR totalmente gerenciado no EKS é fácil e simples com mudanças mínimas necessárias. Como o aplicativo Spark autônomo permanece o mesmo, apenas a implantação da implantação difere.

 

Conclusão

Esta publicação fornece uma introdução ao Amazon EMR no EKS e um tour por uma solução de exemplo para demonstrar o conceito de “ETL como uma definição”. Ao ter uma estrutura declarativa de processamento de dados, permite que os clientes construam e implantem suas cargas de trabalho spark com maior eficiência. Ao aproveitar o EMR da Amazon no Amazon EKS, a execução de aplicativos com base em uma estrutura declarativa maximiza a produtividade, o desempenho, a confiabilidade e a disponibilidade dos processos de dados em escala. Este padrão abstrai a tecnologia Spark para você e ajuda você a se concentrar em produtos que otimizam os resultados dos negócios. Devido à facilidade de uso, que combina as otimizações incorporadas fornecidas pelo nosso serviço de EMR Amazon totalmente gerenciado no Amazon EKS, o público-alvo não são apenas engenheiros de dados com habilidades analíticas, mas também analistas, cientistas de dados e qualquer autor sql que possa expressar totalmente seus fluxos de trabalho de dados declarativamente no Spark SQL. Esse padrão de arquitetura pode ser usado para impulsionar a mudança de propriedade de dados em sua organização de TI para partes interessadas não-TI que tenham uma melhor compreensão das operações e necessidades dos negócios.

 

Este artigo foi traduzido do Blog da AWS em Espanhol.

Sobre los autores

Melody Yang é uma   arquiteta  de soluções da AWS com expertise em tecnologias de Big Data. Ela é uma líder de análise que trabalha com clientes da AWS para fornecer orientação de práticas recomendadas e conselhos técnicos para ajudá-los a ter sucesso na transformação de dados. Suas áreas de interesse são estruturas de código aberto e automação, engenharia de dados e DataOps.

 

 

 

 

Shiva Achari é arquiteta sênior de laboratório de dados da Amazon Web Services. Ajuda os clientes da AWS a projetar e protótipos de dados e análises através do AWS Data Lab Engagement.  Possui mais de 14 anos de experiência trabalhando com clientes corporativos e startups principalmente no espaço Big Data e Analytics.

 

 

 

 

Igor Izotov é arquiteto de soluções corporativas da AWS e trabalha em estreita colaboração com as maiores organizações de serviços financeiros da Austrália. Antes da AWS, Igor ocupou cargos de engenharia de arquitetura e soluções com consultores de nível 1 e fornecedores de software. Igor é apaixonado por tudo relacionado a dados e engenharia de software moderna. Fora do trabalho, ele gosta de escrever e tocar música, um bom audiolivro ou corrida, muitas vezes combinando os dois últimos.

 

 

 

 

Daniel Maldonado é arquiteto de soluções da AWS, especializado em cargas de trabalho da Microsoft e tecnologias de Big Data,focado em ajudar os clientes a migrar seus aplicativos e dados para a AWS. Daniel tem mais de 12 anos de experiência trabalhando com Tecnologia da Informação e gosta de ajudar os clientes a colher os benefícios de executar suas cargas de trabalho na nuvem.