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

Atualizações

• Atualizado para AWS SDK for Java a versão 1.11.759

• SDK do Amazon SageMaker Spark atualizado para a versão 1.3.0

• Atualização do EMR Record Server para a versão 1.6.0

• Atualização do Flink para a versão 1.10.0

• Atualização do Ganglia para a versão 3.7.2

• Atualizado HBase para a versão 1.4.13

• Atualização do Hudi para a versão 0.5.2-incubating

• Atualização do Hue para a versão 4.6.0

• Atualizado JupyterHub para a versão 1.1.0

• Atualização do Livy para a versão 0.7.0-incubating

• Atualização do Oozie para a versão 5.2.0

• Atualização do Presto para a versão 0.232

• Atualização do Spark para a versão 2.4.5

• Atualização de conectores e drivers: Amazon Glue Connector 1.12.0; Amazon Kinesis Connector 3.5.0; EMR DynamoDB Connector 4.14.0

Novos recursos

• Cadernos do EMR: quando usados com clusters do EMR criados com a versão 5.30.0, os kernels dos Cadernos do EMR são executados no cluster. Isso melhora o desempenho do bloco de anotações e permite que instalar e personalizar kernels. Você também pode instalar bibliotecas Python no nó primário do cluster. Para obter mais informações, consulte Instalar e usar kernels e bibliotecas no EMR Management Guide.

• Ajuste de escala gerenciado: com as versões 5.30.0 e posteriores do Amazon EMR, é possível habilitar o ajuste de escala gerenciado pelo EMR para aumentar ou diminuir automaticamente o número de instâncias ou unidades no cluster com base na workload. O Amazon EMR avalia continuamente as métricas do cluster para tomar decisões de ajuste de escala que otimizam os clusters em termos de custo e velocidade. Para obter mais informações, consulte Escalar recursos de cluster no Guia de gerenciamento do Amazon EMR.

• Criptografe arquivos de log armazenados no Amazon S3 — Com o Amazon EMR versão 5.30.0 e posterior, você pode criptografar arquivos de log armazenados no Amazon S3 com uma chave gerenciada pelo cliente. AWS KMS Para obter mais informações, consulte Encrypt log files stored in Amazon S3 no Guia de gerenciamento do Amazon EMR.

• Suporte ao Amazon Linux 2: nas versões 5.30.0 e posteriores do EMR, o EMR usa o sistema operacional Amazon Linux 2. A nova personalização AMIs (Amazon Machine Image) deve ser baseada na Amazon Linux 2 AMI. Para obter mais informações, consulte Usando uma AMI personalizada.

• Escalabilidade automática tranquila do Presto: os clusters do EMR que usam a versão 5.30.0 podem ser definidos com um período limite de ajuste de escala automático que dá tempo às tarefas do Presto para concluir a execução antes do nó delas ser desativado. Para obter mais informações, consulte Usar a escalabilidade automática do Presto com desativação tranquila.

• Criação de instância de frota com nova opção de estratégia de alocação: uma nova opção de estratégia de alocação está disponível nas versões 5.12.1 e posteriores do EMR. Ele oferece provisionamento de cluster mais rápido, alocação de spot mais precisa e menos interrupção de instâncias spot. São necessárias atualizações para perfis de serviço do EMR não padrão. Consulte Configurar frotas de instâncias.

• Comandos sudo systemctl stop e sudo systemctl start: nas versões 5.30.0 e posteriores do EMR, que usam o sistema operacional Amazon Linux 2, o EMR usa os comandos sudo systemctl stop e sudo systemctl start para reiniciar serviços. Para obter mais informações, consulte Como reinicio um serviço no Amazon EMR?.

Alterações, melhorias e problemas resolvidos

• O EMR versão 5.30.0 não instala o Ganglia por padrão. É possível selecionar explicitamente o Ganglia para ser instalado ao criar um cluster.

• Otimizações do desempenho do Spark

• Otimizações do desempenho do Presto

• O Python 3 é o padrão para as versões 5.30.0 e posteriores do Amazon EMR.

• O grupo de segurança gerenciado padrão para acesso ao serviço em sub-redes privadas foi atualizado com novas regras. Se você usar um grupo de segurança personalizado para acesso ao serviço, será necessário incluir as mesmas regras do grupo de segurança gerenciado padrão. Para obter mais informações, consulte Grupo de segurança gerenciado pelo Amazon EMR para acesso ao serviço (sub-redes privadas). Se você usar um perfil de serviço personalizado para o Amazon EMR, será necessário conceder permissão para ec2:describeSecurityGroups de modo que o EMR possa validar se os grupos de segurança são criados corretamente. Se você usar o EMR_DefaultRole, essa permissão já estará incluída na política gerenciada padrão.

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

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

• O mecanismo de banco de dados padrão para o Hue 4.6.0 é SQLite, o que causa problemas quando você tenta usar o Hue com um banco de dados externo. Para corrigir isso, defina engine na sua classificação de configuração hue-ini como mysql. Esse problema foi corrigido na versão 5.30.1 do Amazon EMR.

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