Amazon EMR versão 6.0.0

• Versões do aplicativo nas versões EMR 7.x da Amazon

• 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

• HBaseversão 2.2.3

• HCatalogversã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

• MXNetversã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 atributos

• YARNDocker Runtime Support — YARN aplicativos, como trabalhos do Spark, agora podem ser executados no contexto de um contêiner Docker. Isso permite que você defina facilmente dependências em uma imagem do Docker sem a necessidade de instalar bibliotecas personalizadas em seu cluster da AmazonEMR. Para obter mais informações, consulte Configurar a integração do Docker e executar aplicativos Spark com o Docker usando o Amazon 6.0.0. EMR

• LLAPSuporte do Hive - O Hive agora suporta o modo de LLAP execução para melhorar o desempenho das consultas. Para obter mais informações, consulte Usando o Hive. LLAP

Alterações, melhorias e problemas resolvidos

• Esta é uma versão para corrigir problemas com o Amazon EMR Scaling quando ele falha na escalabilidade ou redução de escala de um cluster com sucesso ou causa falhas no aplicativo.

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

• Daemons EMR no cluster aprimorados para rastrear corretamente os estados dos nós quando os endereços IP são reutilizados para melhorar a confiabilidade durante as 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 falhas de trabalho ocorriam devido a uma condição de corrida no YARN descomissionamento quando o cluster tentava aumentar ou diminuir a escala.

• Foi corrigido o problema com falhas de etapas ou tarefas durante a escalabilidade do cluster, garantindo que os estados dos nós fossem sempre consistentes entre os EMR daemons no cluster da Amazon e/. YARN HDFS

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

• As EMR versões mais recentes da Amazon corrigem o problema com um limite menor de “Máximo de arquivos abertos” em relação aos mais antigos AL2 na AmazonEMR. As EMR 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 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 de lançamento EMR 6.x.

  • systemdé usado para gerenciamento de serviços em vez do inAmazon Linux 1 upstart usado.

• Kit de desenvolvimento Java (JDK)

  • Corretto JDK 8 é o padrão JDK para a série de lançamento EMR 6.x.

• Scala

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

• Python 3

  • O Python 3 agora é a versão padrão do Python em. EMR

• YARNrótulos de nós

  • A partir da série de lançamento Amazon EMR 6.x, o recurso de rótulos de YARN nós está desativado 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. Você pode ativar o recurso de rótulos de YARN nós 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]. EMRLançamentos da Amazon: 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 baseados em versões mais antigas do Linux ofAmazon 2 ()AL2, que têm uma configuração de limite inferior para “Máximo de arquivos abertos” quando os clusters da Amazon são criados com o padrão. EMR AMI As EMR 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 incluem uma correção permanente com uma configuração maior 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, o padrão da Amazon AMI tem uma configuração EMR padrão de ulimit de 4096 para “Máximo de arquivos abertos”, que é inferior ao limite de 65536 arquivos no Linux 2. latestAmazon AMI 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, a Amazon EMR tem um script de ação de bootstrap (BA) que ajusta a configuração ulimit na criação do cluster.

  Se você estiver usando uma EMR versão mais antiga da Amazon que não tem a solução permanente para esse problema, a solução alternativa a seguir permite que você defina explicitamente o ulimit do controlador de instância 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 o SparkR e o spark-shell, não é compatível com o uso do Docker com bibliotecas adicionais.

• Para usar o Python 3 com a EMR versão 6.0.0 da Amazon, você deve adicionar a. PATH 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 em seu cluster com o mesmo tipo de instância e a mesma quantidade de EBS volumes para evitar falhas ao enviar um trabalho do Spark com o tempo de execução do Docker.

• No Amazon EMR 6.0.0, HBase no Amazon S3, o modo de armazenamento é afetado pelo HBASE problema -24286. HBaseo 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 EMR versões 5.20.0 e posteriores da Amazon, poderá encontrar problemas com operações de cluster, como redução de escala 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:

  • SSHcomo hadoop usuário do nó primário principal do EMR cluster 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.