Versão 6.3.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.977

• CloudWatch Sink versão 2.1.0

• Conector do DynamoDB versão 4.16.0

• EMRFS versão 2.46.0

• Amazon EMR Goodies versão 3.2.0

• Conector Kinesis versão 3.5.0 do Amazon EMR

• Servidor de registros do Amazon EMR versão 2.0.0

• Scripts versão 2.5.0 do Amazon EMR

• Flink versão 1.12.1

• Ganglia versão 3.7.2

• Cliente do Hive Metastore versão 3.2.0 do AWS Glue

• Hadoop versão 3.2.1-amzn-3

• HBase versão 2.2.6-amzn-1

• HBase-operator-tools 1.0.0

• HCatalog versão 3.1.2-amzn-0

• Hive versão 3.1.2-amzn-4

• Hudi versão 0.7.0-amzn-0

• Hue versão 4.9.0

• Java JDK versão Corretto-8.282.08.1 (compilação 1.8.0_282-b08)

• JupyterHub versão 1.2.0

• Livy versão 0.7.0-incubating

• MXNet versão 1.7.0

• Oozie versão 5.2.1

• Phoenix versão 5.0.0

• Pig versão 0.17.0

• Presto versão 0.245.1-amzn-0

• PrestoSQL versão 350

• KMS do Apache Ranger (criptografia transparente multi-mestre) versão 2.0.0

• ranger-plugins 2.0.1-amzn-0

• ranger-s3-plugin 1.1.0

• SDK versão 1.4.1 do Spark do SageMaker

• Scala versão 2.12.10 (VM de servidor OpenJDK de 64 bits, Java 1.8.0_282)

• Spark versão 3.1.1-amzn-0

• spark-rapids 0.4.1

• Sqoop versão 1.4.7

• TensorFlow versão 2.4.1

• Tez versão 0.9.2

• Zeppelin versão 0.9.0

• Zookeeper versão 3.4.14

• Conectores e drivers: DynamoDB Connector 4.16.0

Novos atributos

• O Amazon EMR é compatível com Pontos de Acesso Amazon S3, atributo do amazon S3 que permite que você gerencie facilmente o acesso a data lakes compartilhados. Usando o alias do Ponto de Acesso Amazon S3, você pode simplificar o acesso aos dados em grande escala no Amazon EMR. Você pode usar Pontos de Acesso Amazon S3 com todas as versões do Amazon EMR sem custo adicional em todas as regiões da AWS em que o Amazon EMR está disponível. Para saber mais sobre Pontos de Acesso Amazon S3 e aliases de ponto de acesso, consulte Usar um alias em estilo de bucket para seu ponto de acesso no Guia do usuário do Amazon S3.

• Novos parâmetros DescribeReleaseLabel e ListReleaseLabel da API fornecem detalhes do rótulo de lançamento do Amazon EMR. Você pode listar programaticamente as versões disponíveis na região em que a solicitação de API é executada e listar as aplicações disponíveis para um rótulo de lançamento específico do Amazon EMR. Os parâmetros do rótulo de lançamento também listam as versões do Amazon EMR compatíveis com uma aplicação específica, como o Spark. Essas informações podem ser usadas para iniciar programaticamente clusters do Amazon EMR. Por exemplo, você pode iniciar um cluster usando a versão mais recente dos resultados de ListReleaseLabel. Para obter mais informações, consulte DescribeReleaseLabel e ListReleaseLabels na Referência da API do Amazon EMR.

• Com a versão 6.3.0 do Amazon EMR, você pode iniciar um cluster que se integre nativamente ao Apache Ranger. O Apache Ranger é uma estrutura de código aberto para habilitar, monitorar e gerenciar uma segurança de dados abrangente em toda a plataforma Hadoop. Para obter mais informações, consulte Apache Ranger. Com a integração nativa, você pode trazer seu próprio Apache Ranger para aplicar um controle de acesso detalhado aos dados no Amazon EMR. Consulte Integrar o Amazon EMR com o Apache Ranger no Guia de gerenciamento do Amazon EMR.

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

• O padrão do modo de explicação da IU do Spark SQL foi alterado de extended para formatted no Spark 3.1. O Amazon EMR o reverteu para extended com a finalidade de incluir informações do plano lógico na IU do Spark SQL. Isso pode ser revertido definindo spark.sql.ui.explainMode como formatted.

• As confirmações a seguir foram transferidas da principal ramificação do Spark.

  - [SPARK-34752][COMPILAÇÃO] Bump Jetty para 9.4.37 para abordar CVE-2020-27223.

  - [SPARK-34534] Corrigir a ordem de blockIds ao ser usado FetchShuffleBlocks para buscar blocos.

  - [SPARK-34681] [SQL] Corrigir o erro da junção hash completa externa embaralhada ao ser criado o lado esquerdo com condições diferentes.

  - [SPARK-34497] [SQL] Corrigir os provedores de conexão JDBC integrados para restaurar as alterações no contexto de segurança da JVM.

• Para melhorar a interoperabilidade com o plug-in Nvidia Spark RAPIDs, Adicionada uma solução alternativa para tratar de um problema que impede que a remoção dinâmica de partições seja acionada ao ser usado Nvidia Spark RAPIDs com a execução adaptável de consultas desabilitada, consulte o Problema n.º 1378 do RAPIDS e o Problema n.º 1386 do RAPIDS. Para obter detalhes sobre a nova configuração spark.sql.optimizer.dynamicPartitionPruning.enforceBroadcastReuse, consulte o Problema n.º 1386 do RAPIDS.

• O algoritmo padrão do confirmador de saída de arquivo foi alterado do algoritmo v2 para o algoritmo v1 no Spark 3.1 de código aberto. Para obter mais informações, consulte este Amazon EMR otimizando a performance do Spark - remoção dinâmica de partições.

• O Amazon EMR reverteu para o algoritmo v2, o padrão usado em versões anteriores do Amazon EMR 6.x, para evitar a regressão de performance. Para restaurar o comportamento de código aberto do Spark 3.1, defina spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version como 1. O Spark de código aberto fez essa alteração porque a confirmação de tarefas no algoritmo do confirmador de saída de arquivo v2 não é atômica, o que pode causar um problema de exatidão dos dados de saída em alguns casos. No entanto, a confirmação da tarefa no algoritmo v1 também não é atômica. Em alguns cenários, a confirmação da tarefa inclui uma exclusão realizada antes de uma renomeação. Isso pode resultar em um problema silencioso de correção de dados.

• Corrigidos os problemas de ajuste de escala gerenciado em versões anteriores do Amazon EMR e feitas melhorias para que os índices de falha de aplicações fossem significativamente reduzidos.

• Instalado o pacote AWS Java SDK em cada novo cluster. Esse é um único jar contendo todos os SDKs de serviço e suas dependências, em vez de jars de componentes individuais. Para obter mais informações, consulte Dependência no pacote Java SDK.

Problemas conhecidos

• Para clusters de sub-rede privados do Amazon EMR 6.3.0 e 6.2.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.

• Quando o Catálogo de Dados do AWS Glue está habilitado, o uso do Spark para acessar um banco de dados do AWS Glue com URI de localização de string nula pode falhar. Isso acontece com versões anteriores do Amazon EMR, mas o SPARK-31709 (https://issues.apache.org/jira/browse/SPARK-31709) faz com que se aplique a mais casos. Por exemplo, ao ser criada uma tabela no banco de dados padrão do AWS Glue cujo URI de localização é uma string nula, spark.sql("CREATE TABLE mytest (key string) location '/table_path';") apresenta falha com a mensagem “Não é possível criar um caminho de uma string vazia”. Para contornar isso, defina manualmente um URI de localização dos seus bancos de dados do AWS Glue e crie tabelas nesses bancos de dados usando o Spark.

• No Amazon EMR 6.3.0, o PrestoSQL foi atualizado da versão 343 para a versão 350. Há duas alterações relacionadas à segurança provenientes do código aberto que se relaciona a essa alteração de versão. O controle de acesso ao catálogo baseado em arquivos é alterado de deny para allow quando as regras de propriedades de tabela, esquema ou sessão não são definidas. Além disso, o controle de acesso ao sistema baseado em arquivos é alterado para oferecer suporte a arquivos sem regras de catálogo definidas. Nesse caso, todo o acesso aos catálogos é permitido.

  Para obter mais informações, consulte a Versão 344 (9 de outubro de 2020).

• Observe que o diretório de usuário do Hadoop (/home/hadoop) pode ser lido por todos. Ele tem permissões de diretório Unix 755 (drwxr-xr-x) para permitir acesso de leitura por frameworks, como o Hive. Você pode colocar arquivos em /home/hadoop e seus subdiretórios, mas esteja ciente das permissões desses diretórios para proteger informações confidenciais.

• 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

  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.

• Para usar as ações do Spark com o Apache Oozie, você deve adicionar a seguinte configuração ao seu arquivo workflow.xml do Oozie. Caso contrário, várias bibliotecas críticas, como Hadoop e EMRFS, estarão ausentes do classpath dos executores do Spark que o Oozie inicia.

  <spark-opts>--conf spark.yarn.populateHadoopClasspath=true</spark-opts>

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