Perguntas frequentes sobre o Amazon EMR

O Amazon EMR é a plataforma de big data em nuvem líder do setor para processamento de dados, análise interativa e machine learning que usa estruturas de código aberto, como Apache Spark, Apache Hive e Presto. Com o EMR, você pode executar análises em escala de petabytes por menos da metade do custo das soluções tradicionais on-premises e mais de 1,7 vezes mais rápido do que com o Apache Spark padrão.

O Amazon EMR permite que você se concentre na transformação e análise de seus dados sem ter que se preocupar com a gestão da capacidade computacional ou aplicações de código aberto, além de ser econômico. Com o EMR, você pode provisionar instantaneamente a capacidade que desejar no Amazon EC2 e configurar regras de escalabilidade para gerenciar as mudanças na demanda de computação. Você pode configurar alertas do CloudWatch para receber notificações de mudanças em sua infraestrutura e tomar medidas imediatamente. Caso utilize Kubernetes, você também pode usar EMR para enviar suas workloads para clusters do Amazon EKS. Independentemente de utilizar EC2 ou EKS, você se beneficia do runtime otimizado do EMR, que acelera sua análise e gera economia de tempo e dinheiro.

Você pode implantar workloads no EMR usando Amazon EC2, Amazon Elastic Kubernetes Service (EKS) ou AWS Outposts nos on-premises. Você pode executar e gerenciar suas workloads com o console EMR, API, SDK ou CLI e orquestrá-los usando Amazon Managed Workflows for Apache Airflow (MWAA) ou AWS Step Functions. Para uma experiência interativa, utilize o EMR Studio ou SageMaker Studio.

Para se cadastrar no Amazon EMR, clique no botão “Cadastre-se agora” na página de detalhes do Amazon EMR http://aws.amazon.com/emr. Você deverá ter um cadastro no Amazon EC2 e no Amazon S3 para acessar o Amazon EMR. Se ainda não tiver o cadastro nesses serviços, será necessário cadastrar-se durante o processo de inscrição do Amazon EMR. Após o cadastramento, consulte a documentação do Amazon EMR, que inclui o Guia de conceitos básicos – o melhor lugar para dar continuidade ao serviço.

Consulte nosso Acordo de Nível de Serviço.

Verifique o código de exemplo nestes Artigos e tutoriais. Se você usa o EMR Studio, pode explorar os recursos usando um conjunto de exemplos de cadernos.

Você pode desenvolver, visualizar e depurar aplicações de ciência de dados e engenharia de dados escritos em R, Python, Scala e PySpark no Amazon EMR Studio. Você também pode desenvolver um trabalho de processamento de dados no computador, por exemplo, usando Eclipse, Spyder, PyCharm ou RStudio, e executá-lo no Amazon EMR. Além disso, é possível selecionar JupyterHub ou Zeppelin na configuração do software ao ativar um novo cluster e desenvolver sua aplicação no Amazon EMR com o uso de uma ou mais instâncias.

As Ferramentas da linha de comando ou as APIs fornecem a capacidade de iniciar programaticamente e monitorar o andamento dos clusters em execução, criar uma funcionalidade personalizada adicional com relação aos clusters (como sequências com várias etapas de processamento, programação, fluxo de trabalho ou monitoramento) ou elaborar ferramentas ou aplicações de valor agregado para outros clientes do Amazon EMR. Em contrapartida, o Console de Gerenciamento da AWS fornece uma interface gráfica fácil de usar para a inicialização e o monitoramento dos clusters diretamente com base em um navegador da Web.

Sim. Assim que o trabalho estiver em execução, também será possível adicionar mais etapas a ele por meio da API AddJobFlowSteps. A API AddJobFlowSteps adicionará novas etapas ao final da sequência atual de etapas. Talvez você queira usar essa API para implementar uma lógica condicional ao cluster ou para depuração.

Você pode cadastrar-se no Amazon SNS para que o cluster seja publicado no seu tópico SNS quando ele terminar. Você também pode ver o progresso do cluster no Console de gerenciamento da AWS, ou usar a linha de comando, o SDK ou as APIs para obter o status do cluster.

Sim. Você pode encerrar o cluster automaticamente quando todos as etapas terminarem, ativando a bandeira de encerramento automático.

O Amazon EMR 5.30.0, versões posteriores e a série Amazon EMR 6.x são baseados no Amazon Linux 2. Você também pode especificar uma AMI personalizada que cria com base no Amazon Linux 2. Dessa forma, você pode executar pré-configurações sofisticadas para praticamente qualquer aplicação. Para obter mais informações, consulte Usar uma AMI personalizada.

Sim. Você pode usar Bootstrap Actions para instalar pacotes de software de terceiros em seu cluster. Também é possível fazer upload de executáveis compilados estatisticamente usando o mecanismo de cache distribuído do Hadoop. O EMR 6.x suporta o Hadoop 3, que permite que o YARN NodeManager lance contêineres diretamente ou no servidor do cluster EMR ou dentro de um contêiner do Docker. Consulte nossa documentação para saber mais.

Há várias ferramentas que você pode usar para reunir informações sobre o cluster para ajudar a determinar o que deu errado. Se você usa o Amazon EMR Studio, pode iniciar ferramentas como Spark UI e YARN Timeline Service para simplificar a depuração. No Amazon EMR Console, você pode obter acesso off-cluster a interfaces de usuário de aplicações permanentes para Apache Spark, Tez UI e o servidor de linha do tempo YARN, várias interfaces de usuário de aplicações on-cluster e uma visão resumida do histórico de aplicações no console Amazon EMR para todas as aplicações YARN. Você também pode se conectar ao seu nó principal usando SSH e visualizar as instâncias do cluster por meio dessas interfaces da Web. Para obter mais informações, consulte a documentação.

O EMR Studio é um ambiente de desenvolvimento integrado (IDE) que torna fácil para os cientistas e engenheiros de dados desenvolverem, visualizarem e depurarem aplicações de engenharia de dados e ciência de dados escritas em R, Python, Scala e PySpark.

É uma aplicação totalmente gerenciada com autenticação única, blocos de anotações Jupyter totalmente gerenciados, provisionamento de infraestrutura automatizado e a capacidade de depuração de trabalhos sem a necessidade de fazer login no Console ou cluster AWS. Cientistas e analistas de dados podem instalar kernels e bibliotecas personalizados, colaborar com colegas usando repositórios de código como GitHub e BitBucket ou executar blocos de anotações parametrizados como parte de fluxos de trabalho programados usando serviços de orquestração como o Apache Airflow, AWS Step Functions ou Amazon Managed Workflows para Apache Airflow. Você pode ler trabalhos de análise de orquestração nos cadernos do Amazon EMR usando o Amazon MWAA para saber mais. Os kernels e aplicações do EMR Studio são executados em clusters do EMR de forma que você obtenha o benefício do processamento distribuído de dados usando a performance otimizada do Ambiente de Tempo de Execução do Amazon EMR para Apache Spark. Os administradores podem configurar o EMR Studio para que os analistas possam executar suas aplicações em clusters EMR existentes ou criar novos clusters usando modelos predefinidos da AWS CloudFormation para EMR.

Com o EMR Studio, você pode fazer login diretamente nos cadernos Jupyter totalmente gerenciados usando suas credenciais corporativas sem fazer login no console da AWS, iniciar os cadernos em segundos, entrar a bordo com os blocos de anotações de amostra e realizar sua exploração de dados. Você também pode personalizar o ambiente carregando kernels personalizados e bibliotecas python de cadernos. Os kernels e aplicações do EMR Studio são executados em clusters do EMR de forma que você obtenha o benefício do processamento distribuído de dados usando a performance otimizada do Ambiente de Tempo de Execução do Amazon EMR para Apache Spark. Você pode colaborar com os colegas compartilhando cadernos via GitHub e outros repositórios. Você também pode executar blocos de anotações diretamente como integração contínua e pipelines de implantação. Você pode passar diferentes valores de parâmetros para um bloco de anotações. Você também pode ligar blocos de anotações e integrar blocos de anotações em fluxos de trabalho programados usando serviços de orquestração de fluxo de trabalho como o Apache Airflow. Além disso, você pode depurar clusters e trabalhos usando o menor número possível de cliques com interfaces de aplicações nativas como a Spark UI e o serviço YARN Timeline.

Há cinco diferenças principais.

1. Não há necessidade de acessar o Console de gerenciamento da AWS para o EMR Studio. O EMR Studio é hospedado fora do Console de gerenciamento da AWS. Isso é útil se você não fornecer aos cientistas ou engenheiros de dados acesso ao Console de gerenciamento da AWS.

2. Você pode usar as credenciais empresariais de seu fornecedor de identidade usando o AWS IAM Identity Center (sucessor do AWS SSO) para fazer login no EMR Studio. 

3. O EMR Studio traz para você uma primeira experiência com cadernos. Os kernels e aplicações do EMR Studio são executados em clusters do EMR de forma que você obtenha o benefício do processamento distribuído de dados usando a performance otimizada do Ambiente de Tempo de Execução do Amazon EMR para Apache Spark. A execução do código em um cluster é tão simples quanto anexar o cadernos a um cluster existente ou provisionar um novo.

4. O EMR Studio tem uma interface de usuário simplificada e abstrai as configurações de hardware. Por exemplo, você pode configurar os modelos de cluster uma vez e usar os modelos para iniciar novos clusters. 

5. O EMR Studio permite uma experiência de depuração simplificada para que você possa acessar as interfaces de usuário da aplicação nativa em um único lugar usando o menor número de cliques possível.

Você pode usar o EMR Studio e o SageMaker Studio com o Amazon EMR. O EMR Studio fornece um ambiente de desenvolvimento integrado (IDE) que facilita o desenvolvimento, a visualização e a depuração de aplicações de engenharia e ciência de dados escritos em R, Python, Scala e PySpark. O Amazon SageMaker Studio fornece uma interface visual única baseada na Web em que você pode executar todas as etapas de desenvolvimento de machine learning. O SageMaker Studio fornece acesso, controle e visibilidade completos em cada etapa necessária para criar, treinar e implantar modelos. Você pode fazer upload de dados, criar novos cadernos, treinar e ajustar modelos, alternar entre as etapas para ajustar experimentos, comparar resultados e implantar modelos na produção em um único local com rapidez, aumentando muito a sua produtividade. 

Seu administrador deve primeiro configurar o EMR Studio. Quando você receber de seu administrador uma URL única de login para Amazon EMR Studio, você poderá fazer o login diretamente no Studio usando suas credenciais corporativas.

Não. Depois que seu administrador configurar um EMR Studio e fornecer a URL de acesso ao Studio, sua equipe poderá fazer o login usando as credenciais corporativas. Não é preciso fazer login no Console de gerenciamento da AWS. Em um EMR Studio, sua equipe pode realizar tarefas e acessar recursos configurados pelo administrador.

O AWS IAM Identity Center (sucessor do AWS SSO) é o provedor de serviços de logon único para o EMR Studio. Você encontra a lista de fornecedores de identidade compatíveis com o AWS IAM em nossa documentação.

Workspaces ajudam você a organizar os Cadernos Jupyter. Todos os blocos de anotações em um Workspace são salvos no mesmo local do Amazon S3 e funcionam no mesmo cluster. Você também pode ligar um repositório de código como um repositório GitHub a todos os blocos de anotações em um workspace. Você pode criar e configurar um Workspace antes de anexá-lo a um cluster, mas você deve se conectar a um cluster antes de executar um caderno.

Sim, você pode criar ou abrir um espaço de trabalho sem anexá-lo a um cluster. Somente quando for necessário executá-los, você deve conectá-los a um cluster. Os kernels e aplicações do EMR Studio são executados em clusters do EMR, de forma que você obtenha o benefício do processamento distribuído de dados usando a performance otimizada do tempo de execução do Amazon EMR para o Apache Spark.

Todas as consultas do Spark são executadas no cluster do EMR. Portanto, você precisa instalar todas as bibliotecas de runtime que a aplicação Spark usar no cluster. Você pode instalar facilmente bibliotecas com escopo de notebook em uma célula de notebook. Você também pode instalar kernels do caderno Jupyter e das bibliotecas Python em um nó principal do cluster dentro de uma célula do notebook ou enquanto estiver conectado usando SSH ao nó principal do cluster. Para obter mais informações, consulte a documentação. Além disso, você pode usar uma ação de bootstrap ou uma AMI personalizada para instalar as bibliotecas necessárias quando criar um cluster. Para obter mais informações, consulte Criar ações de bootstrap para instalar software adicional e Uso de uma AMI personalizada no Guia de gerenciamento do Amazon EMR.

O Workspace junto com os arquivos do caderno na área de trabalho são salvos automaticamente em intervalos regulares no formato de arquivo ipynb no local do Amazon S3 especificado durante a criação da área de trabalho. O arquivo do caderno tem o mesmo nome que o caderno no Amazon EMR Studio.

Você pode associar repositórios baseados em Git aos cadernos do Amazon EMR Studio para salvar seus cadernos em um ambiente com controle de versão.

Com o EMR Studio, você pode executar o código do caderno no Amazon EMR em execução no Amazon Elastic Compute Cloud (Amazon EC2) ou Amazon EMR no Amazon Elastic Kubernetes Service (Amazon EKS). Você pode anexar blocos de anotações a clusters existentes ou novos. Você pode criar clusters EMR de duas maneiras no EMR Studio: criar um cluster usando um modelo de cluster pré-configurado via AWS Service Catalog, criar um cluster especificando o nome do cluster, o número de instâncias e o tipo de instância.

Sim, você pode abrir seu espaço de trabalho, escolher o ícone EMR Clusters à esquerda, apertar o botão Destacar, e então selecionar um cluster da lista suspensa Selecionar cluster, e apertar o botão Anexar.

No EMR Studio, você pode escolher a aba Workspaces à esquerda e visualizar todos os workspaces criados por você e outros usuários na mesma conta da AWS.

Cada EMR Studio precisa de permissões para interoperar com outros serviços AWS. Para dar a seus EMR Studios as permissões necessárias, seus administradores precisam criar uma função de serviço EMR Studio com as políticas fornecidas. Também é necessário especificar uma função do usuário para o EMR Studio que define permissões de nível do Studio. Quando adicionam usuários e grupos do AWS IAM Identity Center (sucessor do AWS SSO) ao EMR Studio, eles podem atribuir uma política de sessão a um usuário ou grupo para aplicar os controles finos de permissão do site. As políticas de sessão ajudam os administradores a refinarem sem a necessidade de criar múltiplos perfis do IAM. Para mais informações sobre as políticas de sessão, consulte Políticas e permissões no Guia do usuário do AWS Identity and Access Management.

Sim. Os clusters de alta disponibilidade (Multi-master), os clusters Kerberized e os clusters do AWS Lake Formation não têm suporte atualmente.

O Amazon EMR Studio é fornecido sem custo adicional para você. Encargos aplicáveis para armazenamento do Amazon Simple Storage Service e para clusters do Amazon EMR se aplicam quando você usa o EMR Studio. Para obter mais informações sobre opções de preços e detalhes, consulte Preços do Amazon EMR.

Recomendamos que os novos clientes usem o Amazon EMR Studio, não os cadernos do EMR. Os Notebooks EMR disponibilizam um ambiente gerenciado, baseado no Notebook Jupyter, que possibilita que cientistas de dados, analistas e desenvolvedores preparem e visualizem dados, desenvolvam aplicativos e executem análises interativas usando clusters do EMR. Embora recomendemos que novos clientes usem o EMR Studio, os Cadernos do EMR são compatíveis.

Você pode usar cadernos do EMR para criar aplicativos Apache Spark e executar consultas interativas no seu cluster do EMR sem esforço. Vários usuários podem criar blocos de anotações sem servidor diretamente do console, conectá-los a um cluster do EMR existente ou fornecer um cluster diretamente do console e imediatamente começar a usar o Spark. É possível desconectar blocos de anotações e reconectá-los a novos clusters. Os notebooks são salvos automaticamente em buckets do S3 e você pode recuperar os notebooks salvos no console para reiniciar o trabalho. Notebooks EMR são fornecidos com as bibliotecas encontradas no repositório Anaconda, permitindo que você importe e use estas bibliotecas no código dos seus notebooks e as use para manipular dados e visualizar resultados. Além disso, os notebooks EMR possuem recursos integrados de monitoramento do Spark que você pode usar para monitorar o progresso dos seus trabalhos no Spark e depurar o código de dentro do caderno.

Para começar a usar os Cadernos EMR, abra o console do EMR e selecione Cadernos no painel de navegação. A partir daí, selecione Criar Cadernos, digite um nome para o caderno, selecione um cluster do EMR ou crie instantaneamente um novo, forneça um perfil de serviço para o cadernos usar e selecione um bucket do S3 onde você quer salvar os arquivos do caderno e, a seguir, clique em Criar Caderno. Depois que o caderno mostrar o status Pronto, selecione Abrir para iniciar o editor do caderno.

Os Cadernos do EMR podem ser conectados a clusters do EMR que executarem a versão 5.18.0 ou posterior do EMR.

Os cadernos do EMR são fornecidos sem despesas adicionais a você. A cobrança virá na sua conta normalmente pelos clusters do EMR conectados. Você encontrará mais detalhes sobre o preço do seu cluster acessando https://aws.amazon.com/emr/pricing/ 

O Amazon EMR oferece várias maneiras de levar dados para um cluster. A maneira mais comum é carregar os dados no Amazon S3 e usar os recursos embutidos do Amazon EMR para carregar os dados em seu cluster. Você pode usar o recurso de Cache distribuído do Hadoop para transferir arquivos de um sistema de arquivo distribuído para o sistema de arquivo local. Consulte a documentação para obter mais detalhes. Alternativamente, se você estiver migrando dados do local para a nuvem, você pode usar um dos serviços de migração de dados da AWS.

Os logs do sistema Hadoop, assim como logs de usuário, serão posicionados no bucket do Amazon S3 que você especifica ao criar um cluster. UIs de aplicação persistentes são executadas off-cluster, logs de servidores de tempo do Spark History Server, Tez UI e YARN estão disponíveis por 30 dias após o término de uma aplicação.

Não. No momento, o Amazon EMR não compacta logs quando são transferidos para o Amazon S3.

P: Você compacta logs?

Sim. Você pode usar o AWS Direct Connect para estabelecer conexões de rede dedicadas das suas instalações para a AWS. Se você tiver grandes quantidades de dados, você pode usar o AWS Import/Export. Para obter mais detalhes, consulte a nossa documentação.

Não. Como cada cluster e dados de entrada são diferentes, não podemos estimar a duração da tarefa.

O preço do Amazon EMR é simples e previsível: você paga uma taxa por segundo para cada segundo usado, com um mínimo de um minuto. Você pode estimar sua fatura usando a Calculadora de preços da AWS. O uso de outros Amazon Web Services, incluindo Amazon EC2, é cobrado separadamente do Amazon EMR.

A cobrança do Amazon EMR começa quando o cluster está pronto para executar as etapas. A cobrança do Amazon EMR termina quando você solicita o fechamento do cluster. Para obter mais detalhes sobre quando o Amazon EC2 começa e termina a cobrança, consulte a Perguntas frequentes sobre cobrança do Amazon EC2.

Você pode acompanhar o uso no Console de gerenciamento de cobrança e custos.

No Console de Gerenciamento da AWS, cada cluster tem uma coluna Horas de Instâncias Normalizadas que exibe o número aproximado de horas de computação usadas pelo cluster, arredondado para a hora mais próxima.

As horas de instâncias normalizadas são horas do período calculado com base no padrão de uso 1 hora de m1.small = período calculado normalizado de 1 hora. Você pode ver nossa documentação para ver uma lista de tamanhos diferentes dentro de uma família de instância, e o fator de normalização correspondente por hora.

Por exemplo, se você executar um cluster r3.8xlarge de 10 nós por uma hora, o número total de horas de instâncias normalizadas exibido no console será de 640 (10 (número de nós) x 64 (fator de normalização) x 1 (quantidade de horas da execução do cluster) = 640).

Trata-se de um número aproximado e não deve ser usado para fins de faturamento. Consulte o Billing & Cost Management Console para obter o uso faturável do Amazon EMR.

Sim. O Amazon EMR é perfeitamente compatível com instâncias sob demanda, spot e reservadas. Clique aqui para obter mais informações sobre Instâncias reservadas do Amazon EC2. Clique aqui para obter mais informações sobre Instâncias spot do Amazon EC2. Clique aqui para saber mais sobre as reservas de capacidade do Amazon EC2.

Salvo indicação em contrário, nossos preços excluem impostos e taxas aplicáveis, incluindo o IVA e o imposto de vendas aplicável. Para clientes com endereço de pagamento no Japão, o uso da AWS está sujeito ao imposto sobre consumo japonês. Saiba mais. 

O Amazon EMR inicia as instâncias em dois grupos de segurança do Amazon EC2, um para o principal e outro para os demais nós do cluster. O grupo de segurança mestre tem uma porta aberta para comunicação com o serviço. Ele também tem a porta SSH aberta para permitir que você aplique o SSH às instâncias, usando a chave especificada na inicialização. Os outros nós começam em um grupo de segurança separado, que permite a interação somente com a instância principal. Como padrão, ambos os grupos de segurança são configurados para não permitir o acesso de fontes externas, incluindo instâncias do Amazon EC2 pertencentes a outros clientes. Como esses grupos de segurança estão dentro da sua conta, é possível configurá-los usando as ferramentas padrão ou o painel do EC2. Clique aqui para obter mais informações sobre grupos de segurança do EC2. Além disso, você pode configurar o acesso público de bloqueio do Amazon EMR em cada região que você usa para evitar a criação de cluster se uma regra permitir o acesso público em qualquer porta que você não adicionar a uma lista de exceções.

O Amazon S3 fornece mecanismos de autenticação para assegurar que os dados armazenados estejam protegidos contra acesso não autorizado. A menos que o cliente que esteja fazendo o upload dos dados especifique em contrário, somente aquele cliente pode acessar os dados. Os clientes do Amazon EMR também podem optar por enviar dados para o Amazon S3 usando o protocolo HTTPS para uma transmissão segura. Além disso, o Amazon EMR sempre usa HTTPS para enviar dados entre o Amazon S3 e o Amazon EC2. Para uma segurança maior, os clientes poderão criptografar os dados de entrada antes de fazerem o upload desses dados para o Amazon S3 (usando qualquer ferramenta comum de criptografia de dados). Em seguida, eles precisam adicionar uma etapa de descriptografia ao início do seu cluster quando o Amazon EMR analisa os dados do Amazon S3.

Sim. O AWS CloudTrail é um web service que registra as chamadas de APIs da AWS para a sua conta e envia os arquivos de log para você. O histórico de chamadas de APIs da AWS gerado pelo CloudTrail possibilita análises de segurança, rastreamento de alteração de recursos e auditoria de conformidade. Saiba mais sobre o CloudTrail na página de detalhes do AWS CloudTrail e ative-o no Console de Gerenciamento da AWS do CloudTrail.

Por padrão, os processos das aplicações do Amazon EMR usam perfis de instância do EC2 quando chamam outros serviços da AWS. Para clusters multilocatários, o Amazon EMR oferece três opções para gerenciar o acesso do usuário a dados do Amazon S3.

1. A integração com o AWS Lake Formation permite que você defina e gerencie políticas de autorização refinadas no AWS Lake Formation para acessar bancos de dados, tabelas e colunas no Catálogo de Dados do AWS Glue. Você pode aplicar as políticas de autorização em trabalhos enviados por meio dos Cadernos do Amazon EMR e do Apache Zeppelin para workloads interativas do EMR Spark, além de enviar eventos de auditoria ao AWS CloudTrail. Ao habilitar essa integração, você também habilita o Single Sign-On federado em cadernos do EMR ou Apache Zeppelin em sistemas de identidade corporativos compatíveis com Security Assertion Markup Language (SAML) 2.0.

2. A integração nativa com o Apache Ranger permite configurar um servidor Apache Ranger novo ou existente para definir e gerenciar políticas de autorização refinadas para usuários acessarem bancos de dados, tabelas e colunas de dados do Amazon S3 por meio do Hive Metastore. O Apache Ranger é uma ferramenta de código aberto utilizada para habilitar, monitorar e gerenciar a segurança abrangente de dados em toda a plataforma Hadoop.
   
   Essa integração nativa permite definir três tipos de políticas de autorização no servidor Policy Admin do Apache Ranger. Você pode definir autorização em nível da tabela, coluna e linha para o Hive, autorização em nível de tabela e coluna para o Spark e autorização em nível de prefixo objeto para o Amazon S3. O Amazon EMR instala e configura automaticamente os plug-ins do Apache Ranger correspondentes no cluster. Esses plug-ins do Ranger são sincronizados com o servidor Policy Admin para políticas de autorização, aplicação do controle de acesso a dados e envio de eventos de auditoria para o Amazon CloudWatch Logs.

3. O Mapeador de Perfis de Usuário do Amazon EMR permite utilizar as permissões do AWS IAM para gerenciar os acessos aos recursos da AWS. Você pode criar mapeamentos entre os usuários (ou grupos) e perfis do IAM personalizados. Um usuário ou grupo só pode acessar os dados permitidos pelo perfil do IAM personalizado. No momento, esse atributo só está disponível por meio dos AWS Labs.

O Amazon EMR inicia todos os nós para um determinado cluster na mesma zona de disponibilidade do Amazon EC2. A execução de um cluster na mesma zona aprimora a performance dos fluxos de trabalho. Como padrão, o Amazon EMR seleciona a zona de disponibilidade com a maioria dos recursos disponíveis nos quais o cluster será executado. Porém, é possível especificar outra zona de disponibilidade, se exigido. Você também tem a opção de otimizar sua alocação para instâncias sob demanda de menor preço, capacidade local ideal ou usar reservas de capacidade sob demanda.

Para ver uma lista das regiões da AWS com suporte no Amazon EMR, visite a tabela de regiões da AWS para toda a infraestrutura global da AWS.

O EMR é compatível com a execução de clusters na zona local de Los Angeles da AWS. Você pode usar o EMR na região Oeste dos EUA (Oregon) para executar clusters em sub-redes associadas à zona local de Los Angeles da AWS.

Ao criar um cluster, normalmente você deve selecionar a região onde os dados estão localizados.

Sim, você pode. Se você transferir dados de uma região para outra, haverá a cobrança dos encargos de largura de banda. Para obter informações sobre preços de largura de banda, acesse a seção de preços na página de detalhes do EC2.

A região AWS GovCloud (EUA) é destinada a agências e clientes do governo dos EUA. A região cumpre os requisitos do US ITAR. Na GovCloud, o EMR não oferece suporte a instâncias spot nem ao recurso de ativação de depuração. O Console de gerenciamento do EMR ainda não está disponível na GovCloud.

Amazon EMR no Amazon EC2

Amazon EMR no Amazon EKS

Amazon EMR no AWS Outposts

Iniciar

Gerenciamento

Marcação

Um cluster é um conjunto de instâncias do Amazon Elastic Compute Cloud (Amazon EC2). Cada instância do cluster é chamada de nó e possui uma função dentro do cluster, chamada de tipo de nó. O Amazon EMR também instala diferentes componentes de software em cada tipo de nó, conferindo a cada nó uma função em uma aplicação distribuída como o Apache Hadoop. Cada cluster tem um identificador exclusivo começando com "j-".

Um cluster Amazon EMR possui três tipos de nós:

1. Nó principal: um nó que gerencia o cluster executando componentes de software para coordenar a distribuição de dados e tarefas entre outros nós para processamento. O nó principal rastreia o status das tarefas e monitora a integridade do cluster. Cada cluster possui um nó principal e é possível criar um cluster de nó único com apenas o nó principal.

2. Nó central: um nó com componentes de software que executam tarefas e armazenam dados no Hadoop Distributed File System (HDFS) em seu cluster. Os clusters de vários nós possuem pelo menos um nó principal.

3. Nó de tarefa: um nó com componentes de software que apenas executa tarefas e não armazena dados no HDFS. Os nós de tarefas são opcionais.

Uma etapa do cluster é uma unidade de processamento definida pelo usuário, mapeando aproximadamente um algoritmo que manipula os dados. Uma etapa é um aplicativo Hadoop MapReduce implementado como um Java jar ou um programa de streaming escrito em Java, Ruby, Perl, Python, PHP, R ou C++. Por exemplo, para contar a frequência com a qual as palavras aparecem em um documento e exibi-las de modo classificado pela contagem, a primeira etapa seria um aplicativo MapReduce que conta as ocorrências de cada palavra e a segunda etapa seria um aplicativo MapReduce que classifica o resultado da primeira etapa com base nas contagens.

INICIANDO - O cluster começa com a configuração de instâncias do EC2.
BOOTSTRAPPING − Há ações de bootstrap em execução no cluster.
RUNNING – Uma etapa do cluster que está em execução no momento.
WAITING – O cluster está ativo no momento, mas não há etapas para executar.
TERMINATING − O cluster está em desativação.
TERMINATED − O cluster foi encerrado sem erros.
TERMINATED_WITH_ERRORS − O cluster foi encerrado com erros.

PENDING – A etapa está aguardando para ser executada.

RUNNING – A etapa está sendo executada no momento.

COMPLETED – A etapa foi concluída com êxito.

CANCELLED − A etapa foi cancelada antes da execução devido à falha de uma etapa anterior ou porque o cluster foi encerrado antes de executar.

FAILED – Houve falha da etapa durante a execução.

Você pode iniciar um cluster por meio do Console de Gerenciamento da AWS ao preencher um formulário simples de solicitação de cluster. No formulário de solicitação, especifique o nome do cluster, a localização no Amazon S3 dos dados de entrada, o aplicativo de processamento, a localização de saída dos dados desejados e o número e tipo de instâncias do Amazon EC2 que gostaria de usar. Também é possível especificar um local para armazenar arquivos de log do cluster e Chave SSH para efetuar login no cluster durante a execução. Além disso, pode-se iniciar um cluster usando a API RunJobFlow ou o comando “create” nas ferramentas da linha de comando. Para iniciar um cluster com EMR Studio, consulte a seção EMR Studio acima.

A qualquer momento você pode encerrar um cluster por meio do Console de Gerenciamento da AWS selecionando um cluster e clicando no botão "Terminate" (Encerrar). Também é possível usar a API TerminateJobFlows. Se você encerrar um cluster em execução, os resultados que não tiverem persistido no Amazon S3 serão perdidos e todas as instâncias do Amazon EC2 serão desativadas.

Você pode iniciar quantos clusters quiser. Ao começar, há um limite de 20 instâncias em todos os clusters. Se precisar de mais instâncias, preencha o formulário de solicitação de instâncias do Amazon EC2. No Amazon EC2, o limite já foi aumentado. O novo limite será aplicado aos clusters do Amazon EMR.

Você pode fazer upload dos dados de entrada e de uma aplicação de processamento de dados no Amazon S3. O Amazon EMR inicia uma série de instâncias do Amazon EC2 que você especificou. O serviço inicia a execução do cluster ao obter os dados de entrada do Amazon S3 usando o protocolo S3 URI nas instâncias iniciadas do Amazon EC2. Assim que o cluster for concluído, o Amazon EMR transferirá os dados resultantes para o Amazon S3, onde você poderá, então, recuperá-los ou usar como entrada em outro cluster.

O Amazon EMR usa o mecanismo de processamento de dados do Hadoop para realizar computações implementadas no modelo de programação do MapReduce. O cliente implementa seu algoritmo em termos das funções map() e reduce(). O serviço começa com um número específico de clientes de instâncias do Amazon EC2, composto por um principal e vários outros nós. O Amazon EMR executa o software Hadoop nessas instâncias. O nó principal divide os dados de entrada em blocos e distribui o processamento dos blocos para os outros nós. Em seguida, cada nó executa a função de mapeamento nos dados que alocou, gerando dados intermediários. Então, os dados intermediários são classificados, particionados e enviados para processos que aplicam a função reducer a eles localmente nos nós. Finalmente, a saída das tarefas do reducer é coletada nos arquivos. Um único "cluster" poderá envolver uma sequência de etapas MapReduce.

Consulte a página de preço do EMR para obter detalhes sobre preços e os tipos de instâncias disponíveis por região.

O período para executar o cluster dependerá de vários fatores, incluindo o tipo de cluster, a quantidade de dados inseridos e o número e tipo de instâncias do Amazon EC2 selecionados para o cluster.

Sim. Agora, você pode executar um cluster do EMR (versão 5.23 ou superior) com três nós principais e oferecer alta disponibilidade a aplicativos como YARN Resource Manager, HDFS Name Node, Spark, Hive e Ganglia. Em caso de falha do nó principal em operação ou de processos críticos, como o Resource Manager ou o Name Node, o Amazon EMR executará automaticamente um failover para um nó principal em espera. Como o nó principal não é um possível ponto único de falha, você pode executar clusters do EMR de longa duração sem interrupções. Caso ocorra um failover, o Amazon EMR substituirá automaticamente o nó principal com falha por um novo nó principal com a mesma configuração e as mesmas ações de inicialização. 

Sim. O Amazon EMR é tolerante a falhas com relação a falhas de nó e continuará a execução do trabalho se um nó for desativado. Além disso, o Amazon EMR provisionará um novo nó quando um nó core falhar. No entanto, o Amazon EMR não substituirá nós se todos os nós do cluster falharem.

Sim. É possível executar o SSH nos nós do cluster e executar comandos do Hadoop diretamente de lá. Se for necessário executar o SSH em um nó específico, primeiro é necessário executar o SSH no nó principal e, em seguida, em um nó desejado.

As Ações de bootstrap são um recurso do Amazon EMR que fornece aos usuários uma forma de executar a configuração personalizada antes da execução do seu cluster. Ações de bootstrap podem ser usadas para instalar software ou configurar instâncias antes da execução do cluster. Você pode ler mais sobre essas ações do bootstrap no Guia do desenvolvedor do EMR.

É possível gravar um script das ações do Bootstrap em qualquer linguagem já instalada na instância do cluster, incluindo Bash, Perl, Python, Ruby, C++ ou Java. Há vários Bootstrap Actions pré-definidos disponíveis. Assim que o script for gravado, será necessário transferi-lo por upload para o Amazon S3 e fazer referência à sua localização ao iniciar um cluster. Consulte o Guia do desenvolvedor para obter detalhes sobre como usar as ações do Bootstrap.

A configuração padrão do Hadoop do EMR é apropriada para a maioria das workloads. No entanto, com base nos requisitos e específicos de memória e processamento do cluster, talvez seja apropriado adaptar essas definições. Por exemplo, se as tarefas do cluster exigirem bastante memória, você poderá optar por usar menos tarefas por núcleo e reduzir o tamanho do heap do mecanismo de acompanhamento do trabalho. Para isso, uma ação do Bootstrap predefinida está disponível para configurar o cluster na inicialização. Consulte o tópico sobre como Configurar ações de bootstrap que exigem muita memória, no Guia do desenvolvedor, para obter detalhes de configuração e instruções de uso. Uma ação predefinida do bootstrap está disponível, permitindo que você personalize as definições do cluster para qualquer valor selecionado. Consulte o tópico sobre como Configurar ações de bootstrap do Hadoop, no Guia do desenvolvedor, para obter instruções de uso.

Sim. Os nós podem ser de dois tipos: (1) nós core, que hospedam dados persistentes usando Hadoop Distributed File System (HDFS) e executam tarefas do Hadoop e (2) nós de tarefa, que somente executam tarefas do Hadoop. Enquanto um cluster estiver sendo executado, você poderá aumentar o número de nós centrais e aumentar ou diminuir o número de nós de tarefa. Isso pode ser feito por meio da API, Java SDK ou do cliente da linha de comando. Consulte a seção Redimensionamento de clusters em execução, no Guia do desenvolvedor, para obter mais detalhes sobre como modificar o tamanho de um cluster em execução. Você também pode usar a Escalabilidade gerenciada do EMR.

Como os nós centrais hospedam dados persistentes no HDFS e não podem ser removidos, os nós centrais devem ser reservados para a capacidade que é exigida até que o cluster seja concluído. Como os nós de tarefas podem ser adicionados ou removidos e não contêm HDFS, são ideais para a capacidade que é necessária apenas temporariamente. Você pode lançar frotas de exemplo de tarefas em Instâncias spot para aumentar a capacidade enquanto minimiza custos.

Há vários cenários onde talvez você queira modificar o número de nós em um cluster em execução. Se o cluster estiver sendo executado com mais lentidão do que o esperado ou os requisitos de sincronismo forem alterados, você poderá aumentar o número de nós centrais para aumentar a performance do cluster. Se fases diferentes do cluster tiverem necessidades de capacidade diferentes, você poderá começar com um número pequeno de nós centrais e aumentar ou diminuir o número de nós de tarefas para atender aos requisitos de capacidade variáveis do cluster. Você também pode usar a Escalabilidade Gerenciada do EMR.

Sim. Você poderá incluir uma etapa pré-definida no fluxo de trabalho que redimensiona automaticamente um cluster entre as etapas que são conhecidas por ter diferentes necessidades de capacidade. Como todas as etapas tem a garantia de serem executadas sequencialmente, isso permite definir o número de nós que serão executados em uma determinada etapa do cluster.

Para criar um novo cluster que esteja visível para todos os usuários de IAM na ILC do EMR, acrescente o sinalizador --visible-to-all-users ao criar o cluster. Por exemplo: elastic-mapreduce --create --visible-to-all-users. No Management Console, basta selecionar “Visible to all IAM Users”, no painel Advanced Options, do Assistente de criação de cluster.

Para tornar um cluster existente visível para todos os usuários do IAM, é necessário usar a ILC do EMR. Use --set-visible-to-all-users e especifique o identificador do cluster. Por exemplo: Elastic-mapreduce --set-visible-to-all-users true --jobflow j-xxxxxxx. Isso pode ser feito somente pelo autor do cluster.

Para saber mais, consulte a seção Configuração de permissões de usuário do Guia do desenvolvedor do EMR.

É possível adicionar tags a um cluster do Amazon EMR ativo. Um cluster de Amazon EMR consiste em instâncias do Amazon EC2, e um tag adicionado a um cluster de Amazon EMR será propagado para cada instância de Amazon EC2 ativa desse cluster. Não é possível adicionar, editar ou remover tags de clusters encerrados ou instâncias de Amazon EC2 encerradas, que faziam parte de um cluster ativo.

Não, o Amazon EMR não oferece suporte a permissões baseadas em recursos por tag. No entanto, é importante notar que tags propagadas para instâncias de Amazon EC2 se comportam como tags normais do Amazon EC2. Portanto, uma política do IAM para Amazon EC2 atuará em tags propagadas do Amazon EMR se corresponderem às condições daquela política.

É possível adicionar até dez tags a um cluster do Amazon EMR.

Sim, o Amazon EMR propaga as tags adicionadas a um cluster às instâncias do EC2 subjacentes a esse cluster. Se adicionar uma tag a um cluster do Amazon EMR, ela aparecerá também em instâncias do Amazon EC2 relacionadas. Da mesma forma, se remover uma tag de um cluster do Amazon EMR, ela também será removida das instâncias do Amazon EC2 associadas. No entanto, se estiver usando políticas IAM para o Amazon EC2 e planeja usar a funcionalidade de colocação de tags do Amazon EMR, verifique se foi concedida a permissão para usar as APIs de colocação de tags do Amazon EC2: CreateTags e DeleteTags.

Selecione as tags que você gostaria de usar no relatório de faturamento da AWS aqui. Então, para ver o custo dos recursos combinados, é possível organizar suas informações de cobrança com base em recursos que têm os mesmos valores de chave de tag.

Uma instância do Amazon EC2 associada a um cluster do Amazon EMR terá duas tags de sistema:

• aws:elasticmapreduce:instance-group-role=CORE

  • Key = instance-group role ; Value = [CORE ou TASK];

• aws:elasticmapreduce:job-flow-id=j-12345678

  • Key = job-flow-id ; Value = [JobFlowID]

Sim, é possível adicionar ou remover tags diretamente nas instâncias do Amazon EC2 que fazem parte de um cluster do Amazon EMR. No entanto, não é recomendado fazer isso porque o sistema de colocação de tags do Amazon EMR não sincronizará as alterações feitas diretamente em uma instância do Amazon EC2 associada. Recomenda-se que as tags para clusters do Amazon EMR sejam adicionadas e removidas do console do Amazon EMR, da CLI ou da API para garantir que o cluster e suas instâncias associadas do Amazon EC2 tenham as tags corretas.

O Amazon EMR Serverless é uma nova opção de implantação no Amazon EMR que permite executar frameworks de big data, como o Apache Spark e o Apache Hive, sem configurar, gerenciar nem escalar clusters.

Engenheiros de dados, analistas e cientistas podem usar o EMR Serverless para desenvolver aplicações usando frameworks de código aberto, como o Apache Spark e o Apache Hive. Eles podem usar esses frameworks para transformar dados, executar consultas SQL interativas e workloads de machine learning.

Você pode usar o EMR Studio, a AWS CLI ou APIs para enviar trabalhos, rastrear o status da tarefa e criar seus pipelines de dados para serem executados no EMR Serverless. Para começar a usar o EMR Studio, faça login no Console de Gerenciamento da AWS, navegue até Amazon EMR e, na categoria Analytics (Análise), selecione Amazon EMR Serverless. Siga as instruções do Console de Gerenciamento da AWS, navegue até o Amazon EMR na categoria Analytics (Análise) e selecione Amazon EMR Serverless. Siga as instruções do guia conceitos básicos para criar sua aplicação do EMR Serverless e enviar tarefas. Consulte a página Interagir com a aplicação na AWS CLI para iniciar suas aplicações e enviar trabalhos usando a CLI. Você também encontra exemplos do EMR Serverless e código de exemplo em nosso repositório do GitHub

Atualmente, o EMR Serverless oferece suporte aos mecanismos Apache Spark e Apache Hive. Para obter suporte a outros frameworks, como Apache Presto ou Apache Flink, envie uma solicitação para emr-feedback@amazon.com.

O EMR Sem Servidor está disponível nas seguintes regiões da AWS: Ásia-Pacífico (Mumbai), Ásia-Pacífico (Seul), Ásia-Pacífico (Singapura), Ásia-Pacífico (Sydney), Ásia-Pacífico (Tóquio), Canadá (Central), Europa (Frankfurt), Europa (Irlanda), Europa (Londres), Europa (Paris), Europa (Estocolmo), América do Sul (São Paulo), Leste dos EUA (Norte da Virgínia), Leste dos EUA (Ohio), Oeste dos EUA (Norte da Califórnia) e Oeste dos EUA (Oregon).

O Amazon EMR oferece a opção de executar aplicações em clusters baseados no EC2, em clusters do EKS, no Outposts ou no Serverless. Os clusters do EMR no EC2 são perfeitos para clientes que precisam de controle e flexibilidade máximos ao executar aplicações. Com o EMR em clusters do EC2, os clientes podem escolher o tipo de instância do EC2 para atender às necessidades de performance específicas da aplicação, personalizar a AMI do Linux, personalizar a configuração da instância do EC2, personalizar e ampliar frameworks de código aberto e instalar outros softwares personalizados em instâncias de cluster. O Amazon EMR no EKS é perfeito para clientes que desejam padronizar no EKS para gerenciar clusters entre aplicações ou usar versões diferentes de um framework de código aberto no mesmo cluster. O Amazon EMR no AWS Outposts serve para clientes que desejam executar o EMR mais perto de seu datacenter, em um Outpost. O EMR Serverless é perfeito para clientes que desejam evitar o gerenciamento e a operação de clusters e preferem executar aplicações usando frameworks de código aberto.

O EMR Serverless é compatível com rótulos de versão do EMR 6.6 e versões posteriores. Com o EMR Serverless, você obtém o mesmo runtime do EMR com desempenho otimizado disponível em outras opções de implantação do EMR, que é 100% compatível com APIs de frameworks padrão de código aberto.

O BilledResourceUtilization leva em consideração apenas a duração durante a qual a capacidade pré-inicializada foi utilizada para a tarefa e não leva em consideração nenhum tempo ocioso dessa capacidade.

Se a duração do runtime de um operador for menor que 60 segundos, BilledResourceUtilization a contará como 60 segundos, enquanto TotalResourceUtilization a arredondará para o segundo mais próximo. Além disso, BilledResourceUtilization exclui 20 GB de armazenamento gratuito do cálculo.

Com o Amazon EMR Serverless, você pode criar uma ou mais aplicações do EMR Serverless que usam frameworks de análise de código aberto. Para criar uma aplicação, é necessário especificar estes atributos: 1) a versão do Amazon EMR para a versão do framework de código aberto que deseja usar e 2) os mecanismos de análise específicos que você deseja que sua aplicação use, como o Apache Spark 3.1 ou o Apache Hive 3.0. Após criar uma aplicação, você pode começar a executar suas tarefas de processamento de dados ou solicitações interativas para sua aplicação.

Uma aplicação do EMR Serverless usa operadores internamente para executar suas workloads. Quando um trabalho é enviado, o EMR Serverless calcula os recursos necessários para o trabalho e agenda os operadores. O EMR Serverless divide suas workloads em tarefas, provisiona e configura operadores com o framework de código aberto e os desativa quando o trabalho é concluído. O EMR Serverless aumenta e diminui verticalmente os operadores automaticamente, de acordo com a workload e o paralelismo necessários em cada etapa do trabalho, eliminando assim a necessidade de estimar o número de operadores necessários para executar suas workloads. O tamanho padrão desses operadores é baseado no tipo de aplicação e na versão do Amazon EMR. Você pode substituir esses tamanhos ao programar a execução de uma tarefa.

Com o EMR Serverless, você pode especificar o número mínimo e máximo de operadores simultâneos e a configuração de vCPU e memória para operadores. Também é possível definir os limites máximos de capacidade dos recursos da aplicação para controlar os custos.

Considere criar várias aplicações ao realizar qualquer uma destas ações:

1. Usar diferentes frameworks de código aberto

2. Usar diferentes versões de frameworks de código aberto para diferentes casos de uso

3. Realizar testes A/B ao atualizar de uma versão para outra

4. Manter ambientes lógicos separados para cenários de teste e produção

5. Fornecer ambientes lógicos separados para diferentes equipes com controles de custos independentes e rastreamento de uso

6. Separar aplicações de linhas de negócios diferentes

Sim, é possível modificar as propriedades da aplicação, como capacidade inicial, limites máximos de capacidade e configuração de rede usando o EMR Studio ou a chamada API/CLI update-application.

Uma aplicação do EMR Serverless sem operadores pré-inicializados leva até 120 segundos para determinar os recursos necessários e provisioná-los. O EMR Serverless fornece um recurso opcional que mantém os operadores inicializados e prontos para responder em segundos, criando efetivamente um grupo de operadores de plantão para uma aplicação. Esse recurso é chamado de capacidade pré-inicializada e pode ser configurado para cada aplicação definindo o parâmetro de capacidade inicial da aplicação.

A capacidade pré-inicializada permite que os trabalhos sejam iniciados imediatamente, sendo ideal para a implementação de trabalhos urgentes. Você pode especificar o número de operadores que deseja pré-inicializar ao iniciar uma aplicação do EMR Serverless. Em seguida, quando os usuários enviam trabalhos, os operadores pré-inicializados podem ser usados para iniciar os trabalhos imediatamente. Se a tarefa necessitar de mais operadores do que você escolheu para pré-inicializar, o EMR Serverless adicionará automaticamente mais operadores (até o limite máximo simultâneo especificado). Após a conclusão do trabalho, o EMR Serverless volta automaticamente a manter os operadores pré-inicializados que você especificou. Os operadores são desligados automaticamente quando ficam ociosos por 15 minutos. Você pode alterar o tempo limite de inatividade padrão da aplicação usando a API updateApplication ou o EMR Studio.

Você pode enviar e gerenciar tarefas do EMR Serverless usando o EMR Studio, o SDK, a CLI ou nossos conectores do Apache Airflow.

Para o PySpark, você pode empacotar as dependências do Python usando virtualenv e transferir o arquivo usando a opção --archives, que permite que os operadores usem as dependências durante a execução da tarefa. Para Scala ou Java, você pode empacotar as dependências como jars, carregá-las no Amazon S3 e transferi-las usando as opções --jars ou --packages com a execução de tarefa do EMR Serverless.

O EMR Serverless oferece suporte a UDFs baseadas em Java. Você pode empacotá-las como jars, carregá-las no S3 e usá-las em seus scripts do Spark ou do HiveQL.

Para obter detalhes, consulte Configuração de operadores com suporte.

Sim, é possível cancelar uma tarefa do EMR Serverless em execução no EMR Studio ou chamando a API/CLI cancelJobRun.

É possível adicionar armazenamento extra aos operadores no EMR Serverless selecionando a opção de armazenamento apropriada durante o envio da tarefa. O EMR Serverless oferece duas opções de armazenamento temporário:

• Armazenamento padrão: essa opção oferece 20 GB de armazenamento temporário por operador por padrão. Você pode personalizar essa capacidade durante o envio do trabalho e aumentar a capacidade de armazenamento de 20 GB para 200 GB por operador.

• Em disco otimizado para shuffle: essa opção fornece até 2 TB de armazenamento temporário por operador, otimizado para workloads com uso intenso de shuffle.

Você encontra códigos de exemplo do EMR Serverless em nosso repositório do GitHub.

O EMR Serverless oferece duas opções para operadores: operadores sob demanda e operadores pré-inicializados.

Os operadores sob demanda são iniciados somente quando necessários para um trabalho e são liberados automaticamente quando o trabalho é concluído. Isso ajuda você a economizar custos, pagando somente pelos recursos que você usa e a evitar custos adicionais de capacidade ociosa. Operadores sob demanda ampliam ou diminuem sua aplicação com base na sua workload, para que você não precise se preocupar com o provisionamento excessivo ou insuficiente de recursos.

Os trabalhadores pré-inicializados são um recurso opcional em que você pode manter os trabalhadores prontos para responder em segundos. Isso cria efetivamente um grupo aquecido de trabalhadores para uma aplicação. Isso permite que os trabalhos sejam iniciados instantaneamente, tornando-os ideais para aplicações iterativas e trabalhos urgentes.

Sim, é possível configurar aplicações do EMR Serverless em várias AZs. O processo para configurar várias AZs depende do tipo de operador que você usa.

Ao usar somente operadores sob demanda, o EMR Serverless distribui trabalhos em várias AZs por padrão, mas cada tarefa é executada somente em uma AZ. Você pode escolher quais AZs usar associando sub-redes a essas AZs. Se uma AZ falhar, o EMR Serverless executará automaticamente seu trabalho em outra AZ íntegra.

Ao usar trabalhadores pré-inicializados, o EMR Serverless seleciona uma AZ íntegra nas sub-redes que você especifica. Os trabalhos são enviados nessa AZ até que você interrompa a aplicação. Se uma AZ ficar danificada, você poderá reiniciar a aplicação para mudar para outra AZ íntegra.

O EMR Serverless apenas pode acessar determinados recursos da AWS na mesma região quando configurado sem conectividade com a VPC. Consulte as considerações. Para acessar os recursos da AWS em uma região diferente ou em recursos fora da AWS, você precisará configurar o acesso à VPC e um gateway NAT para rotear os recursos da AWS para endpoints públicos.

As métricas de nível de trabalho e de aplicação do Amazon EMR Serverless são publicadas a cada 30 segundos no Amazon CloudWatch.

No EMR Studio, você pode selecionar um trabalho do EMR Serverless em execução ou concluído e clicar no botão Spark UI ou Tez UI para iniciá-los.

Sim, você pode configurar aplicações do Amazon EMR Serverless para acessar recursos em sua própria VPC. Para saber mais, consulte a seção Configurar acesso da VPC da documentação. 

Cada aplicação do EMR Serverless é isolada de outras aplicações e executada em uma Amazon VPC segura.

O Amazon EMR Sem Servidor está introduzindo uma nova cota de serviço chamada Max vCPUs simultâneas por conta. Essa cota baseada em vCPUs permite que você defina o número máximo de vCPUs agregadas que suas aplicações podem usar para aumentar a escala verticalmente em uma região. As cotas existentes com base no operador no nível da aplicação (máximo de operadores ativos) chegaram ao fim do suporte em 1º de fevereiro de 2023.

Você pode visualizar, gerenciar e solicitar aumento de cota no console de gerenciamento do AWS Service Quotas. Para obter mais informações, consulte Solicitar um aumento de cota no Guia do usuário do Service Quotas.

O EMR Serverless oferece dois controles de custo: 1) A cota máxima de vCPUs simultâneas por conta é aplicada a todas as aplicações do EMR Serverless em uma região da sua conta. 2) O parâmetro maximumCapacity limita a vCPU de uma aplicação específica do EMR Serverless. Você deve usar a cota baseada em vCPU para limitar o máximo de vCPUs simultâneas usadas por todas as aplicações em uma região e a propriedade maximumCapacity para limitar os recursos usados por uma aplicação específica. Por exemplo, se você tiver cinco aplicações e cada uma puder escalar até 1.000 vCPUs, defina a propriedade maximumCapacity como 1.000 vCPUs para cada aplicação e configure a cota baseada em vCPU no nível da conta como 5 x 1.000 = 5.000 vCPUs.

Se você exceder sua cota de vCPUs no nível da conta, o EMR Serverless interromperá o provisionamento de nova capacidade. Se você tentar criar uma nova aplicação depois de exceder a cota, a criação da aplicação falhará com uma mensagem de erro “Application failed to create as you have exceeded the maximum concurrent vCPUs per account service quota. You can view and manage your service quota using AWS Service Quotas console” (Falha ao criar a aplicação porque você excedeu o máximo de vCPUs simultâneas por cota de serviço de conta. Você pode visualizar e gerenciar sua cota de serviços usando o console do AWS Service Quotas). Se você enviar um novo trabalho depois de exceder a cota, o trabalho falhará com uma mensagem de erro: “Job failed as you have exceeded the maximum concurrent vCPUs per account service quota. Você pode visualizar e gerenciar sua cota de serviços usando o console do AWS Service Quotas. Consulte a documentação para obter mais detalhes.

O Amazon EMR Serverless pode ajudar você a reduzir custos de três formas. Primeiro, não há sobrecarga operacional de gerenciamento, proteção e escala de clusters. Segundo, o EMR Serverless aumenta automaticamente a escala na vertical dos operadores em cada etapa do processamento de seu trabalho e a diminui quando necessário. Você é cobrado pelos recursos agregados de vCPU, memória e armazenamento usados a partir do momento em que um operador entra em execução até o momento em que termina. O tempo é arredondado para o segundo mais próximo, e o período mínimo é de um minuto. Por exemplo, seu trabalho pode exigir dez operadores nos primeiros dez minutos de processamento do trabalho e 50 operadores nos cinco minutos seguintes. Com a escala automática refinada, você incorre em custos de apenas dez operadores por dez minutos e 50 operadores por cinco minutos. Como resultado, você não precisa pagar por recursos subutilizados. Terceiro, o EMR Serverless inclui o tempo de execução otimizado para performance do Amazon EMR para o Apache Spark e o Apache Hive e o Presto. O tempo de execução do Amazon EMR é compatível com API e duas vezes mais rápido que os mecanismos de análise de código aberto padrão. Assim, suas tarefas são executadas mais rapidamente e incorrem em menos custos de computação.

Depende de seu EMR atual ao utilizar o cluster do EC2. Se você executar clusters do EMR usando instâncias sob demanda do EC2, o EMR Serverless oferecerá um custo total de propriedade (TCO) menor, se a utilização do cluster atual for inferior a 70%. Se estiver usando os EC2 Savings Plans, o EMR Serverless oferecerá um TCO menor, se a utilização do cluster atual for inferior a 50%. E se você usar instâncias spot do EC2, o Amazon EMR no EC2 e o Amazon EMR no EKS ainda terão um custo-benefício melhor.

Sim, caso não interrompa os operadores após a conclusão de uma tarefa, você incorrerá em cobranças relacionadas aos operadores pré-inicializados.

Para o PySpark, você pode empacotar as dependências do Python usando virtualenv e transferir o arquivo usando a opção --archives, que permite que os operadores usem as dependências durante a execução da tarefa. Para Scala ou Java, você pode empacotar as dependências como jars, carregá-las no Amazon S3 e transferi-las usando as opções --jars ou --packages com a execução de tarefa do EMR Serverless.

Para o PySpark, você pode empacotar as dependências do Python usando virtualenv e transferir o arquivo usando a opção --archives, que permite que os operadores usem as dependências durante a execução da tarefa. Para Scala ou Java, você pode empacotar as dependências como jars, carregá-las no Amazon S3 e transferi-las usando as opções --jars ou --packages com a execução de tarefa do EMR Serverless.

O Amazon EMR Serverless elimina o provisionamento de armazenamento local para workloads do Apache Spark, reduzindo os custos de processamento de dados em até 20% e evitando falhas de trabalho devido a restrições de capacidade de disco. O EMR Serverless gerencia automaticamente as operações intermediárias de dados, como o shuffle, sem exigir nenhuma decisão de infraestrutura. Ao lidar automaticamente com dados intermediários independentemente dos funcionários da computação, essa otimização permite que a alocação dinâmica de recursos (DRA) do Spark libere recursos computacionais no momento em que eles não são mais necessários para processamento, em vez de mantê-los funcionando apenas para preservar dados locais temporários. Esse aprimoramento automático fornece maior elasticidade para grandes workloads de transformação, como grandes agregações, uniões e análises pesadas, permitindo que os recursos de computação aumentem e diminuam dinamicamente em todos os estágios do trabalho sem serem restringidos por dados armazenados localmente.

Você simplesmente seleciona essa opção quando usar o EMR versão 7.12 ou posterior. Seus trabalhos do Spark se beneficiarão automaticamente do tratamento otimizado de dados intermediários sem exigir nenhuma configuração da sua parte. Monitore seus trabalhos em tempo real usando a interface do usuário do Spark Live e visualize métricas detalhadas de reprodução aleatória e de vazamento por estágio para trabalhos concluídos no Spark History Server.

Seus dados intermediários são armazenados somente enquanto a tarefa estiver em execução e serão excluídos automaticamente quando ela for concluída, garantindo que nenhum dado persista além do ciclo de vida da tarefa.

Essa otimização automática mantém os mesmos padrões de segurança de nível corporativo do EMR Serverless por meio de várias camadas de proteção. Todos os dados são criptografados em trânsito entre a aplicação EMR Serverless e a camada intermediária de processamento de dados e em repouso enquanto armazenados temporariamente, usando chaves de criptografia gerenciadas pela AWS. Esse recurso impõe isolamento de dados e controle de acesso rigorosos armazenando seus dados intermediários em identificadores específicos do trabalho em seu namespace, garantindo que seus dados permaneçam acessíveis somente à tarefa específica. Seus controles de acesso e permissões existentes do EMR Serverless continuam sendo aplicados, portanto, os dados regidos pelas políticas de tabela ou Lake Formation permanecem totalmente protegidos. Para aumentar a segurança, o EMR Serverless usa uma função de propriedade do serviço para lidar com o processamento intermediário de dados em vez da função de execução da tarefa, impedindo o aumento de privilégios ou o acesso não autorizado entre contas. Se alguma verificação de segurança falhar, a tarefa será interrompida imediatamente para garantir que os dados permaneçam protegidos o tempo todo.