Requisitos EMR de cluster da Amazon

EMRClusters da Amazon em execução na Amazon EC2

Todos os EMR clusters da Amazon em execução na Amazon EC2 que você cria para um EMR Studio Workspace devem atender aos seguintes requisitos. Os clusters que você cria usando a interface do EMR Studio atendem automaticamente a esses requisitos.

• O cluster deve usar EMR as versões 5.32.0 (Amazon EMR 5.x series) ou 6.2.0 (EMRAmazon 6.x series) ou posteriores. Você pode criar um cluster usando o EMR console da Amazon ou SDK anexá-lo a um EMR Studio Workspace. AWS Command Line Interface Os usuários do Studio também podem provisionar e anexar clusters ao criar ou trabalhar em um Amazon EMR Workspace. Para obter 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 é suportada.

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

• Para usar o SQL Explorer, o cluster deve usar a EMR versão 5.34.0 ou posterior da Amazon ou a versão 6.4.0 ou posterior e ter o Presto instalado. Se você quiser especificar o AWS Glue Data Catalog como o 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 tradução de endereço de rede (NAT) para usar repositórios Git hospedados publicamente com o Studio. EMR

Recomendamos as seguintes configurações de cluster quando você trabalha 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 obter mais informações, consulte Planejando e configurando frotas de instâncias para seu cluster Amazon EMR.

• Use a estratégia de alocação de capacidade otimizada para instâncias spot para ajudar a Amazon a EMR fazer seleções efetivas de instâncias com base em insights de capacidade em tempo real da Amazon. EC2 Para obter 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 obter mais informações, consulte Usando escalabilidade gerenciada na Amazon EMR.

Também recomendamos que você mantenha o Amazon EMR Block Public Access ativado e que restrinja o SSH tráfego de entrada a fontes confiáveis. O acesso de entrada a um cluster permite que os usuários executem cadernos no cluster. Para ter mais informações, consulte Usando a Amazon, EMR bloqueie o acesso público e Controle o tráfego de rede com grupos de segurança para seu EMR cluster Amazon.

Amazon EMR em EKS clusters

Além dos EMR clusters em execução na AmazonEC2, você pode configurar e gerenciar a Amazon EMR em EKS clusters para EMR Studio usando AWS CLI o. Configure a Amazon EMR em EKS clusters usando as seguintes diretrizes:

• Crie um HTTPS endpoint gerenciado para o Amazon EMR on EKS cluster. Os usuários anexam um Workspace a um endpoint gerenciado. O cluster Amazon Elastic Kubernetes Service EKS () que você usa para registrar um cluster virtual deve ter uma sub-rede privada para suportar endpoints gerenciados.

• Use um EKS cluster da Amazon com pelo menos uma tradução privada de sub-rede e endereço de rede (NAT) quando quiser usar repositórios Git hospedados publicamente.

• Evite usar o Arm Amazon Linux EKS otimizado para AmazonAMIs, que não é compatível com a Amazon EMR em endpoints EKS gerenciados.

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