Perguntas frequentes sobre o Amazon EMR

O Amazon EMR é um serviço de processamento de big data que acelera workloads de analytics com flexibilidade e escalabilidade incomparáveis. O EMR apresenta runtimes com performance otimizada para Apache Spark, Trino, Apache Flink e Apache Hive, reduzindo drasticamente os custos e os tempos de processamento.

O Amazon EMR no Amazon EC2 oferece controle sobre a configuração do cluster e é compatível com clusters de longa duração, tornando-o ideal para tarefas contínuas de processamento de dados que exigem configurações específicas de hardware. O Amazon EMR Sem Servidor facilita a execução de estruturas de big data analytics de código aberto, como o Apache Spark, sem a necessidade de configurar, gerenciar e escalar clusters ou servidores. O Amazon EMR no Amazon Elastic Kubernetes Service (EKS) permite enviar trabalhos sob demanda no EKS sem provisionar clusters EMR.

É possível implantar suas workloads no EMR usando Amazon EC2, Amazon Elastic Kubernetes Service (EKS) ou EMR Sem Servidor. 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 se cadastrar no Amazon EMR, selecione o botão “Cadastre-se agora” na página de detalhes http://aws.amazon.com/emr.  Após o cadastro, consulte a documentação do Amazon EMR, que inclui o Guia de conceitos básicos – o melhor lugar para começar a usar o EMR no EC2, o EMR Sem Servidor ou o EMR no EKS.

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 notebook.

Você pode desenvolver, visualizar e depurar aplicações de ciência de dados e engenharia de dados escritos em R, Python, Scala e PySpark noAmazon 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 aplicativos 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 esta 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 seu 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 terminar seu cluster automaticamente quando todos os seus passos terminarem, ligando a bandeira de terminação automática.

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 EMR6.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 seu 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 blocos de anotações 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 seus aplicativos 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 cadernos 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 notebooks. 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 notebook 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 notebooks, 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 seu 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 por seu administrador.

O Centro de Identidade do AWS IAM (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 workspace 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 Ambiente de Tempo de Execução do Amazon EMR para Apache Spark.

Todas as consultas do Spark são executadas no cluster do EMR. Portanto, você precisa instalar todas as bibliotecas de runtime que seu aplicativo 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 Jupyter Notebook e 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 notebook 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 notebook tem o mesmo nome que seu notebook no Amazon EMR Studio.

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

Com o EMR Studio, você pode executar o código do notebook 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 workspace, 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 são atualmente suportados.

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.

O Amazon EMR oferece várias maneiras de obter dados em 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 para a nuvem 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 à medida que os transfere para o Amazon S3.

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 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 do trabalho.

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 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 seu uso no Console de gerenciamento de cobrança e custos.

No Console de Gerenciamento da AWS, cada cluster tem uma coluna Normalized Instance Hours 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 consultar 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.

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 grupo 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 CloudTrail na página inicial do CloudTrail no Console de Gerenciamento da AWS.

Por padrão, os processos do 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. Adote 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 a partir de 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 a autorização nos níveis da tabela, coluna e linha para o Hive, nos níveis da tabela e coluna para o Spark e nos níveis do prefixo e 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 deixa que você utilize 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 definição de preço de largura de banda, acesse a seção de definição de preço 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.

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 do 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.

STARTING - 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". 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 seus clusters. Se precisar de mais instâncias, preencha o formulário de solicitação de instâncias do Amazon EC2. Assim que o limite no Amazon EC2 for aumentado, o novo limite será aplicado aos clusters do Amazon EMR.

Você pode fazer upload dos dados de entrada e de um aplicativo 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 de saída 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. Apenas um "cluster" poderá envolver uma sequência de etapas MapReduce.

Consulte a página de definição de preço do EMR para obter detalhes sobre definição de preço 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 actions do boot-strap. 

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, fazê-lo no nó desejado.

As actions do Bootstrap é 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. As actions do bootstrap podem ser usadas para instalar softwares ou configurar instâncias antes da execução do cluster. Você pode ler mais sobre essas actions do bootstrap no Guia do desenvolvedor do EMR.

É possível gravar um script do Bootstrap Action em qualquer idioma já instalado 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 o Bootstrap Actions.

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 Bootstrap Action pré-definida está disponível para configurar o cluster na inicialização. Consulte o tópico sobre como Configurar bootstrap actions que exigem muita memória no Guia do desenvolvedor, para obter detalhes de configuração e instruções de uso. Uma bootstrap action pré-definida adicional está disponível, permitindo que você personalize as definições do cluster para qualquer valor selecionado. Consulte o tópico sobre como Configurar bootstrap actions 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 mais detalhes sobre como modificar o tamanho de um cluster em execução. Você também pode usar o Escalamento Gerenciado EMR.

Como 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 inicializar 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 o Escalamento Gerenciado 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 é assegurado que todas as etapas são 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 terminados ou instâncias de Amazon EC2 terminadas, 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 de 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 etiquetas 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 etiquetas corretas.

O Amazon EMR Sem Servidor é 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, analistas e cientistas de dados podem usar o EMR Sem Servidor 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 do trabalho e criar seus pipelines de dados para serem executados no EMR Sem Servidor. 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 Sem Servidor. Siga as instruções do Console de Gerenciamento da AWS, navegue até o Amazon EMR na categoria Analytics (Análise) e selecione Amazon EMR Sem Servidor. Siga as instruções do guia de conceitos básicos para criar sua aplicação do EMR Sem Servidor e enviar trabalhos. Consulte a página Interacting with your application on the AWS CLI (Interagir com sua aplicação na AWS CLI) para iniciar suas aplicações e enviar trabalhos usando a CLI. Você também encontra exemplos do EMR Sem Servidor e código de exemplo em nosso repositório do GitHub.

O EMR Sem Servidor é compatível com rótulos de versão do EMR 6.6 e versões posteriores. Com o EMR Sem Servidor, você obtém o mesmo runtime do EMR com performance otimizada 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.

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 Sem Servidor, você pode criar uma ou mais aplicações do EMR Sem Servidor 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 seus trabalhos de processamento de dados ou solicitações interativas para sua aplicação.

Uma aplicação do EMR Sem Servidor 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 uma execução de trabalho.

Com o EMR Sem Servidor, 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 Sem Servidor 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.

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 seus operadores usem as dependências durante a execução do trabalho. Para Scala ou Java, você pode empacotar suas dependências como jars, carregá-las no Amazon S3 e transferi-las usando as opções --jars ou --packages com sua execução de trabalhos do EMR Sem Servidor.

O EMR Sem Servidor 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.

Sim, é possível cancelar um trabalho do EMR Sem Servidor em execução no EMR Studio ou chamando a API/CLI cancelJobRun.

É possível adicionar armazenamento extra aos operadores no EMR Sem Servidor selecionando a opção de armazenamento apropriada durante o envio do trabalho. 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.

O EMR Sem Servidor 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 Sem Servidor 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 Sem Servidor 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 Sem Servidor são publicadas a cada 30 segundos no Amazon CloudWatch.

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

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

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

Se você exceder sua cota de vCPUs no nível da conta, o EMR Sem Servidor vai 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. You can view and manage your service quota using AWS Service Quotas console” (O trabalho falhou porque você excedeu o máximo de vCPUs simultâneas por cota de serviços da conta. 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 Sem Servidor pode ajudar você a economizar custos de três modos. 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, seus trabalhos são executados 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 um trabalho, 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 do trabalho. Para Scala ou Java, você pode empacotar suas dependências como jars, carregá-las no Amazon S3 e transferi-las usando as opções --jars ou --packages com sua execução de trabalhos do EMR Sem Servidor.

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 do trabalho. Para Scala ou Java, você pode empacotar suas dependências como jars, carregá-las no Amazon S3 e transferi-las usando as opções --jars ou --packages com sua execução de trabalhos do EMR Sem Servidor.

O Amazon EMR Sem Servidor 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 Sem Servidor 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 operadores 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 Sem Servidor por meio de várias camadas de proteção. Todos os dados são criptografados em trânsito entre a aplicação EMR Sem Servidor 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 Sem Servidor 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 Sem Servidor 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.