Versão 5.30.1 do Amazon EMR

• Versões de aplicações nas versões 7.x do Amazon EMR

• Versões de aplicações nas versões 6.x do Amazon EMR

• Versões de aplicações nas versões 5.x do Amazon EMR

• Versões de aplicações nas versões 4.x do Amazon EMR

Alterações, melhorias e problemas resolvidos

• As versões mais recentes do Amazon EMR corrigem o problema com um limite menor de “Máximo de arquivos abertos” no AL2 antigo no Amazon EMR. As versões 5.30.1, 5.30.2, 5.31.1, 5.32.1, 6.0.1, 6.1.1, 6.2.1, 5.33.0, 6.3.0 e posteriores do Amazon EMR agora incluem uma correção permanente com uma configuração mais alta de “Máximo de arquivos abertos”.

• Corrigido um problema em que o processo do controlador da instância gerava um número infinito de processos.

• Corrigido um problema em que o Hue não conseguia executar uma consulta do Hive, mostrando a mensagem “o banco de dados está bloqueado” e impedindo a execução de consultas.

• Corrigido um problema no Spark para permitir que mais tarefas fossem executadas simultaneamente no cluster do EMR.

• Corrigido um problema no caderno Jupyter que causava um “erro de muitos arquivos abertos” no servidor Jupyter.

• Corrigido um problema com as horas de início do cluster.

Novos atributos

• A interface do usuário do Tez e as interfaces de aplicações persistentes do servidor de linha do tempo do YARN estão disponíveis com as versões 6.x do Amazon EMR e com as versões 5.30.1 e posteriores do EMR. O acesso com um clique no link do histórico persistente da aplicação permite que você acesse rapidamente o histórico de tarefas sem configurar um proxy da Web por meio de uma conexão SSH. Os logs de clusters ativos e encerrados ficam disponíveis por 30 dias após o término da aplicação. Para obter mais informações, consulte View Persistent Application User Interfaces no Guia de gerenciamento do Amazon EMR.

• As APIs de execução do Caderno do EMR estão disponíveis para executar Cadernos do EMR por meio de um script ou uma linha de comando. A capacidade de iniciar, interromper, listar e descrever as execuções do caderno do EMR sem o console da AWS permite que você controle programaticamente um caderno do EMR. Ao usar uma célula do caderno parametrizada, você pode passar valores de parâmetros diferentes para um caderno sem precisar criar uma cópia do caderno para cada novo conjunto de valores de parâmetros. Consulte Ações de API do EMR. Para obter um exemplo de código, consulte Exemplos de comandos para executar Cadernos do EMR programaticamente.

Problemas conhecidos

• Limite inferior de “Máximo de arquivos abertos” no AL2 antigo [corrigido em versões mais recentes]. Versões do Amazon EMR: emr-5.30.x, emr-5.31.0, emr-5.32.0, emr-6.0.0, emr-6.1.0 e emr-6.2.0 são baseadas em versões mais antigas do Amazon Linux 2 (AL2), que têm uma configuração de ulimit inferior para “Máximo de arquivos abertos” quando clusters do Amazon EMR são criados com a AMI padrão. As versões 5.30.1, 5.30.2, 5.31.1, 5.32.1, 6.0.1, 6.1.1, 6.2.1, 5.33.0, 6.3.0 e posteriores do Amazon EMR incluem uma correção permanente com uma configuração mais alta de “Máximo de arquivos abertos”. Versões com o limite inferior de arquivos abertos causam o erro “Muitos arquivos abertos” ao ser enviado um trabalho do Spark. Nas versões afetadas, a AMI padrão do Amazon EMR tem uma configuração de ulimit padrão de 4096 para “Máximo de arquivos abertos”, que é inferior ao limite de 65536 arquivos na AMI mais recente do Amazon Linux 2. A configuração inferior de ulimit para “Máximo de arquivos abertos” causa falhas em trabalhos do Spark quando o driver e o executor do Spark tentam abrir mais de 4096 arquivos. Para corrigir o problema, o Amazon EMR tem um script de ação de bootstrap (BA) que ajusta a configuração de ulimit na criação do cluster.

  Se você está usando uma versão mais antiga do Amazon EMR que não tem a correção permanente para esse problema, a solução alternativa a seguir permite que você defina explicitamente o ulimit instance-controller para um máximo de 65536 arquivos.

  Defina explicitamente um ulimit na linha de comando

  1. Edite /etc/systemd/system/instance-controller.service para adicionar os seguintes parâmetros à seção Serviço.

     LimitNOFILE=65536

     LimitNPROC=65536

  2. Reinicie o InstanceController

     $ sudo systemctl daemon-reload

     $ sudo systemctl restart instance-controller

  Defina um ulimit usando a ação de bootstrap (BA)

  Você também pode usar um script de ação de bootstrap (BA) para configurar o ulimit instance-controller para 65536 arquivos na criação do cluster.

  #!/bin/bash
  for user in hadoop spark hive; do
  sudo tee /etc/security/limits.d/$user.conf << EOF
  $user - nofile 65536
  $user - nproc 65536
  EOF
  done
  for proc in instancecontroller logpusher; do
  sudo mkdir -p /etc/systemd/system/$proc.service.d/
  sudo tee /etc/systemd/system/$proc.service.d/override.conf << EOF
  [Service]
  LimitNOFILE=65536
  LimitNPROC=65536
  EOF
  pid=$(pgrep -f aws157.$proc.Main)
  sudo prlimit --pid $pid --nofile=65535:65535 --nproc=65535:65535
  done
  sudo systemctl daemon-reload

• Cadernos do EMR

  O atributo que permite instalar kernels e bibliotecas Python adicionais no nó primário do cluster está desabilitado por padrão na versão 5.30.1 do EMR. Para obter mais informações sobre esse atributo, consulte Instalar kernels e bibliotecas Python em um nó primário do cluster.

  Para habilitar o recurso, faça o seguinte:

  1. Certifique-se de que a política de permissões anexada ao perfil de serviço para os Cadernos do EMR permite a seguinte ação:

     elasticmapreduce:ListSteps

     Para obter mais informações, consulte Função de serviço do EMR Notebooks.

  2. Use a AWS CLI para executar uma etapa no cluster que configura os Cadernos do EMR, conforme mostrado no exemplo a seguir. Substitua us-east-1 pela região em que seu cluster reside. Para obter mais informações, consulte Adding Steps to a Cluster Using the AWS CLI.

     aws emr add-steps  --cluster-id MyClusterID --steps Type=CUSTOM_JAR,Name=EMRNotebooksSetup,ActionOnFailure=CONTINUE,Jar=s3://us-east-1.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://awssupportdatasvcs.com/bootstrap-actions/EMRNotebooksSetup/emr-notebooks-setup.sh"]
                             

• Ajuste de escala gerenciado

  As operações de ajuste de escala gerenciado nos clusters das versões 5.30.0 e 5.30.1 sem o Presto instalado podem causar falhas na aplicação ou fazer com que um grupo de instâncias ou uma frota de instâncias uniforme permaneça no estado ARRESTED, sobretudo quando uma operação de redução da escala verticalmente logo é seguida por uma operação de aumento da escala verticalmente.

  Como solução alternativa, escolha o Presto como uma aplicação a ser instalada ao criar um cluster com as versões 5.30.0 e 5.30.1 do Amazon EMR, mesmo que o trabalho não exija o Presto.

• Problema conhecido em clusters com vários nós primários e autenticação Kerberos

  Se você executar clusters com vários nós primários e autenticação Kerberos nas versões 5.20.0 e posteriores do Amazon EMR, poderá encontrar problemas nas operações de cluster, como redução da escala verticalmente ou envio de etapas depois que o cluster estiver em execução por algum tempo. O período depende do período de validade do tíquete do Kerberos que você definiu. O problema de redução da escala verticalmente afeta tanto as solicitações de redução automática quanto as de reduções explícitas que você enviou. Operações adicionais de cluster também podem ser afetadas.

  Solução:

  • SSH como usuário do hadoop para o nó primário de liderança do cluster do EMR com vários nós primários.

  • Execute o comando a seguir para renovar o tíquete do Kerberos para o usuário do hadoop.

    kinit -kt <keytab_file> <principal>

    Normalmente, o arquivo keytab está localizado em /etc/hadoop.keytab e a entidade principal está na forma de hadoop/<hostname>@<REALM>.

  nota

  Essa solução alternativa entrará em vigor durante o período de validade do tíquete do Kerberos. Essa duração é de 10 horas por padrão, mas pode ser configurada pelas definições do Kerberos. Você deve executar novamente o comando acima quando o tíquete do Kerberos expirar.

• Quando você usa o Spark com a formatação de localização de partições do Hive para ler dados no Amazon S3 e executa o Spark nas versões 5.30.0 a 5.36.0 e 6.2.0 a 6.9.0 do Amazon EMR, pode encontrar um problema que impede que o cluster leia os dados corretamente. Isso poderá acontecer se suas partições tiverem todas as características a seguir:

  • Duas ou mais partições são verificadas na mesma tabela.

  • Pelo menos um caminho de diretório de partição é um prefixo de pelo menos outro caminho de diretório de partição, por exemplo, s3://bucket/table/p=a é um prefixo de s3://bucket/table/p=a b.

  • O primeiro caractere que segue o prefixo no outro diretório de partição tem um valor UTF-8 menor que o caractere / (U+002F). Por exemplo, o caractere de espaço (U+0020) que ocorre entre a e b em s3://bucket/table/p=a b se enquadra nessa categoria. Observe que existem 14 outros caracteres que não são de controle: !"#$%&‘()*+,-. Para obter mais informações, consulte Tabela de codificação UTF-8 e caracteres Unicode.

  Como solução alternativa para esse problema, defina a configuração spark.sql.sources.fastS3PartitionDiscovery.enabled como false na classificação spark-defaults.