Amazon EMR versão 6.1.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.828

• Flink versão 1.11.0

• Ganglia versão 3.7.2

• Hadoop versão 3.2.1-amzn-1

• HBaseversão 2.2.5

• HBase-operator-tools 1.0.0

• HCatalogversão 3.1.2-amzn-0

• Hive versão 3.1.2-amzn-1

• Hudi versão 0.5.2-incubating

• Hue versão 4.7.1

• JupyterHub versão 1.1.0

• Livy versão 0.7.0

• MXNetversão 1.6.0

• Oozie versão 5.2.0

• Phoenix versão 5.0.0

• Presto versão 0.232

• Presto SQL versão 3.38

• Spark versão 3.0.0-amzn-0

• TensorFlow versão 2.1.0

• Zeppelin versão 0.9.0-preview1

• Zookeeper versão 3.4.14

• Conectores e drivers: DynamoDB Connector 4.14.0

Novos atributos

• ARMOs tipos de instância são suportados a partir da Amazon EMR versão 5.30.0 e da Amazon EMR versão 6.1.0.

• Os tipos de instância de uso geral M6g são suportados a partir das EMR versões 6.1.0 e 5.30.0 da Amazon. Para obter mais informações, consulte Tipos de instância compatíveis no Amazon EMR Management Guide.

• O recurso de grupos de EC2 posicionamento é suportado a partir da EMR versão 5.23.0 da Amazon como uma opção para vários clusters de nós primários. Atualmente, somente os tipos de nós primários são compatíveis com o atributo grupo de posicionamento e a estratégia SPREAD é aplicada a estes nós primários. A estratégia SPREAD posiciona um pequeno grupo de instâncias em um hardware subjacente separado para evitar a perda de múltiplos nós primários em caso de falha de hardware. Para obter mais informações, consulte EMRIntegração com o EC2 Placement Group no Amazon EMR Management Guide.

• Escalabilidade gerenciada — Com a EMR versão 6.1.0 da Amazon, você pode permitir que a escalabilidade EMR gerenciada da Amazon aumente ou diminua automaticamente o número de instâncias ou unidades em seu cluster com base na carga de trabalho. A Amazon avalia EMR continuamente as métricas do cluster para tomar decisões de escalabilidade que otimizem seus clusters em termos de custo e velocidade. O Managed Scaling também está disponível na Amazon EMR versão 5.30.0 e posterior, exceto 6.0.0. Para obter mais informações, consulte Scaling Cluster Resources no Amazon EMR Management Guide.

• A SQL versão 338 do Presto é compatível com EMR 6.1.0. Para obter mais informações, consulte Presto.

  • O Presto SQL é suportado somente na EMR versão 6.1.0 e versões posteriores, não na EMR 6.0.0 ou 5.x. EMR

  • O nome da aplicação, Presto, continua a ser usado para instalar o PrestoDB em clusters. Para instalar o Presto SQL em clusters, use o nome PrestoSQL do aplicativo.

  • Você pode instalar o PrestoDB ou o SQL Presto, mas não pode instalar os dois em um único cluster. Se o PrestoDB e o SQL Presto forem especificados ao tentar criar um cluster, ocorrerá um erro de validação e a solicitação de criação do cluster falhará.

  • O Presto SQL é compatível com clusters single-master e multimaster. Em clusters com vários mestres, é necessário um metastore externo do Hive para executar o Presto ou o PrestoDB. SQL Consulte Aplicativos compatíveis em um EMR cluster com vários nós primários.

• ECRsuporte à autenticação automática no Apache Hadoop e no Apache Spark com Docker: os usuários do Spark podem usar imagens do Docker Hub e do Amazon Elastic Container Registry (AmazonECR) para definir dependências de ambiente e biblioteca.

  Configure o Docker e execute aplicativos Spark com o Docker usando o Amazon 6.x. EMR

• EMRsuporta ACID transações do Apache Hive: o Amazon EMR 6.1.0 adiciona suporte às transações do Hive para que esteja em conformidade com ACID as propriedades de um banco de dados. ACID Com esse atributo, você pode executar as operações INSERT, UPDATE, DELETE, e MERGE em tabelas gerenciadas do Hive com dados no Amazon Simple Storage Service (Amazon S3). Esse é um recurso fundamental para casos de uso como ingestão de streaming, atualização de dados, uso de atualizações em massa e mudanças lentas de dimensões. MERGE Para obter mais informações, incluindo exemplos de configuração e casos de uso, consulte Amazon EMR suporta transações do Apache Hive ACID.

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

• O Apache Flink não é suportado no EMR 6.0.0, mas é suportado no EMR 6.1.0 com o Flink 1.11.0. Esta é a primeira versão do Flink a oficialmente oferecer suporte ao Hadoop 3. Consulte o Anúncio de versão do Apache Flink 1.11.0.

• O Ganglia foi removido dos pacotes padrão EMR 6.1.0.

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

• Importante

  O Amazon EMR 6.1.0 e 6.2.0 incluem um problema de desempenho que pode afetar criticamente todas as operações de inserção, atualização 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 AWS suporte para obter um Hudi corrigido. RPM

• Se você definir uma configuração personalizada de coleta de lixo com spark.driver.extraJavaOptions espark.executor.extraJavaOptions, isso resultará na falha de inicialização do driver/executor com a versão EMR 6.1 devido à configuração conflitante da coleta de lixo. Com a EMR versão 6.1.0, você deve especificar uma configuração personalizada de coleta de lixo do Spark para drivers e executores com as propriedades e em vez disso. spark.driver.defaultJavaOptions spark.executor.defaultJavaOptions Leia mais em Apache Spark Runtime Environment e Configurando a coleta de lixo do Spark na Amazon 6.1.0. EMR

• Usar o Pig com o Oozie (e dentro do Hue, já que o Hue usa ações do Oozie para executar scripts do Pig) gera um erro em que uma biblioteca nativa lzo não pode ser carregada. Essa mensagem de erro é informativa e não impede a execução do Pig.

• Suporte de simultaneidade do Hudi: atualmente, o Hudi não é compatível com gravações simultâneas em uma única tabela do Hudi. Além disso, o Hudi reverte todas as alterações feitas por gravadores em andamento antes de permitir que um novo gravador seja iniciado. As gravações simultâneas podem interferir nesse mecanismo e introduzir condições de corrida, o que pode causar corrupção de dados. Você deve garantir que, como parte do seu fluxo de trabalho de processamento de dados, só exista um gravador do Hudi operando em uma tabela do Hudi em qualquer instante. O Hudi permite vários leitores simultâneos operando na mesma tabela do Hudi.

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

• Há um problema no Amazon EMR 6.1.0 que afeta os clusters que executam o Presto. Depois de um longo período (dias), o cluster pode gerar erros, como “su: failed to execute /bin/bash: Resource temporarily unavailable” ou “shell request failed on channel 0”. Esse problema é causado por um EMR processo interno da Amazon (InstanceController) que está gerando muitos processos leves (LWP), o que acaba fazendo com que o usuário do Hadoop exceda o limite de nproc. Isso impede que o usuário abra processos adicionais. A solução para esse problema é atualizar para EMR 6.2.0.