Versão 6.2.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.828

• emr-record-server versão 1.7.0

• Flink versão 1.11.2

• Ganglia versão 3.7.2

• Hadoop versão 3.2.1-amzn-1

• HBase versão 2.2.6-amzn-0

• HBase-operator-tools 1.0.0

• HCatalog versão 3.1.2-amzn-0

• Hive versão 3.1.2-amzn-3

• Hudi versão 0.6.0-amzn-1

• Hue versão 4.8.0

• JupyterHub versão 1.1.0

• Livy versão 0.7.0

• MXNet versão 1.7.0

• Oozie versão 5.2.0

• Phoenix versão 5.0.0

• Pig versão 0.17.0

• Presto versão 0.238.3-amzn-1

• PrestoSQL versão 343

• Spark versão 3.0.1-amzn-0

• spark-rapids 0.2.0

• TensorFlow versão 2.3.1

• Zeppelin versão 0.9.0-preview1

• Zookeeper versão 3.4.14

• Conectores e drivers: DynamoDB Connector 4.16.0

Novos atributos

• HBase: removida a renomeação na fase de confirmação e adicionado rastreamento persistente do HFile. Consulte Rastreamento persistente do HFile no Guia de lançamento do Amazon EMR.

• HBase: enviado para backport Crie uma configuração que force o armazenamento em cache dos blocos na compactação.

• PrestoDB: melhorias na remoção dinâmica de partições. O Join Reorder baseado em regras funciona em dados não particionados.

• Políticas gerenciadas com escopo: para alinhamento com as práticas recomendadas da AWS, o Amazon EMR introduziu políticas gerenciadas padrão com escopo do EMR v2 como substitutas das políticas que serão descontinuadas. Consulte as políticas gerenciadas do Amazon EMR.

• Status de suporte do serviço de metadados de instância (IMDS) V2: os componentes do Amazon EMR 6.2 ou posteriores usam IMDSv2 para todas as chamadas do IMDS. Para chamadas do IMDS no código da aplicação, você pode usar IMDSv1 e IMDSv2 ou configurar o IMDS para usar somente IMDSv2 para segurança adicional. Se você desabilitar o IMDSv1 em versões anteriores do Amazon EMR 6.x, ocorrerá uma falha na inicialização do cluster.

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

• Spark: melhorias de performance no runtime do Spark.

Problemas conhecidos

• O Amazon EMR 6.2 tem permissões incorretas definidas no arquivo /etc/cron.d/libinstance-controller-java no EMR 6.2.0. As permissões no arquivo são 645 (-rw-r--r-x), quando deveriam ser 644 (-rw-r--r--). Como resultado, a versão 6.2 do Amazon EMR não registra logs do estado da instância e o diretório /emr/instance-logs é vazio. Esse problema foi corrigido nas versões 6.3.0 e posteriores do Amazon EMR.

  Para contornar esse problema, execute o script a seguir como uma ação de bootstrap na inicialização do cluster.

  #!/bin/bash
  sudo chmod 644 /etc/cron.d/libinstance-controller-java
              

• Para clusters de sub-rede privados do Amazon EMR 6.2.0 e 6.3.0, você não pode acessar a interface do usuário da Web do Ganglia. Você receberá um erro de “acesso negado (403)”. Outras interfaces do usuário da Web, como Spark, Hue, JupyterHub, Zeppelin, Livy e Tez, estão funcionando normalmente. O acesso à interface do usuário da Web do Ganglia em clusters de sub-redes públicas também está funcionando normalmente. Para resolver esse problema, reinicie o serviço httpd no nó primário com sudo systemctl restart httpd. Esse problema foi corrigido na versão 6.4.0 do Amazon EMR.

• Há um problema no Amazon EMR 6.2.0 em que o httpd falha continuamente, fazendo com que o Ganglia fique indisponível. Você recebe a mensagem de erro “cannot connect to the server”. Para corrigir um cluster que já está em execução com esse problema, use SSH no nó primário do cluster e adicione a linha Listen 80 ao arquivo httpd.conf localizado em /etc/httpd/conf/httpd.conf. Esse problema foi corrigido na versão 6.3.0 do Amazon EMR.

• O HTTPD apresenta falha nos clusters do EMR 6.2.0 quando é usada uma configuração de segurança. Isso faz com que a interface de usuário da aplicação Web do Ganglia fique indisponível. Para acessar a interface de usuário da aplicação Web do Ganglia, adicione Listen 80 ao arquivo /etc/httpd/conf/httpd.conf no nó primário do cluster. Para obter mais informações sobre como se conectar ao cluster, consulte Connect to the Primary Node Using SSH.

  Os Cadernos do EMR também não conseguem estabelecer uma conexão com clusters do EMR 6.2.0 quando você usa uma configuração de segurança. O caderno não conseguirá listar os kernels e enviar trabalhos do Spark. Em vez disso, recomendamos que você use os Cadernos do EMR com outra versão do Amazon EMR.

• 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

• Importante

  O Amazon EMR 6.1.0 e 6.2.0 incluem um problema de performance que pode afetar criticamente todas as operações de inserção, upsert e exclusão do Hudi. Se você planeja usar o Hudi com o Amazon EMR 6.1.0 ou 6.2.0, entre em contato com o suporte da AWS para obter um RPM do Hudi com patch.

• Importante

  Os clusters do EMR que executam imagens de máquina da Amazon (AMIs) do Amazon Linux ou do Amazon Linux 2 usam o comportamento padrão do Amazon Linux e não baixam nem instalam automaticamente atualizações importantes e críticas do kernel que exigem reinicialização. É o mesmo comportamento de outras instâncias do Amazon EC2 que executam a AMI padrão do Amazon Linux. Se novas atualizações de software do Amazon Linux que exigem reinicialização (como atualizações do kernel, NVIDIA e CUDA) forem disponibilizadas após o lançamento de uma versão do Amazon EMR, as instâncias de cluster do Amazon EMR que executam a AMI padrão não baixarão nem instalarão essas atualizações automaticamente. Para obter atualizações do kernel, você pode personalizar sua AMI do Amazon EMR para usar a AMI do Amazon Linux mais recente.

• Os artefatos do Maven do Amazon EMR 6.2.0 não são publicados. Eles serão publicados com uma versão futura do Amazon EMR.

• O rastreamento persistente do HFile que usa a tabela do sistema storefile do HBase não é compatível com o recurso de replicação da região do HBase. Para obter mais informações sobre a replicação da região do HBase, consulte Timeline-consistent high available reads.

• Diferenças entre as versões de bucketing do Amazon EMR 6.x e do EMR 5.x Hive

  O EMR 5.x usa o OOS Apache Hive 2, enquanto o EMR 6.x usa o OOS Apache Hive 3. O Hive2 de código aberto usa o Bucketing versão 1, enquanto o Hive3 de código aberto usa o Bucketing versão 2. Essa diferença de versão de bucketing entre o Hive 2 (EMR 5.x) e o Hive 3 (EMR 6.x) significa que o hash de bucketing do Hive funciona de uma forma diferente. Veja o exemplo abaixo.

  A tabela a seguir é um exemplo criado no EMR 6.x e no EMR 5.x, respectivamente.

  -- Using following LOCATION in EMR 6.x
  CREATE TABLE test_bucketing (id INT, desc STRING)
  PARTITIONED BY (day STRING)
  CLUSTERED BY(id) INTO 128 BUCKETS
  LOCATION 's3://your-own-s3-bucket/emr-6-bucketing/';
  
  -- Using following LOCATION in EMR 5.x 
  LOCATION 's3://your-own-s3-bucket/emr-5-bucketing/';

  Inserir os mesmos dados no EMR 6.x e no EMR 5.x.

  INSERT INTO test_bucketing PARTITION (day='01') VALUES(66, 'some_data');
  INSERT INTO test_bucketing PARTITION (day='01') VALUES(200, 'some_data');

  A verificação da localização do S3 mostra que o nome do arquivo de bucketing é diferente, pois a função de hash é diferente entre o EMR 6.x (Hive 3) e o EMR 5.x (Hive 2).

  [hadoop@ip-10-0-0-122 ~]$ aws s3 ls s3://your-own-s3-bucket/emr-6-bucketing/day=01/
  2020-10-21 20:35:16         13 000025_0
  2020-10-21 20:35:22         14 000121_0
  [hadoop@ip-10-0-0-122 ~]$ aws s3 ls s3://your-own-s3-bucket/emr-5-bucketing/day=01/
  2020-10-21 20:32:07         13 000066_0
  2020-10-21 20:32:51         14 000072_0
  

  Você também pode ver a diferença de versão executando o comando a seguir na CLI do Hive no EMR 6.x. Observe que ele retorna a versão 2 do bucketing.

  hive> DESCRIBE FORMATTED test_bucketing;
  ...
  Table Parameters:
      bucketing_version       2
  ...

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