Versão 6.0.0 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

Aplicações compatíveis

• AWS SDK for Java versão 1.11.711

• Ganglia versão 3.7.2

• Hadoop versão 3.2.1

• HBase versão 2.2.3

• HCatalog versão 3.1.2

• Hive versão 3.1.2

• Hudi versão 0.5.0 incubadora

• Hue versão 4.4.0

• JupyterHub versão 1.0.0

• Livy versão 0.6.0

• MXNet versão 1.5.1

• Oozie versão 5.1.0

• Phoenix versão 5.0.0

• Presto versão 0.230

• Spark versão 2.4.4

• TensorFlow versão 1.14.0

• Zeppelin versão 0.9.0-SNAPSHOT

• Zookeeper versão 3.4.14

• Conectores e drivers: DynamoDB Connector 4.14.0

Novos recursos

• Suporte ao runtime do Docker do YARN: aplicações do YARN, como trabalhos do Spark, agora podem ser executados no contexto de um contêiner do Docker. Isso permite que você defina facilmente dependências em uma imagem do Docker sem a necessidade de instalar bibliotecas personalizadas no cluster do Amazon EMR. Para obter mais informações, consulte Configurar a integração do Docker e Executar aplicações do Spark com o Docker usando o Amazon EMR 6.0.0.

• Suporte ao LLAP do Hive – agora o Hive oferece suporte ao modo de execução do LLAP para melhorar o desempenho da consulta. Para obter mais informações, consulte Usar o LLAP do Hive.

Alterações, melhorias e problemas resolvidos

• Esta é uma versão para corrigir problemas com a escalabilidade do Amazon EMR quando ele não aumenta nem reduz verticalmente a escala de um cluster com êxito ou causa falhas na aplicação.

• Corrigido um problema em que as solicitações de escalabilidade falhavam em um cluster grande e altamente utilizado quando os daemons do Amazon EMR no cluster estavam executando atividades de verificação de integridade, como a coleta do estado do nó do YARN e o estado do nó do HDFS. Isso estava acontecendo porque os daemons no cluster não conseguiam comunicar os dados do status de integridade de um nó aos componentes internos do Amazon EMR.

• Aprimorados os daemons do EMR no cluster para rastrear corretamente os estados dos nós quando são reutilizados endereços IP para melhorar a confiabilidade durante operações de escalabilidade.

• SPARK-29683. Corrigido um problema em que ocorriam falhas de trabalho durante a redução da escala verticalmente do cluster, pois o Spark presumia que todos os nós disponíveis estavam na lista de negação.

• YARN-9011. Corrigido um problema em que ocorriam falhas de trabalho devido a uma condição de corrida na desativação do YARN quando o cluster tentava aumentar ou reduzir a escala verticalmente.

• Corrigido problema com falhas de etapas ou tarefas durante a escalabilidade do cluster ao ser garantido que os estados dos nós fossem sempre consistentes entre os daemons do Amazon EMR no cluster e o YARN/HDFS.

• Corrigido um problema em que operações de cluster, como redução de escala verticalmente e envio de etapas, falhavam para clusters do Amazon EMR habilitados com a autenticação Kerberos. Isso ocorreu porque o daemon do Amazon EMR no cluster não renovou o tíquete do Kerberos, que é necessário para a comunicação segura com o HDFS/YARN em execução no nó primário.

• As versões mais recentes do Amazon EMR corrigem o problema com um limite menor de “Máximo de arquivos abertos” em relação às versões mais antigas AL2 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”.

• Amazon Linux

  • O Amazon Linux 2 é o sistema operacional da série 6.x do EMR.

  • systemd é usado para gerenciamento de serviço em vez de upstart, usado no Amazon Linux 1.

• Java Development Kit (JDK)

  • O JDK 8 do Coretto é o JDK padrão da série 6.x do EMR.

• Scala

  • O Scala 2.12 é usado com o Apache Spark e com o Apache Livy.

• Python 3

  • Agora o Python 3 é a versão padrão do Python no EMR.

• Rótulos de nó do YARN

  • A partir do Amazon EMR série 6.x, o recurso de rótulos de nó do YARN é desabilitado por padrão. Os principais processos do aplicativo podem ser executados tanto nos nós core como nos nós de tarefa por padrão. É possível habilitar o recurso de rótulos de nó do YARN configurando as seguintes propriedades: yarn.node-labels.enabled e yarn.node-labels.am.default-node-label-expression. Para obter mais informações, consulte Noções básicas sobre nós de tarefa, centrais e primários.

Problemas conhecidos

• Limite inferior de “Máximo de arquivos abertos” em versões mais antigas AL2 [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 (), que AL2 têm uma configuração de limite 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. Reiniciar 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

• O shell interativo do Spark PySpark, incluindo SparkR e spark-shell, não oferece suporte ao uso do Docker com bibliotecas adicionais.

• Para usar o Python 3 com a versão 6.0.0 do Amazon EMR, adicione PATH a yarn.nodemanager.env-whitelist.

• A funcionalidade Live Long and Process (LLAP) não é suportada quando você usa o AWS Glue Data Catalog como metastore do Hive.

• Ao usar o Amazon EMR 6.0.0 com a integração do Spark e do Docker, você precisa configurar as instâncias no cluster com o mesmo tipo de instância e a mesma quantidade de volumes do EBS para evitar falhas quando enviar um trabalho do Spark com runtime do Docker.

• No Amazon EMR 6.0.0, no Amazon HBase S3, o modo de armazenamento é afetado pelo problema do HBASE-24286. HBase o master não pode inicializar quando o cluster é criado usando dados existentes do S3.

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