Considerações sobre o EMR Studio

O EMR Studio está disponível da seguinte forma: Regiões da AWS

* A interface ativa do Spark não é compatível com essas regiões.

Para permitir que os usuários provisionem novos clusters do EMR em execução no Amazon EC2 para um Workspace, você pode associar um EMR Studio a um conjunto de modelos de cluster. Os administradores podem definir modelos de cluster com o Service Catalog e escolher se um usuário ou um grupo pode acessar os modelos de cluster, ou nenhum modelo de cluster, em um Studio.

Ao definir permissões de acesso aos arquivos do notebook armazenados no Amazon S3 ou ler segredos AWS Secrets Manager, use a função de serviço do Amazon EMR. As políticas de sessão não são compatíveis com estas permissões.

Você pode criar diversos EMR Studios para controlar o acesso a clusters do EMR em diferentes VPCs.

Use o AWS CLI para configurar o Amazon EMR em clusters EKS. Em seguida, é possível usar a interface do Studio para anexar clusters a Workspaces com um endpoint gerenciado para executar trabalhos de cadernos.

Há outras considerações ao usar a propagação de identidade confiável com o Amazon EMR que também se aplicam ao EMR Studio. Para ter mais informações, consulte Considerações e limitações para a Amazon EMR com a integração do Identity Center.

O EMR Studio não oferece suporte aos seguintes comandos mágicos do Python:

O Amazon EMR em clusters EKS não oferece suporte a SparkMagic comandos para o EMR Studio.

Para escrever instruções do Scala com várias linhas em células de cadernos, certifique-se de que todas as linhas, exceto a última, terminem com um ponto final. O exemplo a seguir usa a sintaxe adequada para instruções do Scala com várias linhas.

val df = spark.sql("SELECT * from table_name).
        filter("col1=='value'").
        limit(50)

Para aumentar a segurança das aplicações fora do console que podem ser usadas com o Amazon EMR, os domínios de hospedagem das aplicações são registrados na Public Suffix List (PSL). Exemplos desses domínios de hospedagem incluem os seguintes: emrstudio-prod.us-east-1.amazonaws.com, emrnotebooks-prod.us-east-1.amazonaws.com, emrappui-prod.us-east-1.amazonaws.com. Para maior segurança, se precisar definir cookies confidenciais no nome de domínio padrão, recomendamos que você use cookies com um prefixo __Host-. Isso ajuda a defender seu domínio contra tentativas de falsificação de solicitação entre sites (CSRF). Para obter mais informações, consulte a página Set-Cookie em Mozilla Developer Network.

Um EMR Studio que usa o Centro de Identidade do IAM com a propagação de identidade confiável habilitada só pode se associar a clusters do EMR que também usam a propagação de identidade confiável.

Certifique-se de desativar as ferramentas de gerenciamento de proxy, como FoxyProxy ou SwitchyOmega, no navegador antes de criar um Studio. Os proxies ativos podem causar erros quando você escolhe Criar Studio e resultar em uma mensagem de erro de falha de rede.

Os kernels executados em clusters do Amazon EMR no EKS podem falhar ao iniciar devido a problemas de tempo limite. Se você encontrar um erro ou problema ao iniciar o kernel, feche o arquivo de caderno, encerre o kernel e reabra o arquivo de caderno.

A operação Reiniciar kernel não funciona conforme o esperado quando você usa um cluster do Amazon EMR no EKS. Após selecionar Reiniciar kernel, atualize o Workspace para que a reinicialização entre em vigor.

Se um Workspace não estiver anexado a um cluster, uma mensagem de erro será exibida quando um usuário do Studio abrir um arquivo de caderno e tentar selecionar um kernel. Você pode ignorar essa mensagem de erro ao escolher OK, mas deve anexar o Workspace a um cluster e selecionar um kernel antes de poder executar o código do caderno.

Ao usar o Amazon EMR 6.2.0 com uma configuração de segurança para definir a segurança do cluster, a interface do Workspace aparece em branco e não funciona conforme o esperado. Recomendamos usar uma versão diferente do Amazon EMR com suporte, se desejar configurar a criptografia de dados ou a autorização do Amazon S3 para o EMRFS em um cluster. O EMR Studio funciona com as versões 5.32.0 (série 5.x) e 6.2.0 (série 6.x) e superiores do Amazon EMR.

Ao realizar a Depure a Amazon em EMR execução com trabalhos da Amazon EC2, os links para a interface do usuário do Spark no cluster podem não funcionar ou não aparecer. Para gerar os links novamente, crie uma nova célula de caderno e execute o comando %%info.

O Jupyter Enterprise Gateway não limpa os kernels ociosos no nó primário de um cluster nas seguintes versões de liberação do Amazon EMR: 5.32.0, 5.33.0, 6.2.0 e 6.3.0. Os kernels ociosos consomem recursos de computação e podem causar falhas em clusters de longa execução. Você pode configurar a limpeza de kernels ociosos para o Jupyter Enterprise Gateway usando o script de exemplo a seguir. É possível Conecte-se ao nó primário usando SSH ou enviar o script como uma etapa. Para obter mais informações, consulte Run commands and scripts on an Amazon EMR cluster.

#!/bin/bash
sudo tee -a /emr/notebook-env/conf/jupyter_enterprise_gateway_config.py << EOF
c.MappingKernelManager.cull_connected = True
c.MappingKernelManager.cull_idle_timeout = 10800
c.MappingKernelManager.cull_interval = 300
EOF
sudo systemctl daemon-reload
sudo systemctl restart jupyter_enterprise_gateway

Quando você usa uma política de encerramento automático com as versões 5.32.0, 5.33.0, 6.2.0 ou 6.3.0 do Amazon EMR, o Amazon EMR marca um cluster como ocioso e pode encerrá-lo automaticamente mesmo se você tiver um kernel do Python3 ativo. Isso ocorre porque a execução de um kernel do Python3 não envia um trabalho do Spark no cluster. Para usar o encerramento automático com um kernel do Python3, recomendamos usar a versão 6.4.0 ou as versões posteriores do Amazon EMR. Para obter mais informações sobre o encerramento automático, consulte Usar uma política de término automático.

Quando você costuma %%display exibir um Spark DataFrame em uma tabela, tabelas muito largas podem ficar truncadas. Você pode clicar com o botão direito do mouse na saída e selecionar Criar nova visualização para a saída para obter uma visualização da saída com rolagem.

Iniciar um kernel baseado em Spark, como PySpark Spark ou SparkR, inicia uma sessão do Spark, e executar uma célula em um notebook coloca as tarefas do Spark em fila nessa sessão. Quando você interrompe uma célula em execução, o trabalho do Spark continua a ser executado. Para interromper o trabalho do Spark, você deve usar a interface do usuário do Spark no cluster. Para obter instruções sobre como se conectar à interface do usuário do Spark, consulte Depure aplicativos e trabalhos com EMR o Studio.

Usar o Amazon EMR Studio Workspaces como usuário raiz em um Conta da AWS causa um erro. 403: Forbidden Isso ocorre porque a configuração do Jupyter Enterprise Gateway no Amazon EMR não permite acesso ao usuário raiz. Recomendamos que você não use o usuário root para suas tarefas diárias. Para outras opções de autenticação, consulte AWS Identity and Access Management o Amazon EMR.

Anexação e execução de trabalhos em clusters do EMR com uma configuração de segurança que especifica a autenticação do Kerberos.

Clusters com vários nós primários.

Clusters que usam instâncias do Amazon EC2 com base no AWS Graviton2 para versões 6.x do Amazon EMR inferiores a 6.9.0 e versões 5.x inferiores a 5.36.1

Criação de clusters do EMR sem um modelo.

Uso de aplicações do EMR Sem Servidor.

Execução de clusters do Amazon EMR no EKS.

Uso de um perfil de runtime.

Ativação da colaboração do SQL Explorer ou do Workspace.

Você pode especificar, no máximo, cinco sub-redes em sua VPC para serem associadas ao Studio. Recomendamos fornecer várias sub-redes em diferentes zonas de disponibilidade para oferecer suporte à disponibilidade do Workspace e disponibilizar aos usuários do Studio o acesso a clusters em diferentes zonas de disponibilidade. Para saber mais sobre como trabalhar com VPCs, sub-redes e zonas de disponibilidade, consulte VPCs e sub-redes no Guia do usuário da Amazon Virtual Private Cloud .

As sub-redes especificadas deverão ser capazes de se comunicar entre si.

Para permitir que os usuários vinculem um Workspace a repositórios Git hospedados publicamente, você deve especificar somente sub-redes privadas que tenham acesso à Internet através da conversão de endereços de rede (NAT). Para obter mais informações sobre como configurar uma sub-rede privada para o Amazon EMR, consulte Sub-redes privadas.

Ao usar o Amazon EMR no EKS com o EMR Studio, deve haver, no mínimo, uma sub-rede em comum entre o Studio e o cluster do Amazon EKS usado para registrar um cluster virtual. Caso contrário, o endpoint gerenciado não aparecerá como uma opção nos Workspaces do Studio. Você pode criar um cluster do Amazon EKS e associá-lo a uma sub-rede que pertence ao Studio ou criar um Studio e especificar as sub-redes do seu cluster do EKS.

Se você planeja usar o Amazon EMR no EKS com o EMR Studio, escolha a mesma VPC dos nós de processamento do cluster do Amazon EKS.

O cluster deve usar as versões 5.32.0 (Amazon EMR de série 5.x) ou 6.2.0 (Amazon EMR de série 6.x) ou posteriores do Amazon EMR. Você pode criar um cluster usando o console do Amazon EMR, ou SDK AWS Command Line Interface, e depois anexá-lo a um espaço de trabalho do EMR Studio. Os usuários do Studio também podem provisionar e anexar clusters ao criar ou trabalhar em um Workspace do Amazon EMR. Para ter mais informações, consulte Anexar uma computação a um espaço de trabalho do EMR Studio.

O cluster deve estar em uma Amazon Virtual Private Cloud. A plataforma EC2-Classic não é compatível.

O cluster deve ter o Spark, o Livy e o Jupyter Enterprise Gateway instalados. Se você planeja usar o cluster para o SQL Explorer, deverá instalar o Presto e o Spark.

Para usar o SQL Explorer, o cluster deve usar a versão 5.34.0, ou versões posteriores, ou a versão 6.4.0, ou versões posteriores, do Amazon EMR e ter o Presto instalado. Se quiser especificar o AWS Glue Data Catalog como metastore do Hive para o Presto, você deve configurá-lo no cluster. Para obter mais informações, consulte Using Presto with the AWS Glue Data Catalog.

O cluster deve estar em uma sub-rede privada com conversão de endereços de rede (NAT) para usar repositórios Git hospedados publicamente com o EMR Studio.

Defina o modo de implantação das sessões do Spark para o modo de cluster. O modo de cluster coloca os processos principais de aplicações nos nós centrais e não no nó primário de um cluster. Isso alivia o nó primário de possíveis pressões de memória. Para obter mais informações, consulte o tópico de Visão geral do modo de cluster na documentação do Apache Spark.

Altere o tempo limite do Livy do padrão de uma hora para seis horas, como no exemplo de configuração apresentado a seguir.

{
    "classification":"livy-conf",
        "Properties":{
            "livy.server.session.timeout":"6h",
            "livy.spark.deploy-mode":"cluster"
        }
}

Crie diversas frotas de instâncias com até 30 instâncias e selecione vários tipos de instâncias em sua frota de instâncias spot. Por exemplo, é possível especificar os seguintes tipos de instâncias otimizadas para memória para workloads do Spark: r5.2x, r5.4x, r5.8x, r5.12x, r5.16x, r4.2x, r4.4x, r4.8x, r4.12 etc. Para ter mais informações, consulte Configurar frotas de instâncias.

Use a estratégia de alocação com capacidade otimizada para instâncias spot com a finalidade de ajudar o Amazon EMR a fazer seleções de instâncias eficazes com base em insights de capacidade em tempo real do Amazon EC2. Para ter mais informações, consulte Estratégia de alocação para frotas de instâncias.

Habilite o ajuste de escala gerenciado em seu cluster. Defina o parâmetro máximo de nós centrais para a capacidade persistente mínima que você planeja usar, e configure a escalabilidade em uma frota de tarefas bem diversificada que é executada em instâncias spot para economizar custos. Para ter mais informações, consulte Usando escalabilidade gerenciada na Amazon EMR.

Crie um endpoint HTTPS gerenciado para o cluster do Amazon EMR no EKS. Os usuários anexam um Workspace a um endpoint gerenciado. O cluster do Amazon Elastic Kubernetes Service (EKS) usado para registrar um cluster virtual deve ter uma sub-rede privada para oferecer suporte a endpoints gerenciados.

Use um cluster do Amazon EKS com, no mínimo, uma sub-rede privada e com conversão de endereços de rede (NAT) quando desejar usar repositórios Git hospedados publicamente.

Evite usar ARM de AMIs do Amazon Linux otimizadas para o Amazon EKS, que não são compatíveis com os endpoints gerenciados pelo Amazon EMR no EKS.

Evite usar clusters AWS Fargate somente do Amazon EKS, que não são compatíveis.