As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# O que há de novo?
<a name="emr-whatsnew"></a>

Esta página descreve as alterações e as funcionalidades disponíveis nas versões mais recentes do Amazon EMR 7.x, 6.x e 5.x. 

Essas notas de versão também estão disponíveis nas páginas do [Amazon EMR 7.12.0](emr-7120-release.md), Amazon EMR 6.15.0 [e Amazon](emr-5362-release.md) [EMR](emr-6150-release.md) 5.36.2, junto com as versões do aplicativo, as versões dos componentes e as classificações de configuração disponíveis para cada versão.
+ Para obter notas de versões anteriores, consulte o [Arquivo de notas de versão do Amazon EMR](emr-whatsnew-history.md).
+ Para receber atualizações quando uma nova versão do Amazon EMR estiver disponível, assine o [RSS feed das notas de versão do Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/amazon-emr-release-notes.rss).

**nota**  
Versões posteriores do Amazon EMR usam o AWS Signature Version 4 (SigV4) para autenticar solicitações no Amazon S3. Recomendamos o uso de uma versão do Amazon EMR que ofereça suporte ao SigV4 para que você possa acessar novos buckets do S3 e evitar a interrupção das suas workloads. Para obter mais informações e uma lista das versões do Amazon EMR compatíveis com o SigV4, consulte [Amazon EMR e AWS Signature versão 4](#emr-sigv4).

## Agentes de atualização e solução de problemas do Apache Spark
<a name="emr-spark-agents-whatsnew"></a>

**Agente de atualização do Apache Spark**

O Apache Spark Upgrade Agent para Amazon EMR é um recurso de IA conversacional que acelera as atualizações de versão do Apache Spark para seus aplicativos EMR. As atualizações tradicionais do Spark exigem meses de esforço de engenharia para analisar as mudanças na API, resolver conflitos de dependência e validar a correção funcional. O agente simplifica o processo de upgrade por meio de solicitações em linguagem natural, transformação automatizada de código e validação da qualidade dos dados.

Você pode usar o agente para atualizar PySpark e escalar aplicativos em execução no Amazon EMR no EC2 e no Amazon EMR Serverless. O agente analisa seu código, identifica as alterações necessárias e realiza transformações automatizadas, mantendo seu controle de aprovação sobre todas as modificações. Para obter mais detalhes, consulte[O que é o Apache Spark Upgrade Agent para Amazon EMR](spark-upgrades.md).

**Agente de solução de problemas do Apache Spark**

O agente de solução de problemas do Apache Spark para o Amazon EMR é um recurso de IA conversacional que simplifica a solução de problemas de aplicativos do Apache Spark no Amazon EMR, Glue e Amazon Notebooks. AWS SageMaker A solução de problemas tradicional do Spark exige uma ampla análise manual de registros, métricas de desempenho e padrões de erro para identificar as causas principais e as correções de código. O agente simplifica esse processo por meio de solicitações em linguagem natural, análise automatizada da carga de trabalho e recomendações inteligentes de código.

Você pode usar o agente para solucionar problemas PySpark e falhas nos aplicativos Scala. O agente analisa seus trabalhos fracassados, identifica gargalos de desempenho e fornece recomendações práticas e correções de código, ao mesmo tempo em que oferece controle total sobre as decisões de implementação. Para obter mais detalhes, consulte[O que é o agente de solução de problemas do Apache Spark para o Amazon EMR](spark-troubleshoot.md).

## Amazon EMR 7.12.0 (versão mais recente da série 7.x)
<a name="emr-7120-whatsnew"></a>

Novas versões do Amazon EMR são disponibilizadas em diferentes regiões durante um período de vários anos, começando com a primeira região na data da versão inicial. A versão mais recente pode não estar disponível em sua região durante esse período.

As notas de lançamento a seguir incluem informações sobre a versão 7.11.0 do Amazon EMR.
+ **Novos recursos**
  + Atualizações de **aplicativos — As atualizações** de aplicativos do Amazon EMR 7.11.0 incluem Delta 3.3.2-amzn-0, Flink 1.20.0-amzn-5, 2.6.2-amzn-2, 3.1.3-amzn-20, Hadoop 3.4.1-amzn-3, Hive 3.1.3-amzn-20, Hudi 1.0.2-amzn-0, Iceberg 1.9.1-amzn-0, Presto 0.287-amzn-5 HBase , Spark 3.5.6-amzn-0, 2.19.0, Tez 0.10.2-amzn-18 HCatalog , Trino 475-amzn-0 e 3.9.3-amzn-3. TensorFlow ZooKeeper 
  + O Amazon EMR no EC2 agora oferece suporte a sessões de segundo plano de usuários do IAM Identity Center
    + **Sessões em segundo plano do usuário**: permite que cargas de trabalho de longa duração do Spark continuem em execução mesmo após os usuários se desconectarem do SageMaker Unified Studio, oferecendo suporte a sessões de até 90 dias
    + Configuração **flexível de sessão em segundo plano: configuração** de dois níveis (instância do IAM Identity Center e cluster Amazon EMR-EC2) com duração de sessão em segundo plano personalizável de 15 minutos a 90 dias (padrão: 7 dias)
    + **Propagação de identidade confiável**: mantém o contexto de identidade seguro durante todo o ciclo de vida da sessão em segundo plano usando o recurso de propagação de identidade confiável do Amazon EMR
    + **SageMaker Integração com o Unified Studio**: sessões em segundo plano iniciadas por meio de sessões interativas do Livy no SageMaker Unified Studio
  + **Sessões de longa duração com identidades corporativas** — O Amazon SageMaker Unified Studio agora oferece suporte a sessões de longa duração com identidades corporativas por meio do Trusted Identity Propagation (TIP) do IAM Identity Center. Os usuários podem lançar notebooks interativos e sessões de processamento de dados no Amazon EMR e no AWS Glue que persistem usando credenciais corporativas, mesmo quando estão desconectados ou as sessões expiram. As sessões duram até 90 dias (padrão 7 dias), mantendo as permissões de identidade e os controles de segurança consistentes.

## Amazon EMR 6.15.0 (versão mais recente da série 6.x)
<a name="emr-6150-whatsnew"></a>

Novas versões do Amazon EMR são disponibilizadas em diferentes regiões durante um período de vários anos, começando com a primeira região na data da versão inicial. A versão mais recente pode não estar disponível em sua região durante esse período.

As notas da versão a seguir incluem informações sobre a versão 6.15.0 do Amazon EMR. As alterações são referentes à versão 6.14.0. Para obter informações sobre o cronograma da versão, consulte o [Log de alterações 6.15.0](emr-6150-release.md#6150-changelog).

**Novos recursos**
+ **Atualizações da aplicação**: Amazon EMR 6.15.0 application upgrades include Apache Hadoop 3.3.6, Apache Hudi 0.14.0-amzn-0, Iceberg 1.4.0-amzn-0, and Trino 426.
+ **[Lançamentos mais rápidos para clusters do EMR executados no EC2](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-emr-ec2-clusters-5-minutes-less/)**: agora é até 35% mais rápido lançar um cluster do Amazon EMR no EC2. Com essa melhoria, a maioria dos clientes pode lançar seus clusters em cinco minutos ou menos.
+ **[CodeWhisperer para o EMR Studio](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-studio-codewhisperer.html)** — Agora você pode usar a Amazon com o CodeWhisperer Amazon EMR Studio para obter recomendações em tempo real à medida que você escreve código. JupyterLab CodeWhisperer pode concluir seus comentários, concluir linhas únicas de código, fazer line-by-line recomendações e gerar funções totalmente formadas.
+ **[Tempos de reinicialização de trabalhos mais rápidos com o Flink](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/flink-restart.html)**: com o Amazon EMR 6.15.0 e superior, vários novos mecanismos estão disponíveis para o Apache Flink a fim de melhorar o tempo de reinicialização de trabalhos durante as operações de recuperação ou escalabilidade de tarefas. Isso otimiza a velocidade de recuperação e reinicialização dos gráficos de execução para melhorar a estabilidade do trabalho.
+ **[Controle de acesso detalhado e em nível de tabela para formatos de tabela aberta — Com o Amazon EMR 6.15.0 e superior, quando você executa trabalhos do Spark no Amazon EMR em clusters EC2 que acessam dados no Glue Data Catalog, você AWS Lake Formation pode usar para aplicar permissões em AWS nível de tabela, linha, coluna e célula em tabelas baseadas em Hudi, Iceberg ou Delta](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-lf-enable.html)** Lake.
+ **Atualização do Hadoop**: o Amazon EMR 6.15.0 inclui uma atualização do Apache Hadoop para a versão 3.3.6. O Hadoop 3.3.6 era a versão mais recente na época da implantação do Amazon EMR 6.15, lançada pela Apache em junho de 2023. Versões anteriores do Amazon EMR (6.9.0 até 6.14.x) usavam o Hadoop 3.3.3.

  A atualização inclui centenas de melhorias e correções, além de recursos com parâmetros de nós de dados reconfiguráveis, a opção `DFSAdmin` para iniciar operações de reconfiguração em massa em todos os nós de dados ativos e uma API vetorizada que permite aos leitores exigentes especificar vários intervalos de leitura. O Hadoop 3.3.6 também adiciona suporte ao HDFS APIs e semântica ao seu registro de gravação antecipada (WAL), para que ele possa ser executado em outras implementações de sistemas de armazenamento. HBase Para obter mais informações, consulte os logs de alterações das versões [3.3.4](https://hadoop.apache.org/docs/r3.3.4/hadoop-project-dist/hadoop-common/release/3.3.4/CHANGELOG.3.3.4.html), [3.3.5](https://hadoop.apache.org/docs/r3.3.5/hadoop-project-dist/hadoop-common/release/3.3.5/CHANGELOG.3.3.5.html) e [3.3.6](https://hadoop.apache.org/docs/r3.3.6/hadoop-project-dist/hadoop-common/release/3.3.6/CHANGELOG.3.3.6.html) na *documentação do Apache Hadoop*.
+ **Suporte ao AWS SDK for Java, versão** [2 - Os aplicativos Amazon EMR 6.15.0 podem usar o SDK for AWS Java nas [versões](https://github.com/aws/aws-sdk-java/tree/1.12.569) 1.12.569 ou 2.20.160 se o aplicativo suportar a versão 2.](https://github.com/aws/aws-sdk-java-v2/tree/2.20.160) O AWS SDK for Java 2.x é uma grande reescrita da base de código da versão 1.x. Ele foi criado com base no Java 8\$1 e adiciona vários recursos frequentemente solicitados. Entre eles, suporte para E/S sem bloqueio e capacidade de conectar uma implementação HTTP diferente no runtime. Para obter mais informações, incluindo um **Guia de migração do SDK para Java da v1 à v2**, consulte o guia [AWS SDK para Java, versão 2](https://docs.aws.amazon.com/sdk-for-java).

**Problemas conhecidos**
+ Um script de estado de instância no cluster que monitora a integridade da instância pode consumir recursos excessivos de CPU e memória quando há um grande número de threads and/or abertos e manipuladores de arquivos no nó.

**Alterações, melhorias e problemas resolvidos**
+  *A partir do Spark 3.3.1 (com suporte nas versões 6.10 e posteriores do EMR), todos os executores em um host de descomissionamento são configurados para um novo `ExecutorState`, chamado de estado DECOMMISSIONING*. Os executores que estão sendo desativados não podem ser usados pelo Yarn para alocar tarefas e, portanto, ele solicitará novos executores, se necessário, para as tarefas que estão sendo executadas. Portanto, se você desativar o Spark DRA enquanto estiver usando o EMR Managed Scaling, o EMR Auto Scaling ou qualquer mecanismo de ajuste de escala personalizado em clusters EMR-EC2, o Yarn poderá solicitar o número máximo permitido de executores para cada trabalho. Para evitar esse problema, deixe a propriedade `spark.dynamicAllocation.enabled` definida como `TRUE` (que é o padrão) ao usar a combinação de recursos acima. Além disso, você também pode definir restrições mínimas e máximas para executores, definindo valores para as propriedades `spark.dynamicAllocation.maxExecutors` e `spark.dynamicAllocation.minExecutors` para seus trabalhos Spark, a fim de restringir o número de executores alocados durante a execução do trabalho. 
+ Para melhorar seus clusters de alta disponibilidade do EMR, essa versão permite a conectividade com daemons do Amazon EMR em um host local que usa endpoints IPv6.
+ Esta versão habilita o TLS 1.2 para comunicação com ZooKeeper provisionados em todos os nós primários do seu cluster de alta disponibilidade.
+ Esta versão melhora o gerenciamento dos arquivos de log de ZooKeeper transações que são mantidos nos nós primários para minimizar os cenários em que os arquivos de log ultrapassam os limites e interrompem as operações do cluster.
+ Essa versão torna a comunicação entre nós mais resiliente para clusters de alta disponibilidade do EMR. Essa melhoria reduz a chance de falhas na ação de bootstrap ou na inicialização do cluster.
+ O Tez no Amazon EMR 6.15.0 introduz configurações que você pode especificar para abrir de forma assíncrona as divisões de entrada em uma divisão agrupada do Tez. Isso resulta em uma performance mais rápida das consultas de leitura quando há um grande número de divisões de entrada em uma única divisão agrupada do Tez. Para obter mais informações, consulte a [Abertura assíncrona da divisão do Tez](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/tez-configure.html#tez-configure-async).
+ Quando você inicia um cluster com a *versão de patch mais recente* do Amazon EMR 5.36 ou superior, 6.6 ou superior ou 7.0 ou superior, o Amazon EMR usa a versão mais recente do Amazon Linux 2023 ou do Amazon Linux 2 para a AMI padrão do Amazon EMR. Para obter mais informações, consulte [Como usar a AMI padrão do Amazon Linux para Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew.html)

## Amazon EMR 5.36.2 (versão mais recente da série 5.x)
<a name="emr-5362-whatsnew"></a>

Novas versões do Amazon EMR são disponibilizadas em diferentes regiões durante um período de vários anos, começando com a primeira região na data da versão inicial. A versão mais recente pode não estar disponível em sua região durante esse período.

As notas da versão a seguir incluem informações sobre a versão 5.36.2 do Amazon EMR. As alterações são referentes à versão 5.36.1. Para obter informações sobre o cronograma da versão, consulte o [log de alterações](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-5362-release.html#5362-changelog).

**Alterações, melhorias e problemas resolvidos**
+ Essa versão melhora a lógica de redução vertical da escala do cluster para que o Amazon EMR não reduza a escala dos nós centrais abaixo da configuração do fator de replicação do HDFS para o cluster. Essa melhoria atende aos requisitos de redundância de dados e reduz a chance de uma operação de ajuste de escala ser interrompida. 
+ Esta versão adiciona um mecanismo de nova tentativa ao fluxo de trabalho de escalabilidade de clusters para clusters do EMR que executam o Presto ou o Trino. Essa melhoria reduz o risco de o redimensionamento do cluster ser executado indefinidamente devido a uma única operação de redimensionamento com falha. Ela também aprimora a utilização dos clusters, porque seu cluster aumenta e reduz a escala verticalmente com mais rapidez.
+ Corrige um problema em que as operações de redução vertical da escala do cluster podem ficar paralisadas enquanto o Amazon EMR desativa normalmente um nó central e ele se torna não íntegro antes de ser totalmente desativado.
+ Melhora a estabilidade de um nó em um cluster de alta disponibilidade com vários nós primários quando o Amazon EMR reinicia um único nó.
+ Otimiza o gerenciamento de logs com o Amazon EMR em execução no Amazon EC2. Como resultado, é possível ver uma pequena redução nos custos de armazenamento dos logs do cluster.
+ Melhora o gerenciamento dos arquivos de log de ZooKeeper transações que são mantidos nos nós primários para minimizar os cenários em que os arquivos de log ultrapassam os limites e interrompem as operações do cluster.
+ Corrige um bug raro que pode fazer com que um cluster de alta disponibilidade com vários nós primários falhe por não conseguir se comunicar com o ResourceManager Yarn.
+ Quando você inicia um cluster com a *versão de patch mais recente* do Amazon EMR 5.36 ou superior, 6.6 ou superior ou 7.0 ou superior, o Amazon EMR usa a versão mais recente do Amazon Linux 2023 ou do Amazon Linux 2 para a AMI padrão do Amazon EMR. Para obter mais informações, consulte [Como usar a AMI padrão do Amazon Linux para Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew.html)

## Amazon EMR e AWS Signature versão 4
<a name="emr-sigv4"></a>

As versões do Amazon EMR usam AWS Signature versão 4 (SigV4) para autenticar solicitações no Amazon S3. Os buckets criados no Amazon S3 depois de 24 de junho de 2020 não são compatíveis com solicitações assinadas pelo Signature Version 2 (SigV2). Os buckets criados em ou antes de 24 de junho de 2020 continuarão a oferecer suporte ao SigV2. Recomendamos a migração para uma versão do Amazon EMR que ofereça suporte ao SigV4 para que você possa acessar novos buckets do S3 e evitar a interrupção das suas workloads. 

Se você usa aplicações incluídas no Amazon EMR, como Apache Spark, Apache Hive e Presto, não precisa alterar o código da aplicação para usar o SigV4. Se você usa aplicações personalizadas que não estão incluídas no Amazon EMR, talvez seja necessário atualizar seu código para usar o SigV4. Para obter mais informações, consulte [Migração do Signature Version 2 para o Signature Version 4](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingAWSSDK.html#UsingAWSSDK-move-to-Sig4) no Guia do usuário do Amazon S3.

As seguintes versões do Amazon EMR são compatíveis com SigV4: emr-4.7.4, emr-4.8.5, emr-4.9.6, emr-4.10.1, emr-5.1.1, emr-5.2.3, emr-5.3.2, emr-5.4.1, emr-5.5.4, emr-5.6.1, emr-5.7.1, emr-5.8.3, emr-5.9.1, emr-5.10.1, emr-5.11.4, emr-5.12.3, emr-5.13.1, emr-5.14.2, emr-5.15.1, emr-5.16.1, emr-5.17.2, emr-5.18.1, emr-5.19.1, emr-5.20.1, emr-5.21.2, and emr-5.22.0 and higher. Todas as versões 6.x e 7.x são compatíveis com SigV4.

# Abordagem para mitigar o CVE-2021-44228
<a name="emr-log4j-vulnerability"></a>

**nota**  
Para as versões 6.9.0 e posteriores do Amazon EMR, todos os componentes instalados pelo Amazon EMR que usam bibliotecas do Log4j usam o Log4j versão 2.17.1 ou posterior.

**Amazon EMR em execução no EC2**

O problema discutido no [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) é relevante para as versões do núcleo do Apache Log4j entre 2.0.0 e 2.14.1 ao serem processadas entradas de fontes não confiáveis. Os clusters do Amazon EMR iniciados com as versões 5.x do Amazon EMR até 5.34.0 e as versões do EMR 6.x até o Amazon EMR 6.5.0 incluem estruturas de código aberto, como Apache Hive, Flink, HUDI, Presto e Trino, que usam essas versões do Apache Log4j. No entanto, muitos clientes usam as estruturas de código aberto instaladas nos seus clusters do Amazon EMR para processar e registrar em log entradas de fontes não confiáveis.

Recomendamos que você aplique a “Solução de ação de bootstrap do Amazon EMR para Log4j CVE-2021-44228” conforme descrito na seção a seguir. Essa solução também trata do CVE-2021-45046.

**nota**  
Os scripts de ação de bootstrap para Amazon EMR foram atualizados em 7 de setembro de 2022 para incluir correções incrementais de bugs e melhorias para o Oozie. Se você usa o Oozie, deve aplicar a solução de ação de bootstrap atualizada do Amazon EMR descrita na seção a seguir.

**Amazon EMR no EKS**

Se você usa o [Amazon EMR no EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks.html) com a configuração padrão, o problema descrito no CVE-2021-44228 não afeta você e não é preciso aplicar a solução descrita na seção [Solução de ação bootstrap do Amazon EMR para Log4j CVE-2021-44228 e CVE-2021-45046](#emr-log4j-vulnerability-patch-instructions). Para o Amazon EMR no EKS, o runtime do Amazon EMR para Spark usa o Apache Log4j versão 1.2.17. Ao usar o Amazon EMR no EKS, você não deve alterar a definição padrão do componente `log4j.appender` como `log`.

## Solução de ação bootstrap do Amazon EMR para Log4j CVE-2021-44228 e CVE-2021-45046
<a name="emr-log4j-vulnerability-patch-instructions"></a>

Essa solução fornece uma ação de bootstrap do Amazon EMR que deve ser aplicada nos clusters do Amazon EMR. Para cada versão do Amazon EMR, você encontrará um link para um script de ação de bootstrap abaixo. Para aplicar essa ação de bootstrap, você deve concluir as seguintes etapas:

1. Copie o script que corresponde à sua versão do Amazon EMR para um bucket do S3 local na sua Conta da AWS. Certifique-se de estar usando um script de bootstrap específico para sua versão do Amazon EMR.

1. Configure uma ação de bootstrap para que os clusters do EMR executem o script copiado para o bucket do S3 de acordo com as instruções descritas na [documentação do EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-bootstrap.html). Se você tiver outras ações de bootstrap configuradas para os clusters do EMR, certifique-se de que esse script esteja configurado como o primeiro script de ação de bootstrap a ser executado.

1. Encerre os clusters EMR existentes e inicie novos clusters com o script de ação bootstrap. AWS recomenda que você teste os scripts de bootstrap em seu ambiente de teste e valide seus aplicativos antes de aplicá-los ao seu ambiente de produção. Se você não estiver usando a revisão mais recente de uma versão secundária do EMR (por exemplo, 6.3.0), deverá usar a revisão mais recente (por exemplo, 6.3.1) e, em seguida, aplicar a solução discutida acima.


**CVE-2021-44228 e CVE-2021-45046: scripts de bootstrap para versões do Amazon EMR**  

| Número da versão do Amazon EMR | Local do script | Data da versão do script | 
| --- | --- | --- | 
| 6.5.0 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-6.5.0-v2.sh</pre>  | 24 de março de 2022 | 
| 6.4.0 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-6.4.0-v2.sh</pre>  | 24 de março de 2022 | 
| 6.3.1 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-6.3.1-v2.sh</pre>  | 24 de março de 2022 | 
| 6.2.1 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-6.2.1-v2.sh</pre>  | 24 de março de 2022 | 
| 6.1.1 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-6.1.1-v2.sh</pre>  | 14 de dezembro de 2021 | 
| 6.0.1 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-6.0.1-v2.sh</pre>  | 14 de dezembro de 2021 | 
| 5.34,0 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.34.0-v2.sh</pre>  | 12 de dezembro de 2021 | 
| 5.3.1 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.33.1-v2.sh</pre>  | 12 de dezembro de 2021 | 
| 5.32.1 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.32.1-v2.sh</pre>  | 13 de dezembro de 2021 | 
| 5.31.1 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.31.1-v2.sh</pre>  | 13 de dezembro de 2021 | 
| 5.30.2 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.30.2-v2.sh</pre>  | 14 de dezembro de 2021 | 
| 5.29.0 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.29.0-v2.sh</pre>  | 14 de dezembro de 2021 | 
| 5.28.1 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.28.1-v2.sh</pre>  | 15 de dezembro de 2021 | 
| 5.27.1 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.27.1-v2.sh</pre>  | 15 de dezembro de 2021 | 
| 5.26.0 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.26.0-v2.sh</pre>  | 15 de dezembro de 2021 | 
| 5.25.0 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.25.0-v2.sh</pre>  | 15 de dezembro de 2021 | 
| 5.24.1 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.24.1-v2.sh</pre>  | 15 de dezembro de 2021 | 
| 5.23.1 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.23.1-v2.sh</pre>  | 15 de dezembro de 2021 | 
| 5.22.0 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.22.0-v2.sh</pre>  | 15 de dezembro de 2021 | 
| 5.21.2 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.21.2-v2.sh</pre>  | 15 de dezembro de 2021 | 
| 5.20.1 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.20.1-v2.sh</pre>  | 15 de dezembro de 2021 | 
| 5.19.1 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.19.1-v2.sh</pre>  | 15 de dezembro de 2021 | 
| 5.18.1 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.18.1-v2.sh</pre>  | 15 de dezembro de 2021 | 
| 5.17.2 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.17.2-v2.sh</pre>  | 15 de dezembro de 2021 | 
| 5.16.1 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.16.1-v2.sh</pre>  | 15 de dezembro de 2021 | 
| 5.15.1 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.15.1-v2.sh</pre>  | 15 de dezembro de 2021 | 
| 5.14.2 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.14.2-v2.sh</pre>  | 15 de dezembro de 2021 | 
| 5.13.1 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.13.1-v2.sh</pre>  | 15 de dezembro de 2021 | 
| 5.12.3 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.12.3-v2.sh</pre>  | 15 de dezembro de 2021 | 
| 5.11.4 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.11.4-v2.sh</pre>  | 15 de dezembro de 2021 | 
| 5.10.1 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.10.1-v2.sh</pre>  | 15 de dezembro de 2021 | 
| 5.9.1 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.9.1-v2.sh</pre>  | 15 de dezembro de 2021 | 
| 5.8.3 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.8.3-v2.sh</pre>  | 15 de dezembro de 2021 | 
| 5.7.1 |  <pre>s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.7.1-v2.sh</pre>  | 15 de dezembro de 2021 | 


****  

| Versão de lançamento do EMR | Revisão mais recente em dezembro de 2021 | 
| --- | --- | 
| 6.3.0 | 6.3.1 | 
| 6.2.0 | 6.2.1 | 
| 6.1.0 | 6.1.1 | 
| 6.0.0 | 6.0.1 | 
| 5.33.0 | 5.3.1 | 
| 5.32.0 | 5.32.1 | 
| 5.31.0 | 5.31.1 | 
| 5.30.0 ou 5.30.1 | 5.30.2 | 
| 5.28.0 | 5.28.1 | 
| 5.27.0 | 5.27.1 | 
| 5.24,0 | 5.24.1 | 
| 5.23,0 | 5.23.1 | 
| 5.21.0 ou 5.21.1 | 5.21.2 | 
| 5.20.0 | 5.20.1 | 
| 5.19.0 | 5.19.1 | 
| 5.18.0 | 5.18.1 | 
| 5.17.0 ou 5.17.1 | 5.17.2 | 
| 5.16.0 | 5.16.1 | 
| 5.15.0 | 5.15.1 | 
| 5.14.0 ou 5.14.1 | 5.14.2 | 
| 5.13.0 | 5.13.1 | 
| 5.12.0, 5.12.1, 5.12.2 | 5.12.3 | 
| 5.11.0, 5.11.1, 5.11.2, 5.11.3 | 5.11.4 | 
| 5.9.0 | 5.9.1 | 
| 5.8.0, 5.8.1, 5.8.2 | 5.8.3 | 
| 5.7.0 | 5.7.1 | 

## Perguntas frequentes
<a name="emr-log4j-vulnerability-faqs"></a>
+ **As versões do EMR anteriores ao EMR 5 são afetadas pelo CVE-2021-44228**?

  Não. As versões do EMR anteriores à versão 5 do EMR usam versões do Log4j anteriores à 2.0.
+ **Essa solução aborda o CVE-2021-45046?**

  Sim, essa solução também aborda o **CVE-2021-45046.**
+ **A solução lida com aplicações personalizadas que instalo nos meus clusters do EMR?**

  O script de bootstrap só atualiza os arquivos JAR que são instalados pelo EMR. Se você instalar e executar aplicações personalizadas e arquivos JAR nos clusters do EMR por meio de ações de bootstrap, como etapas enviadas aos clusters, usando a AMI personalizada do Amazon Linux ou por meio de qualquer outro mecanismo, trabalhe com o fornecedor da aplicação para determinar se suas aplicações personalizadas são afetadas pelo CVE-2021-44228 e determine uma solução apropriada. 
+ **Como devo lidar com [imagens do docker personalizadas](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/docker-custom-images.html) com o EMR no EKS?**

  Se você adicionar aplicativos personalizados ao Amazon EMR no EKS usando [imagens docker](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/docker-custom-images.html) personalizadas ou enviar trabalhos para o Amazon EMR em arquivos de aplicativos EKSwith personalizados, trabalhe com o fornecedor do aplicativo para determinar se seus aplicativos personalizados são afetados pelo CVE-2021-44228 e determine uma solução apropriada.
+ **Como o script de bootstrap funciona para mitigar o problema descrito no CVE-2021-44228 e no CVE-2021-45046?**

  O script de bootstrap atualiza as instruções de inicialização do EMR ao adicionar um novo conjunto de instruções. Essas novas instruções excluem os arquivos de JndiLookup classe usados pelo Log4j por todas as estruturas de código aberto instaladas pelo EMR. Isso segue a [recomendação publicada pela Apache](https://nvd.nist.gov/vuln/detail/CVE-2021-45046#vulnCurrentDescriptionTitle) para lidar com os problemas do Log4j.
+ **Existe alguma atualização do EMR que usa as versões 2.17.1 ou superiores do Log4j?**

  As versões do EMR 5 até a versão 5.34 e as versões do EMR 6 até a versão 6.5 usam versões mais antigas de estruturas de código aberto que são incompatíveis com as versões mais recentes do Log4j. Se você continuar usando essas versões, recomendamos que você aplique a ação bootstrap para mitigar os problemas discutidos no. CVEs Após a versão 5.34 do EMR 5 e a versão 6.5 do EMR 6, as aplicações que usam o Log4j 1.x e o Log4j 2.x serão atualizadas para usar o Log4j 1.2.17 (ou superior) e o Log4j 2.17.1 (ou superior), respectivamente, e não exigirão o uso das ações de bootstrap indicadas acima para mitigar os problemas do CVE.
+ **As versões do EMR são afetadas pelo CVE-2021-45105?**

  As aplicações instaladas pelo Amazon EMR com as configurações padrão do EMR não são afetados pelo CVE-2021-45105. Entre as aplicações instaladas pelo Amazon EMR, somente o Apache Hive usa o Apache Log4j com [pesquisas de contexto](https://logging.apache.org/log4j/2.x/index.html) e não usa layout de modelo não padrão de uma forma que permita o processamento de dados de entrada inadequados.
+ **O Amazon EMR é afetado por alguma das divulgações do CVE a seguir?**

  A tabela a seguir contém uma lista dos CVEs que estão relacionados ao Log4j e indica se cada CVE afeta o Amazon EMR. As informações dessa tabela só se aplicam quando as aplicações são instaladas pelo Amazon EMR usando as configurações padrão.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-log4j-vulnerability.html)

# Arquivo de notas de versão do Amazon EMR
<a name="emr-whatsnew-history"></a>

Notas de versão para todas as versões do Amazon EMR estão disponíveis a seguir. Para obter informações de versão abrangentes para cada versão, consulte [Versões de lançamento 6.x do Amazon EMR](emr-release-6x.md), [Versões de lançamento 5.x do Amazon EMR](emr-release-5x.md) e [Versões de lançamento 4.x do Amazon EMR](emr-release-4x.md).

Para receber atualizações quando uma nova versão do Amazon EMR estiver disponível, assine o [RSS feed das notas de versão do Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/amazon-emr-release-notes.rss).

## Versão 6.14.0
<a name="emr-6140-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 6.14.0 do Amazon EMR. As alterações são referentes à versão 6.13.0. Para obter informações sobre o cronograma da versão, consulte o [Log de alterações 6.14.0](emr-6140-release.md#6140-changelog).

**Novos recursos**
+ Amazon EMR 6.14.0 supports Apache Spark 3.4.1, Apache Spark RAPIDS 23.06.0-amzn-2, Flink 1.17.1, Iceberg 1.3.1, and Trino 422.
+ O [Ajuste de Escala Gerenciado do Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-scaling.html) agora está disponível na região `ap-southeast-3` Ásia-Pacífico (Jacarta) para clusters criados com o Amazon EMR 6.14.0 e superior.

**Problemas conhecidos**
+ Um script de estado de instância no cluster que monitora a integridade da instância pode consumir recursos excessivos de CPU e memória quando há um grande número de threads and/or abertos e manipuladores de arquivos no nó.

**Alterações, melhorias e problemas resolvidos**
+  *A partir do Spark 3.3.1 (com suporte nas versões 6.10 e posteriores do EMR), todos os executores em um host de descomissionamento são configurados para um novo `ExecutorState`, chamado de estado DECOMMISSIONING*. Os executores que estão sendo desativados não podem ser usados pelo Yarn para alocar tarefas e, portanto, ele solicitará novos executores, se necessário, para as tarefas que estão sendo executadas. Portanto, se você desativar o Spark DRA enquanto estiver usando o EMR Managed Scaling, o EMR Auto Scaling ou qualquer mecanismo de ajuste de escala personalizado em clusters EMR-EC2, o Yarn poderá solicitar o número máximo permitido de executores para cada trabalho. Para evitar esse problema, deixe a propriedade `spark.dynamicAllocation.enabled` definida como `TRUE` (que é o padrão) ao usar a combinação de recursos acima. Além disso, você também pode definir restrições mínimas e máximas para executores, definindo valores para as propriedades `spark.dynamicAllocation.maxExecutors` e `spark.dynamicAllocation.minExecutors` para seus trabalhos Spark, a fim de restringir o número de executores alocados durante a execução do trabalho. 
+ A versão 6.14.0 otimiza o gerenciamento de logs com o Amazon EMR em execução no Amazon EC2. Como resultado, é possível ver uma pequena redução nos custos de armazenamento dos logs do cluster.
+ A versão 6.14.0 melhora o fluxo de trabalho de ajuste de escala para considerar diferentes instâncias principais que têm variação substancial no tamanho dos volumes do Amazon EBS. Essa melhoria se aplica somente aos nós centrais; as operações de redução dos nós de tarefas não são afetadas.
+ A versão 6.14.0 melhora a forma como o Amazon EMR interage com aplicações de código aberto, como. Apache Hadoop YARN ResourceManager and HDFS NameNode Essa melhoria reduz o risco de atrasos operacionais com o escalonamento do cluster e atenua as falhas de inicialização que ocorrem devido a problemas de conectividade com os aplicações de código aberto.
+ A versão 6.14.0 otimiza a instalação da aplicação na inicialização do cluster. Isso melhora os tempos de inicialização do cluster para determinadas combinações de aplicações do Amazon EMR.
+ A versão 6.14.0 corrige um problema em que as operações de redução de escala do cluster podem parar quando um cluster executado em uma VPC com um domínio personalizado é reiniciado no nó central ou da tarefa.
+ Quando você inicia um cluster com a *versão de patch mais recente* do Amazon EMR 5.36 ou superior, 6.6 ou superior ou 7.0 ou superior, o Amazon EMR usa a versão mais recente do Amazon Linux 2023 ou do Amazon Linux 2 para a AMI padrão do Amazon EMR. Para obter mais informações, consulte [Como usar a AMI padrão do Amazon Linux para Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew-history.html)

## Versão 6.13.0
<a name="emr-613-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 6.13.0 do Amazon EMR. As alterações são referentes à versão 6.12.0. Para obter informações sobre o cronograma da versão, consulte o [Log de alterações 6.13.0](emr-6130-release.md#6130-changelog).

**Novos recursos**
+ Amazon EMR 6.13.0 supports Apache Spark 3.4.1, Apache Spark RAPIDS 23.06.0-amzn-1, CUDA Toolkit 11.8.0, and JupyterHub 1.5.0.

**Problemas conhecidos**
+ Um script de estado de instância no cluster que monitora a integridade da instância pode consumir recursos excessivos de CPU e memória quando há um grande número de threads and/or abertos e manipuladores de arquivos no nó.

**Alterações, melhorias e problemas resolvidos**
+  *A partir do Spark 3.3.1 (com suporte nas versões 6.10 e posteriores do EMR), todos os executores em um host de descomissionamento são configurados para um novo `ExecutorState`, chamado de estado DECOMMISSIONING*. Os executores que estão sendo desativados não podem ser usados pelo Yarn para alocar tarefas e, portanto, ele solicitará novos executores, se necessário, para as tarefas que estão sendo executadas. Portanto, se você desativar o Spark DRA enquanto estiver usando o EMR Managed Scaling, o EMR Auto Scaling ou qualquer mecanismo de ajuste de escala personalizado em clusters EMR-EC2, o Yarn poderá solicitar o número máximo permitido de executores para cada trabalho. Para evitar esse problema, deixe a propriedade `spark.dynamicAllocation.enabled` definida como `TRUE` (que é o padrão) ao usar a combinação de recursos acima. Além disso, você também pode definir restrições mínimas e máximas para executores, definindo valores para as propriedades `spark.dynamicAllocation.maxExecutors` e `spark.dynamicAllocation.minExecutors` para seus trabalhos Spark, a fim de restringir o número de executores alocados durante a execução do trabalho. 
+ A versão 6.13.0 aprimora o daemon de gerenciamento de logs do Amazon EMR para garantir que todos os logs sejam carregados regularmente para o Amazon S3 quando um comando de encerramento de cluster é emitido. Isso facilita o encerramento mais rápido do cluster.
+ A versão 6.13.0 aprimora os recursos de gerenciamento de logs do Amazon EMR para garantir o carregamento consistente e oportuno de todos os arquivos de log para o Amazon S3. Isso beneficia especialmente os clusters do EMR de execução prolongada.
+ Quando você inicia um cluster com a *versão de patch mais recente* do Amazon EMR 5.36 ou superior, 6.6 ou superior ou 7.0 ou superior, o Amazon EMR usa a versão mais recente do Amazon Linux 2023 ou do Amazon Linux 2 para a AMI padrão do Amazon EMR. Para obter mais informações, consulte [Como usar a AMI padrão do Amazon Linux para Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew-history.html)

## Versão 6.12.0
<a name="emr-6120-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 6.12.0 do Amazon EMR. As alterações são referentes à versão 6.11.0. Para obter informações sobre o cronograma da versão, consulte o [Log de alterações 6.12.0](emr-6120-release.md#6120-changelog).

**Novos recursos**
+ Amazon EMR 6.12.0 supports Apache Spark 3.4.0, Apache Spark RAPIDS 23.06.0-amzn-0, CUDA 11.8.0, Apache Hudi 0.13.1-amzn-0, Apache Iceberg 1.3.0-amzn-0, Trino 414, and PrestoDB 0.281.
+ As versões 6.12.0 e superiores do Amazon EMR oferecem suporte à integração LDAP com Apache Livy, Apache Hive through HiveServer 2 (), Trino, Presto e Hue. HS2 Você também pode instalar o Apache Spark e o Apache Hadoop em um cluster do EMR que use a versão 6.12.0 ou superior e configurá-los para usar LDAP. Para obter mais informações, consulte [Usar servidores do Active Directory ou LDAP para autenticação com o Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/ldap.html).

**Problemas conhecidos**
+ Um script de estado de instância no cluster que monitora a integridade da instância pode consumir recursos excessivos de CPU e memória quando há um grande número de threads and/or abertos e manipuladores de arquivos no nó.

**Alterações, melhorias e problemas resolvidos**
+  *A partir do Spark 3.3.1 (com suporte nas versões 6.10 e posteriores do EMR), todos os executores em um host de descomissionamento são configurados para um novo `ExecutorState`, chamado de estado DECOMMISSIONING*. Os executores que estão sendo desativados não podem ser usados pelo Yarn para alocar tarefas e, portanto, ele solicitará novos executores, se necessário, para as tarefas que estão sendo executadas. Portanto, se você desativar o Spark DRA enquanto estiver usando o EMR Managed Scaling, o EMR Auto Scaling ou qualquer mecanismo de ajuste de escala personalizado em clusters EMR-EC2, o Yarn poderá solicitar o número máximo permitido de executores para cada trabalho. Para evitar esse problema, deixe a propriedade `spark.dynamicAllocation.enabled` definida como `TRUE` (que é o padrão) ao usar a combinação de recursos acima. Além disso, você também pode definir restrições mínimas e máximas para executores, definindo valores para as propriedades `spark.dynamicAllocation.maxExecutors` e `spark.dynamicAllocation.minExecutors` para seus trabalhos Spark, a fim de restringir o número de executores alocados durante a execução do trabalho. 
+ As versões 6.12.0 e superiores do Amazon EMR oferecem suporte ao runtime do Java 11 para o Flink. Para obter mais informações, consulte [Configurar o Flink para ser executado com o Java 11](flink-configure.md#flink-configure-java11).
+ A versão 6.12.0 adiciona um mecanismo de nova tentativa ao fluxo de trabalho de escalabilidade de clusters para os clusters do EMR que executam Presto ou Trino. Essa melhoria reduz o risco de que o redimensionamento do cluster fique paralisado indefinidamente devido a uma única falha na operação de redimensionamento. Ela também aprimora a utilização dos clusters, porque seu cluster aumenta e reduz a escala verticalmente com mais rapidez.
+ A versão 6.12.0 corrige um problema em que as operações de redução da escala verticalmente do cluster podem ficar paralisadas quando um nó central que está passando por uma desativação tranquila se torna não íntegro por qualquer motivo antes de ser totalmente desativado.
+ A versão 6.12.0 melhora a lógica de redução da escala verticalmente do cluster para que o cluster não tente reduzir a escala verticalmente dos nós centrais abaixo da configuração do fator de replicação do HDFS para o cluster. Isso se alinha aos seus requisitos de redundância de dados e reduz a probabilidade de uma operação de escalabilidade paralisar.
+ A versão 6.12.0 aprimora a performance e a eficiência do serviço de monitoramento de integridade do Amazon EMR, ao aumentar a velocidade com que ele registra em log as mudanças de estado das instâncias. Essa melhoria reduz a probabilidade de degradação do desempenho dos nós do cluster que estão executando várias ferramentas de cliente ou aplicações de terceiros personalizadas.
+ A versão 6.12.0 melhora a performance do daemon de gerenciamento de logs no cluster para o Amazon EMR. Como resultado, existe uma menor probabilidade de degradação da performance com clusters do EMR que executam etapas com alta simultaneidade.
+ Com a versão 6.12.0 do Amazon EMR, o daemon de gerenciamento de logs foi atualizado para identificar todos os logs que estão em uso ativo com identificadores de arquivos abertos no armazenamento da instância local e nos processos associados. Essa atualização garante que o Amazon EMR exclua adequadamente os arquivos e recupere o espaço de armazenamento depois que os logs são arquivados no Amazon S3.
+ A versão 6.12.0 inclui um aprimoramento do daemon de gerenciamento de logs que exclui diretórios de etapas vazios e não utilizados no sistema de arquivos de cluster local. Um número excessivamente grande de diretórios vazios pode degradar a performance dos daemons do Amazon EMR e resultar na utilização excessiva do disco.
+ A versão 6.12.0 permite a alternância de logs do servidor de linha do tempo do YARN. Isso minimiza os cenários de utilização excessiva do disco, especialmente para clusters de execução prolongada.
+ O tamanho padrão do volume raiz aumentou para 15 GB nas versões 6.10.0 e superiores do Amazon EMR. O tamanho padrão do volume raiz das versões anteriores é de 10 GB.
+ Quando você inicia um cluster com a *versão de patch mais recente* do Amazon EMR 5.36 ou superior, 6.6 ou superior ou 7.0 ou superior, o Amazon EMR usa a versão mais recente do Amazon Linux 2023 ou do Amazon Linux 2 para a AMI padrão do Amazon EMR. Para obter mais informações, consulte [Como usar a AMI padrão do Amazon Linux para Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew-history.html)

## Versão 6.11.1
<a name="emr-6111-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 6.11.1 do Amazon EMR. As alterações são referentes à versão 6.11.0. Para obter informações sobre o cronograma da versão, consulte o [Log de alterações 6.11.1](emr-6111-release.md#6111-changelog).

**Alterações, melhorias e problemas resolvidos**
+  *A partir do Spark 3.3.1 (com suporte nas versões 6.10 e posteriores do EMR), todos os executores em um host de descomissionamento são configurados para um novo `ExecutorState`, chamado de estado DECOMMISSIONING*. Os executores que estão sendo desativados não podem ser usados pelo Yarn para alocar tarefas e, portanto, ele solicitará novos executores, se necessário, para as tarefas que estão sendo executadas. Portanto, se você desativar o Spark DRA enquanto estiver usando o EMR Managed Scaling, o EMR Auto Scaling ou qualquer mecanismo de ajuste de escala personalizado em clusters EMR-EC2, o Yarn poderá solicitar o número máximo permitido de executores para cada trabalho. Para evitar esse problema, deixe a propriedade `spark.dynamicAllocation.enabled` definida como `TRUE` (que é o padrão) ao usar a combinação de recursos acima. Além disso, você também pode definir restrições mínimas e máximas para executores, definindo valores para as propriedades `spark.dynamicAllocation.maxExecutors` e `spark.dynamicAllocation.minExecutors` para seus trabalhos Spark, a fim de restringir o número de executores alocados durante a execução do trabalho. 
+ Devido à contenção de bloqueio, um nó pode entrar em um deadlock se for adicionado ou removido ao mesmo tempo em que tenta ser desativado. Como resultado, o Hadoop Resource Manager (YARN) deixa de responder e afeta todos os contêineres de entrada e em execução no momento.
+ Esta versão inclui uma alteração que permite que clusters de alta disponibilidade se recuperem de um estado de falha após a reinicialização.
+ Esta versão inclui correções de segurança para Hue e. HBase
+ Esta versão corrige um problema em que clusters que estão executando workloads no Spark com o Amazon EMR podem receber silenciosamente resultados incorretos com `contains`, `startsWith`, `endsWith` e `like`. Esse problema ocorre quando você usa as expressões em campos particionados que têm metadados no Hive3 Metastore Server (HMS) no Amazon EMR.
+ Esta versão corrige um problema com controle de utilização no lado do Glue quando não há funções definidas pelo usuário (UDF).
+ Esta versão corrige um problema que exclui logs de contêineres pelo serviço de agregação de logs de nó antes que o pusher de logs possa enviá-los para o S3 em caso de desativação do YARN.
+ Esta versão corrige um problema com as métricas do FairShare Scheduler quando o Node Label está habilitado para o Hadoop.
+ Esta versão corrige um problema que afetou a performance do Spark quando você definiu um valor de `true` padrão para a configuração `spark.yarn.heterogeneousExecutors.enabled` no `spark-defaults.conf`.
+ Esta versão corrige um problema com a falha do Reduce Task em ler dados embaralhados. O problema causou falhas na consulta do Hive com um erro de memória corrompida.
+ Esta versão adiciona um mecanismo de nova tentativa ao fluxo de trabalho de escalabilidade de clusters para clusters do EMR que executam o Presto ou o Trino. Essa melhoria reduz o risco de que o redimensionamento do cluster fique paralisado indefinidamente devido a uma única falha na operação de redimensionamento. Ela também aprimora a utilização dos clusters, porque seu cluster aumenta e reduz a escala verticalmente com mais rapidez.
+ Esta versão melhora a lógica de redução da escala verticalmente do cluster para que o cluster não tente reduzir a escala verticalmente dos nós centrais abaixo da configuração do fator de replicação do HDFS para o cluster. Isso se alinha aos seus requisitos de redundância de dados e reduz a probabilidade de uma operação de escalabilidade paralisar.
+ O daemon de gerenciamento de logs foi atualizado para identificar todos os logs que estão em uso ativo com identificadores de arquivos abertos no armazenamento da instância local e nos processos associados. Essa atualização garante que o Amazon EMR exclua adequadamente os arquivos e recupere o espaço de armazenamento depois que os logs são arquivados no Amazon S3.
+ Esta versão inclui um aprimoramento do daemon de gerenciamento de logs que exclui diretórios de etapas vazios e não utilizados no sistema de arquivos de cluster local. Um número excessivamente grande de diretórios vazios pode degradar a performance dos daemons do Amazon EMR e resultar na utilização excessiva do disco.
+ Quando você inicia um cluster com a *versão de patch mais recente* do Amazon EMR 5.36 ou superior, 6.6 ou superior ou 7.0 ou superior, o Amazon EMR usa a versão mais recente do Amazon Linux 2023 ou do Amazon Linux 2 para a AMI padrão do Amazon EMR. Para obter mais informações, consulte [Como usar a AMI padrão do Amazon Linux para Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew-history.html)

## Versão 6.11.0
<a name="emr-6110-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 6.11.0 do Amazon EMR. As alterações são referentes à versão 6.10.0. Para obter informações sobre o cronograma da versão, consulte o [log de alterações](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-6110-release.html#6110-changelog).

**Novos recursos**
+ O Amazon EMR 6.11.0 é compatível com Apache Spark 3.3.2-amzn-0, Apache Spark RAPIDS 23.02.0-amzn-0, CUDA 11.8.0, Apache Hudi 0.13.0-amzn-0, Apache Iceberg 1.2.0-amzn-0, Trino 410-amzn-0 e PrestoDB 0.279-amzn-0.

**Alterações, melhorias e problemas resolvidos**
+  *A partir do Spark 3.3.1 (com suporte nas versões 6.10 e posteriores do EMR), todos os executores em um host de descomissionamento são configurados para um novo `ExecutorState`, chamado de estado DECOMMISSIONING*. Os executores que estão sendo desativados não podem ser usados pelo Yarn para alocar tarefas e, portanto, ele solicitará novos executores, se necessário, para as tarefas que estão sendo executadas. Portanto, se você desativar o Spark DRA enquanto estiver usando o EMR Managed Scaling, o EMR Auto Scaling ou qualquer mecanismo de ajuste de escala personalizado em clusters EMR-EC2, o Yarn poderá solicitar o número máximo permitido de executores para cada trabalho. Para evitar esse problema, deixe a propriedade `spark.dynamicAllocation.enabled` definida como `TRUE` (que é o padrão) ao usar a combinação de recursos acima. Além disso, você também pode definir restrições mínimas e máximas para executores, definindo valores para as propriedades `spark.dynamicAllocation.maxExecutors` e `spark.dynamicAllocation.minExecutors` para seus trabalhos Spark, a fim de restringir o número de executores alocados durante a execução do trabalho. 
+ Com o Amazon EMR 6.11.0, o conector do DynamoDB foi atualizado para a versão 5.0.0. A versão 5.0.0 usa AWS SDK for Java 2.x. As versões anteriores usavam AWS SDK para Java 1.x. Como resultado dessa atualização, recomendamos firmemente que você teste seu código antes de usar o conector do DynamoDB com o Amazon EMR 6.11.
+ Quando o conector do DynamoDB para Amazon EMR 6.11.0 chama o serviço do DynamoDB, ele usa o valor da região que você fornece para a propriedade `dynamodb.endpoint`. Recomendamos que você também configure `dynamodb.region` quando usar `dynamodb.endpoint` e que ambas as propriedades tenham como destino a mesma Região da AWS. Se você usar `dynamodb.endpoint` e não configurar`dynamodb.region`, o conector do DynamoDB para Amazon EMR 6.11.0 retornará uma exceção de região inválida e tentará reconciliar suas informações do serviço de metadados de instância Região da AWS do Amazon EC2 (IMDS). Se o conector não conseguir recuperar a região do IMDS, o padrão será Leste dos EUA (Norte da Virgínia) (`us-east-1`). O erro a seguir é um exemplo da exceção de região inválida que você pode obter se não configurar adequadamente a `dynamodb.region` propriedade: `error software.amazon.awssdk.services.dynamodb.model.DynamoDbException: Credential should be scoped to a valid region.` Para obter mais informações sobre as classes afetadas pela AWS SDK para Java atualização para 2.x, consulte o commit [Upgrade AWS SDK para Java from 1.x to 2.x (\$1175)](https://github.com/awslabs/emr-dynamodb-connector/commit/1dec9d1972d3673c3fae6c6ea51f19f295147ccf) no GitHub repositório do conector Amazon EMR - DynamoDB.
+ Esta versão corrige um problema em que os dados da coluna se tornam `NULL` quando você usa o Delta Lake para armazenar dados da tabela Delta no Amazon S3 após a operação de renomeação da coluna. Para obter mais informações sobre esse atributo experimental no Delta Lake, consulte [Operação de renomeação de coluna](https://docs.delta.io/latest/delta-batch.html#rename-columns) no Guia do usuário do Delta Lake.
+ A versão 6.11.0 corrige um problema que pode ocorrer quando você cria um nó de borda ao replicar um dos nós primários de um cluster com vários nós primários. O nó de borda replicado pode causar atrasos nas operações de redução da escala verticalmente ou resultar em alta utilização de memória nos nós primários. Para obter mais informações sobre como criar um nó de borda para se comunicar com seu cluster EMR, consulte [Edge Node Creator](https://github.com/aws-samples/aws-emr-utilities/tree/main/utilities/emr-edge-node-creator) no `aws-samples` repositório em. GitHub
+ A versão 6.11.0 melhora o processo de automação que o Amazon EMR usa para remontar volumes do Amazon EBS em uma instância após uma reinicialização.
+ A versão 6.11.0 corrige um problema que resultou em lacunas intermitentes nas métricas do Hadoop que o Amazon EMR publica na Amazon. CloudWatch
+ A versão 6.11.0 corrige um problema com clusters do EMR em que uma atualização no arquivo de configuração do YARN que contém a lista de exclusão de nós do cluster é interrompida devido à utilização excessiva do disco. A atualização incompleta impede futuras operações de redução da escala verticalmente do cluster. Esta versão garante que o cluster permaneça íntegro e que as operações de escalabilidade funcionem conforme esperado.
+ O tamanho padrão do volume raiz aumentou para 15 GB nas versões 6.10.0 e superiores do Amazon EMR. O tamanho padrão do volume raiz das versões anteriores é de 10 GB.
+ O Hadoop 3.3.3 introduziu uma alteração no YARN ([YARN-9608](https://issues.apache.org/jira/browse/YARN-9608)) que mantém os nós em que os contêineres eram executados em um estado de desativação até que a aplicação seja concluída. Essa alteração garante que dados locais, como dados embaralhados, não sejam perdidos e que você não precise executar o trabalho novamente. Essa abordagem também pode levar à subutilização de recursos em clusters com ou sem o ajuste de escala gerenciado habilitado.

  Com as versões 6.11.0 e superiores do Amazon EMR, além das versões 6.8.1, 6.9.1 e 6.10.1, o valor de `yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-applications` é definido como `false` em `yarn-site.xml` para resolver esse problema.

  Embora a correção resolva os problemas introduzidos pelo YARN-9608, ela pode fazer com que os trabalhos do Hive falhem devido à perda de dados embaralhados em clusters com ajuste de escala gerenciado habilitado. Reduzimos esse risco nesta versão também ao configurar `yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data` para workloads do Hive. Essa configuração só está disponível com as versões 6.11.0 e superiores do Amazon EMR.
+ Quando você inicia um cluster com a *versão de patch mais recente* do Amazon EMR 5.36 ou superior, 6.6 ou superior ou 7.0 ou superior, o Amazon EMR usa a versão mais recente do Amazon Linux 2023 ou do Amazon Linux 2 para a AMI padrão do Amazon EMR. Para obter mais informações, consulte [Como usar a AMI padrão do Amazon Linux para Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).
**nota**  
Essa versão não recebe mais atualizações automáticas da AMI, pois foi substituída por uma ou mais versões de patch. A versão de patch é indicada pelo número após o segundo ponto decimal (`6.8.1`). Para ver se você está usando a versão de patch mais recente, verifique as versões disponíveis no [https://docs.aws.amazon.com/emr/latest/ReleaseGuide](https://docs.aws.amazon.com/emr/latest/ReleaseGuide) ou verifique o menu suspenso de **versões do Amazon EMR** quando criar um cluster no console ou use a ação de API [https://docs.aws.amazon.com/emr/latest/APIReference/API_ListReleaseLabels.html](https://docs.aws.amazon.com/emr/latest/APIReference/API_ListReleaseLabels.html) ou da CLI [https://docs.aws.amazon.com/cli/latest/reference/emr/list-release-labels.html](https://docs.aws.amazon.com/cli/latest/reference/emr/list-release-labels.html). Para obter atualizações sobre novas versões, assine o feed RSS na página [Novidades](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-whatsnew.html).    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew-history.html)

## Versão 6.10.0
<a name="emr-6100-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 6.10.0 do Amazon EMR. As alterações são referentes à versão 6.9.0. Para obter informações sobre o cronograma da versão, consulte o [log de alterações](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-6100-release.html#6100-changelog).

**Novos recursos**
+ O Amazon EMR 6.10.0 é compatível com Apache Spark 3.3.1, Apache Spark RAPIDS 22.12.0, CUDA 11.8.0, Apache Hudi 0.12.2-amzn-0, Apache Iceberg 1.1.0-amzn-0, Trino 403 e PrestoDB 0.278.1.
+ O Amazon EMR 6.10.0 inclui um conector Trino-Hudi nativo que fornece acesso de leitura aos dados nas tabelas Hudi. Você pode ativar o conector com `trino-cli --catalog hudi` e configurar o conector de acordo com suas necessidades com `trino-connector-hudi`. A integração nativa com o Amazon EMR significa que você não precisa mais usar `trino-connector-hive` para consultar tabelas do Hudi. Para obter uma lista das configurações compatíveis com o novo conector, consulte a página do [conector do Hudi](https://trino.io/docs/current/connector/hudi.html) na documentação do Trino.
+ O Amazon EMR 6.10.0 e versões posteriores oferecem suporte à integração do Apache Zeppelin com o Apache Flink. Consulte [Usar trabalhos do Flink pelo Zeppelin no Amazon EMR](flink-zeppelin.md) para obter mais informações.

**Problemas conhecidos**
+ O Hadoop 3.3.3 introduziu uma alteração no YARN ([YARN-9608](https://issues.apache.org/jira/browse/YARN-9608)) que mantém os nós em que os contêineres eram executados em um estado de desativação até que a aplicação seja concluída. Essa alteração garante que dados locais, como dados embaralhados, não sejam perdidos e que você não precise executar o trabalho novamente. Essa abordagem também pode levar à subutilização de recursos em clusters com ou sem o ajuste de escala gerenciado habilitado.

  Para contornar esse problema no Amazon EMR 6.10.0, você pode definir o valor de `yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-applications` como `false` em `yarn-site.xml`. Nas versões 6.11.0 e superiores do Amazon EMR, além das versões 6.8.1, 6.9.1 e 6.10.1, o config é definido como `false` por padrão para resolver esse problema.
+  *A partir do Spark 3.3.1 (com suporte nas versões 6.10 e posteriores do EMR), todos os executores em um host de descomissionamento são configurados para um novo `ExecutorState`, chamado de estado DECOMMISSIONING*. Os executores que estão sendo desativados não podem ser usados pelo Yarn para alocar tarefas e, portanto, ele solicitará novos executores, se necessário, para as tarefas que estão sendo executadas. Portanto, se você desativar o Spark DRA enquanto estiver usando o EMR Managed Scaling, o EMR Auto Scaling ou qualquer mecanismo de ajuste de escala personalizado em clusters EMR-EC2, o Yarn poderá solicitar o número máximo permitido de executores para cada trabalho. Para evitar esse problema, deixe a propriedade `spark.dynamicAllocation.enabled` definida como `TRUE` (que é o padrão) ao usar a combinação de recursos acima. Além disso, você também pode definir restrições mínimas e máximas para executores, definindo valores para as propriedades `spark.dynamicAllocation.maxExecutors` e `spark.dynamicAllocation.minExecutors` para seus trabalhos Spark, a fim de restringir o número de executores alocados durante a execução do trabalho. 

**Alterações, melhorias e problemas resolvidos**
+ O Amazon EMR 6.10.0 remove a dependência de `minimal-json.jar` para a [integração do Amazon Redshift para Apache Spark](emr-spark-redshift-launch.md) e adiciona automaticamente os jars necessários relacionados ao Spark-Redshift ao caminho de classe do executor para o Spark: `spark-redshift.jar`, `spark-avro.jar` e `RedshiftJDBC.jar`.
+ A versão 6.10.0 aprimora o daemon de gerenciamento de logs no cluster para monitorar pastas de log adicionais no cluster do EMR. Essa melhoria minimiza os cenários de utilização excessiva do disco.
+ A versão 6.10.0 reinicia automaticamente o daemon de gerenciamento de logs no cluster quando ele é interrompido. Essa melhoria reduz o risco de os nós parecerem não íntegros devido à utilização excessiva do disco. 
+ O Amazon EMR 6.10.0 é compatível com endpoints regionais para mapeamento de usuários do EMRFS.
+ O tamanho padrão do volume raiz aumentou para 15 GB nas versões 6.10.0 e superiores do Amazon EMR. O tamanho padrão do volume raiz das versões anteriores é de 10 GB.
+ A versão 6.10.0 corrige um problema que fazia com que os trabalhos do Spark paralisassem quando todos os executores restantes do Spark estivessem em um host em desativação com o gerenciador de recursos do YARN. 
+ Com o Amazon EMR 6.6.0 a 6.9.x, as consultas INSERT com partição dinâmica e uma cláusula ORDER BY ou SORT BY sempre terá dois redutores. Esse problema é causado pela alteração do OSS [HIVE-20703](https://issues.apache.org/jira/browse/HIVE-20703), que coloca a otimização da partição dinâmica de classificação sob uma decisão baseada em custos. Se sua workload não exigir a classificação de partições dinâmicas, recomendamos que você defina a propriedade `hive.optimize.sort.dynamic.partition.threshold` como `-1` para desabilitar o novo atributo e obter o número de redutores calculado corretamente. Esse problema foi corrigido no OSS Hive como parte do [HIVE-22269](https://issues.apache.org/jira/browse/HIVE-22269) e foi corrigido no Amazon EMR 6.10.0.
+ Quando você inicia um cluster com a *versão de patch mais recente* do Amazon EMR 5.36 ou superior, 6.6 ou superior ou 7.0 ou superior, o Amazon EMR usa a versão mais recente do Amazon Linux 2023 ou do Amazon Linux 2 para a AMI padrão do Amazon EMR. Para obter mais informações, consulte [Como usar a AMI padrão do Amazon Linux para Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).
**nota**  
Essa versão não recebe mais atualizações automáticas da AMI, pois foi substituída por uma ou mais versões de patch. A versão de patch é indicada pelo número após o segundo ponto decimal (`6.8.1`). Para ver se você está usando a versão de patch mais recente, verifique as versões disponíveis no [https://docs.aws.amazon.com/emr/latest/ReleaseGuide](https://docs.aws.amazon.com/emr/latest/ReleaseGuide) ou verifique o menu suspenso de **versões do Amazon EMR** quando criar um cluster no console ou use a ação de API [https://docs.aws.amazon.com/emr/latest/APIReference/API_ListReleaseLabels.html](https://docs.aws.amazon.com/emr/latest/APIReference/API_ListReleaseLabels.html) ou da CLI [https://docs.aws.amazon.com/cli/latest/reference/emr/list-release-labels.html](https://docs.aws.amazon.com/cli/latest/reference/emr/list-release-labels.html). Para obter atualizações sobre novas versões, assine o feed RSS na página [Novidades](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-whatsnew.html).    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew-history.html)

## Versão 6.9.0
<a name="emr-690-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 6.9.0 do Amazon EMR. As alterações são referentes à versão 6.8.0 do Amazon EMR. Para obter informações sobre o cronograma da versão, consulte o [log de alterações](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-690-release.html#690-changelog).

**Novos atributos**
+ A versão 6.9.0 do Amazon EMR é compatível com Apache Spark RAPIDS 22.08.0, Apache Hudi 0.12.1, Apache Iceberg 0.14.1, Trino 398 e Tez 0.10.2.
+ A versão 6.9.0 do Amazon EMR inclui uma nova aplicação de código aberto, [Delta Lake](emr-delta.md) 2.1.0.
+ A integração do Amazon Redshift para Apache Spark está inclusa nas versões 6.9.0 e posteriores do Amazon EMR. Anteriormente uma ferramenta de código aberto, a integração nativa é um conector do Spark que você pode usar para criar aplicações do Apache Spark que realizam a leitura e a gravação de dados no Amazon Redshift e no Amazon Redshift sem servidor. Para obter mais informações, consulte [Usar a integração do Amazon Redshift para Apache Spark com o Amazon EMR](emr-spark-redshift.md).
+ A versão 6.9.0 do Amazon EMR adiciona suporte ao arquivamento de logs no Amazon S3 durante a redução da escala do cluster verticalmente. Anteriormente, só era possível arquivar arquivos de log no Amazon S3 durante o encerramento do cluster. A nova capacidade garante que os arquivos de log gerados no cluster persistam no Amazon S3 mesmo após o encerramento do nó. Para obter mais informações, consulte [Configurar registro em log e depuração do cluster](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-debugging.html).
+ Para dar suporte a consultas de longa execução, o Trino agora inclui um mecanismo de execução tolerante a falhas. A execução tolerante a falhas atenua as falhas nas consultas ao tentar novamente as consultas com falha ou as tarefas dos seus componentes.
+ Você pode usar o Apache Flink no Amazon EMR para `BATCH` unificado e processamento de `STREAM` de tabelas do Apache Hive ou metadados de qualquer tablesource do Flink, como Iceberg, Kinesis ou Kafka. Você pode especificar o AWS Glue Data Catalog como metastore para o Flink usando a API Console de gerenciamento da AWS,, AWS CLI ou Amazon EMR. Para obter mais informações, consulte [Configurar o Flink no Amazon EMR](flink-configure.md).
+ Agora você pode especificar funções de tempo de execução AWS Identity and Access Management (IAM) e controle de acesso AWS Lake Formation baseado para consultas do Apache Spark, Apache Hive e Presto no Amazon EMR em clusters EC2 com o Amazon AI Studio. SageMaker Para obter mais informações, consulte [Configurar funções de runtime para as etapas do Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-steps-runtime-roles.html). 

**Problemas conhecidos**
+ Para a versão 6.9.0 do Amazon EMR, o Trino não funciona em clusters habilitados para o Apache Ranger. Se você precisar usar o Trino com o Ranger, entre em contato com o [Suporte](https://console.aws.amazon.com/support/home#/).
+ Se você usar a integração do Amazon Redshift para Apache Spark e tiver um time, timetz, timestamp ou timestamptz com precisão de microssegundos no formato Parquet, o conector arredondará os valores de tempo para o valor de milissegundo mais próximo. Como solução alternativa, use o parâmetro `unload_s3_format` do formato de descarregamento de texto.
+ 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\$1002F). Por exemplo, o caractere de espaço (U\$10020) 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](https://www.utf8-chartable.de/).

  Como solução alternativa para esse problema, defina a configuração `spark.sql.sources.fastS3PartitionDiscovery.enabled` como `false` na classificação `spark-defaults`.
+ **As conexões com clusters do Amazon EMR do Amazon SageMaker AI Studio podem falhar intermitentemente com um código de resposta 403 Forbidden.** Esse erro ocorre quando a configuração do perfil do IAM no cluster leva mais de 60 segundos. Como solução alternativa, você pode instalar um patch do Amazon EMR para permitir novas tentativas e aumentar o tempo limite para um mínimo de 300 segundos. Use as etapas a seguir para aplicar a ação de bootstrap quando iniciar o cluster.

  1.  Baixe o script de bootstrap e os arquivos RPM do Amazon URIs S3 a seguir.

     ```
     s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/gcsc/replace-rpms.sh
     s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/gcsc/emr-secret-agent-1.18.0-SNAPSHOT20221121212949.noarch.rpm
     ```

  1. Carregue os arquivos da etapa anterior em um bucket do Amazon S3 de sua propriedade. O bucket deve estar no mesmo Região da AWS local em que você planeja iniciar o cluster.

  1. Inclua a seguinte ação de bootstrap ao iniciar o cluster do EMR. Substitua *bootstrap\$1URI* e *RPM\$1URI* pelo correspondente URIs do Amazon S3. 

     ```
     --bootstrap-actions "Path=bootstrap_URI,Args=[RPM_URI]"
     ```
+ Com as versões 5.36.0 e 6.6.0 a 6.9.0 do Amazon EMR, os componentes do serviço `SecretAgent` e `RecordServer` podem sofrer perda de dados de log devido a uma configuração incorreta do padrão de nome de arquivo nas propriedades do Log4j2. A configuração incorreta faz com que os componentes gerem somente um arquivo de log por dia. Quando a estratégia de rotação ocorre, ela substitui o arquivo existente em vez de gerar um novo arquivo de log, conforme esperado. Como solução alternativa, use uma ação de bootstrap para gerar arquivos de log a cada hora e acrescentar um número inteiro de incremento automático no nome do arquivo para lidar com a rotação.

  Para as versões 6.6.0 a 6.9.0 do Amazon EMR, use a seguinte ação de bootstrap ao iniciar um cluster. 

  ```
  ‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-6x/replace-puppet.sh,Args=[]"
  ```

  Para o Amazon EMR 5.36.0, use a ação de bootstrap a seguir ao iniciar um cluster.

  ```
  ‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-5x/replace-puppet.sh,Args=[]"
  ```
+ O Apache Flink fornece FileSystem conectores nativos S3 FileSystem e Hadoop, que permitem que os aplicativos criem FileSink e gravem os dados no Amazon S3. Isso FileSink falha com uma das duas exceções a seguir.

  ```
  java.lang.UnsupportedOperationException: Recoverable writers on Hadoop are only supported for HDFS
  ```

  ```
  Caused by: java.lang.NoSuchMethodError: org.apache.hadoop.io.retry.RetryPolicies.retryOtherThanRemoteAndSaslException(Lorg/apache/hadoop/io/retry/RetryPolicy;Ljava/util/Map;)Lorg/apache/hadoop/io/retry/RetryPolicy;
                                          at org.apache.hadoop.yarn.client.RMProxy.createRetryPolicy(RMProxy.java:302) ~[hadoop-yarn-common-3.3.3-amzn-0.jar:?]
  ```

  Como solução alternativa, você pode instalar um patch do Amazon EMR, que corrige o problema acima no Flink. Para aplicar a ação de bootstrap quando iniciar o cluster, execute as etapas a seguir.

  1. Baixe o flink-rpm no bucket Amazon S3. Seu caminho de RPM é `s3://DOC-EXAMPLE-BUCKET/rpms/flink/`.

  1. Baixe o script de bootstrap e os arquivos RPM do Amazon S3 usando o URI a seguir. `regionName`Substitua pelo Região da AWS local em que você planeja iniciar o cluster.

     ```
     s3://emr-data-access-control-regionName/customer-bootstrap-actions/gcsc/replace-rpms.sh
     ```

  1. O Hadoop 3.3.3 introduziu uma alteração no YARN ([YARN-9608](https://issues.apache.org/jira/browse/YARN-9608)) que mantém os nós em que os contêineres eram executados em um estado de desativação até que a aplicação seja concluída. Essa alteração garante que dados locais, como dados embaralhados, não sejam perdidos e que você não precise executar o trabalho novamente. Nas versões 6.8.0 e 6.9.0 do Amazon EMR, essa abordagem também pode levar à subutilização de recursos em clusters com ou sem o ajuste de escala gerenciado habilitado.

     Com o [Amazon EMR 6.10.0](emr-6100-release.md#emr-6100-relnotes), há uma solução alternativa para esse problema: definir o valor de `yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-applications` como `false` em `yarn-site.xml`. Nas versões 6.11.0 e superiores do Amazon EMR, além das versões 6.8.1, 6.9.1 e 6.10.1, o config é definido como `false` por padrão para resolver esse problema.

**Alterações, melhorias e problemas resolvidos**
+ Para as versões 6.9.0 e posteriores do Amazon EMR, todos os componentes instalados pelo Amazon EMR que usam bibliotecas do Log4j usam o Log4j versão 2.17.1 ou posterior.
+ Ao usar o conector DynamoDB com o Spark nas versões 6.6.0, 6.7.0 e 6.8.0 do Amazon EMR, todas as leituras da tabela retornam um resultado vazio, mesmo que a divisão de entrada faça referência a dados que não estão vazios. A versão 6.9.0 do Amazon EMR corrige esse problema.
+ O Amazon EMR 6.9.0 adiciona suporte limitado ao controle de acesso baseado no Lake Formation com o Apache Hudi ao ler dados usando o Spark SQL. O suporte se destina a consultas SELECT usando o Spark SQL e é limitado ao controle de acesso em nível de coluna. Para obter mais informações, consulte [Hudi e Lake Formation](https://docs.aws.amazon.com/emr/latest/ManagementGuide/hudi-with-lake-formation.html).
+ Quando você usa o Amazon EMR 6.9.0 para criar um cluster do Hadoop com [Rótulos de nós](https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/NodeLabel.html) habilitados, a [API de métricas do YARN](https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/ResourceManagerRest.html#Cluster_Metrics_API) retorna informações agregadas em todas as partições, em vez de na partição padrão. Para obter mais informações, consulte [YARN-11414](https://issues.apache.org/jira/browse/YARN-11414).
+ Com a versão 6.9.0 do Amazon EMR, atualizamos o Trino para a versão 398, que usa Java 17. A versão anterior do Trino compatível com o Amazon EMR 6.8.0 era Trino 388 em execução no Java 11. Para obter mais informações sobre essa alteração, consulte [Atualizações do Trino para Java 17](https://trino.io/blog/2022/07/14/trino-updates-to-java-17.html) no blog do Trino.
+ Esta versão corrige um problema de incompatibilidade de sequência de tempo entre o Apache BigTop e o Amazon EMR na sequência de inicialização do cluster EC2. Essa incompatibilidade de sequência de tempo ocorre quando um sistema tenta realizar duas ou mais operações ao mesmo tempo em vez de fazê-las na sequência correta. Como resultado, determinadas configurações de cluster apresentaram tempos limite de inicialização da instância e tempos de inicialização do cluster mais lentos.
+ Quando você inicia um cluster com a *versão de patch mais recente* do Amazon EMR 5.36 ou superior, 6.6 ou superior ou 7.0 ou superior, o Amazon EMR usa a versão mais recente do Amazon Linux 2023 ou do Amazon Linux 2 para a AMI padrão do Amazon EMR. Para obter mais informações, consulte [Como usar a AMI padrão do Amazon Linux para Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).
**nota**  
Essa versão não recebe mais atualizações automáticas da AMI, pois foi substituída por uma ou mais versões de patch. A versão de patch é indicada pelo número após o segundo ponto decimal (`6.8.1`). Para ver se você está usando a versão de patch mais recente, verifique as versões disponíveis no [https://docs.aws.amazon.com/emr/latest/ReleaseGuide](https://docs.aws.amazon.com/emr/latest/ReleaseGuide) ou verifique o menu suspenso de **versões do Amazon EMR** quando criar um cluster no console ou use a ação de API [https://docs.aws.amazon.com/emr/latest/APIReference/API_ListReleaseLabels.html](https://docs.aws.amazon.com/emr/latest/APIReference/API_ListReleaseLabels.html) ou da CLI [https://docs.aws.amazon.com/cli/latest/reference/emr/list-release-labels.html](https://docs.aws.amazon.com/cli/latest/reference/emr/list-release-labels.html). Para obter atualizações sobre novas versões, assine o feed RSS na página [Novidades](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-whatsnew.html).    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew-history.html)

## Versão 6.8.0
<a name="emr-680-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 6.8.0 do Amazon EMR. As alterações são referentes à versão 6.7.0.

**Novos atributos**
+ O recurso de etapas do Amazon EMR agora oferece suporte a endpoints e clientes Apache Livy. JDBC/ODBC Para obter mais informações, consulte [Configurar funções de runtime para as etapas do Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-steps-runtime-roles.html).
+ A versão 6.8.0 do Amazon EMR vem com a versão 2.4.12 do Apache. HBase Com essa HBase versão, você pode arquivar e excluir suas HBase tabelas. O processamento de arquivos do Amazon S3 renomeia todos os arquivos da tabela para o diretório de arquivos. Isso pode ser um processo custoso e demorado. Agora, você pode pular o processamento de arquivos e rapidamente eliminar e excluir tabelas grandes. Para obter mais informações, consulte [Usando a HBase concha](emr-hbase-connect.md).

**Problemas conhecidos**
+ O Hadoop 3.3.3 introduziu uma alteração no YARN ([YARN-9608](https://issues.apache.org/jira/browse/YARN-9608)) que mantém os nós em que os contêineres eram executados em um estado de desativação até que a aplicação seja concluída. Essa alteração garante que dados locais, como dados embaralhados, não sejam perdidos e que você não precise executar o trabalho novamente. Nas versões 6.8.0 e 6.9.0 do Amazon EMR, essa abordagem também pode levar à subutilização de recursos em clusters com ou sem o ajuste de escala gerenciado habilitado.

  Com o [Amazon EMR 6.10.0](emr-6100-release.md#emr-6100-relnotes), há uma solução alternativa para esse problema: definir o valor de `yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-applications` como `false` em `yarn-site.xml`. Nas versões 6.11.0 e superiores do Amazon EMR, além das versões 6.8.1, 6.9.1 e 6.10.1, o config é definido como `false` por padrão para resolver esse problema.

**Alterações, melhorias e problemas resolvidos**
+ Quando a versão 6.5.0, 6.6.0 ou 6.7.0 do Amazon EMR leu as tabelas do Apache Phoenix por meio do shell do Apache Spark, o Amazon EMR produziu um `NoSuchMethodError`. A versão 6.8.0 do Amazon EMR corrige esse problema.
+ A versão 6.8.0 do Amazon EMR vem com o [Apache Hudi](https://hudi.apache.org/) 0.11.1; no entanto, os clusters do Amazon EMR 6.8.0 também são compatíveis com o código aberto `hudi-spark3.3-bundle_2.12` do Hudi 0.12.0.
+ A versão 6.8.0 do Amazon EMR vem com a versão 3.3.0 do Apache Spark. Esta versão do Spark usa o Apache Log4j 2 e o arquivo `log4j2.properties` para configurar o Log4j nos processos do Spark. Se você usar o Spark no cluster ou criar clusters do EMR com parâmetros de configuração personalizados e quiser atualizar para a versão 6.8.0 do Amazon EMR, deverá migrar para a nova classificação de configuração `spark-log4j2` e para o formato de chave do Apache Log4j 2. Para obter mais informações, consulte [Migrar do Apache Log4j 1.x para Log4j 2.x](emr-spark-configure.md#spark-migrate-logj42).
+ Quando você inicia um cluster com a *versão de patch mais recente* do Amazon EMR 5.36 ou superior, 6.6 ou superior ou 7.0 ou superior, o Amazon EMR usa a versão mais recente do Amazon Linux 2023 ou do Amazon Linux 2 para a AMI padrão do Amazon EMR. Para obter mais informações, consulte [Como usar a AMI padrão do Amazon Linux para Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).
**nota**  
Essa versão não recebe mais atualizações automáticas da AMI, pois foi substituída por uma ou mais versões de patch. A versão de patch é indicada pelo número após o segundo ponto decimal (`6.8.1`). Para ver se você está usando a versão de patch mais recente, verifique as versões disponíveis no [https://docs.aws.amazon.com/emr/latest/ReleaseGuide](https://docs.aws.amazon.com/emr/latest/ReleaseGuide) ou verifique o menu suspenso de **versões do Amazon EMR** quando criar um cluster no console ou use a ação de API [https://docs.aws.amazon.com/emr/latest/APIReference/API_ListReleaseLabels.html](https://docs.aws.amazon.com/emr/latest/APIReference/API_ListReleaseLabels.html) ou da CLI [https://docs.aws.amazon.com/cli/latest/reference/emr/list-release-labels.html](https://docs.aws.amazon.com/cli/latest/reference/emr/list-release-labels.html). Para obter atualizações sobre novas versões, assine o feed RSS na página [Novidades](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-whatsnew.html).    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew-history.html)

**Problemas conhecidos**
+ Ao usar o conector DynamoDB com o Spark nas versões 6.6.0, 6.7.0 e 6.8.0 do Amazon EMR, todas as leituras da tabela retornam um resultado vazio, mesmo que a divisão de entrada faça referência a dados que não estão vazios. Isso ocorre porque o Spark 3.2.0 define `spark.hadoopRDD.ignoreEmptySplits` como `true` por padrão. Como solução alternativa, defina explicitamente `spark.hadoopRDD.ignoreEmptySplits` como `false`. A versão 6.9.0 do Amazon EMR corrige esse problema.
+ 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\$1002F). Por exemplo, o caractere de espaço (U\$10020) 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](https://www.utf8-chartable.de/).

  Como solução alternativa para esse problema, defina a configuração `spark.sql.sources.fastS3PartitionDiscovery.enabled` como `false` na classificação `spark-defaults`.
+ Com as versões 5.36.0 e 6.6.0 a 6.9.0 do Amazon EMR, os componentes do serviço `SecretAgent` e `RecordServer` podem sofrer perda de dados de log devido a uma configuração incorreta do padrão de nome de arquivo nas propriedades do Log4j2. A configuração incorreta faz com que os componentes gerem somente um arquivo de log por dia. Quando a estratégia de rotação ocorre, ela substitui o arquivo existente em vez de gerar um novo arquivo de log, conforme esperado. Como solução alternativa, use uma ação de bootstrap para gerar arquivos de log a cada hora e acrescentar um número inteiro de incremento automático no nome do arquivo para lidar com a rotação.

  Para as versões 6.6.0 a 6.9.0 do Amazon EMR, use a seguinte ação de bootstrap ao iniciar um cluster. 

  ```
  ‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-6x/replace-puppet.sh,Args=[]"
  ```

  Para o Amazon EMR 5.36.0, use a ação de bootstrap a seguir ao iniciar um cluster.

  ```
  ‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-5x/replace-puppet.sh,Args=[]"
  ```

Para obter mais informações sobre o cronograma da versão, consulte o [log de alterações](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-680-release.html#680-changelog).

## Versão 6.7.0
<a name="emr-670-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 6.7.0 do Amazon EMR. As alterações são referentes à versão 6.6.0.

Data da versão inicial: 15 de julho de 2022

**Novos atributos**
+ O Amazon EMR agora é compatível com Apache Spark 3.2.1, Apache Hive 3.1.3, HUDI 0.11, PrestoDB 0.272 e Trino 0.378.
+ Ele é compatível com controles de acesso baseados em Perfil do IAM e Lake Formation com etapas do EMR (Spark, Hive) para Amazon EMR em clusters do EC2.
+ Ele é compatível com instruções de definição de dados do Apache Spark em clusters habilitados para Apache Ranger. Isso agora inclui suporte para aplicações do Trino lendo e gravando metadados do Apache Hive em clusters habilitados para Apache Ranger. Para obter mais informações, consulte [Habilitar governança federada usando Trino e Apache Ranger no Amazon EMR](https://aws.amazon.com/blogs/big-data/enable-federated-governance-using-trino-and-apache-ranger-on-amazon-emr/).
+ Quando você inicia um cluster com a *versão de patch mais recente* do Amazon EMR 5.36 ou superior, 6.6 ou superior ou 7.0 ou superior, o Amazon EMR usa a versão mais recente do Amazon Linux 2023 ou do Amazon Linux 2 para a AMI padrão do Amazon EMR. Para obter mais informações, consulte [Como usar a AMI padrão do Amazon Linux para Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew-history.html)

**Problemas conhecidos**
+ Quando a versão 6.5.0, 6.6.0 ou 6.7.0 do Amazon EMR lê as tabelas do Apache Phoenix por meio do shell do Apache Spark, ocorre um `NoSuchMethodError` porque o Amazon EMR usa um `Hbase.compat.version` incorreto. A versão 6.8.0 do Amazon EMR corrige esse problema.
+ Ao usar o conector DynamoDB com o Spark nas versões 6.6.0, 6.7.0 e 6.8.0 do Amazon EMR, todas as leituras da tabela retornam um resultado vazio, mesmo que a divisão de entrada faça referência a dados que não estão vazios. Isso ocorre porque o Spark 3.2.0 define `spark.hadoopRDD.ignoreEmptySplits` como `true` por padrão. Como solução alternativa, defina explicitamente `spark.hadoopRDD.ignoreEmptySplits` como `false`. A versão 6.9.0 do Amazon EMR corrige esse problema.
+ 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\$1002F). Por exemplo, o caractere de espaço (U\$10020) 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](https://www.utf8-chartable.de/).

  Como solução alternativa para esse problema, defina a configuração `spark.sql.sources.fastS3PartitionDiscovery.enabled` como `false` na classificação `spark-defaults`.
+ Com as versões 5.36.0 e 6.6.0 a 6.9.0 do Amazon EMR, os componentes do serviço `SecretAgent` e `RecordServer` podem sofrer perda de dados de log devido a uma configuração incorreta do padrão de nome de arquivo nas propriedades do Log4j2. A configuração incorreta faz com que os componentes gerem somente um arquivo de log por dia. Quando a estratégia de rotação ocorre, ela substitui o arquivo existente em vez de gerar um novo arquivo de log, conforme esperado. Como solução alternativa, use uma ação de bootstrap para gerar arquivos de log a cada hora e acrescentar um número inteiro de incremento automático no nome do arquivo para lidar com a rotação.

  Para as versões 6.6.0 a 6.9.0 do Amazon EMR, use a seguinte ação de bootstrap ao iniciar um cluster. 

  ```
  ‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-6x/replace-puppet.sh,Args=[]"
  ```

  Para o Amazon EMR 5.36.0, use a ação de bootstrap a seguir ao iniciar um cluster.

  ```
  ‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-5x/replace-puppet.sh,Args=[]"
  ```
+ A API `GetClusterSessionCredentials` não é compatível com clusters executados no Amazon EMR 6.7 ou versões inferiores.
+ Os seguintes commits do Hadoop foram retroportados.

  - [[HADOOP-16080]](https://issues.apache.org/jira/browse/HADOOP-16080) Corrigido o problema em que `hadoop-aws` não funciona com `hadoop-client-api`.

  - [[HADOOP-18237]](https://issues.apache.org/jira/browse/HADOOP-18237) Upgrade para a versão 2.12.2 do Apache Xerces Java.

  - [[YARN-11092]](https://issues.apache.org/jira/browse/YARN-11092) Upgrade do jquery para ui para 1.13.1.

  - [[YARN-10720]](https://issues.apache.org/jira/browse/YARN-10720) O YARN WebAppProxyServlet deve suportar o tempo limite de conexão para evitar que o servidor proxy trave.

## Versão 6.6.0
<a name="emr-660-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 6.6.0 do Amazon EMR. As alterações são referentes à versão 6.5.0.

Data da versão inicial: 9 de maio de 2022

Data da documentação atualizada: 15 de junho de 2022

**Novos atributos**
+ O Amazon EMR 6.6 agora é compatível com Apache Spark 3.2, Apache Spark RAPIDS 22.02, CUDA 11, Apache Hudi 0.10.1, Apache Iceberg 0.13, Trino 0.367 e PrestoDB 0.267.
+ Quando você inicia um cluster com a *versão de patch mais recente* do Amazon EMR 5.36 ou superior, 6.6 ou superior ou 7.0 ou superior, o Amazon EMR usa a versão mais recente do Amazon Linux 2023 ou do Amazon Linux 2 para a AMI padrão do Amazon EMR. Para obter mais informações, consulte [Como usar a AMI padrão do Amazon Linux para Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew-history.html)
+ Com as versões 6.6 e posteriores do Amazon EMR,as aplicações que usam o Log4j 1.x e o Log4j 2.x são atualizadas para usar o Log4j 1.2.17 (ou superior) e o Log4j 2.17.1 (ou superior), respectivamente, e não exigem o uso de [ações de bootstrap](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-log4j-vulnerability.html) para mitigar os problemas de CVE.
+ **[Ajuste de escala gerenciado] Otimização do ajuste de escala gerenciado de dados embaralhados do Spark**: para as versões 5.34.0 e posteriores do Amazon EMR e as versões 6.4.0 e posteriores do EMR, o ajuste de escala gerenciado agora reconhece dados embaralhados do Spark (dados que o Spark redistribui entre partições para executar operações específicas). Para obter mais informações sobre operações de shuffle, consulte [Usar ajuste de escala gerenciado do EMR no Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-scaling.html) no *Guia de gerenciamento do Amazon EMR* e no [Guia de programação do Spark](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations).
+ Desde as versões 5.32.0 e 6.5.0 do Amazon EMR, o dimensionamento do executor dinâmico para o Apache Spark está habilitado por padrão. Para ativar ou desativar esse atributo, você pode usar o parâmetro de configuração `spark.yarn.heterogeneousExecutors.enabled`.

**Alterações, melhorias e problemas resolvidos**
+ O Amazon EMR reduz o tempo de inicialização do cluster em até 80 segundos, em média, para clusters que usam a opção de AMI padrão do EMR e só instalam aplicações comuns, como Apache Hadoop, Apache Spark e Apache Hive.

**Problemas conhecidos**
+ Quando a versão 6.5.0, 6.6.0 ou 6.7.0 do Amazon EMR lê as tabelas do Apache Phoenix por meio do shell do Apache Spark, ocorre um `NoSuchMethodError` porque o Amazon EMR usa um `Hbase.compat.version` incorreto. A versão 6.8.0 do Amazon EMR corrige esse problema.
+ Ao usar o conector DynamoDB com o Spark nas versões 6.6.0, 6.7.0 e 6.8.0 do Amazon EMR, todas as leituras da tabela retornam um resultado vazio, mesmo que a divisão de entrada faça referência a dados que não estão vazios. Isso ocorre porque o Spark 3.2.0 define `spark.hadoopRDD.ignoreEmptySplits` como `true` por padrão. Como solução alternativa, defina explicitamente `spark.hadoopRDD.ignoreEmptySplits` como `false`. A versão 6.9.0 do Amazon EMR corrige esse problema.
+ Em clusters de execução prolongada do Trino, o Amazon EMR 6.6.0 habilita os parâmetros de registro em log da coleta de resíduos no jvm.config do Trino para obter melhores insights dos registros em log da coleta de resíduos. Essa alteração anexa muitos registros da coleta de lixo ao arquivo launcher.log (/var/log/trino/launcher.log). Se você estiver executando clusters do Trino no Amazon EMR 6.6.0, poderá encontrar nós que perderão espaço em disco depois que o cluster estiver em execução por alguns dias devido aos logs anexados.

  A solução alternativa para esse problema é executar o script abaixo como uma ação de bootstrap para desativar os parâmetros de registro em log da coleta de resíduos no jvm.config ao criar ou clonar o cluster para o Amazon EMR 6.6.0.

  ```
  #!/bin/bash
    set -ex
    PRESTO_PUPPET_DIR='/var/aws/emr/bigtop-deploy/puppet/modules/trino'
    sudo bash -c "sed -i '/-Xlog/d' ${PRESTO_PUPPET_DIR}/templates/jvm.config"
  ```
+ 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\$1002F). Por exemplo, o caractere de espaço (U\$10020) 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](https://www.utf8-chartable.de/).

  Como solução alternativa para esse problema, defina a configuração `spark.sql.sources.fastS3PartitionDiscovery.enabled` como `false` na classificação `spark-defaults`.
+ Com as versões 5.36.0 e 6.6.0 a 6.9.0 do Amazon EMR, os componentes do serviço `SecretAgent` e `RecordServer` podem sofrer perda de dados de log devido a uma configuração incorreta do padrão de nome de arquivo nas propriedades do Log4j2. A configuração incorreta faz com que os componentes gerem somente um arquivo de log por dia. Quando a estratégia de rotação ocorre, ela substitui o arquivo existente em vez de gerar um novo arquivo de log, conforme esperado. Como solução alternativa, use uma ação de bootstrap para gerar arquivos de log a cada hora e acrescentar um número inteiro de incremento automático no nome do arquivo para lidar com a rotação.

  Para as versões 6.6.0 a 6.9.0 do Amazon EMR, use a seguinte ação de bootstrap ao iniciar um cluster. 

  ```
  ‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-6x/replace-puppet.sh,Args=[]"
  ```

  Para o Amazon EMR 5.36.0, use a ação de bootstrap a seguir ao iniciar um cluster.

  ```
  ‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-5x/replace-puppet.sh,Args=[]"
  ```

## Versão 5.35.0
<a name="emr-5350-whatsnew"></a>

Esta é a nota de lançamento da versão 5.35.0 do Amazon EMR.

As notas da versão a seguir incluem informações para a versão 5.35.0 do Amazon EMR. As alterações são referentes à versão 5.34.0.

Data da versão inicial: 30 de março de 2022

**Novos atributos**
+ As aplicações da versão 5.35 do Amazon EMR que usam o Log4j 1.x e o Log4j 2.x são atualizadas para usar o Log4j 1.2.17 (ou superior) e o Log4j 2.17.1 (ou superior), respectivamente, e não exigem o uso de ações de bootstrap para mitigar os problemas de CVE em versões anteriores. Consulte [Abordagem para mitigar o CVE-2021-44228](emr-log4j-vulnerability.md).

**Alterações, melhorias e problemas resolvidos**


**Alterações no Flink**  

| Alterar tipo | Description | 
| --- | --- | 
| Atualizações | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew-history.html) | 


**Alterações no Hadoop**  

| Alterar tipo | Description | 
| --- | --- | 
| Backports de código aberto do Hadoop desde o EMR 5.34.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew-history.html) | 
| Alterações e correções no Hadoop | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew-history.html) | 


**Alterações no Hive**  

| Alterar tipo | Description | 
| --- | --- | 
| O Hive foi atualizado para a [versão 2.3.9](https://www.mail-archive.com/user@hive.apache.org/msg22311.html) de código aberto, incluindo estas correções do JIRA | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew-history.html) | 
| Backports de código aberto do Hive desde o EMR 5.34.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew-history.html) | 
| Atualizações e correções do Hive | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew-history.html) | 
| Novos recursos | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew-history.html) | 


**Alterações no Oozie**  

| Alterar tipo | Description | 
| --- | --- | 
| Backports de código aberto do Oozie desde o EMR 5.34.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew-history.html) | 


**Alterações no Pig**  

| Alterar tipo | Description | 
| --- | --- | 
| Atualizações | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew-history.html) | 

**Problemas conhecidos**
+ 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\$1002F). Por exemplo, o caractere de espaço (U\$10020) 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](https://www.utf8-chartable.de/).

  Como solução alternativa para esse problema, defina a configuração `spark.sql.sources.fastS3PartitionDiscovery.enabled` como `false` na classificação `spark-defaults`.

## Versão 5.34.0
<a name="emr-5340-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.34.0 do Amazon EMR. As alterações são referentes à versão 5.33.1.

Data da versão inicial: 20 de janeiro de 2022

Data da versão atualizada: 21 de março de 2022

**Novos atributos**
+ **[Ajuste de escala gerenciado] Otimização do ajuste de escala gerenciado de dados embaralhados do Spark**: para as versões 5.34.0 e posteriores do Amazon EMR e as versões 6.4.0 e posteriores do EMR, o ajuste de escala gerenciado agora reconhece dados embaralhados do Spark (dados que o Spark redistribui entre partições para executar operações específicas). Para obter mais informações sobre operações de shuffle, consulte [Usar ajuste de escala gerenciado do EMR no Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-scaling.html) no *Guia de gerenciamento do Amazon EMR* e no [Guia de programação do Spark](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations).
+ [Hudi] Melhorias para simplificar a configuração do Hudi. Desabilitado o controle de simultaneidade otimista por padrão.

**Alterações, melhorias e problemas resolvidos**
+ Esta é uma versão para corrigir problemas com o Amazon EMR Scaling quando ele não consegue up/scale reduzir a escala de um cluster com sucesso ou causa falhas no aplicativo.
+ Anteriormente, a reinicialização manual do gerenciador de recursos em um cluster multimestre fazia com que os daemons do Amazon EMR no cluster, como o Zookeeper, recarregassem todos os nós anteriormente desativados ou perdidos no arquivo znode do Zookeeper. Isso fez com que os limites padrão fossem excedidos em determinadas situações. O Amazon EMR agora remove os registros de nós desativados ou perdidos há mais de uma hora do arquivo do Zookeeper e os limites internos foram aumentados.
+ 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](https://issues.apache.org/jira/browse/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](https://issues.apache.org/jira/browse/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 no cluster do Amazon EMR não renovou o tíquete Kerberos, que é necessário para se comunicar com segurança com a execução no nó primário. HDFS/YARN 
+ Zeppelin atualizado para a versão 0.10.0.
+ Livy Fix: atualizado para 0.7.1
+ Melhoria da performance do Spark: executores heterogêneos são desabilitados quando determinados valores de configuração do Spark são substituídos no EMR 5.34.0.
+ WebHDFS e o servidor HttpFS estão desabilitados por padrão. Você pode reabilitar o WebHDFS usando a configuração do Hadoop, `dfs.webhdfs.enabled`. O servidor HttpFS pode ser iniciado usando `sudo systemctl start hadoop-httpfs`.

**Problemas conhecidos**
+ O atributo Cadernos do Amazon EMR usado com a personificação de usuários do Livy não funciona porque o HttpFS está desabilitado por padrão. Nesse caso, o caderno do EMR não pode se conectar ao cluster que tem a personificação do Livy habilitada. A solução alternativa é iniciar o servidor HttpFS antes de conectar o caderno do EMR ao cluster usando `sudo systemctl start hadoop-httpfs`.
+ As consultas no Hue não funcionam no Amazon EMR 6.4.0 porque o servidor HttpFS do Apache Hadoop está desabilitado por padrão. Para usar o Hue no Amazon EMR 6.4.0, inicie manualmente o servidor HttpFS no nó primário do Amazon EMR usando `sudo systemctl start hadoop-httpfs`, ou [use uma etapa do Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/add-step-cli.html).
+ O atributo Cadernos do Amazon EMR usado com a personificação de usuários do Livy não funciona porque o HttpFS está desabilitado por padrão. Nesse caso, o caderno do EMR não pode se conectar ao cluster que tem a personificação do Livy habilitada. A solução alternativa é iniciar o servidor HttpFS antes de conectar o caderno do EMR ao cluster usando `sudo systemctl start hadoop-httpfs`.
+ 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\$1002F). Por exemplo, o caractere de espaço (U\$10020) 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](https://www.utf8-chartable.de/).

  Como solução alternativa para esse problema, defina a configuração `spark.sql.sources.fastS3PartitionDiscovery.enabled` como `false` na classificação `spark-defaults`.

## Versão 6.5.0
<a name="emr-650-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 6.5.0 do Amazon EMR. As alterações são referentes à versão 6.4.0.

Data da versão inicial: 20 de janeiro de 2022

Data da versão atualizada: 21 de março de 2022

**Novos atributos**
+ **[Ajuste de escala gerenciado] Otimização do ajuste de escala gerenciado de dados embaralhados do Spark**: para as versões 5.34.0 e posteriores do Amazon EMR e as versões 6.4.0 e posteriores do EMR, o ajuste de escala gerenciado agora reconhece dados embaralhados do Spark (dados que o Spark redistribui entre partições para executar operações específicas). Para obter mais informações sobre operações de shuffle, consulte [Usar ajuste de escala gerenciado do EMR no Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-scaling.html) no *Guia de gerenciamento do Amazon EMR* e no [Guia de programação do Spark](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations).
+ Desde as versões 5.32.0 e 6.5.0 do Amazon EMR, o dimensionamento do executor dinâmico para o Apache Spark está habilitado por padrão. Para ativar ou desativar esse atributo, você pode usar o parâmetro de configuração `spark.yarn.heterogeneousExecutors.enabled`.
+ Suporte para o formato de tabela aberta Apache Iceberg para conjuntos de dados analíticos imensos.
+ Support para ranger-trino-plugin 2.0.1-amzn-1
+ Suporte para toree 0.5.0

**Alterações, melhorias e problemas resolvidos**
+ A versão de lançamento do Amazon EMR 6.5 agora é compatível com o Apache Iceberg 0.12.0 e fornece melhorias no runtime com o Ambiente de Tempo de Execução do Amazon EMR para Apache Spark, o Ambiente de Tempo de Execução do Amazon EMR para Presto e o Runtime do Amazon EMR para Apache Hive.
+ O [Apache Iceberg](https://iceberg.apache.org/) é um formato de tabela aberta para grandes conjuntos de dados no Amazon S3 que fornece performance rápida de consultas em tabelas grandes, confirmações atômicas, gravações simultâneas e evolução de tabelas compatível com SQL. Com o EMR 6.5, você pode usar o Apache Spark 3.1.2 com o formato de tabela Iceberg.
+ O Apache Hudi 0.9 adiciona suporte a DDL e DML do Spark SQL. Isso permite a criação e a atualização de tabelas do Hudi usando apenas instruções de SQL. O Apache Hudi 0.9 também inclui melhorias na performance do lado da consulta e do lado do gravador.
+ O Runtime do Amazon EMR para Apache Hive melhora a performance do Apache Hive no Amazon S3 ao remover operações de renomeação durante operações de preparação e melhora a performance dos comandos de verificação do metastore (MSCK) usados para reparar tabelas.

**Problemas conhecidos**
+ Quando a versão 6.5.0, 6.6.0 ou 6.7.0 do Amazon EMR lê as tabelas do Apache Phoenix por meio do shell do Apache Spark, ocorre um `NoSuchMethodError` porque o Amazon EMR usa um `Hbase.compat.version` incorreto. A versão 6.8.0 do Amazon EMR corrige esse problema.
+ Os clusters do pacote do Hbase em alta disponibilidade (HA) apresentam falha no provisionamento com o tamanho de volume e o tipo de instância padrão. A solução alternativa para esse problema é aumentar o tamanho do volume raiz.
+ 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\$1002F). Por exemplo, o caractere de espaço (U\$10020) 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](https://www.utf8-chartable.de/).

  Como solução alternativa para esse problema, defina a configuração `spark.sql.sources.fastS3PartitionDiscovery.enabled` como `false` na classificação `spark-defaults`.

## Versão 6.4.0
<a name="emr-640-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 6.4.0 do Amazon EMR. As alterações são referentes à versão 6.3.0.

Data da versão inicial: 20 de setembro de 2021

Data da versão atualizada: 21 de março de 2022

**Aplicações compatíveis**
+ AWS SDK para Java versão 1.12.31
+ CloudWatch Sink versão 2.2.0
+ Conector do DynamoDB versão 4.16.0
+ EMRFS versão 2.47.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.1.0
+ Scripts versão 2.5.0 do Amazon EMR
+ Flink versão 1.13.1
+ Ganglia versão 3.7.2
+ AWS Glue Hive Metastore Client versão 3.3.0
+ Hadoop versão 3.2.1-amzn-4
+ HBase versão 2.4.4-amzn-0
+ HBase-operator-tools 1.1.0
+ HCatalog versão 3.1.2-amzn-5
+ Hive versão 3.1.2-amzn-5
+ Hudi versão 0.8.0-amzn-0
+ Hue versão 4.9.0
+ Java JDK versão Corretto-8.302.08.1 (compilação 1.8.0\$1302-b08)
+ JupyterHub versão 1.4.1
+ Livy versão 0.7.1-incubating
+ MXNet versão 1.8.0
+ Oozie versão 5.2.1
+ Phoenix versão 5.1.2
+ Pig versão 0.17.0
+ Presto versão 0.254.1-amzn-0
+ Trino versão 359
+ KMS do Apache Ranger (criptografia transparente multi-mestre) versão 2.0.0
+ ranger-plugins 2.0.1-amzn-0
+ ranger-s3-plugin 1.2.0
+ SageMaker SDK do Spark versão 1.4.1
+ Scala versão 2.12.10 (VM de servidor OpenJDK de 64 bits, Java 1.8.0\$1282)
+ Spark versão 3.1.2-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.5.7
+ Conectores e drivers: DynamoDB Connector 4.16.0

**Novos recursos**
+ **[Ajuste de escala gerenciado] Otimização do ajuste de escala gerenciado de dados embaralhados do Spark**: para as versões 5.34.0 e posteriores do Amazon EMR e as versões 6.4.0 e posteriores do EMR, o ajuste de escala gerenciado agora reconhece dados embaralhados do Spark (dados que o Spark redistribui entre partições para executar operações específicas). Para obter mais informações sobre operações de shuffle, consulte [Usar ajuste de escala gerenciado do EMR no Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-scaling.html) no *Guia de gerenciamento do Amazon EMR* e no [Guia de programação do Spark](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations).
+ Em clusters do Amazon EMR habilitados para Apache Ranger, você pode usar o Apache Spark SQL para inserir dados ou atualizar as tabelas de metastore do Apache Hive usando `INSERT INTO`, `INSERT OVERWRITE` e `ALTER TABLE`. Ao ser usado ALTER TABLE com Spark SQL, o local da partição deve ser o diretório filho do local de uma tabela. Atualmente,o Amazon EMR não permite a inserção de dados em uma partição cuja localização seja diferente da localização da tabela.
+ O PrestoSQL foi [renomeado como Trino.](https://trino.io/blog/2020/12/27/announcing-trino.html) 
+ Hive: a execução de consultas SELECT simples com a cláusula LIMIT é acelerada com a interrupção da execução da consulta assim que o número de registros mencionados na cláusula LIMIT é obtido. As consultas SELECT simples são consultas que não têm a cláusula GROUP BY/ORDER by ou consultas que não têm um estágio redutor. Por exemplo, .`SELECT * from <TABLE> WHERE <Condition> LIMIT <Number>` 

**Controle de simultaneidade do Hudi**
+ O Hudi, agora, é compatível com o Optimistic Concurrency Control (OCC - Controle de simultaneidade otimista), que pode ser aproveitado com operações de gravação como UPSERT e INSERT para permitir alterações de vários gravadores na mesma tabela do Hudi. Esse é o OCC em nível de arquivo. Portanto, quaisquer duas confirmações (ou gravadores) podem gravar na mesma tabela, se suas alterações não são conflitantes. Para obter mais informações, consulte o [Controle de simultaneidade do Hudi](https://hudi.apache.org/docs/concurrency_control/). 
+ Os clusters do Amazon EMR têm o Zookeeper instalado, que pode ser usado como provedor de bloqueio para o OCC. Para facilitar o uso desse atributo, os clusters do Amazon EMR têm as seguintes propriedades pré-configuradas:

  ```
  hoodie.write.lock.provider=org.apache.hudi.client.transaction.lock.ZookeeperBasedLockProvider
  hoodie.write.lock.zookeeper.url=<EMR Zookeeper URL>
  hoodie.write.lock.zookeeper.port=<EMR Zookeeper Port>
  hoodie.write.lock.zookeeper.base_path=/hudi
  ```

  Para habilitar o OCC, você precisa configurar as seguintes propriedades com as opções de trabalho do Hudi ou em nível de cluster usando a API de configurações do Amazon EMR:

  ```
  hoodie.write.concurrency.mode=optimistic_concurrency_control
  hoodie.cleaner.policy.failed.writes=LAZY (Performs cleaning of failed writes lazily instead of inline with every write)
  hoodie.write.lock.zookeeper.lock_key=<Key to uniquely identify the Hudi table> (Table Name is a good option)
  ```

**Monitoramento Hudi: CloudWatch integração com a Amazon para reportar Hudi Metrics**
+ O Amazon EMR oferece suporte à publicação de Hudi Metrics na Amazon. CloudWatch Isso é habilitado com a definição das seguintes configurações necessárias:

  ```
  hoodie.metrics.on=true
  hoodie.metrics.reporter.type=CLOUDWATCH
  ```
+ A seguir, são mostradas as configurações opcionais do Hudi que você pode alterar:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew-history.html)

**Suporte e melhorias das configurações do Hudi no Amazon EMR**
+ Agora, os clientes podem aproveitar a API de configurações e o atributo de reconfiguração do EMR para definir as configurações do Hudi em nível de cluster. Um novo suporte de configuração baseado em arquivos foi introduzido via/etc/hudi/conf/hudi-defaults.conf nos moldes de outros aplicativos como Spark, Hive etc. O EMR configura alguns padrões para melhorar a experiência do usuário:

  — `hoodie.datasource.hive_sync.jdbcurl ` está configurado para a URL do servidor do Hive do cluster e não precisa mais ser especificado. Isso é particularmente útil na execução de um trabalho no modo de cluster do Spark, em que anteriormente era necessário especificar o IP principal do Amazon EMR. 

  — configurações HBase específicas, que são úteis para usar o HBase índice com o Hudi.

  — Configuração específica do provedor de bloqueio do Zookeeper, conforme discutido em Controle de simultaneidade, o que facilita o uso do Controle de simultaneidade otimista (OCC).
+ Alterações adicionais foram introduzidas para reduzir o número de configurações que você precisa passar e inferir automaticamente sempre que possível:

  — A palavra-chave `partitionBy ` pode ser usada para especificar a coluna de partição. 

  — Ao habilitar o Hive Sync, não é mais obrigatório passar `HIVE_TABLE_OPT_KEY, HIVE_PARTITION_FIELDS_OPT_KEY, HIVE_PARTITION_EXTRACTOR_CLASS_OPT_KEY`. Esses valores podem ser deduzidos com base no nome da tabela Hudi e no campo de partição. 

  — não é obrigatório passar `KEYGENERATOR_CLASS_OPT_KEY`, que pode ser inferido com base em casos mais simples de `SimpleKeyGenerator` e `ComplexKeyGenerator`. 

**Advertências do Hudi**
+ O Hudi não permite execução vetorizada no Hive de tabelas Merge on Read (MoR - Mesclar na leitura) e Bootstrap. Por exemplo, `count(*)` apresenta falha com a tabela do Hudi em tempo real quando `hive.vectorized.execution.enabled` está definido como verdadeiro. Como solução alternativa, você pode desabilitar a leitura vetorizada configurando `hive.vectorized.execution.enabled` como `false`. 
+ O suporte a vários gravadores não é compatível com o atributo de bootstrap do Hudi.
+ O streamer e o SQL do Flink são atributos experimentais nesta versão. Esses atributos não são recomendados para uso em implantações de produção.

**Alterações, melhorias e problemas resolvidos**

Esta é uma versão para corrigir problemas com o Amazon EMR Scaling quando ele não consegue up/scale reduzir a escala de um cluster com sucesso ou causa falhas no aplicativo.
+ Anteriormente, a reinicialização manual do gerenciador de recursos em um cluster multimestre fazia com que os daemons do Amazon EMR no cluster, como o Zookeeper, recarregassem todos os nós anteriormente desativados ou perdidos no arquivo znode do Zookeeper. Isso fez com que os limites padrão fossem excedidos em determinadas situações. O Amazon EMR agora remove os registros de nós desativados ou perdidos há mais de uma hora do arquivo do Zookeeper e os limites internos foram aumentados.
+ 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](https://issues.apache.org/jira/browse/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](https://issues.apache.org/jira/browse/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 no cluster do Amazon EMR não renovou o tíquete Kerberos, que é necessário para se comunicar com segurança com a execução no nó primário. HDFS/YARN 
+ **Configurar um cluster para corrigir problemas de desempenho do servidor de linha do tempo do Apache YARN versões 1 e 1.5**

  As versões 1 e 1.5 do servidor de linha do tempo do Apache YARN podem causar problemas de performance com clusters do EMR muito ativos e grandes, especialmente com `yarn.resourcemanager.system-metrics-publisher.enabled=true`, que é a configuração padrão no Amazon EMR. Um servidor de linha do tempo do YARN v2 de código aberto resolve o problema de performance relacionado à escalabilidade do servidor de linha do tempo do YARN.

  Outras soluções alternativas para esse problema incluem:
  + Configurando yarn.resourcemanager. system-metrics-publisher.enabled=false em yarn-site.xml.
  + Habilitar a correção para esse problema na criação de um cluster, conforme descrito abaixo.

  As seguintes versões do Amazon EMR contêm uma correção para esse problema de performance do servidor de linha do tempo do YARN.

  EMR 5.30.2, 5.31.1, 5.32.1, 5.33.1, 5.34.x, 6.0.1, 6.1.1, 6.2.1, 6.3.1, 6.4.x

  Para habilitar a correção em qualquer uma das versões do Amazon EMR especificadas acima, defina essas propriedades como `true` em um arquivo JSON de configurações que é passado usando o [parâmetro de comando `aws emr create-cluster`](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps-create-cluster.html): `--configurations file://./configurations.json`. Ou habilite a correção usando a [interface do usuário do console de reconfiguração](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps-running-cluster.html).

  Exemplo de conteúdo do arquivo configurations.json:

  ```
  [
  {
  "Classification": "yarn-site",
  "Properties": {
  "yarn.resourcemanager.system-metrics-publisher.timeline-server-v1.enable-batch": "true",
  "yarn.resourcemanager.system-metrics-publisher.enabled": "true"
  },
  "Configurations": []
  }
  ]
  ```
+ WebHDFS e o servidor HttpFS estão desabilitados por padrão. Você pode reabilitar o WebHDFS usando a configuração do Hadoop, `dfs.webhdfs.enabled`. O servidor HttpFS pode ser iniciado usando `sudo systemctl start hadoop-httpfs`.
+ O HTTPS agora está habilitado por padrão para repositórios do Amazon Linux. Se você estiver usando uma política de VPCE do Amazon S3 para restringir o acesso a buckets específicos, deverá adicionar o novo ARN `arn:aws:s3:::amazonlinux-2-repos-$region/*` do bucket do Amazon Linux à sua política (substitua `$region` pela região em que o endpoint está situado). Para obter mais informações, consulte esse tópico nos fóruns de AWS discussão. [Anúncio: o Amazon Linux 2 agora oferece suporte à capacidade de usar HTTPS ao se conectar a repositórios de pacotes ](https://forums.aws.amazon.com/ann.jspa?annID=8528). 
+ Hive: a performance da consulta de gravação foi aprimorada ao ser permitido o uso de um diretório temporário no HDFS para o último trabalho. Os dados temporários do trabalho final são gravados no HDFS em vez de no Amazon S3 e a performance é melhorada porque os dados são movidos do HDFS para a localização da tabela final (Amazon S3) em vez de entre dispositivos do Amazon S3.
+ Hive: melhoria do tempo de compilação de consultas em até 2,5 vezes com a remoção de partições de metastores do Glue.
+ Por padrão, quando UDFs os integrados são passados pelo Hive para o Hive Metastore Server, somente um subconjunto desses incorporados é UDFs passado para o Glue Metastore, já que o Glue suporta apenas operadores de expressão limitados. Se você definir `hive.glue.partition.pruning.client=true`, toda a remoção de partições ocorrerá no lado do cliente. Se você definir `hive.glue.partition.pruning.server=true`, toda a remoção de partições ocorrerá no lado do servidor. 

**Problemas conhecidos**
+ As consultas no Hue não funcionam no Amazon EMR 6.4.0 porque o servidor HttpFS do Apache Hadoop está desabilitado por padrão. Para usar o Hue no Amazon EMR 6.4.0, inicie manualmente o servidor HttpFS no nó primário do Amazon EMR usando `sudo systemctl start hadoop-httpfs`, ou [use uma etapa do Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/add-step-cli.html).
+ O atributo Cadernos do Amazon EMR usado com a personificação de usuários do Livy não funciona porque o HttpFS está desabilitado por padrão. Nesse caso, o caderno do EMR não pode se conectar ao cluster que tem a personificação do Livy habilitada. A solução alternativa é iniciar o servidor HttpFS antes de conectar o caderno do EMR ao cluster usando `sudo systemctl start hadoop-httpfs`.
+ Na versão 6.4.0 do Amazon EMR, o Phoenix não é compatível com o componente de conectores do Phoenix.
+ 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\$1002F). Por exemplo, o caractere de espaço (U\$10020) 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](https://www.utf8-chartable.de/).

  Como solução alternativa para esse problema, defina a configuração `spark.sql.sources.fastS3PartitionDiscovery.enabled` como `false` na classificação `spark-defaults`.

## Versão 5.32.0
<a name="emr-5320-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.32.0 do Amazon EMR. As alterações são referentes à versão 5.31.0.

Data da versão inicial: 8 de janeiro de 2021

**Atualizações**
+ Atualizado o conector do Amazon Glue para a versão 1.14.0
+ SDK do Amazon SageMaker Spark atualizado para a versão 1.4.1
+ Atualizado para AWS SDK para Java a versão 1.11.890
+ Atualizado o conector do DynamoDB para EMR, versão 4.16.0
+ Atualizado o EMRFS para a versão 2.45.0
+ Atualizadas as métricas de analytics de log do EMR para a versão 1.18.0
+ Cliente MetricsAndEventsApiGateway EMR atualizado para a versão 1.5.0
+ Atualizado o servidor de registros do EMR para a versão 1.8.0
+ Atualizado o EMR S3 Dist CP para a versão 2.17.0
+ Atualizado o agente secreto do EMR para a versão 1.7.0
+ Atualizado o Flink para a versão 1.11.2
+ Atualizado o Hadoop para a versão 2.10.1-amzn-0
+ Atualizado o Hive para a versão 2.3.7-amzn-3
+ Atualizado o Hue para a versão 4.8.0
+ Atualizado o Mxnet para a versão 1.7.0
+ Atualizado o OpenCV para a versão 4.4.0
+ Atualizado o Presto para a versão 0.240.1-amzn-0
+ Atualizado o Spark para a versão 2.4.7-amnz-0
+ Atualizado TensorFlow para a versão 2.3.1

**Alterações, melhorias e problemas resolvidos**
+ Esta é uma versão para corrigir problemas com o Amazon EMR Scaling quando ele não consegue up/scale reduzir a 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 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](https://issues.apache.org/jira/browse/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](https://issues.apache.org/jira/browse/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 no cluster do Amazon EMR não renovou o tíquete Kerberos, que é necessário para se comunicar com segurança com a execução no nó primário. HDFS/YARN 
+ As versões mais recentes do Amazon EMR corrigem o problema com um limite menor de “Máximo de arquivos abertos” em relação às versões mais antigas AL2 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”.
+ Atualizadas versões do componente.
+ Para obter uma lista das versões do componente, consulte [Sobre versões do Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-release-components.html) neste guia.

**Novos recursos**
+ Desde as versões 5.32.0 e 6.5.0 do Amazon EMR, o dimensionamento do executor dinâmico para o Apache Spark está habilitado por padrão. Para ativar ou desativar esse atributo, você pode usar o parâmetro de configuração `spark.yarn.heterogeneousExecutors.enabled`.
+ Status de suporte do Instance Metadata Service (IMDS) V2: os componentes do Amazon EMR 5.23.1, 5.27.1 e 5.32 ou posteriores são usados para todas as chamadas do IMDS. IMDSv2 Para chamadas IMDS no código do aplicativo, você pode usar ambos IMDSv1 e IMDSv2, ou configurar o IMDS para uso somente IMDSv2 para aumentar a segurança. Para outras versões 5.x do EMR, a IMDSv1 desativação causa falha na inicialização do cluster.
+ Desde a versão 5.32.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](https://ranger.apache.org/). 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](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-ranger.html) no *Guia de lançamento do Amazon EMR*.
+ A versão 5.32.0 do Amazon EMR é compatível com o Amazon EMR no EKS. Para obter mais detalhes sobre os conceitos básicos do EMR no EKS, consulte [O que é o Amazon EMR no EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks.html).
+ A versão 5.32.0 do Amazon EMR é compatível com o Amazon EMR Studio (versão de demonstração). Para obter mais detalhes sobre os conceitos básicos do EMR Studio, consulte [Amazon EMR Studio (versão de demonstração)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-studio.html).
+ Políticas gerenciadas com escopo definido: para se alinhar às AWS melhores práticas, 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](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-iam-policies.html).

**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)”. Outros sites UIs, como Spark, Hue, Zeppelin JupyterHub, 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.
+ **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`

  1. 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**  
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](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-custom-ami.html) para [usar a AMI do Amazon Linux mais recente](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/finding-an-ami.html).
+ O suporte do console para criar uma configuração de segurança que especifica a opção de integração do AWS Ranger atualmente não é suportado na GovCloud região. A configuração de segurança do pode ser feita usando a CLI. Consulte [Criar a configuração de segurança do EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-ranger-security-config.html) no *Guia de gerenciamento do Amazon EMR.*
+ Quando AtRestEncryption a criptografia HDFS é habilitada em um cluster que usa o Amazon EMR 5.31.0 ou 5.32.0, as consultas do Hive resultam na seguinte exceção de tempo de execução.

  ```
  TaskAttempt 3 failed, info=[Error: Error while running task ( failure ) : attempt_1604112648850_0001_1_01_000000_3:java.lang.RuntimeException: java.lang.RuntimeException: Hive Runtime Error while closing operators: java.io.IOException: java.util.ServiceConfigurationError: org.apache.hadoop.security.token.TokenIdentifier: Provider org.apache.hadoop.hbase.security.token.AuthenticationTokenIdentifier not found
  ```
+ 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\$1002F). Por exemplo, o caractere de espaço (U\$10020) 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](https://www.utf8-chartable.de/).

  Como solução alternativa para esse problema, defina a configuração `spark.sql.sources.fastS3PartitionDiscovery.enabled` como `false` na classificação `spark-defaults`.

## Versão 6.2.0
<a name="emr-620-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 6.2.0 do Amazon EMR. As alterações são referentes à versão 6.1.0.

Data da versão inicial: 9 de dezembro de 2020

Data da última atualização: 4 de outubro de 2021

**Aplicações compatíveis**
+ AWS SDK para 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 recursos**
+ HBase: a renomeação foi removida na fase de confirmação e o HFile rastreamento persistente foi adicionado. Consulte [ HFile Rastreamento persistente](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hbase-s3.html#emr-hbase-s3-hfile-tracking) no *Guia de lançamento do Amazon EMR.*
+ HBase: Backported [Crie uma configuração que força o armazenamento em cache dos blocos na compactação](https://issues.apache.org/jira/browse/HBASE-23066).
+ 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 definido: para se alinhar às AWS melhores práticas, 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](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-iam-policies.html).
+ Status de suporte do Instance Metadata Service (IMDS) V2: Para o Amazon EMR 6.2 ou posterior, os componentes do Amazon EMR são usados para todas as chamadas do IMDS. IMDSv2 Para chamadas IMDS no código do aplicativo, você pode usar ambos IMDSv1 e IMDSv2, ou configurar o IMDS para uso somente IMDSv2 para aumentar a segurança. Se você desabilitar IMDSv1 em versões anteriores do Amazon EMR 6.x, isso causará uma falha na inicialização do cluster.

**Alterações, melhorias e problemas resolvidos**
+ Esta é uma versão para corrigir problemas com o Amazon EMR Scaling quando ele não consegue up/scale reduzir a 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 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](https://issues.apache.org/jira/browse/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](https://issues.apache.org/jira/browse/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 no cluster do Amazon EMR não renovou o tíquete Kerberos, que é necessário para se comunicar com segurança com a execução no nó primário. HDFS/YARN 
+ As versões mais recentes do Amazon EMR corrigem o problema com um limite menor de “Máximo de arquivos abertos” em relação às versões mais antigas AL2 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 diretório/etc/cron.d/libinstance-controller-java file in EMR 6.2.0. Permissions on the file are 645 (-rw-r--r-x), when they should be 644 (-rw-r--r--). As a result, Amazon EMR version 6.2 does not log instance-state logs, and the /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)”. Outros sites UIs, como Spark, Hue, Zeppelin JupyterHub, 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](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-connect-master-node-ssh.html).

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

  1. 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 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 AWS contato com o suporte para obter um Hudi RPM corrigido.
+ 
**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](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-custom-ami.html) para [usar a AMI do Amazon Linux mais recente](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/finding-an-ami.html).
+ 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 HFile rastreamento persistente usando a tabela do sistema HBase storefile não oferece suporte ao recurso de replicação da HBase região. Para obter mais informações sobre a replicação HBase da região, consulte Leituras de alta disponibilidade [consistentes com o cronograma](http://hbase.apache.org/book.html#arch.timelineconsistent.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\$1002F). Por exemplo, o caractere de espaço (U\$10020) 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](https://www.utf8-chartable.de/).

  Como solução alternativa para esse problema, defina a configuração `spark.sql.sources.fastS3PartitionDiscovery.enabled` como `false` na classificação `spark-defaults`.

## Versão 5.31.0
<a name="emr-5310-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.31.0 do Amazon EMR. As alterações são referentes à versão 5.30.1.

Data da versão inicial: 9 de outubro de 2020

Data da última atualização: 15 de outubro de 2020

**Atualizações**
+ Atualizado o conector do Amazon Glue para a versão 1.13.0
+ SDK do Amazon SageMaker Spark atualizado para a versão 1.4.0
+ Atualizado o conector do Amazon Kinesis para a versão 3.5.9 
+ Atualizado para AWS SDK para Java a versão 1.11.852
+ Atualizado o Bigtop-tomcat para a versão 8.5.56
+ Atualizado o EMRFS para a versão 2.43.0
+ Cliente MetricsAndEventsApiGateway EMR atualizado para a versão 1.4.0
+ Atualizado o EMR S3 Dist CP para a versão 2.15.0
+ Atualizado o EMR S3 Select para a versão 1.6.0
+ Atualizado o Flink para a versão 1.11.0
+ Atualizado o Hadoop para a versão 2.10.0
+ Atualizado o Hive para a versão 2.3.7
+ Atualizado o Hudi para a versão 0.6.0
+ Atualizado o Hue para a versão 4.7.1
+ Atualizado JupyterHub para a versão 1.1.0
+ Atualizado o Mxnet para a versão 1.6.0
+ Atualizado o OpenCV para a versão 4.3.0
+ Atualizado o Presto para a versão 0.238.3
+ Atualizado TensorFlow para a versão 2.1.0

**Alterações, melhorias e problemas resolvidos**
+ Esta é uma versão para corrigir problemas com o Amazon EMR Scaling quando ele não consegue up/scale reduzir a 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 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](https://issues.apache.org/jira/browse/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](https://issues.apache.org/jira/browse/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 no cluster do Amazon EMR não renovou o tíquete Kerberos, que é necessário para se comunicar com segurança com a execução no nó primário. HDFS/YARN 
+ As versões mais recentes do Amazon EMR corrigem o problema com um limite menor de “Máximo de arquivos abertos” em relação às versões mais antigas AL2 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”.
+ [As estatísticas de colunas do Hive](https://cwiki.apache.org/confluence/display/Hive/StatsDev#StatsDev-ColumnStatistics) são compatíveis com as versões 5.31.0 e posteriores do Amazon EMR.
+ Atualizadas versões do componente.
+ Suporte ao EMRFS S3EC V2 no Amazon EMR 5.31.0. Nas versões 1.11.837 e posteriores do SDK para Java no S3, a versão 2 do cliente de criptografia (S3EC V2) foi introduzida com vários aprimoramentos de segurança. Para saber mais, consulte:
  + Publicações no blog do S3: [Atualizações no cliente de criptografia do Amazon S3](https://aws.amazon.com/blogs/developer/updates-to-the-amazon-s3-encryption-client/).
  + AWS SDK para Java Guia do desenvolvedor: [Migre clientes de criptografia e descriptografia](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/s3-encryption-migration.html#s3-cse-update-code) para a V2.
  + Guia de gerenciamento do EMR: [Criptografia do lado do cliente do Amazon S3](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-emrfs-encryption-cse.html).

  O Encryption Client V1 ainda está disponível no SDK para compatibilidade retroativa.

**Novos recursos**
+ **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`

  1. 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
  ```
+ Com a versão 5.31.0 do Amazon EMR, você pode iniciar um cluster que se integre ao Lake Formation. Essa integração fornece filtragem de dados refinada em nível de coluna para bancos de dados e tabelas no Glue Data Catalog. AWS Ela também permite logon único federado para Cadernos do EMR ou para o Apache Zeppelin em um sistema de identidade empresarial. Para obter mais informações, consulte [Integrating Amazon EMR with AWS Lake Formation](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-lake-formation.html) no *Guia de gerenciamento do Amazon EMR*.

  Atualmente, o Amazon EMR com Lake Formation está disponível em 16 AWS regiões: Leste dos EUA (Ohio e Norte da Virgínia), Oeste dos EUA (Norte da Califórnia e Oregon), Ásia-Pacífico (Mumbai, Seul, Cingapura, Sydney e Tóquio), Canadá (Central), Europa (Frankfurt, Irlanda, Londres, Paris e Estocolmo) e América do Sul (São Paulo).

**Problemas conhecidos**
+ 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 AtRestEncryption a criptografia HDFS é habilitada em um cluster que usa o Amazon EMR 5.31.0 ou 5.32.0, as consultas do Hive resultam na seguinte exceção de tempo de execução.

  ```
  TaskAttempt 3 failed, info=[Error: Error while running task ( failure ) : attempt_1604112648850_0001_1_01_000000_3:java.lang.RuntimeException: java.lang.RuntimeException: Hive Runtime Error while closing operators: java.io.IOException: java.util.ServiceConfigurationError: org.apache.hadoop.security.token.TokenIdentifier: Provider org.apache.hadoop.hbase.security.token.AuthenticationTokenIdentifier not found
  ```
+ 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\$1002F). Por exemplo, o caractere de espaço (U\$10020) 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](https://www.utf8-chartable.de/).

  Como solução alternativa para esse problema, defina a configuração `spark.sql.sources.fastS3PartitionDiscovery.enabled` como `false` na classificação `spark-defaults`.

## Versão 6.1.0
<a name="emr-610-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 6.1.0 do Amazon EMR. As alterações são referentes à versão 6.0.0.

Data da versão inicial: 4 de setembro de 2020

Data da última atualização: 15 de outubro de 2020

**Aplicações compatíveis**
+ AWS SDK para 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
+ HBase versão 2.2.5
+ HBase-operator-tools 1.0.0
+ HCatalog versã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
+ MXNet versão 1.6.0
+ Oozie versão 5.2.0
+ Phoenix versão 5.0.0
+ Presto versão 0.232
+ PrestoSQL versão 338
+ 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 recursos**
+ Os tipos de instância ARM são compatíveis desde o Amazon EMR versão 5.30.0 e do Amazon EMR versão 6.1.0.
+ Os tipos de instância de uso geral M6g são compatíveis desde as versões 6.1.0 e 5.30.0 do Amazon EMR. Para obter mais informações, consulte [Tipos de instâncias compatíveis](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-supported-instance-types.html) no *Guia de gerenciamento do Amazon EMR*.
+ O atributo grupo de posicionamento do EC2 é compatível desde a versão 5.23.0 do Amazon EMR 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 [Integração do EMR com o grupo de posicionamento do EC2](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-placementgroup.html) no *Guia de gerenciamento do Amazon EMR*.
+ Ajuste de escala gerenciado: com a versão 6.1.0 do Amazon EMR, é possível habilitar o Ajuste de Escala Gerenciado do Amazon 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. O ajuste de escala gerenciado também está disponível na versão 5.30.0 e posteriores do Amazon EMR, exceto na versão 6.0.0. Para obter mais informações, consulte [Escalar recursos de cluster](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-scale-on-demand.html) no *Guia de gerenciamento do Amazon EMR*.
+ O PrestoSQL versão 338 é compatível com o EMR 6.1.0. Para obter mais informações, consulte [Presto](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-presto.html).
  + O PrestoSQL só é compatível com as versões 6.1.0 e posteriores do EMR e não no EMR 6.0.0 ou no EMR 5.x.
  + O nome da aplicação, `Presto`, continua a ser usado para instalar o PrestoDB em clusters. Para instalar o PrestoSQL em clusters, use o nome da aplicação `PrestoSQL`.
  + Você pode instalar o PrestoDB ou o PrestoSQL, mas não pode instalar os dois em um único cluster. Se o PrestoDB e o PrestoSQL forem especificados na tentativa de criação de um cluster, ocorrerá um erro de validação e a solicitação de criação do cluster falhará.
  + O PrestoSQL é compatível com clusters de mestre único e de vários mestres. Em clusters de vários mestres, é necessário um metastore externo do Hive para executar o PrestoSQL ou o PrestoDB. Consulte [Aplicações compatíveis em um cluster do EMR com vários nós primários](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-applications.html#emr-plan-ha-applications-list).
+ Suporte à autenticação automática do ECR no Apache Hadoop e no Apache Spark com Docker: os usuários do Spark podem usar imagens do Docker do Docker Hub e do Amazon Elastic Container Registry (Amazon ECR) para definir dependências de ambiente e biblioteca.

  [Configure o Docker](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-docker.html) e [execute aplicações do Spark com o Docker usando o Amazon EMR 6.x](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-docker.html).
+ O EMR é compatível com as transações ACID do Apache Hive: o Amazon EMR 6.1.0 adiciona suporte às transações ACID do Hive para estar em conformidade com as propriedades ACID de um banco de dados. 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 atributo essencial para casos de uso, como ingestão de streaming, redefinição de dados, atualizações em massa usando MERGE e mudanças lentas de dimensões. Para obter mais informações, incluindo exemplos de configuração e casos de uso, consulte [O Amazon EMR é compatível com as transações ACID do Apache Hive](https://aws.amazon.com/blogs/big-data/amazon-emr-supports-apache-hive-acid-transactions).

**Alterações, melhorias e problemas resolvidos**
+ Esta é uma versão para corrigir problemas com o Amazon EMR Scaling quando ele não consegue up/scale reduzir a 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 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](https://issues.apache.org/jira/browse/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](https://issues.apache.org/jira/browse/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 no cluster do Amazon EMR não renovou o tíquete Kerberos, que é necessário para se comunicar com segurança com a execução no nó primário. HDFS/YARN 
+ As versões mais recentes do Amazon EMR corrigem o problema com um limite menor de “Máximo de arquivos abertos” em relação às versões mais antigas AL2 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 Apache Flink não é compatível com o EMR 6.0.0, mas é compatível com o 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](https://flink.apache.org/news/2020/07/06/release-1.11.0.html).
+ O Ganglia foi removido dos pacotes padrão do 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].** 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`

  1. 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 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 AWS contato com o suporte para obter um Hudi RPM corrigido.
+ Se você definir uma configuração personalizada de coleta de lixo com `spark.driver.extraJavaOptions` e`spark.executor.extraJavaOptions`, isso resultará em falha de driver/executor inicialização com o EMR 6.1 devido à configuração conflitante da coleta de lixo. Em vez disso, com o EMR versão 6.1.0, você deve especificar uma configuração personalizada de coleta de resíduos do Spark para drivers e executores com as propriedades `spark.driver.defaultJavaOptions` e `spark.executor.defaultJavaOptions`. Leia mais em [Ambiente de runtime do Apache Spark](https://spark.apache.org/docs/latest/configuration.html#runtime-environment) e [Configurar a coleta de resíduos do Spark no Amazon EMR 6.1.0](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-configure.html#spark-gc-config).
+ 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 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.
+ 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 processo interno do Amazon EMR (InstanceController) que está gerando muitos processos leves (LWP), o que acaba fazendo com que o usuário do Hadoop exceda seu limite de nproc. Isso impede que o usuário abra processos adicionais. A solução para esse problema é fazer a atualização para o EMR 6.2.0.

## Versão 6.0.0
<a name="emr-600-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 6.0.0 do Amazon EMR.

Data da versão inicial: 10 de março de 2020

**Aplicações compatíveis**
+ AWS SDK para Java versão 1.11.711
+ Ganglia versão 3.7.2
+ Hadoop versão 3.2.1
+ HBase versão 2.2.3
+ HCatalog versã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
+ MXNet versã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

**nota**  
Flink, Sqoop, Pig e Mahout não estão disponíveis na versão 6.0.0 do Amazon EMR. 

**Novos recursos**
+ Suporte ao runtime do Docker do YARN: aplicações do YARN, como trabalhos do Spark, agora podem ser executados no contexto de um contêiner do Docker. Isso permite que você defina facilmente dependências em uma imagem do Docker sem a necessidade de instalar bibliotecas personalizadas no cluster do Amazon EMR. Para obter mais informações, consulte [Configurar a integração do Docker](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-docker.html) e [Executar aplicações do Spark com o Docker usando o Amazon EMR 6.0.0](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-docker.html).
+ Suporte ao LLAP do Hive – agora o Hive oferece suporte ao modo de execução do LLAP para melhorar o desempenho da consulta. Para obter mais informações, consulte [Usar o LLAP do Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-llap.html).

**Alterações, melhorias e problemas resolvidos**
+ Esta é uma versão para corrigir problemas com o Amazon EMR Scaling quando ele não consegue up/scale reduzir a 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 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](https://issues.apache.org/jira/browse/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](https://issues.apache.org/jira/browse/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 no cluster do Amazon EMR não renovou o tíquete Kerberos, que é necessário para se comunicar com segurança com a execução no nó primário. HDFS/YARN 
+ As versões mais recentes do Amazon EMR corrigem o problema com um limite menor de “Máximo de arquivos abertos” em relação às versões mais antigas AL2 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”.
+ Amazon Linux
  + O Amazon Linux 2 é o sistema operacional da série 6.x do EMR.
  + `systemd` é usado para gerenciamento de serviço em vez de `upstart`, usado no Amazon Linux 1.
+ Java Development Kit (JDK)
  + O JDK 8 do Coretto é o JDK padrão da série 6.x do EMR.
+ Scala
  + O Scala 2.12 é usado com o Apache Spark e com o Apache Livy.
+ Python 3
  + Agora o Python 3 é a versão padrão do Python no EMR.
+ Rótulos de nó do YARN
  + A partir do Amazon EMR série 6.x, o recurso de rótulos de nó do YARN é desabilitado 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. É possível habilitar o recurso de rótulos de nó do YARN 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](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html).

**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`

  1. 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 versão 6.0.0 do Amazon EMR, adicione `PATH` a `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 no cluster com o mesmo tipo de instância e a mesma quantidade de volumes do EBS para evitar falhas quando enviar um trabalho do Spark com runtime do Docker.
+ [No Amazon EMR 6.0.0, no Amazon HBase S3, o modo de armazenamento é afetado pelo problema do HBASE-24286.](https://issues.apache.org/jira/browse/HBASE-24286) HBase o 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 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.

## Versão 5.30.1
<a name="emr-5301-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.30.1 do Amazon EMR. As alterações são referentes à versão 5.30.0.

Data da versão inicial: 30 de junho de 2020

Data da última atualização: 24 de agosto de 2020

**Alterações, melhorias e problemas resolvidos**
+ As versões mais recentes do Amazon EMR corrigem o problema com um limite menor de “Máximo de arquivos abertos” em relação às versões mais antigas AL2 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”.
+ Corrigido um problema em que o processo do controlador da instância gerava um número infinito de processos.
+ Corrigido um problema em que o Hue não conseguia executar uma consulta do Hive, mostrando a mensagem “o banco de dados está bloqueado” e impedindo a execução de consultas.
+ Corrigido um problema no Spark para permitir que mais tarefas fossem executadas simultaneamente no cluster do EMR.
+ Corrigido um problema no caderno Jupyter que causava um “erro de muitos arquivos abertos” no servidor Jupyter.
+ Corrigido um problema com as horas de início do cluster.

**Novos recursos**
+ A interface do usuário do Tez e as interfaces de aplicações persistentes do servidor de linha do tempo do YARN estão disponíveis com as versões 6.x do Amazon EMR e com as versões 5.30.1 e posteriores do EMR. O acesso com um clique no link do histórico persistente da aplicação permite que você acesse rapidamente o histórico de tarefas sem configurar um proxy da Web por meio de uma conexão SSH. Os logs de clusters ativos e encerrados ficam disponíveis por 30 dias após o término da aplicação. Para obter mais informações, consulte [View Persistent Application User Interfaces](https://docs.aws.amazon.com/emr/latest/ManagementGuide/app-history-spark-UI.html) no *Guia de gerenciamento do Amazon EMR*.
+ A execução do EMR Notebook APIs está disponível para executar notebooks EMR por meio de um script ou linha de comando. A capacidade de iniciar, parar, listar e descrever as execuções do notebook EMR sem o AWS console permite que você controle programaticamente um notebook EMR. Ao usar uma célula do caderno parametrizada, você pode passar valores de parâmetros diferentes para um caderno sem precisar criar uma cópia do caderno para cada novo conjunto de valores de parâmetros. Consulte [Ações de API do EMR.](https://docs.aws.amazon.com/emr/latest/APIReference/API_Operations.html) Para obter um exemplo de código, consulte [Exemplos de comandos para executar Cadernos do EMR programaticamente.](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-notebooks-headless.html)

**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`

  1. 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
  ```
+ **Cadernos do EMR**

  O atributo que permite instalar kernels e bibliotecas Python adicionais no nó primário do cluster está desabilitado por padrão na versão 5.30.1 do EMR. Para obter mais informações sobre esse atributo, consulte [Instalar kernels e bibliotecas Python em um nó primário do cluster](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-notebooks-installing-libraries-and-kernels.html).

  Para habilitar o recurso, faça o seguinte:

  1. Certifique-se de que a política de permissões anexada ao perfil de serviço para os Cadernos do EMR permite a seguinte ação:

     `elasticmapreduce:ListSteps`

     Para obter mais informações, consulte [Função de serviço do EMR Notebooks](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-notebooks-service-role.html).

  1. Use o AWS CLI para executar uma etapa no cluster que configura os Notebooks EMR, conforme mostrado no exemplo a seguir. *us-east-1*Substitua pela região em que seu cluster reside. Para obter mais informações, consulte [Adding Steps to a Cluster Using the AWS CLI](https://docs.aws.amazon.com/emr/latest/ManagementGuide/add-step-cli.html).

     ```
     aws emr add-steps  --cluster-id MyClusterID --steps Type=CUSTOM_JAR,Name=EMRNotebooksSetup,ActionOnFailure=CONTINUE,Jar=s3://us-east-1.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://awssupportdatasvcs.com/bootstrap-actions/EMRNotebooksSetup/emr-notebooks-setup.sh"]
     ```
+ **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.
+ 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\$1002F). Por exemplo, o caractere de espaço (U\$10020) 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](https://www.utf8-chartable.de/).

  Como solução alternativa para esse problema, defina a configuração `spark.sql.sources.fastS3PartitionDiscovery.enabled` como `false` na classificação `spark-defaults`.

## Versão 5.30.0
<a name="emr-5300-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.30.0 do Amazon EMR. As alterações são referentes à versão 5.29.0.

Data da versão inicial: 13 de maio de 2020

Data da última atualização: 25 de junho de 2020

**Atualizações**
+ Atualizado para AWS SDK para 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](https://docs.aws.amazon.com//emr/latest/ManagementGuide/emr-managed-notebooks-installing-libraries-and-kernels.html) 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](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-scale-on-demand.html) 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](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-debugging.html#emr-log-encryption) 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](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-custom-ami.html).
+ **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](presto-graceful-autoscale.md).
+ **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](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-fleet.html).
+ **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?](https://aws.amazon.com/premiumsupport/knowledge-center/restart-service-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)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-man-sec-groups.html#emr-sg-elasticmapreduce-sa-private). 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`

  1. 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\$1002F). Por exemplo, o caractere de espaço (U\$10020) 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](https://www.utf8-chartable.de/).

  Como solução alternativa para esse problema, defina a configuração `spark.sql.sources.fastS3PartitionDiscovery.enabled` como `false` na classificação `spark-defaults`.

## Versão 5.29.0
<a name="emr-5290-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.29.0 do Amazon EMR. As alterações são referentes à versão 5.28.1.

Data da versão inicial: 17 de janeiro de 2020

**Atualizações**
+ Atualizado para AWS SDK para Java a versão 1.11.682
+ Atualizado o Hive para a versão 2.3.6
+ Atualizado o Flink para a versão 1.9.1
+ Atualizado o EMRFS para a versão 2.38.0
+ Atualizado o conector do DynamoDB para EMR, versão 4.13.0

**Alterações, melhorias e problemas resolvidos**
+ Spark
  + Otimizações do desempenho do Spark
+ EMRFS
  + O Guia de gerenciamento é atualizado para as configurações padrão emrfs-site.xml para uma visualização consistente.

**Problemas conhecidos**
+ 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.

## Versão 5.28.1
<a name="emr-5281-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.28.1 do Amazon EMR. As alterações são referentes à versão 5.28.0.

Data da versão inicial: 10 de janeiro de 2020

**Alterações, melhorias e problemas resolvidos**
+ Spark
  + Correção de problemas de compatibilidade do Spark.
+ CloudWatch Métricas
  + Foi corrigida a publicação do Amazon CloudWatch Metrics em um cluster do EMR com vários nós primários.
+ Desabilitada mensagem de log
  + Desabilitada mensagem de log falsa, “... uso de versão antiga (<4.5.8) do cliente Apache http”.

**Problemas conhecidos**
+ 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.

## Versão 5.28.0
<a name="emr-5280-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.28.0 do Amazon EMR. As alterações são referentes à 5.27.0.

Data da versão inicial: 12 de novembro de 2019

**Atualizações**
+ Flink atualizado para a versão 1.9.0
+ Atualizado o Hive para a versão 2.3.6
+ Atualizado MXNet para a versão 1.5.1
+ Phoenix atualizado para a versão 4.14.3
+ Presto atualizado para a versão 0.227
+ Zeppelin atualizado para a versão 0.8.2

**Novos recursos**
+ O [Apache Hudi](https://hudi.apache.org/) agora está disponível para o Amazon EMR instalar na criação de um cluster. Para obter mais informações, consulte [Hudi](emr-hudi.md).
+ (25 de novembro de 2019) Agora você pode optar por executar várias etapas em paralelo para melhorar a utilização do cluster e economizar custos. Pode também cancelar etapas pendentes e em execução. Para obter mais informações, consulte [Trabalhar com etapas usando o console AWS CLI e.](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-work-with-steps.html)
+ (3 de dezembro de 2019) Agora você pode criar e executar clusters do EMR no. AWS Outposts AWS Outposts habilita AWS serviços, infraestrutura e modelos operacionais nativos em instalações locais. Em AWS Outposts ambientes, você pode usar as mesmas AWS APIs ferramentas e infraestrutura que usa na AWS nuvem. Para obter mais informações, consulte [Clusters do EMR ativados. AWS Outposts](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-outposts.html)
+ (11 de março de 2020) A partir da versão 5.28.0 do Amazon EMR, você pode criar e executar clusters do Amazon EMR em uma sub-rede de Zonas AWS Locais como uma extensão lógica de uma região que suporta Zonas Locais. AWS Uma zona local permite que os recursos do Amazon EMR e um subconjunto de AWS serviços, como serviços de computação e armazenamento, estejam localizados mais perto dos usuários, fornecendo acesso de latência muito baixa aos aplicativos executados localmente. Para obter uma lista das zonas locais disponíveis, consulte [Zonas locais da AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/). Para obter informações sobre como acessar as Zonas AWS Locais disponíveis, consulte [Regiões, Zonas de Disponibilidade e Zonas Locais](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html).

  Atualmente, as zonas locais não são compatíveis com os Cadernos do Amazon EMR nem com conexões diretas com o Amazon EMR usando o endpoint da VPC da interface (AWS PrivateLink).

**Alterações, melhorias e problemas resolvidos**
+ Suporte expandido do aplicativo para clusters de alta disponibilidade
  + Para obter mais informações, consulte [Supported applications in an EMR cluster with Multiple Primary Nodes](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-applications.html#emr-plan-ha-applications-list) no *Guia de gerenciamento do Amazon EMR*.
+ Spark
  + Otimizações da performance
+ Hive
  + Otimizações da performance
+ Presto
  + Otimizações da performance

**Problemas conhecidos**
+ 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.

## Versão 5.27.0
<a name="emr-5270-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.27.0 do Amazon EMR. As alterações são referentes à versão 5.26.0.

Data da versão inicial: 23 de setembro de 2019

**Atualizações**
+ AWS SDK para Java 1.11.615
+ Flink 1.8.1
+ JupyterHub 1.0.0
+ Spark 2.4.4
+ Tensorflow 1.14.0
+ Conectores e drivers:
  + Conector do DynamoDB 4.12.0

**Novos recursos**
+ (24 de outubro de 2019) Os seguintes novos atributos dos Cadernos do EMR estão disponíveis em todas as versões do Amazon EMR.
  + É possível associar repositórios do Git a Cadernos do EMR para armazenar os cadernos em um ambiente controlado de versão. Você pode compartilhar códigos com pares e reutilizar cadernos Jupyter existentes por meio de repositórios do Git remotos. Para obter mais informações, consulte [Associate Git Repositories with Amazon EMR Notebooks](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-git-repo.html) no *Guia de gerenciamento do Amazon EMR*.
  + O [utilitário nbdime](https://github.com/jupyter/nbdime) agora está disponível em Cadernos do EMR para simplificar a comparação e a mesclagem de cadernos.
  + Agora há suporte para notebooks EMR. JupyterLab JupyterLab é um ambiente de desenvolvimento interativo baseado na Web totalmente compatível com os notebooks Jupyter. Agora você pode optar por abrir seu caderno em qualquer um dos editores de cadernos JupyterLab ou no editor de cadernos Jupyter.
+ (30 de outubro de 2019) Com as versões 5.25.0 e posteriores do Amazon EMR, é possível conectar-se ao servidor de histórico do Spark na página **Resumo** do cluster ou na guia **Histórico da aplicação** no console. Em vez de configurar um proxy da Web por meio de uma conexão SSH, você pode acessar rapidamente a interface do usuário do servidor de histórico do Spark para visualizar as métricas da aplicação e acessar arquivos de log relevantes para clusters ativos e encerrados. Para obter mais informações, consulte [Acesso fora do cluster a interfaces de usuário de aplicações persistentes](https://docs.aws.amazon.com/emr/latest/ManagementGuide/app-history-spark-UI.html) no *Guia de gerenciamento do Amazon EMR*.

**Alterações, melhorias e problemas resolvidos**
+ Cluster do Amazon EMR com vários nós primários
  + Você pode instalar e executar o Flink em um cluster do Amazon EMR com vários nós primários. Para obter mais informações, consulte [Supported applications and features](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-applications.html).
  + Você pode configurar a criptografia transparente do HDFS em um cluster do Amazon EMR com vários nós primários. Para obter mais informações, consulte [Criptografia transparente do HDFS em clusters do EMR com vários nós primários](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-encryption-tdehdfs.html#emr-hadoop-kms-multi-master).
  + Agora você pode modificar a configuração das aplicações em execução em um cluster do Amazon EMR com vários nós primários. Para obter mais informações, consulte [Supplying a Configuration for an Instance Group in a Running Cluster](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps-running-cluster.html).
+ Conector Amazon EMR-DynamoDB
  + O conector Amazon EMR-DynamoDB agora é compatível com os seguintes tipos de dados do DynamoDB: booleanos, lista, mapa, item, nulos. Para obter mais informações, consulte [Configurar uma tabela do Hive para executar comandos do Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/EMR_Interactive_Hive.html).

**Problemas conhecidos**
+ 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.

## Versão 5.26.0
<a name="emr-5260-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.26.0 do Amazon EMR. As alterações são referentes à versão 5.25.0.

Data da versão inicial: 8 de agosto de 2019

Data da última atualização: 19 de agosto de 2019

**Atualizações**
+ AWS SDK para Java 1.11.595
+ HBase 1.4.10
+ Phoenix 4.14.2
+ Conectores e drivers:
  + Conector do DynamoDB 4.11.0
  + Conector do MariaDB 2.4.2
  + Driver JDBC do Amazon Redshift, 1.2.32.1056

**Novos recursos**
+ (Beta) Com a versão 5.26.0 do Amazon EMR, você pode iniciar um cluster que se integre ao Lake Formation. Essa integração fornece acesso refinado em nível de coluna a bancos de dados e tabelas no Glue Data Catalog. AWS Ela também permite logon único federado para Cadernos do EMR ou para o Apache Zeppelin em um sistema de identidade empresarial. Para obter mais informações, consulte [Integração do Amazon EMR AWS Lake Formation com (](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-lake-formation.html)Beta).
+ (19 de agosto de 2019) O bloqueio de acesso público do Amazon EMR agora está disponível em todas as versões do Amazon EMR compatíveis com grupos de segurança. Bloquear o acesso público é uma configuração de toda a conta aplicada a cada AWS região. Bloquear o acesso público impede que um cluster seja iniciado quando qualquer grupo de segurança associado ao cluster tem uma regra que permite tráfego de entrada de IPv4 0.0.0.0/0 ou IPv6 : :/0 (acesso público) em uma porta, a menos que uma porta seja especificada como uma exceção. A porta 22 é uma exceção por padrão. Para obter mais informações, consulte [Usar o bloqueio de acesso público do Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-block-public-access.html) no *Guia de gerenciamento do Amazon EMR*.

**Alterações, melhorias e problemas resolvidos**
+ Cadernos do EMR
  + Com as versões 5.26.0 e posteriores do EMR, os Cadernos do EMR são compatíveis com as bibliotecas Python com escopo de caderno, além das bibliotecas Python padrão. Você pode instalar bibliotecas com escopo de caderno de dentro do editor de caderno sem precisar recriar um cluster ou reanexar um caderno a um cluster. As bibliotecas com escopo de caderno são criadas em um ambiente Python virtual para serem aplicadas somente à sessão de caderno atual. Isso permite isolar as dependências do caderno. Para obter mais informações, consulte [Usar bibliotecas com escopo de caderno](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-notebooks-custom-libraries-limitations.html) no *Guia de gerenciamento do Amazon EMR*.
+ EMRFS
  + Você pode ativar um recurso ETag de verificação (Beta) configurando `fs.s3.consistent.metadata.etag.verification.enabled` como`true`. Com esse recurso, o EMRFS usa o Amazon ETags S3 para verificar se os objetos que estão sendo lidos são a versão mais recente disponível. Esse recurso é útil para casos de read-after-update uso em que os arquivos no Amazon S3 são sobrescritos, mantendo o mesmo nome. Atualmente, esse recurso de ETag verificação não funciona com o S3 Select. Para obter mais informações, consulte [Configurar visualização consistente](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emrfs-configure-consistent-view.html).
+ Spark
  + As seguintes otimizações agora estão habilitadas por padrão: remoção dinâmica de partições, DISTINCT antes de INTERSECT, melhorias na inferência de estatísticas do plano SQL para JOIN seguida por consultas DISTINCT, nivelamento de subconsultas escalares, reordenamento otimizado de junções e junção com filtro de Bloom. Para obter mais informações, consulte [Otimizar a performance do Spark](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-performance.html).
  + Aprimorada a geração de código de estágio completo para Sort-Merge Join.
  + Aprimorado o fragmento de consulta e a reutilização de subconsultas.
  + Melhorias na pré-alocação de executores na inicialização do Spark.
  + As junções com filtro de Bloom não são mais aplicadas quando o lado menor da junção inclui uma dica de transmissão.
+ Tez
  + Resolvido um problema com o Tez. A IU do Tez agora funciona em um cluster do Amazon EMR com vários nós primários.

**Problemas conhecidos**
+ Os recursos aprimorados de geração de código em todo o estágio de Sort Merge Join podem aumentar a pressão de memória quando habilitados. Essa otimização melhora a performance, mas pode resultar em novas tentativas ou falhas de trabalho se `spark.yarn.executor.memoryOverheadFactor` não for ajustado para fornecer memória suficiente. Para desabilitar esse atributo, defina `spark.sql.sortMergeJoinExec.extendedCodegen.enabled` como falso.
+ 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.

## Versão 5.25.0
<a name="emr-5250-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.25.0 do Amazon EMR. As alterações são referentes à versão 5.24.1.

Data da versão inicial: 17 de julho de 2019

Data da última atualização: 30 de outubro de 2019

**Amazon EMR 5.25.0**

**Atualizações**
+ AWS SDK para Java 1.11.566
+ Hive 2.3.5
+ Presto 0.220
+ Spark 2.4.3
+ TensorFlow 1.13.1
+ Tez 0.9.2
+ Zookeeper 3.4.14

**Novos recursos**
+ (30 de outubro de 2019) Desde a versão 5.25.0 do Amazon EMR, é possível conectar-se ao servidor de histórico do Spark na página **Resumo** do cluster ou na guia **Histórico da aplicação** no console. Em vez de configurar um proxy da Web por meio de uma conexão SSH, você pode acessar rapidamente a interface do usuário do servidor de histórico do Spark para visualizar as métricas da aplicação e acessar arquivos de log relevantes para clusters ativos e encerrados. Para obter mais informações, consulte [Acesso fora do cluster a interfaces de usuário de aplicações persistentes](https://docs.aws.amazon.com/emr/latest/ManagementGuide/app-history-spark-UI.html) no *Guia de gerenciamento do Amazon EMR*.

**Alterações, melhorias e problemas resolvidos**
+ Spark
  + Aprimorada a performance de algumas junções usando filtros de Bloom para pré-filtrar as entradas. A otimização é desabilitada por padrão e pode ser habilitada com a definição do parâmetro `spark.sql.bloomFilterJoin.enabled` de configuração do Spark como `true`.
  + Aprimorada a performance do agrupamento por colunas do tipo string.
  + Melhorou a memória padrão do executor Spark e a configuração dos núcleos dos tipos de instância R4 para clusters sem instalação. HBase 
  + Resolvido um problema anterior com o atributo de remoção dinâmica de partições, em que a tabela removida precisava estar no lado esquerdo da junção.
  + Aprimorada a otimização do DISTINCT antes do INTERSECT para ser aplicada a casos adicionais envolvendo aliases.
  + Aprimorada a inferência de estatísticas do plano SQL para JOIN seguida por consultas DISTINCT. Essa melhoria é desabilitada por padrão e pode ser habilitada pela definição do parâmetro `spark.sql.statsImprovements.enabled` de configuração do Spark como `true`. Essa otimização é exigida pelo atributo Distinct antes do Intersect e será habilitada automaticamente quando `spark.sql.optimizer.distinctBeforeIntersect.enabled` estiver definido como `true`.
  + Otimizada a ordem de junção com base no tamanho da tabela e nos filtros. Essa otimização é desativada por padrão e pode ser ativada com a definição do parâmetro `spark.sql.optimizer.sizeBasedJoinReorder.enabled` de configuração do Spark como `true`.

  Para obter mais informações, consulte [Otimizar a performance do Spark](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-performance.html).
+ EMRFS
  + A configuração do EMRFS, `fs.s3.buckets.create.enabled`, agora está desabilitada por padrão. Por meio de testes, descobrimos que a desabilitação dessa configuração melhora a performance e evita a criação não intencional de buckets do S3. Se sua aplicação depende dessa funcionalidade, você pode habilitá-la definindo a propriedade `fs.s3.buckets.create.enabled` como `true` na classificação de configuração `emrfs-site`. Para obter informações, consulte [Supplying a Configuration when Creating a Cluster](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps-create-cluster.html).
+ Melhorias na criptografia de disco local e na criptografia do S3 nas configurações de segurança (5 de agosto de 2019)
  + Separadas as configurações de criptografia do Amazon S3 das configurações de criptografia de disco local na configuração de segurança.
  + Adicionada uma opção para habilitar a criptografia do EBS com as versões 5.24.0 e posteriores. Selecionar essa opção criptografa o volume do dispositivo raiz, além dos volumes de armazenamento. As versões anteriores exigiam o uso de uma AMI personalizada para criptografar o volume do dispositivo raiz.
  + Para obter mais informações, consulte [Opções de criptografia](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-data-encryption-options.html) no *Guia de gerenciamento do Amazon EMR*.

**Problemas conhecidos**
+ 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.

## Versão 5.24.1
<a name="emr-5241-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.24.1 do Amazon EMR. As alterações são referentes à versão 5.24.0.

Data da versão inicial: 26 de junho de 2019

**Alterações, melhorias e problemas resolvidos**
+ Atualizada a AMI padrão do Amazon Linux para Amazon EMR para incluir atualizações de segurança importantes do kernel Linux, incluindo o problema de negação de serviço do TCP SACK ([AWS-2019-005](https://aws.amazon.com/security/security-bulletins/AWS-2019-005/)).

**Problemas conhecidos**
+ 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.

## Versão 5.24.0
<a name="emr-5240-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.24.0 do Amazon EMR. As alterações são referentes à versão 5.23.0.

Data da versão inicial: 11 de junho de 2019

Data da última atualização: 5 de agosto de 2019

**Atualizações**
+ Flink 1.8.0
+ Hue 4.4.0
+ JupyterHub 0.9.6
+ Livy 0.6.0
+ MxNet 1.4.0
+ Presto 0.219
+ Spark 2.4.2
+ AWS SDK para Java 1.11.546
+ Conectores e drivers:
  + Conector do DynamoDB 4.9.0
  + Conector do MariaDB 2.4.1
  + Driver JDBC do Amazon Redshift, 1.2.27.1051

**Alterações, melhorias e problemas resolvidos**
+ Spark
  + Adicionada otimização para remover partições dinamicamente. A otimização está desabilitada por padrão. Para habilitá-la, defina o parâmetro `spark.sql.dynamicPartitionPruning.enabled` de configuração do Spark como `true`.
  + Aprimorada a performance de consultas `INTERSECT`. Essa otimização está desabilitada por padrão. Para habilitá-la, defina o parâmetro `spark.sql.optimizer.distinctBeforeIntersect.enabled` de configuração do Spark como `true`.
  + Adicionada otimização para nivelar subconsultas escalares com agregados que usam a mesma relação. A otimização está desabilitada por padrão. Para habilitá-la, defina o parâmetro `spark.sql.optimizer.flattenScalarSubqueriesWithAggregates.enabled` de configuração do Spark como `true`.
  + Aprimorada a geração de código em todo o estágio.

  Para obter mais informações, consulte [Otimizar a performance do Spark](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-performance.html).
+ Melhorias na criptografia de disco local e na criptografia do S3 nas configurações de segurança (5 de agosto de 2019)
  + Separadas as configurações de criptografia do Amazon S3 das configurações de criptografia de disco local na configuração de segurança.
  + Adicionada uma opção para habilitar a criptografia do EBS. Selecionar essa opção criptografa o volume do dispositivo raiz, além dos volumes de armazenamento. As versões anteriores exigiam o uso de uma AMI personalizada para criptografar o volume do dispositivo raiz.
  + Para obter mais informações, consulte [Opções de criptografia](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-data-encryption-options.html) no *Guia de gerenciamento do Amazon EMR*.

**Problemas conhecidos**
+ 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.

## Versão 5.23.0
<a name="emr-5230-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.23.0 do Amazon EMR. As alterações são referentes à versão 5.22.0.

Data da versão inicial: 1.º de abril de 2019

Data da última atualização: 30 de abril de 2019

**Atualizações**
+ AWS SDK para Java 1.11.519

**Novos recursos**
+ (30 de abril de 2019) Com o Amazon EMR 5.23.0 e versões posteriores, você pode iniciar um cluster com três nós principais para oferecer suporte à alta disponibilidade de aplicativos como YARN Resource Manager, HDFS, Spark, Hive e NameNode Ganglia. O nó primário não é mais um possível ponto de falha único com esse recurso. Se um dos nós primários apresenta falha, o Amazon EMR executa failover automaticamente para um nó primário em espera e substitui o nó primário com falha por um novo com as mesmas ações de configuração e bootstrap. Para obter mais informações, consulte [Plan and Configure Primary Nodes](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha.html).

**Problemas conhecidos**
+ Interface do usuário do Tez (corrigida na versão 5.26.0 do Amazon EMR)

  A interface do usuário do Tez não funciona em um cluster do EMR com vários nós primários. 
+ Hue (corrigido na versão 5.24.0 do Amazon EMR)
  + O Hue executado no Amazon EMR não é compatível com o Solr. Desde a versão 5.20.0 do Amazon EMR, um problema de configuração incorreta faz com que o Solr seja habilitado e uma mensagem de erro inofensiva semelhante à seguinte seja exibida:

    `Solr server could not be contacted properly: HTTPConnectionPool('host=ip-xx-xx-xx-xx.ec2.internal', port=1978): Max retries exceeded with url: /solr/admin/info/system?user.name=hue&doAs=administrator&wt=json (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 111] Connection refused',))`

    **Para evitar que a mensagem de erro do Solr seja exibida:**

    1. Conecte-se à linha de comando do nó primário usando SSH.

    1. Use um editor de texto para abrir o arquivo `hue.ini`. Por exemplo:

       `sudo vim /etc/hue/conf/hue.ini`

    1. Pesquise o termo `appblacklist` e modifique a linha para o seguinte:

       ```
       appblacklist = search
       ```

    1. Salve as alterações e reinicie o Hue, conforme mostrado no exemplo a seguir:

       ```
       sudo stop hue; sudo start hue
       ```
+ 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.

## Versão 5.22.0
<a name="emr-5220-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.22.0 do Amazon EMR. As alterações são referentes à versão 5.21.0.

**Importante**  
A partir da versão 5.22.0 do Amazon EMR, o Amazon EMR AWS usa o Signature versão 4 exclusivamente para autenticar solicitações para o Amazon S3. As versões anteriores do Amazon EMR usam o AWS Signature versão 2 em alguns casos, a menos que as notas de lançamento indiquem que o Signature versão 4 é usado exclusivamente. Para obter mais informações, consulte [Autenticação de solicitações (AWS assinatura versão 4)](https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html) e [Solicitações de autenticação (AWS assinatura versão 2) no Guia](https://docs.aws.amazon.com/AmazonS3/latest/API/auth-request-sig-v2.html) do *desenvolvedor do Amazon Simple Storage Service*.

Data da versão inicial: 20 de março de 2019

**Atualizações**
+ Flink 1.7.1
+ HBase 1.4.9
+ Oozie 5.1.0
+ Phoenix 4.14.1
+ Zeppelin 0.8.1
+ Conectores e drivers:
  + Conector do DynamoDB 4.8.0
  + Conector do MariaDB 2.2.6
  + Driver JDBC do Amazon Redshift, 1.2.20.1043

**Novos recursos**
+ Modificada a configuração padrão do EBS para tipos de instância do EC2 com armazenamento somente do EBS. Ao ser criado um cluster usando as versões 5.22.0 e posteriores do Amazon EMR, a quantidade padrão de armazenamento do EBS aumenta de acordo com o tamanho da instância. Além disso, dividimos o armazenamento aumentado em vários volumes, proporcionando maior performance de IOPS. Se você quiser usar uma instância de configuração de armazenamento EBS diferente, você poderá especificá-la ao criar um cluster do EMR ou adicionar nós a um cluster existente. Para obter mais informações sobre a quantidade de armazenamento e o número de volumes alocados por padrão para cada tipo de instância, consulte [Armazenamento padrão do EBS para instâncias](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-storage.html#emr-plan-storage-ebs-storage-default) no *Guia de gerenciamento do Amazon EMR*.

**Alterações, melhorias e problemas resolvidos**
+ Spark
  + Introduzida uma nova propriedade de configuração para o Spark no YARN, `spark.yarn.executor.memoryOverheadFactor`. O valor dessa propriedade é um fator de escala que define o valor da sobrecarga de memória como uma porcentagem da memória do executor, com um mínimo de 384 MB. Se a sobrecarga de memória for definida explicitamente usando `spark.yarn.executor.memoryOverhead`, essa propriedade não terá efeito. O valor padrão é `0.1875`, representando 18,75%. Esse padrão para o Amazon EMR deixa mais espaço nos contêineres do YARN para a sobrecarga de memória do executor do que o padrão de 10% definido internamente pelo Spark. O padrão do Amazon EMR de 18,75% mostrou empiricamente menos falhas relacionadas à memória nas avaliações comparativas do TPC-DS.
  + Backport do [SPARK-26316](https://issues.apache.org/jira/browse/SPARK-26316) para melhorar a performance.
+ Nas versões 5.19.0, 5.20.0 e 5.21.0 do Amazon EMR, os rótulos dos nós do YARN são armazenados em um diretório do HDFS. Em algumas situações, isso leva a atrasos na inicialização do nó central causando, em seguida, tempo limite do cluster e falha na inicialização. Desde a versão 5.22.0 do Amazon EMR, esse problema foi resolvido. Os rótulos dos nós do YARN são armazenados no disco local de cada nó do cluster, evitando dependências no HDFS. 

**Problemas conhecidos**
+ Hue (corrigido na versão 5.24.0 do Amazon EMR)
  + O Hue executado no Amazon EMR não é compatível com o Solr. Desde a versão 5.20.0 do Amazon EMR, um problema de configuração incorreta faz com que o Solr seja habilitado e uma mensagem de erro inofensiva semelhante à seguinte seja exibida:

    `Solr server could not be contacted properly: HTTPConnectionPool('host=ip-xx-xx-xx-xx.ec2.internal', port=1978): Max retries exceeded with url: /solr/admin/info/system?user.name=hue&doAs=administrator&wt=json (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 111] Connection refused',))`

    **Para evitar que a mensagem de erro do Solr seja exibida:**

    1. Conecte-se à linha de comando do nó primário usando SSH.

    1. Use um editor de texto para abrir o arquivo `hue.ini`. Por exemplo:

       `sudo vim /etc/hue/conf/hue.ini`

    1. Pesquise o termo `appblacklist` e modifique a linha para o seguinte:

       ```
       appblacklist = search
       ```

    1. Salve as alterações e reinicie o Hue, conforme mostrado no exemplo a seguir:

       ```
       sudo stop hue; sudo start hue
       ```
+ 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.

## Versão 5.21.1
<a name="emr-5211-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.21.1 do Amazon EMR. As alterações são referentes à versão 5.21.0.

Data da versão inicial: 18 de julho de 2019

**Alterações, melhorias e problemas resolvidos**
+ Atualizada a AMI padrão do Amazon Linux para Amazon EMR para incluir atualizações de segurança importantes do kernel Linux, incluindo o problema de negação de serviço do TCP SACK ([AWS-2019-005](https://aws.amazon.com/security/security-bulletins/AWS-2019-005/)).

**Problemas conhecidos**
+ 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.

## Versão 5.21.0
<a name="emr-5210-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.21.0 do Amazon EMR. As alterações são referentes à versão 5.20.0.

Data da versão inicial: 18 de fevereiro de 2019

Data da última atualização: 3 de abril de 2019

**Atualizações**
+ Flink 1.7.0
+ Presto 0.215
+ AWS SDK para Java 1.11.479

**Novos recursos**
+ (3 de abril de 2019) Com as versões 5.21.0 e posteriores do Amazon EMR, você pode substituir as configurações de cluster e especificar classificações de configuração adicionais para cada grupo de instâncias em um cluster em execução. Você faz isso usando o console do Amazon EMR, o AWS Command Line Interface (AWS CLI) ou o AWS SDK. Para obter mais informações, consulte [Supplying a Configuration for an Instance Group in a Running Cluster](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps-running-cluster.html).

**Alterações, melhorias e problemas resolvidos**
+ Zeppelin
  + Backport do [ZEPPELIN-3878](https://issues.apache.org/jira/browse/ZEPPELIN-3878).

**Problemas conhecidos**
+ Hue (corrigido na versão 5.24.0 do Amazon EMR)
  + O Hue executado no Amazon EMR não é compatível com o Solr. Desde a versão 5.20.0 do Amazon EMR, um problema de configuração incorreta faz com que o Solr seja habilitado e uma mensagem de erro inofensiva semelhante à seguinte seja exibida:

    `Solr server could not be contacted properly: HTTPConnectionPool('host=ip-xx-xx-xx-xx.ec2.internal', port=1978): Max retries exceeded with url: /solr/admin/info/system?user.name=hue&doAs=administrator&wt=json (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 111] Connection refused',))`

    **Para evitar que a mensagem de erro do Solr seja exibida:**

    1. Conecte-se à linha de comando do nó primário usando SSH.

    1. Use um editor de texto para abrir o arquivo `hue.ini`. Por exemplo:

       `sudo vim /etc/hue/conf/hue.ini`

    1. Pesquise o termo `appblacklist` e modifique a linha para o seguinte:

       ```
       appblacklist = search
       ```

    1. Salve as alterações e reinicie o Hue, conforme mostrado no exemplo a seguir:

       ```
       sudo stop hue; sudo start hue
       ```
+ Tez
  + Esse problema foi corrigido no Amazon EMR 5.22.0.

    Quando você se conecta à interface do usuário do Tez em http: //:8080/tez-ui *MasterDNS* por meio de uma conexão SSH com o nó primário do cluster, aparece o erro “Falha na operação do adaptador - o servidor Timeline (ATS) está fora de alcance. Ele está inoperante ou o CORS não está habilitado” ou as tarefas mostram, inesperadamente, N/A.

    Isso é causado pela interface do usuário do Tez ao fazer solicitações ao servidor de linha do tempo do YARN usando `localhost` em vez do nome do host do nó primário. Como solução alternativa, um script está disponível para execução como ação ou etapa de bootstrap. O script atualiza o nome do host no arquivo `configs.env` do Tez. Para obter mais informações e a localização do script, consulte [Instruções de bootstrap](http://awssupportdatasvcs.com/bootstrap-actions/fix_tez_ui_0-9-1/).
+ Nas versões 5.19.0, 5.20.0 e 5.21.0 do Amazon EMR, os rótulos dos nós do YARN são armazenados em um diretório do HDFS. Em algumas situações, isso leva a atrasos na inicialização do nó central causando, em seguida, tempo limite do cluster e falha na inicialização. Desde a versão 5.22.0 do Amazon EMR, esse problema foi resolvido. Os rótulos dos nós do YARN são armazenados no disco local de cada nó do cluster, evitando dependências no HDFS. 
+ 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.

## Versão 5.20.0
<a name="emr-5200-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.20.0 do Amazon EMR. As alterações são referentes à versão 5.19.0.

Data da versão inicial: 18 de dezembro de 2018

Data da última atualização: 22 de janeiro de 2019

**Atualizações**
+ Flink 1.6.2
+ HBase 1.4.8
+ Hive 2.3.4
+ Hue 4.3.0
+ MXNet 1.3.1
+ Presto 0.214
+ Spark 2.4.0
+ TensorFlow 1.12.0
+ Tez 0.9.1
+ AWS SDK para Java 1.11.461

**Novos recursos**
+ (22 de janeiro de 2019) O Kerberos no Amazon EMR foi aprimorado para oferecer suporte à autenticação de entidades principais de um KDC externo. Isso centraliza o gerenciamento de principais porque vários clusters podem compartilhar um único KDC externo. Além disso, o KDC externo pode ter uma relação de confiança entre realm com um domínio do Active Directory. Isso permite que todos os clusters autentiquem principais do Active Directory. Para obter mais informações, consulte [Usar autenticação Kerberos](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-kerberos.html) no *Guia de gerenciamento do Amazon EMR*.

**Alterações, melhorias e problemas resolvidos**
+ AMI padrão do Amazon Linux para Amazon EMR
  + O pacote Python3 foi atualizado do python 3.4 para 3.6.
+ O confirmador otimizado para EMRFS S3 
  + O confirmador otimizado para EMRFS S3 agora está habilitado por padrão, o que melhora a performance de gravação. Para obter mais informações, consulte [Usar o confirmador otimizado para EMRFS S3](emr-spark-s3-optimized-committer.md).
+ Hive
  + Backport do [HIVE-16686](https://issues.apache.org/jira/browse/HIVE-16686).
+ Glue com Spark e Hive
  + No EMR 5.20.0 ou posterior, a remoção paralela de partições é ativada automaticamente para o Spark e o Hive quando o AWS Glue Data Catalog é usado como metastore. Essa alteração reduz significativamente o tempo de planejamento de consultas ao executar várias solicitações em paralelo para recuperar partições. O número total de segmentos que podem ser executados simultaneamente varia entre 1 e 10. O valor padrão é 5, que é uma configuração recomendada. Você pode alterá-lo especificando a propriedade `aws.glue.partition.num.segments` na classificação de configuração `hive-site`. Se ocorrer controle de utilização, você poderá desativar o atributo alterando o valor para 1. Para obter mais informações, consulte a [Estrutura de segmentos do AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-catalog-partitions.html#aws-glue-api-catalog-partitions-Segment).

**Problemas conhecidos**
+ Hue (corrigido na versão 5.24.0 do Amazon EMR)
  + O Hue executado no Amazon EMR não é compatível com o Solr. Desde a versão 5.20.0 do Amazon EMR, um problema de configuração incorreta faz com que o Solr seja habilitado e uma mensagem de erro inofensiva semelhante à seguinte seja exibida:

    `Solr server could not be contacted properly: HTTPConnectionPool('host=ip-xx-xx-xx-xx.ec2.internal', port=1978): Max retries exceeded with url: /solr/admin/info/system?user.name=hue&doAs=administrator&wt=json (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 111] Connection refused',))`

    **Para evitar que a mensagem de erro do Solr seja exibida:**

    1. Conecte-se à linha de comando do nó primário usando SSH.

    1. Use um editor de texto para abrir o arquivo `hue.ini`. Por exemplo:

       `sudo vim /etc/hue/conf/hue.ini`

    1. Pesquise o termo `appblacklist` e modifique a linha para o seguinte:

       ```
       appblacklist = search
       ```

    1. Salve as alterações e reinicie o Hue, conforme mostrado no exemplo a seguir:

       ```
       sudo stop hue; sudo start hue
       ```
+ Tez
  + Esse problema foi corrigido no Amazon EMR 5.22.0.

    Quando você se conecta à interface do usuário do Tez em http: //:8080/tez-ui *MasterDNS* por meio de uma conexão SSH com o nó primário do cluster, aparece o erro “Falha na operação do adaptador - o servidor Timeline (ATS) está fora de alcance. Ele está inoperante ou o CORS não está habilitado” ou as tarefas mostram, inesperadamente, N/A.

    Isso é causado pela interface do usuário do Tez ao fazer solicitações ao servidor de linha do tempo do YARN usando `localhost` em vez do nome do host do nó primário. Como solução alternativa, um script está disponível para execução como ação ou etapa de bootstrap. O script atualiza o nome do host no arquivo `configs.env` do Tez. Para obter mais informações e a localização do script, consulte [Instruções de bootstrap](http://awssupportdatasvcs.com/bootstrap-actions/fix_tez_ui_0-9-1/).
+ Nas versões 5.19.0, 5.20.0 e 5.21.0 do Amazon EMR, os rótulos dos nós do YARN são armazenados em um diretório do HDFS. Em algumas situações, isso leva a atrasos na inicialização do nó central causando, em seguida, tempo limite do cluster e falha na inicialização. Desde a versão 5.22.0 do Amazon EMR, esse problema foi resolvido. Os rótulos dos nós do YARN são armazenados no disco local de cada nó do cluster, evitando dependências no HDFS. 
+ 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.

## Versão 5.19.0
<a name="emr-5190-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.19.0 do Amazon EMR. As alterações são referentes à versão 5.18.0.

Data da versão inicial: 7 de novembro de 2018

Data da última atualização: 19 de novembro de 2018

**Atualizações**
+ Hadoop 2.8.5
+ Flink 1.6.1
+ JupyterHub 0.9.4
+ MXNet 1.3.0
+ Presto 0.212
+ TensorFlow 1.11.0
+ Zookeeper 3.4.13
+ AWS SDK para Java 1.11.433

**Novos recursos**
+ (19 de novembro de 2018) Os Cadernos do EMR constituem um ambiente gerenciado baseado no caderno Jupyter. Ele suporta os kernels mágicos do Spark para Spark PySpark SQL, Spark R e Scala. Os Cadernos do EMR podem ser usados com clusters criados usando as versões 5.18.0 e posteriores do Amazon EMR. Para obter mais informações, consulte [Usar Cadernos do EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-notebooks.html) no *Guia de gerenciamento do Amazon EMR*.
+ O confirmador otimizado para EMRFS S3 está disponível ao serem gravados arquivos Parquet usando Spark e EMRFS. Esse confirmador melhora a performance de gravação. Para obter mais informações, consulte [Usar o confirmador otimizado para EMRFS S3](emr-spark-s3-optimized-committer.md).

**Alterações, melhorias e problemas resolvidos**
+ YARN
  + Modificada a lógica que limita o processo mestre da aplicação à execução nos nós centrais. Essa funcionalidade agora usa o atributo e as propriedades de rótulos de nós do YARN nas classificações de configuração `yarn-site` e `capacity-scheduler`. Para saber mais, consulte [https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-instances-guidelines.html#emr-plan-spot-YARN.](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-instances-guidelines.html#emr-plan-spot-YARN.)
+ AMI padrão do Amazon Linux para Amazon EMR
  + `ruby18`, `php56`, e `gcc48` não são mais instalados por padrão. Eles podem ser instalados, se desejado, usando `yum`.
  + A gem do ruby aws-sdk não é mais instalada por padrão. Ela pode ser instalada usando `gem install aws-sdk`, se desejado. Componentes específicos também podem ser instalados. Por exemplo, .`gem install aws-sdk-s3`

**Problemas conhecidos**
+ **Cadernos do EMR**: em algumas circunstâncias, com vários editores de cadernos abertos, o editor de cadernos pode parecer incapaz de se conectar ao cluster. Se isso acontecer, limpe os cookies do navegador e reabra os editores de cadernos.
+ **CloudWatch ContainerPending Escalabilidade métrica e automática** — (corrigida na versão 5.20.0) O Amazon EMR pode emitir um valor negativo para. `ContainerPending` Se `ContainerPending` for usado em uma regra de escalabilidade automática, a escalabilidade automática não se comportará conforme esperado. Evite usar `ContainerPending` com escalabilidade automática.
+ Nas versões 5.19.0, 5.20.0 e 5.21.0 do Amazon EMR, os rótulos dos nós do YARN são armazenados em um diretório do HDFS. Em algumas situações, isso leva a atrasos na inicialização do nó central causando, em seguida, tempo limite do cluster e falha na inicialização. Desde a versão 5.22.0 do Amazon EMR, esse problema foi resolvido. Os rótulos dos nós do YARN são armazenados no disco local de cada nó do cluster, evitando dependências no HDFS. 

## Versão 5.18.0
<a name="emr-5180-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.18.0 do Amazon EMR. As alterações são referentes à versão 5.17.0.

Data da versão inicial: 24 de outubro de 2018

**Atualizações**
+ Flink 1.6.0
+ HBase 1.4.7
+ Presto 0.210
+ Spark 2.3.2
+ Zeppelin 0.8.0

**Novos recursos**
+ Desde a versão 5.18.0 do Amazon EMR, você pode usar o repositório de artefatos do Amazon EMR para criar o código de trabalho em comparação com as versões exatas de bibliotecas e dependências disponíveis com versões específicas do Amazon EMR. Para obter mais informações, consulte [Verificar dependências usando o repositório de artefatos do Amazon EMR](emr-artifact-repository.md).

**Alterações, melhorias e problemas resolvidos**
+ Hive
  + Adicionado suporte para o S3 Select. Para obter mais informações, consulte [Usar o S3 Select com o Hive para melhorar a performance](emr-hive-s3select.md).
+ Presto
  + Adicionado suporte para o [S3 Select](https://aws.amazon.com/blogs/aws/s3-glacier-select/) Pushdown. Para obter mais informações, consulte [Usar S3 Select Pushdown com o Presto para melhorar a performance](emr-presto-s3select.md).
+ Spark
  + A configuração log4j padrão do Spark foi alterada para lançar logs de contêineres por hora para trabalhos de streaming do Spark. Isso ajuda a evitar a exclusão de lo de trabalhos de streaming do Spark de execução prolongada.

## Versão 5.17.1
<a name="emr-5171-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.17.1 do Amazon EMR. As alterações são referentes à versão 5.17.0.

Data da versão inicial: 18 de julho de 2019

**Alterações, melhorias e problemas resolvidos**
+ Atualizada a AMI padrão do Amazon Linux para Amazon EMR para incluir atualizações de segurança importantes do kernel Linux, incluindo o problema de negação de serviço do TCP SACK ([AWS-2019-005](https://aws.amazon.com/security/security-bulletins/AWS-2019-005/)).

## Versão 5.17.0
<a name="emr-5170-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.17.0 do Amazon EMR. As alterações são referentes à versão 5.16.0.

Data da versão inicial: 30 de agosto de 2018

**Atualizações**
+ Flink 1.5.2
+ HBase 1.4.6
+ Presto 0.206

**Novos recursos**
+ Adicionado suporte para Tensorflow. Para obter mais informações, consulte [TensorFlow](emr-tensorflow.md).

**Alterações, melhorias e problemas resolvidos**
+ JupyterHub
  + Adicionado suporte para a persistência de cadernos no Amazon S3. Para obter mais informações, consulte [Configurar a persistência de cadernos no Amazon S3](emr-jupyterhub-s3.md).
+ Spark
  + Adicionado suporte para o [S3 Select](https://aws.amazon.com/blogs/aws/s3-glacier-select/). Para obter mais informações, consulte [Usar o S3 Select com Spark para melhorar a performance das consultas](emr-spark-s3select.md).
+ Resolvidos os problemas com as métricas do Cloudwatch e o atributo de escalabilidade automática nas versões 5.14.0, 5.15.0 ou 5.16.0 do Amazon EMR. 

**Problemas conhecidos**
+ Quando você cria um cluster kerberizado com o Livy instalado, o Livy apresenta falha com um erro em que a autenticação simples não está habilitada. A reinicialização do servidor do Livy resolve o problema. Como solução alternativa, adicione uma etapa durante a criação do cluster que execute `sudo restart livy-server` no nó primário.
+ Se você usar uma AMI do Amazon Linux personalizada com base em uma AMI do Amazon Linux com data de criação 11/8/2018, o servidor Oozie falhará ao iniciar. Se você usar o Oozie, crie uma AMI personalizada com base em um ID de AMI do Amazon Linux com uma data de criação diferente. Você pode usar o AWS CLI comando a seguir para retornar uma lista de imagens IDs para todos os HVM Amazon Linux AMIs com uma versão 2018.03, junto com a data de lançamento, para que você possa escolher uma Amazon Linux AMI apropriada como sua base. MyRegion Substitua pelo seu identificador de região, como us-west-2.

  ```
  aws ec2 --region MyRegion describe-images --owner amazon --query 'Images[?Name!=`null`]|[?starts_with(Name, `amzn-ami-hvm-2018.03`) == `true`].[CreationDate,ImageId,Name]' --output text | sort -rk1
  ```

## Versão 5.16.0
<a name="emr-5160-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.16.0 do Amazon EMR. As alterações são referentes à versão 5.15.0.

Data da versão inicial: 19 de julho de 2018

**Atualizações**
+ Hadoop 2.8.4
+ Flink 1.5.0
+ Livy 0.5.0
+ MXNet 1.2.0
+ Phoenix 4.14.0
+ Presto 0.203
+ Spark 2.3.1
+ AWS SDK para Java 1.11.336
+ CUDA 9.2
+ Driver JDBC do Redshift, 1.2.15.1025

**Alterações, melhorias e problemas resolvidos**
+ HBase
  + Backport do [HBASE-20723](https://issues.apache.org/jira/browse/HBASE-20723)
+ Presto
  + Alterações na configuração para oferecer suporte à autenticação LDAP. Para obter mais informações, consulte [Usar autenticação LDAP para o Presto no Amazon EMR](emr-presto-ldap.md).
+ Spark
  + [[A versão 2.3.1 do Apache Spark, disponível desde a versão 5.16.0 do Amazon EMR, aborda CVE-2018-8024](https://nvd.nist.gov/vuln/detail/CVE-2018-1334) e CVE-2018-1334](https://nvd.nist.gov/vuln/detail/CVE-2018-8024). Recomendamos que você migre as versões anteriores do Spark para a versão 2.3.1 ou posteriores.

**Problemas conhecidos**
+ Essa versão não é compatível com os tipos de instância c1.medium ou m1.small. Os clusters que usam qualquer um desses tipos de instância não são iniciados. Como solução alternativa, especifique um tipo de instância diferente ou use uma versão diferente.
+ Quando você cria um cluster kerberizado com o Livy instalado, o Livy apresenta falha com um erro em que a autenticação simples não está habilitada. A reinicialização do servidor do Livy resolve o problema. Como solução alternativa, adicione uma etapa durante a criação do cluster que execute `sudo restart livy-server` no nó primário.
+ Depois que o nó primário for reinicializado ou o controlador de instância for reiniciado, as CloudWatch métricas não serão coletadas e o recurso de escalabilidade automática não estará disponível nas versões 5.14.0, 5.15.0 ou 5.16.0 do Amazon EMR. Esse problema foi corrigido na versão 5.17.0 do Amazon EMR. 

## Versão 5.15.0
<a name="emr-5150-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.15.0 do Amazon EMR. As alterações são referentes à versão 5.14.0.

Data da versão inicial: 21 de junho de 2018

**Atualizações**
+ Atualizado HBase para 1.4.4
+ Atualizado Hive para 2.3.3
+ Atualizado Hue para 4.2.0
+ Atualizado Oozie para 5.0.0
+ Atualizado Zookeeper para 3.4.12
+  AWS SDK atualizado para 1.11.333

**Alterações, melhorias e problemas resolvidos**
+ Hive
  + Backport do [HIVE-18069](https://issues.apache.org/jira/browse/HIVE-18069)
+ Hue
  + Atualizado o Hue para se autenticar corretamente com o Livy quando o Kerberos está habilitado. Agora, o Livy é compatível quando usa o Kerberos com o Amazon EMR.
+ JupyterHub
  + Atualizado JupyterHub para que o Amazon EMR instale bibliotecas de clientes LDAP por padrão.
  + Corrigido um erro no script que gera certificados autoassinados. 

**Problemas conhecidos**
+ Essa versão não é compatível com os tipos de instância c1.medium ou m1.small. Os clusters que usam qualquer um desses tipos de instância não são iniciados. Como solução alternativa, especifique um tipo de instância diferente ou use uma versão diferente.
+ Depois que o nó primário for reinicializado ou o controlador de instância for reiniciado, as CloudWatch métricas não serão coletadas e o recurso de escalabilidade automática não estará disponível nas versões 5.14.0, 5.15.0 ou 5.16.0 do Amazon EMR. Esse problema foi corrigido na versão 5.17.0 do Amazon EMR. 

## Versão 5.14.1
<a name="emr-5141-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.14.1 do Amazon EMR. As alterações são referentes à versão 5.14.0.

Data da versão inicial: 17 de outubro de 2018

Atualizada a AMI padrão para Amazon EMR para abordar possíveis vulnerabilidades de segurança.

## Versão 5.14.0
<a name="emr-5140-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.14.0 do Amazon EMR. As alterações são referentes à versão 5.13.0.

Data da versão inicial: 4 de junho de 2018

**Atualizações**
+ Atualizado Apache Flink para 1.4.2
+ Apache MXnet atualizado para 1.1.0
+ Atualizado Apache Sqoop para 1.4.7

**Novos recursos**
+  JupyterHub Suporte adicionado. Para obter mais informações, consulte [JupyterHub](emr-jupyterhub.md).

**Alterações, melhorias e problemas resolvidos**
+ EMRFS
  + A string userAgent nas solicitações ao Amazon S3 foi atualizada para conter as informações de usuário e grupo da entidade principal invocadora. Isso pode ser usado com AWS CloudTrail registros para um rastreamento de solicitações mais abrangente.
+ HBase
  +  Incluído o [HBASE-20447](https://issues.apache.org/jira/browse/HBASE-20447), que aborda um problema que poderia causar falhas de cache, especialmente com regiões divididas. 
+ MXnet
  + Adicionadas bibliotecas OpenCV.
+ Spark
  + Quando o Spark grava arquivos Parquet em um local do Amazon S3 usando o EMRFS, FileOutputCommitter o algoritmo foi atualizado para usar a versão 2 em vez da versão 1. Isso reduz o número de renomeações, o que melhora a performance da aplicação. Essa alteração não afeta: 
    + Aplicações diferentes do Spark. 
    + Aplicativos que gravam em outros sistemas de arquivos, como o HDFS (que ainda usa a versão 1 do FileOutputCommitter).
    + Aplicações que usam outros formatos de saída, como texto ou csv, que já usam a gravação direta do EMRFS.

**Problemas conhecidos**
+ JupyterHub
  + O uso de classificações de configuração para configurar JupyterHub notebooks Jupyter individuais ao criar um cluster não é suportado. Edite manualmente o arquivo jupyterhub\$1config.py e os arquivos jupyter\$1notebook\$1config.py para cada usuário. Para obter mais informações, consulte [Configurando JupyterHub](emr-jupyterhub-configure.md).
  + JupyterHub falha ao iniciar em clusters dentro de uma sub-rede privada, falhando com a mensagem. `Error: ENOENT: no such file or directory, open '/etc/jupyter/conf/server.crt' ` Isso é causado por um erro no script que gera certificados autoassinados. Use a solução alternativa a seguir para gerar certificados autoassinados. Todos os comandos são executados enquanto estão conectados ao nó primário.

    1. Copie o script de geração de certificados do contêiner para o nó primário:

       ```
       sudo docker cp jupyterhub:/tmp/gen_self_signed_cert.sh ./
       ```

    1. Use um editor de texto para alterar a linha 23 e mudar o nome de host público para o nome deo host local, conforme mostrado abaixo:

       ```
       local hostname=$(curl -s $EC2_METADATA_SERVICE_URI/local-hostname)
       ```

    1. Execute o script para gerar certificados autoassinados:

       ```
       sudo bash ./gen_self_signed_cert.sh
       ```

    1. Mova os arquivos de certificado que o script gera para o diretório `/etc/jupyter/conf/`:

       ```
       sudo mv /tmp/server.crt /tmp/server.key /etc/jupyter/conf/
       ```

    Você pode acessar `tail` o `jupyter.log` arquivo para verificar se ele JupyterHub foi reiniciado e está retornando um código de resposta 200. Por exemplo:

    ```
    tail -f /var/log/jupyter/jupyter.log
    ```

    Essa ação deve retornar uma resposta semelhante à seguinte:

    ```
    # [I 2018-06-14 18:56:51.356 JupyterHub app:1581] JupyterHub is now running at https://:9443/
    # 19:01:51.359 - info: [ConfigProxy] 200 GET /api/routes
    ```
+ Depois que o nó primário for reinicializado ou o controlador de instância for reiniciado, as CloudWatch métricas não serão coletadas e o recurso de escalabilidade automática não estará disponível nas versões 5.14.0, 5.15.0 ou 5.16.0 do Amazon EMR. Esse problema foi corrigido na versão 5.17.0 do Amazon EMR. 

## Versão 5.13.0
<a name="emr-5130-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.13.0 do Amazon EMR. As alterações são referentes à versão 5.12.0.

**Atualizações**
+ Atualizado Spark para 2.3.0
+ Atualizado HBase para 1.4.2
+ Atualizado Presto para 0.194
+ Atualizado para AWS SDK para Java 1.11.297

**Alterações, melhorias e problemas resolvidos**
+ Hive
  + Backport do [HIVE-15436](https://issues.apache.org/jira/browse/HIVE-15436). Hive aprimorado APIs para retornar somente visualizações.

**Problemas conhecidos**
+ MXNet atualmente não tem bibliotecas OpenCV.

## Versão 5.12.2
<a name="emr-5122-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.12.2 do Amazon EMR. As alterações são referentes à versão 5.12.1.

Data da versão inicial: 29 de agosto de 2018

**Alterações, melhorias e problemas resolvidos**
+ Esta versão aborda uma possível vulnerabilidade de segurança.

## Versão 5.12.1
<a name="emr-5121-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.12.1 do Amazon EMR. As alterações são referentes à versão 5.12.0.

Data da versão inicial: 29 de março de 2018

**Alterações, melhorias e problemas resolvidos**
+ Atualizado o kernel do Amazon Linux da AMI padrão do Amazon Linux para Amazon EMR para abordar possíveis vulnerabilidades.

## Versão 5.12.0
<a name="emr-5120-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.12.0 do Amazon EMR. As alterações são referentes à versão 5.11.1.

**Atualizações**
+ AWS SDK para Java 1.11.238 ⇒ 1.11.267. Para obter mais informações, consulte o [AWS SDK for Java Change](https://github.com/aws/aws-sdk-java/blob/master/CHANGELOG.md) Log on GitHub.
+ Hadoop 2.7.3 ⇒ 2.8.3. Para obter mais informações, consulte [Versões do Apache Hadoop](http://hadoop.apache.org/releases.html).
+ Flink 1.3.2 ⇒ 1.4.0. Para obter mais informações, consulte o [Anúncio de versão do Apache Flink 1.4.0](https://flink.apache.org/news/2017/12/12/release-1.4.0.html).
+ HBase 1.3.1 ⇒ 1.4.0. Para obter mais informações, consulte o [anúncio HBase de lançamento](http://mail-archives.apache.org/mod_mbox/www-announce/201712.mbox/%3CCA+RK=_AU+tB=7SU1HRbeKVEd-sKA5WcJo3oa43vQ6PMB3L9pgQ@mail.gmail.com%3E).
+ Hue 4.0.1 ⇒ 4.1.0. Para obter mais informações, consulte as [Notas de versão](https://docs.gethue.com/releases/release-notes-4.10.0/).
+ MxNet 0,12,0 ⇒ 1,0,0. Para obter mais informações, consulte o [MXNet Change Log](https://github.com/apache/incubator-mxnet/releases/tag/1.0.0) on GitHub.
+ Presto 0.187 ⇒ 0.188. Para obter mais informações, consulte as [Notas de versão](https://prestodb.io/docs/current/release/release-0.188.html).

**Alterações, melhorias e problemas resolvidos**
+ **Hadoop**
  + A propriedade `yarn.resourcemanager.decommissioning.timeout` foi alterada para `yarn.resourcemanager.nodemanager-graceful-decommission-timeout-secs`. Você pode usar essa propriedade para personalizar a redução da escala do cluster verticalmente. Para obter mais informações, consulte [Redução da escala do cluster verticalmente](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-scaledown-behavior.html) no *Guia de gerenciamento do Amazon EMR*.
  + A CLI do Hadoop adicionou a opção `-d` ao comando `cp` (copy), que especifica cópia direta. Você pode usar isso para evitar a criação de um arquivo `.COPYING` intermediário, o que torna mais rápida a cópia de dados entre o Amazon S3. Para obter mais informações, consulte [HADOOP-12384](https://issues.apache.org/jira/browse/HADOOP-12384).
+ **Pig**
  + Adicionada a classificação de configuração `pig-env`, que simplifica a configuração das propriedades do ambiente do Pig. Para obter mais informações, consulte [Configurar aplicações](emr-configure-apps.md).
+ **Presto**
  + Adicionada a classificação de configuração `presto-connector-redshift`, que pode ser usada para configurar os valores no arquivo de configuração `redshift.properties` do Presto. Para obter mais informações, consulte [Conector do Redshift](https://prestodb.io/docs/current/connector/redshift.html) na documentação do Presto e [Configurar aplicações](emr-configure-apps.md).
  + O suporte do Presto para EMRFS foi adicionado e é a configuração padrão. As versões anteriores do Amazon EMR usavam o PrestOS3FileSystem, que era a única opção. Para obter mais informações, consulte [Configuração do EMRFS e do PrestOS3 FileSystem](emr-presto-considerations.md#emr-presto-prestos3).
**nota**  
Se você consultar dados subjacentes no Amazon S3 com a versão 5.12.0 do Amazon EMR, poderão ocorrer erros no Presto. Isso acontece porque o Presto não consegue obter valores de classificação de configuração em `emrfs-site.xml`. Como solução alternativa, crie um subdiretório `emrfs` em `usr/lib/presto/plugin/hive-hadoop2/` e crie um link simbólico em `usr/lib/presto/plugin/hive-hadoop2/emrfs` para o arquivo `/usr/share/aws/emr/emrfs/conf/emrfs-site.xml` existente. Em seguida, reinicie o processo presto-server (`sudo presto-server stop` seguido por `sudo presto-server start`).
+ **Spark**
  + [SPARK-22036 retroportado: a BigDecimal multiplicação](https://issues.apache.org/jira/browse/SPARK-22036) às vezes retorna nula.

**Problemas conhecidos**
+ MXNet não inclui bibliotecas OpenCV.
+ O SparkR não está disponível para clusters criados usando uma AMI personalizada porque R não é instalado por padrão nos nós do cluster.

## Versão 5.11.3
<a name="emr-5113-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.11.3 do Amazon EMR. As alterações são referentes à versão 5.11.2.

Data da versão inicial: 18 de julho de 2019

**Alterações, melhorias e problemas resolvidos**
+ Atualizada a AMI padrão do Amazon Linux para Amazon EMR para incluir atualizações de segurança importantes do kernel Linux, incluindo o problema de negação de serviço do TCP SACK ([AWS-2019-005](https://aws.amazon.com/security/security-bulletins/AWS-2019-005/)).

## Versão 5.11.2
<a name="emr-5112-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.11.2 do Amazon EMR. As alterações são referentes à versão 5.11.1.

Data da versão inicial: 29 de agosto de 2018

**Alterações, melhorias e problemas resolvidos**
+ Esta versão aborda uma possível vulnerabilidade de segurança.

## Versão 5.11.1
<a name="emr-5111-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.11.1 do Amazon EMR. As alterações são referentes à versão 5.11.0 do Amazon EMR.

Data da versão inicial: 22 de janeiro de 2018

### Alterações, melhorias e problemas resolvidos
<a name="emr-5111-enhancements"></a>
+ Atualizado o kernel do Amazon Linux da AMI padrão do Amazon Linux para Amazon EMR para abordar vulnerabilidades associadas à execução especulativa (CVE-2017-5715, CVE-2017-5753 e CVE-2017-5754). Para obter mais informações, consulte [https://aws.amazon.com/security/security-bulletins/AWS-2018-013/](https://aws.amazon.com/security/security-bulletins/AWS-2018-013/).

### Problemas conhecidos
<a name="emr-5111-known-issues"></a>
+ MXNet não inclui bibliotecas OpenCV.
+ Por padrão, o Hive 2.3.2 define `hive.compute.query.using.stats=true`. Isso faz com que as consultas obtenham dados de estatísticas existentes em vez de diretamente dos dados, o que pode gerar confusão. Por exemplo, se você tiver uma tabela com `hive.compute.query.using.stats=true` e fizer upload de novos arquivos para a tabela `LOCATION`, a execução de uma consulta `SELECT COUNT(*)` na tabela retornará a contagem das estatísticas, e não selecionará as linhas adicionadas.

  Como alternativa, use o comando `ANALYZE TABLE` para reunir novas estatísticas ou defina `hive.compute.query.using.stats=false`. Para obter mais informações, consulte [Estatísticas no Hive](https://cwiki.apache.org/confluence/display/Hive/StatsDev#StatsDev-ExistingTables–ANALYZE) na documentação do Apache Hive.

## Versão 5.11.0
<a name="emr-5110-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.11.0 do Amazon EMR. As alterações são referentes à versão 5.10.0 do Amazon EMR.

### Atualizações
<a name="emr-5110-upgrades"></a>

Os aplicativos e os componentes a seguir foram atualizados nesta versão para incluir as seguintes versões.
+ Hive 2.3.2
+ Spark 2.2.1
+ SDK para Java 1.11.238

### Novos recursos
<a name="emr-5110-new-features"></a>
+ **Spark**
  + Adicionada a configuração `spark.decommissioning.timeout.threshold`, que aprimora o comportamento de desativação do Spark ao usar instâncias spot. Para obter mais informações, consulte [Configurar o comportamento de desativação de nós](emr-spark-configure.md#spark-decommissioning).
  + [Foi adicionado o `aws-sagemaker-spark-sdk` componente ao Spark, que instala o Amazon SageMaker Spark e as dependências associadas para a integração do Spark com a Amazon. SageMaker](https://aws.amazon.com/sagemaker/) Você pode usar o Amazon SageMaker Spark para criar pipelines de aprendizado de máquina (ML) do Spark usando os estágios da Amazon. SageMaker *Para obter mais informações, consulte o [readme do SageMaker Spark](https://github.com/aws/sagemaker-spark/blob/master/README.md) sobre GitHub e como [usar o Apache Spark com a Amazon SageMaker no Amazon Developer](https://docs.aws.amazon.com/sagemaker/latest/dg/apache-spark.html) Guide. SageMaker *

### Problemas conhecidos
<a name="emr-5110-known-issues"></a>
+ MXNet não inclui bibliotecas OpenCV.
+ Por padrão, o Hive 2.3.2 define `hive.compute.query.using.stats=true`. Isso faz com que as consultas obtenham dados de estatísticas existentes em vez de diretamente dos dados, o que pode gerar confusão. Por exemplo, se você tiver uma tabela com `hive.compute.query.using.stats=true` e fizer upload de novos arquivos para a tabela `LOCATION`, a execução de uma consulta `SELECT COUNT(*)` na tabela retornará a contagem das estatísticas, e não selecionará as linhas adicionadas.

  Como alternativa, use o comando `ANALYZE TABLE` para reunir novas estatísticas ou defina `hive.compute.query.using.stats=false`. Para obter mais informações, consulte [Estatísticas no Hive](https://cwiki.apache.org/confluence/display/Hive/StatsDev#StatsDev-ExistingTables–ANALYZE) na documentação do Apache Hive.

## Versão 5.10.0
<a name="emr-5100-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.10.0 do Amazon EMR. As alterações são referentes à versão 5.9.0 do Amazon EMR.

### Atualizações
<a name="emr-5100-upgrades"></a>

Os aplicativos e os componentes a seguir foram atualizados nesta versão para incluir as seguintes versões.
+ AWS SDK para Java 1.11.221
+ Hive 2.3.1
+ Presto 0.187

### Novos recursos
<a name="emr-5100-new-features"></a>
+ Adicionado o suporte para autenticação do Kerberos. Para obter mais informações, consulte [Usar autenticação Kerberos](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-kerberos.html) no *Guia de gerenciamento do Amazon EMR*
+ Adicionado suporte para perfis do IAM para solicitações do EMRFS para o Amazon S3. Para obter mais informações, consulte [Configurar perfis do IAM para solicitações do EMRFS para o Amazon S3](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-emrfs-iam-roles.html) no *Guia de gerenciamento do Amazon EMR*.
+ Suporte adicionado para tipos de instância P2 e P3 baseados em GPU. Para obter mais informações, consulte [Instâncias P2 do Amazon EC2](https://aws.amazon.com/ec2/instance-types/p2/) e [Instâncias P3 do Amazon EC2](https://aws.amazon.com/ec2/instance-types/p3/). Os drivers NVIDIA 384.81 e CUDA driver 9.0.176 são instalados nesses tipos de instância por padrão.
+ O suporte adicionado para [Apache MXNet](emr-mxnet.md).

### Alterações, melhorias e problemas resolvidos
<a name="emr-5100-enhancements"></a>
+ Presto
  + Foi adicionado suporte para usar o AWS Glue Data Catalog como metastore padrão do Hive. Para obter mais informações, consulte [Usando o Presto com o AWS Glue Data Catalog](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-presto.html#emr-presto-glue).
  + Suporte adicionado para [funções geoespaciais](https://prestodb.io/docs/current/functions/geospatial.html).
  + Suporte de [vazamento para disco](https://prestodb.io/docs/current/admin/spill.html) adicionado para uniões.
  + Suporte adicionado para o [Conector Redshift](https://prestodb.io/docs/current/connector/redshift.html).
+ Spark
  + Backport [SPARK-20640](https://issues.apache.org/jira/browse/SPARK-20640), que causa tempo limite rpc e as repetições de valores de registro configuráveis usando as propriedades `spark.shuffle.registration.timeout` e `spark.shuffle.registration.maxAttempts`.
  + [SPARK-21549](https://issues.apache.org/jira/browse/SPARK-21549) retroportado, que corrige um erro que ocorre ao gravar de forma personalizada em locais não HDFS. OutputFormat 
+ Backport [Hadoop-13270](https://issues.apache.org/jira/browse/HADOOP-13270)
+ As bibliotecas Numpy, Scipy e Matplotlib foram removidas da AMI base do Amazon EMR. Se forem necessárias para o aplicativo, essas bibliotecas estarão disponíveis no repositório do aplicativo. Portanto, você pode usar uma ação de bootstrap para instalá-las em todos os nós usando `yum install`.
+ A AMI base do Amazon EMR não tem mais pacotes do RPM de aplicações incluídos, de maneira que os pacotes do RPM não estão mais presentes em nós de cluster. A AMI personalizada AMIs e a AMI básica do Amazon EMR agora fazem referência ao repositório de pacotes RPM no Amazon S3.
+ Devido à introdução de faturamento por segundo no Amazon EC2, o **Comportamento padrão da redução da escala verticalmente** agora é **Encerrar na conclusão da tarefa** em vez de **Encerrar no horário da instância**. Para obter mais informações, consulte [Configurar redução da escala verticalmente do cluster](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-scaledown-behavior.html).

### Problemas conhecidos
<a name="emr-5100-known-issues"></a>
+ MXNet não inclui bibliotecas OpenCV.
+ Por padrão, o Hive 2.3.1 define `hive.compute.query.using.stats=true`. Isso faz com que as consultas obtenham dados de estatísticas existentes em vez de diretamente dos dados, o que pode gerar confusão. Por exemplo, se você tiver uma tabela com `hive.compute.query.using.stats=true` e fizer upload de novos arquivos para a tabela `LOCATION`, a execução de uma consulta `SELECT COUNT(*)` na tabela retornará a contagem das estatísticas, e não selecionará as linhas adicionadas.

  Como alternativa, use o comando `ANALYZE TABLE` para reunir novas estatísticas ou defina `hive.compute.query.using.stats=false`. Para obter mais informações, consulte [Estatísticas no Hive](https://cwiki.apache.org/confluence/display/Hive/StatsDev#StatsDev-ExistingTables–ANALYZE) na documentação do Apache Hive.

## Versão 5.9.0
<a name="emr-590-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.9.0 do Amazon EMR. As alterações são referentes à versão 5.8.0 do Amazon EMR.

Data do release: 5 de outubro de 2017

Última atualização de recursos: 12 de outubro de 2017

### Atualizações
<a name="emr-590-upgrades"></a>

Os aplicativos e os componentes a seguir foram atualizados nesta versão para incluir as seguintes versões.
+ AWS SDK para Java versão 1.11.183
+ Flink 1.3.2
+ Hue 4.0.1
+ Pig 0.17.0
+ Presto 0.184

### Novos recursos
<a name="emr-590-new-features"></a>
+ Adição do suporte ao Livy (versão Livy 0.4.0 - em incubação). Para obter mais informações, consulte [Apache Livy](emr-livy.md).
+ Adição de suporte para Hue Notebook para Spark.
+ Adicionado suporte para instâncias série i3 do Amazon EC2 (12 de outubro de 2017).

### Alterações, melhorias e problemas resolvidos
<a name="emr-590-enhancements"></a>
+ Spark
  + Adição de um novo conjunto de recursos que ajudam a garantir que o Spark lide de uma forma mais fácil com o encerramento de nós devido a um redimensionamento manual ou uma solicitação de política de escalabilidade automática. Para obter mais informações, consulte [Configurar o comportamento de desativação de nós](emr-spark-configure.md#spark-decommissioning).
  + O SSL é usado em vez do 3DES para criptografia em trânsito para o serviço de transferência de bloco, o que aumenta a performance durante o uso dos tipos de instância do Amazon EC2 com AES-NI.
  + [SPARK-21494](https://issues.apache.org/jira/browse/SPARK-21494) enviado para backport.
+ Zeppelin
  + [ZEPPELIN-2377](https://issues.apache.org/jira/browse/ZEPPELIN-2377) enviado para backport.
+ HBase
  + Foi adicionado o patch [HBASE-18533](https://issues.apache.org/jira/browse/HBASE-18533), que permite valores adicionais para HBase BucketCache configuração usando a classificação de configuração. `hbase-site`
+ Hue
  + Foi adicionado suporte ao AWS Glue Data Catalog para o editor de consultas Hive no Hue.
  + Por padrão, os superusuários do Hue podem acessar todos os arquivos que os perfis do IAM do Amazon EMR têm permissão para acessar. Os usuários recém-criados não têm automaticamente permissões para acessar o navegador de arquivos Amazon S3 e devem ter as permissões `filebrowser.s3_access` ativadas para o grupo deles.
+ Resolvido um problema que fazia com que os dados JSON subjacentes criados com o Catálogo de Dados do AWS Glue ficassem inacessíveis.

### Problemas conhecidos
<a name="emr-590-known-issues"></a>
+ A inicialização do cluster falha quando todas as aplicações são instaladas e o tamanho padrão do volume raiz do Amazon EBS não é alterado. Como solução alternativa, use o `aws emr create-cluster` comando do AWS CLI e especifique um `--ebs-root-volume-size` parâmetro maior.
+ Por padrão, o Hive 2.3.0 define `hive.compute.query.using.stats=true`. Isso faz com que as consultas obtenham dados de estatísticas existentes em vez de diretamente dos dados, o que pode gerar confusão. Por exemplo, se você tiver uma tabela com `hive.compute.query.using.stats=true` e fizer upload de novos arquivos para a tabela `LOCATION`, a execução de uma consulta `SELECT COUNT(*)` na tabela retornará a contagem das estatísticas, e não selecionará as linhas adicionadas.

  Como alternativa, use o comando `ANALYZE TABLE` para reunir novas estatísticas ou defina `hive.compute.query.using.stats=false`. Para obter mais informações, consulte [Estatísticas no Hive](https://cwiki.apache.org/confluence/display/Hive/StatsDev#StatsDev-ExistingTables–ANALYZE) na documentação do Apache Hive.

## Versão 5.8.2
<a name="emr-582-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.8.2 do Amazon EMR. As alterações são referentes à versão 5.8.1.

Data da versão inicial: 29 de março de 2018

**Alterações, melhorias e problemas resolvidos**
+ Atualizado o kernel do Amazon Linux da AMI padrão do Amazon Linux para Amazon EMR para abordar possíveis vulnerabilidades.

## Versão 5.8.1
<a name="emr-581-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.8.1 do Amazon EMR. As alterações são referentes à versão 5.8.0 do Amazon EMR.

Data da versão inicial: 22 de janeiro de 2018

### Alterações, melhorias e problemas resolvidos
<a name="emr-581-enhancements"></a>
+ Atualizado o kernel do Amazon Linux da AMI padrão do Amazon Linux para Amazon EMR para abordar vulnerabilidades associadas à execução especulativa (CVE-2017-5715, CVE-2017-5753 e CVE-2017-5754). Para obter mais informações, consulte [https://aws.amazon.com/security/security-bulletins/AWS-2018-013/](https://aws.amazon.com/security/security-bulletins/AWS-2018-013/).

## Versão 5.8.0
<a name="emr-580-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.8.0 do Amazon EMR. As alterações são referentes à versão 5.7.0 do Amazon EMR.

Data da versão inicial: 10 de agosto de 2017

Última atualização de recurso: 25 de setembro de 2017

### Atualizações
<a name="emr-580-upgrades"></a>

Os aplicativos e os componentes a seguir foram atualizados nesta versão para incluir as seguintes versões:
+ AWS SDK 1.11.160
+ Flink 1.3.1
+ Hive 2.3.0. Para obter mais informações, consulte [Notas de versão](https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectId=12310843&version=12340269) no site do Apache Hive.
+ Spark 2.2.0. Para obter mais informações, consulte [Notas de versão](https://spark.apache.org/releases/spark-release-2-2-0.html) no site do Apache Spark.

### Novos recursos
<a name="emr-580-new-features"></a>
+ Adição de suporte para visualização do histórico de aplicativos (25 de setembro de 2017). Para obter mais informações, consulte [Visualizar histórico de aplicações](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-cluster-application-history.html) no *Guia de gerenciamento do Amazon EMR*.

### Alterações, melhorias e problemas resolvidos
<a name="emr-580-enhancements"></a>
+ **Integração com o AWS Glue Data Catalog**
  + Foi adicionada a capacidade do Hive e do Spark SQL de usar o AWS Glue Data Catalog como armazenamento de metadados do Hive. Para obter mais informações, consulte [Usando o AWS Glue Data Catalog como metastore para o Hive](emr-hive-metastore-glue.md) e [Use o catálogo do AWS Glue Data Catalog com o Spark no Amazon EMR](emr-spark-glue.md).
+ Adicionado o **Application history (Histórico do aplicativo)** aos detalhes do cluster, o que permite que você visualize dados históricos de aplicativos do YARN e detalhes adicionais de aplicativos do Spark. Para obter mais informações, consulte [Visualizar histórico de aplicações](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-cluster-application-history.html) no *Guia de gerenciamento do Amazon EMR*.
+ **Oozie**
  + [OOZIE-2748](https://issues.apache.org/jira/browse/OOZIE-2748) enviado para backport.
+ **Hue**
  + [HUE-5859](https://issues.cloudera.org/browse/HUE-5859) enviado para backport
+ **HBase**
  + Foi adicionado um patch para expor a hora de início do servidor HBase mestre por meio do Java Management Extensions (JMX) usando. `getMasterInitializedTime`
  + Adicionado um patch que melhora a hora de início do cluster.

### Problemas conhecidos
<a name="emr-580-known-issues"></a>
+ A inicialização do cluster falha quando todas as aplicações são instaladas e o tamanho padrão do volume raiz do Amazon EBS não é alterado. Como solução alternativa, use o `aws emr create-cluster` comando do AWS CLI e especifique um `--ebs-root-volume-size` parâmetro maior.
+ Por padrão, o Hive 2.3.0 define `hive.compute.query.using.stats=true`. Isso faz com que as consultas obtenham dados de estatísticas existentes em vez de diretamente dos dados, o que pode gerar confusão. Por exemplo, se você tiver uma tabela com `hive.compute.query.using.stats=true` e fizer upload de novos arquivos para a tabela `LOCATION`, a execução de uma consulta `SELECT COUNT(*)` na tabela retornará a contagem das estatísticas, e não selecionará as linhas adicionadas.

  Como alternativa, use o comando `ANALYZE TABLE` para reunir novas estatísticas ou defina `hive.compute.query.using.stats=false`. Para obter mais informações, consulte [Estatísticas no Hive](https://cwiki.apache.org/confluence/display/Hive/StatsDev#StatsDev-ExistingTables–ANALYZE) na documentação do Apache Hive.
+ **Spark**: ao usar o Spark, há um problema de vazamento no manipulador de arquivos com o daemon apppusher, o que pode ocorrer para um trabalho de execução prolongada do Spark depois de várias horas ou dias. Para corrigir o problema, conecte-se ao nó principal e digite `sudo /etc/init.d/apppusher stop`. Isso interrompe o daemon apppusher, que o Amazon EMR reiniciará automaticamente.
+ **Application history**
  + Os dados históricos dos executores inativos do Spark não está disponível.
  + O histórico do aplicativo não está disponível para clusters que usam uma configuração de segurança para habilitar a criptografia em andamento.

## Versão 5.7.0
<a name="w2aac11c29d119"></a>

As notas da versão a seguir incluem informações para a versão 5.7.0 do Amazon EMR. As alterações são referentes à versão 5.6.0 do Amazon EMR.

Data do release: 13 de julho de 2017

### Atualizações
<a name="w2aac11c29d119b7"></a>
+ Flink 1.3.0
+ Phoenix 4.11.0
+ Zeppelin 0.7.2

### Novos recursos
<a name="w2aac11c29d119b9"></a>
+ Adicionada a possibilidade de especificar uma AMI do Amazon Linux personalizada ao criar um cluster. Para obter mais informações, consulte [Usar uma AMI personalizada](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-custom-ami.html).

### Alterações, melhorias e problemas resolvidos
<a name="w2aac11c29d119c11"></a>
+ **HBase**
  + Capacidade adicional para configurar clusters de HBase réplica de leitura. Consulte [Usar um cluster de réplica de leitura.](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hbase-s3.html#emr-hbase-s3-read-replica)
  + Várias correções de erros e melhorias
+ **Presto**: adicionada a capacidade de configurar `node.properties`.
+ **YARN** :adicionada a capacidade de configurar `container-log4j.properties`
+ **Sqoop**: enviado para backport [SQOOP-2880](https://issues.apache.org/jira/browse/SQOOP-2880), que apresenta um argumento que permite definir o diretório temporário do Sqoop.

## Versão 5.6.0
<a name="w2aac11c29d121"></a>

As notas da versão a seguir incluem informações para a versão 5.6.0 do Amazon EMR. As alterações são referentes à versão 5.5.0 do Amazon EMR.

Data do release: 5 de junho de 2017

### Atualizações
<a name="w2aac11c29d121b7"></a>
+ Flink 1.2.1
+ HBase 1.3.1
+ Mahout 0.13.0. Esta é a primeira versão do Mahout compatível com o Spark 2.x nas versões 5.0 e posteriores do Amazon EMR.
+ Spark 2.1.1

### Alterações, melhorias e problemas resolvidos
<a name="w2aac11c29d121b9"></a>
+ **Presto**
  + Foi adicionada a capacidade de permitir a comunicação SSL/TLS segura entre os nós do Presto, ativando a criptografia em trânsito usando uma configuração de segurança. Para obter mais informações, consulte [Criptografia de dados em trânsito](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-data-encryption-options.html#emr-encryption-intransit).
  + [Presto 7661](https://github.com/prestodb/presto/pull/7661/commits) enviado para backport, adiciona a opção `VERBOSE` à instrução `EXPLAIN ANALYZE` para relatar estatísticas de baixo nível mais detalhadas sobre um plano de consulta.

## Versão 5.5.3
<a name="emr-553-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.5.3 do Amazon EMR. As alterações são referentes à versão 5.5.2.

Data da versão inicial: 29 de agosto de 2018

**Alterações, melhorias e problemas resolvidos**
+ Esta versão aborda uma possível vulnerabilidade de segurança.

## Versão 5.5.2
<a name="emr-552-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.5.2 do Amazon EMR. As alterações são referentes à versão 5.5.1.

Data da versão inicial: 29 de março de 2018

**Alterações, melhorias e problemas resolvidos**
+ Atualizado o kernel do Amazon Linux da AMI padrão do Amazon Linux para Amazon EMR para abordar possíveis vulnerabilidades.

## Versão 5.5.1
<a name="emr-551-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.5.1 do Amazon EMR. As alterações são referentes à versão 5.5.0 do Amazon EMR.

Data da versão inicial: 22 de janeiro de 2018

### Alterações, melhorias e problemas resolvidos
<a name="emr-551-enhancements"></a>
+ Atualizado o kernel do Amazon Linux da AMI padrão do Amazon Linux para Amazon EMR para abordar vulnerabilidades associadas à execução especulativa (CVE-2017-5715, CVE-2017-5753 e CVE-2017-5754). Para obter mais informações, consulte [https://aws.amazon.com/security/security-bulletins/AWS-2018-013/](https://aws.amazon.com/security/security-bulletins/AWS-2018-013/).

## Versão 5.5.0
<a name="w2aac11c29d129"></a>

As notas da versão a seguir incluem informações para a versão 5.5.0 do Amazon EMR. As alterações são referentes à versão 5.4.0 do Amazon EMR.

Data do release: 26 de abril de 2017

### Atualizações
<a name="w2aac11c29d129b7"></a>
+ Hue 3.12
+ Presto 0.170
+ Zeppelin 0.7.1
+ ZooKeeper 3.4.10

### Alterações, melhorias e problemas resolvidos
<a name="w2aac11c29d129b9"></a>
+ **Spark**
  + [Correção do Backported Spark Patch (SPARK-20115) DAGScheduler para recalcular todos os blocos de reprodução aleatória perdidos quando o serviço externo de reprodução aleatória não está disponível na versão 2.1.0 do Spark](https://issues.apache.org/jira/browse/SPARK-20115), incluída nesta versão.
+ **Flink**
  + O Flink agora é compilado com o Scala 2.11. Se você usar a API e as bibliotecas do Scala, recomendamos que use o Scala 2.11 em seus projetos.
  + Tratado um problema em que os padrões `HADOOP_CONF_DIR` e `YARN_CONF_DIR` não estavam definidos corretamente, portanto havia falha no funcionamento de `start-scala-shell.sh`. Também foi adicionada a possibilidade de definir esses valores usando `env.hadoop.conf.dir` e `env.yarn.conf.dir` em `/etc/flink/conf/flink-conf.yaml` ou na classificação de configuração `flink-conf`.
  + Introduzido um novo comando específico do EMR, `flink-scala-shell`, como um wrapper para `start-scala-shell.sh`. Recomendamos o uso desse comando, em vez de `start-scala-shell`. O novo comando simplifica a execução. Por exemplo, `flink-scala-shell -n 2` inicia um shell Scala Flink com um paralelismo de tarefa de 2.
  + Introduzido um novo comando específico do EMR, `flink-yarn-session`, como um wrapper para `yarn-session.sh`. Recomendamos o uso desse comando, em vez de `yarn-session`. O novo comando simplifica a execução. Por exemplo, `flink-yarn-session -d -n 2` inicia uma sessão de longa execução do Flink em um estado desanexado com dois gerenciadores de tarefas. 
  + Resolvido [(FLINK-6125) commons httpclient não está mais esmaecido no Flink 1.2](https://issues.apache.org/jira/browse/FLINK-6125).
+ **Presto**
  + Adicionado o suporte para autenticação do LDAP. Usar LDAP com o Presto no Amazon EMR requer que você habilite o acesso HTTPS para o coordenador do Presto (`http-server.https.enabled=true` em `config.properties`). Para obter detalhes da configuração, consulte [Autenticação LDAP](https://prestodb.io/docs/current/security/ldap.html) na documentação do Presto.
  + O suporte adicionado para `SHOW GRANTS`.
+ **AMI base do Linux do Amazon EMR**
  + As versões do Amazon EMR agora são baseadas no Amazon Linux 2017.03. Para obter mais informações, consulte [Notas da versão da AMI do Amazon Linux 2017.03](https://aws.amazon.com/amazon-linux-ami/2017.03-release-notes/).
  + Removido o Python 2.6 da imagem de base Linux do Amazon EMR. Python 2.7 e 3.4 estão instalados por padrão. Você pode instalar o Python 2.6 manualmente, se necessário.

## Versão 5.4.0
<a name="w2aac11c29d131"></a>

As notas da versão a seguir incluem informações para a versão 5.4.0 do Amazon EMR. As alterações são referentes à versão 5.3.0 do Amazon EMR.

Data do release: 08 de março de 2017

### Atualizações
<a name="w2aac11c29d131b7"></a>

As seguintes atualizações estão disponíveis nesta versão:
+ Atualizado para Flink 1.2.0
+ Atualizado para Hbase 1.3.0
+ Atualizado para Phoenix 4.9.0
**nota**  
Se você fez a atualização de uma versão mais antiga do Amazon EMR para a versão 5.4.0 ou posterior do Amazon EMR e usa indexação secundária, atualize os índices locais conforme descrito na [documentação do Apache Phoenix](https://phoenix.apache.org/secondary_indexing.html#Upgrading_Local_Indexes_created_before_4.8.0). O Amazon EMR remove as configurações necessárias da classificação do `hbase-site`, mas os índices precisam ser preenchidos novamente. O sistema oferece suporte a atualizações de índices online e offline. As atualizações online são o padrão, o que significa que os índices são preenchidos novamente durante a inicialização de clientes do Phoenix versão 4.8.0 ou posterior. Para especificar as atualizações offline, defina a configuração do `phoenix.client.localIndexUpgrade` como falsa na classificação do `phoenix-site` e, em seguida, execute o SSH no nó principal para executar o `psql [zookeeper] -1`.
+ Atualizado para Presto 0.166
+ Atualizado para Zeppelin 0.7.0

### Alterações e melhorias
<a name="w2aac11c29d131b9"></a>

As seguintes alterações foram feitas nas versões do Amazon EMR com o rótulo de versão emr-5.4.0:
+ Adicionado o suporte para instâncias r4. Consulte [Tipos de instância do Amazon EC2](https://aws.amazon.com/ec2/instance-types/).

## Versão 5.3.1
<a name="emr-531-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 5.3.1 do Amazon EMR. As alterações são referentes à versão 5.3.0 do Amazon EMR.

Data da versão: 7 de fevereiro de 2017

Pequenas alterações nos patches do Zeppelin de backport e na atualização da AMI padrão para o Amazon EMR.

## Versão 5.3.0
<a name="w2aac11c29d135"></a>

As notas da versão a seguir incluem informações para a versão 5.3.0 do Amazon EMR. As alterações são referentes à versão 5.2.1 do Amazon EMR.

Data do release: 26 de janeiro de 2017

### Atualizações
<a name="w2aac11c29d135b7"></a>

As seguintes atualizações estão disponíveis nesta versão:
+ Atualizado para Hive 2.1.1
+ Atualizado para Hue 3.11.0
+ Atualizado para Spark 2.1.0
+ Atualizado para Oozie 4.3.0
+ Atualizado para Flink 1.1.4

### Alterações e melhorias
<a name="w2aac11c29d135b9"></a>

As seguintes alterações foram feitas nas versões do Amazon EMR com o rótulo de versão emr-5.3.0:
+ Adicionado um patch para o Hue que permite usar a configuração `interpreters_shown_on_wheel` para definir o que intérpretes mostram primeiro na roda de seleção do bloco de anotações, independentemente de sua ordem no arquivo `hue.ini`.
+ Adicionada a classificação de configuração `hive-parquet-logging`, que pode ser usada para configurar os valores no arquivo `parquet-logging.properties` do Hive.

## Versão 5.2.2
<a name="w2aac11c29d137"></a>

As notas da versão a seguir incluem informações para a versão 5.2.2 do Amazon EMR. As alterações são referentes à versão 5.2.1 do Amazon EMR.

Data do release: 2 de maio de 2017

### Problemas conhecidos das versões anteriores que foram resolvidos
<a name="w2aac11c29d137b7"></a>
+ Backported [SPARK-194459](https://issues.apache.org/jira/browse/SPARK-19459), que soluciona um problema em que a leitura de uma tabela ORC com colunas pode falhar. char/varchar 

## Versão 5.2.1
<a name="w2aac11c29d139"></a>

As notas da versão a seguir incluem informações para a versão 5.2.1 do Amazon EMR. As alterações são referentes à versão 5.2.0 do Amazon EMR.

Data do release: 29 de dezembro de 2016

### Atualizações
<a name="w2aac11c29d139b7"></a>

As seguintes atualizações estão disponíveis nesta versão:
+ Atualizado para Presto 0.157.1. Para obter mais informações, consulte [Notas de versão do Presto](https://prestodb.io/docs/current/release/release-0.157.1.html) na documentação do Presto. 
+ Zookeeper atualizado para 3.4.9. Para obter mais informações, consulte as [notas de ZooKeeper lançamento](https://zookeeper.apache.org/doc/r3.4.9/releasenotes.html) na ZooKeeper documentação do Apache.

### Alterações e melhorias
<a name="w2aac11c29d139b9"></a>

As seguintes alterações foram feitas nas versões do Amazon EMR com o rótulo de versão emr-5.2.1:
+ Adicionado o suporte para o tipo de instância do Amazon EC2 m4.16xlarge no Amazon EMR versão 4.8.3 e posterior, com exceção das versões 5.0.0, 5.0.3 e 5.2.0.
+ As versões do Amazon EMR agora são baseadas no Amazon Linux 2016.09. Para obter mais informações, consulte [https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/](https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/).
+ A localização de caminhos de configuração do Flink e do YARN agora são definidas por padrão em `/etc/default/flink` para que você não precise definir as variáveis de ambiente `FLINK_CONF_DIR` e `HADOOP_CONF_DIR` ao executar os scripts de driver `flink` ou `yarn-session.sh` para iniciar trabalhos do Flink.
+ Foi adicionado suporte para a FlinkKinesisConsumer aula.

### Problemas conhecidos das versões anteriores que foram resolvidos
<a name="w2aac11c29d139c11"></a>
+ Corrigido um problema no Hadoop em que o ReplicationMonitor thread podia ficar preso por um longo tempo devido a uma corrida entre a replicação e a exclusão do mesmo arquivo em um grande cluster.
+ Corrigido um problema em que ControlledJob \$1toString falhava com uma exceção de ponteiro nulo (NPE) quando o status do trabalho não era atualizado com êxito.

## Versão 5.2.0
<a name="w2aac11c29d141"></a>

As notas da versão a seguir incluem informações para a versão 5.2.0 do Amazon EMR. As alterações são referentes à versão 5.1.0 do Amazon EMR.

Data do release: 21 de novembro de 2016

### Alterações e melhorias
<a name="w2aac11c29d141b7"></a>

As seguintes alterações e melhorias estão disponíveis nesta versão:
+ Adicionado o modo de armazenamento Amazon S3 para. HBase
+  Permite que você especifique uma localização do Amazon S3 para o HBase rootdir. Para obter mais informações, consulte [HBaseno Amazon S3](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hbase-s3.html).

### Atualizações
<a name="w2aac11c29d141b9"></a>

As seguintes atualizações estão disponíveis nesta versão:
+ Atualizado para Spark 2.0.2

### Problemas conhecidos das versões anteriores que foram resolvidos
<a name="w2aac11c29d141c11"></a>
+ Corrigido um problema com /mnt ficar restrito a 2 TB em tipos de instância somente EBS.
+ Corrigido um problema com o controlador de instância e com os logs do logpusher serem a saída para seus arquivos .out correspondentes, em vez de para seus arquivos normais .log configurados com log4j, que mudam de hora em hora. Os arquivos .out não mudam, portanto isso eventualmente encheria a partição /emr. Esse problema afeta somente tipos de instância de HVM (máquina virtual de hardware).

## Versão 5.1.0
<a name="w2aac11c29d143"></a>

As notas da versão a seguir incluem informações para a versão 5.1.0 do Amazon EMR. As alterações são referentes à versão 5.0.0 do Amazon EMR.

Data do release: 03 de novembro de 2016

### Alterações e melhorias
<a name="w2aac11c29d143b7"></a>

As seguintes alterações e melhorias estão disponíveis nesta versão:
+ Adicionado o suporte para Flink 1.1.3.
+ O Presto foi adicionado como uma opção na seção bloco de anotações do Hue.

### Atualizações
<a name="w2aac11c29d143b9"></a>

As seguintes atualizações estão disponíveis nesta versão:
+ Atualizado para 1.2.3 HBase 
+ Atualizado para Zeppelin 0.6.2

### Problemas conhecidos das versões anteriores que foram resolvidos
<a name="w2aac11c29d143c11"></a>
+ Corrigido um problema com consultas do Tez no Amazon S3 com arquivos ORC que não tinham uma performance tão boa quanto em versões 4.x anteriores do Amazon EMR.

## Versão 5.0.3
<a name="w2aac11c29d145"></a>

As notas da versão a seguir incluem informações para a versão 5.0.3 do Amazon EMR. As alterações são referentes à versão 5.0.0 do Amazon EMR.

Data do release: 24 de outubro de 2016

### Atualizações
<a name="w2aac11c29d145b7"></a>

As seguintes atualizações estão disponíveis nesta versão:
+ Atualizado para Hadoop 2.7.3
+ Atualizado para Presto 0.152.3, que inclui o suporte para a interface da web do Presto. Você pode acessar a interface da web do Presto no coordenador do Presto usando a porta 8889. Para obter mais informações sobre a interface da Web do Presto, consulte [Interface da Web](https://prestodb.io/docs/current/admin/web-interface.html) na documentação do Presto.
+ Atualizado para Spark 2.0.1
+ As versões do Amazon EMR agora são baseadas no Amazon Linux 2016.09. Para obter mais informações, consulte [https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/](https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/).

## Versão 5.0.0
<a name="w2aac11c29d147"></a>

 Data do release: 27 de julho de 2016

### Atualizações
<a name="w2aac11c29d147b5"></a>

As seguintes atualizações estão disponíveis nesta versão:
+ Atualizado para Hive 2.1
+ Atualizado para Presto 0.150
+ Atualizado para Spark 2.0
+ Atualizado para Hue 3.10.0
+ Atualizado para Pig 0.16.0
+ Atualizado para Tez 0.8.4
+ Atualizado para Zeppelin 0.6.1

### Alterações e melhorias
<a name="w2aac11c29d147b7"></a>

As seguintes alterações foram feitas nas versões do Amazon EMR com o rótulo de versão emr-5.0.0 ou posterior:
+ O Amazon EMR é compatível com as versões de código aberto mais recentes do Hive (versão 2.1) e do Pig (versão 0.16.0). Se, anteriormente, você tiver usado o Hive ou Pig no Amazon EMR, isso poderá afetar alguns casos de uso. Para obter mais informações, consulte [Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive.html) e [Pig](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-pig.html).
+ O mecanismo de execução padrão para o Hive e o Pig agora é o Tez. Para alterar isso, você deve editar os valores apropriados nas classificações de configuração `hive-site` e `pig-properties`, respectivamente.
+ Um recurso de etapa aprimorada de depuração foi adicionado, o que permite que você veja a causa raiz de falhas de etapa se o serviço puder determinar a causa. Para obter mais informações, consulte [Depuração de etapa aprimorada](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-enhanced-step-debugging.html) no Guia de gerenciamento do Amazon EMR.
+ Os aplicativos que, anteriormente, terminavam com "-Sandbox" não têm mais esse sufixo. Isso pode inutilizar sua automação, por exemplo, se você estiver usando scripts para iniciar clusters com esses aplicativos. A tabela a seguir mostra nomes de aplicações na versão 4.7.2 do Amazon EMR em relação à versão 5.0.0 do Amazon EMR.   
**Alterações dos nomes de aplicativos**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-whatsnew-history.html)
+ O Spark agora está compilado para Scala 2.11.
+ Java 8 é agora o JVM padrão. Todas as aplicações são executadas usando o runtime do Java 8. Não há alterações em qualquer destino de código de bytes da aplicação. A maioria dos aplicativos continuam a usar o Java 7 como destino.
+ O Zeppelin agora inclui recursos de autenticação. Para obter mais informações, consulte [Zeppelin](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-zeppelin.html).
+ Adicionado o suporte para configurações de segurança, que permitem criar e aplicar opções de criptografia com mais facilidade. Para obter mais informações, consulte [Criptografia de dados](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-data-encryption.html).

## Versão 4.9.5
<a name="emr-495-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 4.9.5 do Amazon EMR. As alterações são referentes à versão 4.9.4.

Data da versão inicial: 29 de agosto de 2018

**Alterações, melhorias e problemas resolvidos**
+ HBase
  + Esta versão aborda uma possível vulnerabilidade de segurança.

## Versão 4.9.4
<a name="emr-494-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 4.9.4 do Amazon EMR. As alterações são referentes à versão 4.9.3.

Data da versão inicial: 29 de março de 2018

**Alterações, melhorias e problemas resolvidos**
+ Atualizado o kernel do Amazon Linux da AMI padrão do Amazon Linux para Amazon EMR para abordar possíveis vulnerabilidades.

## Versão 4.9.3
<a name="emr-493-whatsnew"></a>

As notas da versão a seguir incluem informações para a versão 4.9.3 do Amazon EMR. As alterações são referentes à versão 4.9.2 do Amazon EMR.

Data da versão inicial: 22 de janeiro de 2018

### Alterações, melhorias e problemas resolvidos
<a name="emr-493-enhancements"></a>
+ Atualizado o kernel do Amazon Linux da AMI padrão do Amazon Linux para Amazon EMR para abordar vulnerabilidades associadas à execução especulativa (CVE-2017-5715, CVE-2017-5753 e CVE-2017-5754). Para obter mais informações, consulte [https://aws.amazon.com/security/security-bulletins/AWS-2018-013/](https://aws.amazon.com/security/security-bulletins/AWS-2018-013/).

## Versão 4.9.2
<a name="w2aac11c29d155"></a>

As notas da versão a seguir incluem informações para a versão 4.9.2 do Amazon EMR. As alterações são referentes à versão 4.9.1 do Amazon EMR.

Data do release: 13 de julho de 2017

Pequenas alterações, correções de erros e melhorias foram feitas nesta versão.

## Versão 4.9.1
<a name="w2aac11c29d157"></a>

As notas da versão a seguir incluem informações para a versão 4.9.1 do Amazon EMR. As alterações são referentes à versão 4.8.4 do Amazon EMR.

Data do release: 10 de abril de 2017

### Problemas conhecidos das versões anteriores que foram resolvidos
<a name="w2aac11c29d157b7"></a>
+ Envio para backport do [HIVE-9976](https://issues.apache.org/jira/browse/HIVE-9976) e do [HIVE-10106](https://issues.apache.org/jira/browse/HIVE-10106)
+ Corrigido um problema no YARN em que um grande número de nós (mais de 2.000) e de contêineres (mais de 5.000) causavam um erro de memória insuficiente, por exemplo: `"Exception in thread 'main' java.lang.OutOfMemoryError"`.

### Alterações e melhorias
<a name="w2aac11c29d157b9"></a>

As seguintes alterações foram feitas nas versões do Amazon EMR com o rótulo de versão emr-4.9.1:
+ As versões do Amazon EMR agora são baseadas no Amazon Linux 2017.03. Para obter mais informações, consulte [https://aws.amazon.com/amazon-linux-ami/2017.03-release-notes/](https://aws.amazon.com/amazon-linux-ami/2017.03-release-notes/).
+ Removido o Python 2.6 da imagem de base Linux do Amazon EMR. Você pode instalar o Python 2.6 manualmente, se necessário.

## Versão 4.8.4
<a name="w2aac11c29d159"></a>

As notas da versão a seguir incluem informações para a versão 4.8.4 do Amazon EMR. As alterações são referentes à versão 4.8.3 do Amazon EMR.

Data do release: 7 de fevereiro de 2017

Pequenas alterações, correções de erros e melhorias foram feitas nesta versão.

## Versão 4.8.3
<a name="w2aac11c29d161"></a>

As notas da versão a seguir incluem informações para a versão 4.8.3 do Amazon EMR. As alterações são referentes à versão 4.8.2 do Amazon EMR.

Data do release: 29 de dezembro de 2016

### Atualizações
<a name="w2aac11c29d161b7"></a>

As seguintes atualizações estão disponíveis nesta versão:
+ Atualizado para Presto 0.157.1. Para obter mais informações, consulte [Notas de versão do Presto](https://prestodb.io/docs/current/release/release-0.157.1.html) na documentação do Presto.
+ Atualizado para Spark 1.6.3. Para obter mais informações, consulte [Spark release notes](http://spark.apache.org/releases/spark-release-1-6-3.html) na documentação do Apache Spark.
+ Atualizado para ZooKeeper 3.4.9. Para obter mais informações, consulte as [notas de ZooKeeper lançamento](https://zookeeper.apache.org/doc/r3.4.9/releasenotes.html) na ZooKeeper documentação do Apache.

### Alterações e melhorias
<a name="w2aac11c29d161b9"></a>

As seguintes alterações foram feitas nas versões do Amazon EMR com o rótulo de versão emr-4.8.3:
+ Adicionado o suporte para o tipo de instância do Amazon EC2 m4.16xlarge no Amazon EMR versão 4.8.3 e posterior, com exceção das versões 5.0.0, 5.0.3 e 5.2.0.
+ As versões do Amazon EMR agora são baseadas no Amazon Linux 2016.09. Para obter mais informações, consulte [https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/](https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/).

### Problemas conhecidos das versões anteriores que foram resolvidos
<a name="w2aac11c29d161c11"></a>
+ Corrigido um problema no Hadoop em que o ReplicationMonitor thread podia ficar preso por um longo tempo devido a uma corrida entre a replicação e a exclusão do mesmo arquivo em um grande cluster.
+ Corrigido um problema em que ControlledJob \$1toString falhava com uma exceção de ponteiro nulo (NPE) quando o status do trabalho não era atualizado com êxito.

## Versão 4.8.2
<a name="w2aac11c29d163"></a>

As notas da versão a seguir incluem informações para a versão 4.8.2 do Amazon EMR. As alterações são referentes à versão 4.8.0 do Amazon EMR.

Data do release: 24 de outubro de 2016

### Atualizações
<a name="w2aac11c29d163b7"></a>

As seguintes atualizações estão disponíveis nesta versão:
+ Atualizado para Hadoop 2.7.3
+ Atualizado para Presto 0.152.3, que inclui o suporte para a interface da web do Presto. Você pode acessar a interface da web do Presto no coordenador do Presto usando a porta 8889. Para obter mais informações sobre a interface da Web do Presto, consulte [Interface da Web](https://prestodb.io/docs/current/admin/web-interface.html) na documentação do Presto.
+ As versões do Amazon EMR agora são baseadas no Amazon Linux 2016.09. Para obter mais informações, consulte [https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/](https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/).

## Versão 4.8.0
<a name="w2aac11c29d165"></a>

Data do release: 7 de setembro de 2016

### Atualizações
<a name="w2aac11c29d165b5"></a>

As seguintes atualizações estão disponíveis nesta versão:
+ Atualizado para 1.2.2 HBase 
+ Atualizado para Presto-Sandbox 0.151
+ Atualizado para Tez 0.8.4
+ Atualizado para Zeppelin-Sandbox 0.6.1

### Alterações e melhorias
<a name="w2aac11c29d165b7"></a>

As seguintes alterações foram feitas nas versões do Amazon EMR com o rótulo de versão emr-4.8.0:
+ Corrigido um problema no YARN em que eles ApplicationMaster tentavam limpar contêineres que não existem mais porque suas instâncias foram encerradas.
+ Corrigido o URL do hive-server2 para ações do Hive2 em exemplos do Oozie.
+ Adicionado o suporte para catálogos Presto adicionais.
+ Patches enviados para backport: [HIVE-8948](https://issues.apache.org/jira/browse/HIVE-8948), [HIVE-12679](https://issues.apache.org/jira/browse/HIVE-12679), [HIVE-13405](https://issues.apache.org/jira/browse/HIVE-13405), [PHOENIX-3116](https://issues.apache.org/jira/browse/PHOENIX-3116), [HADOOP-12689](https://issues.apache.org/jira/browse/HADOOP-12689)
+ Adicionado o suporte para configurações de segurança, que permitem criar e aplicar opções de criptografia com mais facilidade. Para obter mais informações, consulte [Criptografia de dados](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-data-encryption.html).

## Versão 4.7.2
<a name="w2aac11c29d167"></a>

As notas da versão a seguir incluem informações para a versão 4.7.2 do Amazon EMR.

Data do release: 15 de julho de 2016

### Recursos
<a name="w2aac11c29d167b7"></a>

Os seguintes recursos estão disponíveis nesta versão:
+ Atualizado para Mahout 0.12.2
+ Atualizado para Presto 0.148
+ Atualizado para Spark 1.6.2
+ Agora você pode criar um AWSCredentials provedor para uso com o EMRFS usando um URI como parâmetro. Para obter mais informações, consulte [Criar um AWSCredentials provedor para o EMRFS](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-plan-credentialsprovider.html).
+ O EMRFS agora permite que os usuários configurem um endpoint personalizado do Dynamo para seus metadados de visualização consistente usando a propriedade `fs.s3.consistent.dynamodb.endpoint` em `emrfs-site.xml`.
+ Adicionado um script em `/usr/bin` chamado `spark-example`, que encapsula `/usr/lib/spark/spark/bin/run-example` para que você possa executar exemplos diretamente. Por exemplo, para executar o SparkPi exemplo que vem com a distribuição do Spark, você pode executar a `spark-example SparkPi 100` partir da linha de comando ou usando `command-runner.jar` como uma etapa na API.

### Problemas conhecidos das versões anteriores que foram resolvidos
<a name="w2aac11c29d167b9"></a>
+ Corrigido um problema em que o Oozie não tinha o `spark-assembly.jar` no local correto quando o Spark também estava instalado, o que resultava em falha para iniciar aplicativos do Spark com o Oozie.
+ Corrigido um problema com o registro baseado em Log4j do Spark em contêineres do YARN.

## Versão 4.7.1
<a name="w2aac11c29d169"></a>

Data do release: 10 de junho de 2016

### Problemas conhecidos das versões anteriores que foram resolvidos
<a name="w2aac11c29d169b5"></a>
+ Corrigido um problema que estendia o tempo de inicialização de clusters iniciados em uma VPC com sub-redes privadas. O bug só afetava os clusters iniciados com a versão 4.7.0. do Amazon EMR. 
+ Corrigido um problema que tratava incorretamente a listagem de arquivos no Amazon EMR para os clusters iniciados com a versão 4.7.0 do Amazon EMR.

## Versão 4.7.0
<a name="w2aac11c29d171"></a>

**Importante**  
A versão 4.7.0 do Amazon EMR foi descontinuada. Use a versão 4.7.1 ou posterior do Amazon EMR.

Data do release: 2 de junho de 2016

### Recursos
<a name="w2aac11c29d171b7"></a>

Os seguintes recursos estão disponíveis nesta versão:
+ Adicionado o Apache Phoenix 4.7.0
+ Adicionado o Apache Tez 0.8.3
+ Atualizado para 1.2.1 HBase 
+ Atualizado para Mahout 0.12.0
+ Atualizado para Presto 0.147
+ Atualizou o AWS SDK para Java para 1.10.75
+ O sinalizador final foi removido da propriedade `mapreduce.cluster.local.dir` em `mapred-site.xml` para permitir que os usuários executem o Pig no modo local.

### Drivers JDBC do Amazon Redshift disponíveis no cluster
<a name="w2aac11c29d171b9"></a>

Os drivers JDBC do Amazon Redshift agora estão incluídos em `/usr/share/aws/redshift/jdbc`. `/usr/share/aws/redshift/jdbc/RedshiftJDBC41.jar` é o driver do Amazon Redshift compatível com JDBC 4.1 e `/usr/share/aws/redshift/jdbc/RedshiftJDBC4.jar` é o driver do Amazon Redshift compatível com JDBC 4.0. Para obter mais informações, consulte [Configurar uma conexão JDBC](https://docs.aws.amazon.com/redshift/latest/mgmt/configure-jdbc-connection.html) no *Guia de gerenciamento do Amazon Redshift*.

### Java 8
<a name="w2aac11c29d171c11"></a>

Com exceção do Presto, o OpenJDK 1.7 é o JDK padrão usado para todos os aplicativos. No entanto, o OpenJDK 1.7 e o 1.8 estão instalados. Para obter mais informações sobre como configurar `JAVA_HOME` para aplicações, consulte [Configurar aplicações para usar Java 8](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html#configuring-java8).

### Problemas conhecidos das versões anteriores que foram resolvidos
<a name="w2aac11c29d171c13"></a>
+ Corrigido um problema do kernel que afetava significativamente a performance dos volumes do EBS no disco rígido com throughput otimizado (st1) para o Amazon EMR no emr-4.6.0.
+ Corrigido um problema em que havia uma falha do cluster se qualquer zona de criptografia do HDFS fosse especificada sem escolher o Hadoop como um aplicativo.
+ Alterada a política de gravação padrão do HDFS de `RoundRobin` para `AvailableSpaceVolumeChoosingPolicy`. Alguns volumes não foram utilizados adequadamente com a RoundRobin configuração, o que resultou em falhas nos nós principais e em um HDFS não confiável.
+ Corrigido um problema com a CLI do EMRFS, que causava uma exceção ao criar a tabela de metadados do DynamoDB padrão para visualizações consistentes.
+ Corrigido um problema de deadlock no EMRFS que potencialmente ocorria durante a renomeação do multipart e operações de cópia.
+ Corrigido um problema com o EMRFS que fazia com que o CopyPart tamanho padrão fosse 5 MB. O padrão agora está definido corretamente como 128 MB.
+ Corrigido um problema com a configuração de inicialização do Zeppelin que potencialmente impedia a interrupção do serviço.
+ Corrigido um problema com o Spark e o Zeppelin que impedia o uso do esquema de URI `s3a://` porque `/usr/lib/hadoop/hadoop-aws.jar` não era carregado adequadamente em seus respectivos classpath.
+ [HUE-2484](https://issues.cloudera.org/browse/HUE-2484) enviado para backport.
+ Reportou um [commit](https://github.com/cloudera/hue/commit/c3c89f085e7a29c9fac7de016d881142d90af3eb) do Hue 3.9.0 (não existe JIRA) para corrigir um problema com a amostra do navegador. HBase 
+ [HIVE-9073](https://issues.apache.org/jira/browse/HIVE-9073) enviado para backport.

## Versão 4.6.0
<a name="w2aac11c29d173"></a>

Data do release: 21 de abril de 2016

### Recursos
<a name="w2aac11c29d173b5"></a>

Os seguintes recursos estão disponíveis nesta versão:
+ Adicionado HBase 1.2.0
+ Adicionado o ZooKeeper-Sandbox 3.4.8 
+ Atualizado para Presto-Sandbox 0.143
+ As versões do Amazon EMR agora são baseadas no Amazon Linux 2016.03.0. Para obter mais informações, consulte [https://aws.amazon.com/amazon-linux-ami/2016.03-release-notes/](https://aws.amazon.com/amazon-linux-ami/2016.03-release-notes/).

### Problema afetando os tipos de volumes do EBS no disco rígido com throughput otimizado (st1)
<a name="w2aac11c29d173b7"></a>

Um problema no kernel do Linux versões 4.2 e superior afeta significativamente o desempenho nos volumes do EBS no disco rígido com throughput otimizado (st1) para o EMR. Esta versão (emr-4.6.0) usa uma versão do kernel 4.4.5 e, portanto, é afetada. Por isso, recomendamos não usar o emr-4.6.0 se você deseja usar volumes do EBS no st1. Você pode usar emr-4.5.0 ou versões anteriores do Amazon EMR com o st1 sem impacto algum. Além disso, fornecemos a correção com futuras versões.

### Padrões do Python
<a name="w2aac11c29d173b9"></a>

O Python 3.4 agora está instalado por padrão, mas o Python 2.7 permanece como o sistema padrão. Você pode configurar o Python 3.4 como o padrão do sistema usando uma ação de bootstrap; você pode usar a API de configuração para definir a exportação de PYSPARK\$1PYTHON na classificação `spark-env` para afetar a versão `/usr/bin/python3.4` do Python usada por. PySpark

### Java 8
<a name="w2aac11c29d173c11"></a>

Com exceção do Presto, o OpenJDK 1.7 é o JDK padrão usado para todos os aplicativos. No entanto, o OpenJDK 1.7 e o 1.8 estão instalados. Para obter mais informações sobre como configurar `JAVA_HOME` para aplicações, consulte [Configurar aplicações para usar Java 8](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html#configuring-java8).

### Problemas conhecidos das versões anteriores que foram resolvidos
<a name="w2aac11c29d173c13"></a>
+ Corrigido um problema em que, às vezes, ocorria uma falha aleatória no provisionamento de aplicativos devido a uma senha gerada.
+ Anteriormente, `mysqld` estava instalado em todos os nós. Agora, ele só está instalado na instância principal e somente se o aplicativo escolhido incluir `mysql-server` como componente. Atualmente, os seguintes aplicativos incluem o `mysql-server` componente: Hive HCatalog, Hue, Presto-Sandbox e Sqoop-Sandbox.
+ Alterado o `yarn.scheduler.maximum-allocation-vcores` para 80 do padrão de 32, que corrige um problema apresentado na emr-4.4.0 que ocorre, principalmente, com o Spark enquanto usa a opção `maximizeResourceAllocation` em um cluster cujo tipo de instância core é um dos grandes tipos de instância que têm os vcores do YARN definidos como maior do que 32, ou seja, c4.8xlarge, cc2.8xlarge, hs1.8xlarge, i2.8xlarge, m2.4xlarge, r3.8xlarge, d2.8xlarge ou m4.10xlarge foram afetados por esse problema.
+ s3-dist-cp agora usa o EMRFS para todas as indicações do Amazon S3 e não mais estágios para um diretório HDFS temporário.
+ Corrigido um problema com o tratamento de exceções para os multipart uploads de criptografia no lado do cliente.
+ Adicionada uma opção para permitir que os usuários alterem a classe de armazenamento do Amazon S3. Por padrão, essa configuração é `STANDARD`. A configuração da classificação de configuração `emrfs-site` é `fs.s3.storageClass` e os valores possíveis são `STANDARD`, `STANDARD_IA`e `REDUCED_REDUNDANCY`. Para obter mais informações sobre classes de armazenamento, consulte [Classes de armazenamento](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html) no Guia do usuário do Amazon Simple Storage Service. 

## Versão 4.5.0
<a name="w2aac11c29d175"></a>

Data do release: 4 de abril de 2016

### Recursos
<a name="w2aac11c29d175b5"></a>

Os seguintes recursos estão disponíveis nesta versão:
+ Atualizado para Spark 1.6.1
+ Atualizado para Hadoop 2.7.2
+ Atualizado para Presto 0.140
+ Foi adicionado AWS KMS suporte para criptografia do lado do servidor Amazon S3.

### Problemas conhecidos das versões anteriores que foram resolvidos
<a name="w2aac11c29d175b7"></a>
+ Corrigido um problema em que os servidores MySQL e Apache não iniciavam depois que um nó fosse reinicializado. 
+ Corrigido um problema em que IMPORT não funcionava corretamente com tabelas não particionadas armazenadas no Amazon S3
+ Corrigido um problema em que o Presto exigia que o diretório de preparo fosse `/mnt/tmp` em vez de `/tmp` ao gravar em tabelas do Hive.

## Versão 4.4.0
<a name="w2aac11c29d177"></a>

Data do release: 14 de março de 2016

### Recursos
<a name="w2aac11c29d177b5"></a>

Os seguintes recursos estão disponíveis nesta versão:
+ Adicionado HCatalog 1.0.0
+ Adicionado o Sqoop-Sandbox 1.4.6
+ Atualizado para Presto 0.136
+ Atualizado para Zeppelin 0.5.6
+ Atualizado para Mahout 0.11.1
+ Habilitada a `dynamicResourceAllocation` por padrão.
+ Adicionada uma tabela de todas as classificações de configuração para a versão. Para obter mais informações, consulte a tabela de classificações de configuração em [Configurar aplicações](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html).

### Problemas conhecidos das versões anteriores que foram resolvidos
<a name="w2aac11c29d177b7"></a>
+ Corrigido um problema em que a `maximizeResourceAllocation` configuração não reservava memória suficiente para os ApplicationMaster daemons do YARN.
+ Corrigido um problema encontrado com um DNS personalizado. Se alguma entrada em `resolve.conf` preceder as entradas personalizadas fornecidas, as entradas personalizadas não serão resolvíveis. Esse comportamento foi afetado por clusters em uma VPC em que o servidor de nomes padrão da VPC está inserido como a entrada superior em `resolve.conf`.
+ Corrigido um problema em que o Python padrão mudou para a versão 2.7 e boto não estava instalado para essa versão.
+ Corrigido um problema em que contêineres do YARN e aplicativos do Spark geravam um arquivo (rrd) exclusivo do banco de dados Ganglia round robin, que resultava no enchimento do primeiro disco anexado à instância. Devido a essa correção, as métricas no nível do contêiner do YARN e as métricas no nível do aplicativo do Spark foram desativadas.
+ Corrigido um problema no log pusher em que ele excluía todas as pastas de log vazias. O efeito era que a CLI do Hive não podia criar logs porque o log pusher estava removendo a pasta `user` vazia em `/var/log/hive`.
+ Corrigido um problema com as importações do Hive, que afetava o particionamento e resultava em um erro durante a importação.
+ Corrigido um problema em que EMRFS e s3-dist-cp não lidavam adequadamente com nomes de bucket que continham pontos.
+ Alterado um comportamento no EMRFS, de modo que nos buckets habilitados para versionamento, o arquivo marcador `_$folder$` não é criado continuamente, o que pode contribuir para um melhor desempenho dos buckets habilitados para versionamento.
+ Alterado o comportamento no EMRFS de forma que ele não use os arquivos de instrução, exceto para casos em que a criptografia no lado do cliente esteja habilitada. Se desejar excluir os arquivos de instrução enquanto usa a criptografia no lado do cliente, você poderá definir a propriedade emrfs-site.xml `fs.s3.cse.cryptoStorageMode.deleteInstructionFiles.enabled`, como verdadeiro. 
+ Alterada a agregação de logs do YARN para reter os logs no destino de agregação por dois dias. O destino padrão é o armazenamento HDFS do cluster. Se desejar mudar essa duração, altere o valor de `yarn.log-aggregation.retain-seconds` usando a classificação de configuração `yarn-site` quando criar seu cluster. Como sempre, você pode salvar os logs de aplicações no Amazon S3 usando o parâmetro `log-uri` quando criar o cluster.

### Patches aplicados
<a name="w2aac11c29d177b9"></a>

Os seguintes patches de projetos de código aberto foram incluídos nesta versão:
+ [HIVE-9655](https://issues.apache.org/jira/browse/HIVE-9655)
+ [HIVE-9183](https://issues.apache.org/jira/browse/HIVE-9183)
+ [HADOOP-12810](https://issues.apache.org/jira/browse/HADOOP-12810)

## Versão 4.3.0
<a name="w2aac11c29d179"></a>

Data do release: 19 de janeiro de 2016

### Recursos
<a name="w2aac11c29d179b5"></a>

Os seguintes recursos estão disponíveis nesta versão:
+ Atualizado para Hadoop 2.7.1
+ Atualizado para Spark 1.6.0
+ Ganglia atualizado para 3.7.2 
+ Presto atualizado para 0.130

O Amazon EMR fez algumas alterações na configuração `spark.dynamicAllocation.enabled` quando ela estava definida como verdadeiro. Ela é definida como falso por padrão. Quando definida como verdadeiro, isso afeta os padrões definidos pela configuração `maximizeResourceAllocation`:
+ Se `spark.dynamicAllocation.enabled` estiver definida como true, `spark.executor.instances` não será definida por `maximizeResourceAllocation`.
+ A configuração `spark.driver.memory` agora é definida com base nos tipos de instância no cluster de maneira semelhante a como `spark.executors.memory` é definida. No entanto, como o aplicativo de driver do Spark pode ser executado na instância principal ou em uma das instâncias core (por exemplo, nos modos de cluster e de cliente do YARN, respectivamente), a configuração `spark.driver.memory` é definida com base no tipo de instância do menor tipo de instância entre esses dois grupos de instâncias.
+ A configuração `spark.default.parallelism` agora é definida em duas vezes mais núcleos de CPU disponíveis para contêineres do YARN. Em versões anteriores, era a metade desse valor.
+ Os cálculos para a sobrecarga de memória reservada para os processos do Spark YARN foram ajustados para serem mais precisos, resultando em um pequeno aumento na quantidade total de memória disponível para o Spark (ou seja, `spark.executor.memory`).

### Problemas conhecidos das versões anteriores que foram resolvidos
<a name="w2aac11c29d179b7"></a>
+ A agregação de logs do YARN agora está ativada por padrão.
+ Corrigido um problema em que os logs não eram enviados para um bucket de logs do Amazon S3 do cluster quando a agregação de logs do YARN estava habilitada.
+ Os contêineres do YARN agora têm um novo mínimo de 32 em todos os tipos de nós.
+ Corrigido um problema com o Ganglia que causava excesso de disco I/O no nó principal em grandes clusters.
+ Corrigido um problema que impedia que os logs de aplicações fossem enviados para o Amazon S3 quando um cluster estivesse sendo encerrado.
+ Corrigido um problema na CLI do EMRFS que fazia com que houvesse falha em determinados comandos.
+ Corrigido um problema com o Zeppelin que impedia que dependências fossem carregadas no subjacente. SparkContext
+ Corrigido um problema resultante da emissão de um redimensionamento para tentar adicionar instâncias. 
+ Corrigido um problema no Hive, em que CREATE TABLE AS SELECT fazia chamadas de lista excessivas para o Amazon S3. 
+ Corrigido um problema em que clusters grandes não provisionavam corretamente quando o Hue, o Oozie e o Ganglia estivessem instalados.
+ Corrigido um problema no s3-dist-cp em que retornava um código de saída zero, mesmo se houvesse falha com um erro.

### Patches aplicados
<a name="w2aac11c29d179b9"></a>

Os seguintes patches de projetos de código aberto foram incluídos nesta versão:
+ [OOZIE-2402](https://issues.apache.org/jira/browse/OOZIE-2402)
+ [HIVE-12502](https://issues.apache.org/jira/browse/HIVE-12502)
+ [HIVE-10631](https://issues.apache.org/jira/browse/HIVE-10631)
+ [HIVE-12213](https://issues.apache.org/jira/browse/HIVE-12213)
+ [HIVE-10559](https://issues.apache.org/jira/browse/HIVE-10559)
+ [HIVE-12715](https://issues.apache.org/jira/browse/HIVE-12715)
+ [HIVE-10685](https://issues.apache.org/jira/browse/HIVE-10685)

## Versão 4.2.0
<a name="w2aac11c29d181"></a>

Data do release: 18 de novembro de 2015

### Recursos
<a name="w2aac11c29d181b5"></a>

Os seguintes recursos estão disponíveis nesta versão:
+ Adicionado o suporte ao Ganglia
+ Atualizado para Spark 1.5.2
+ Atualizado para Presto 0.125
+ Oozie atualizado para 4.2.0
+ Zeppelin atualizado para 0.5.5
+ Atualizou o AWS SDK para Java para 1.10.27

### Problemas conhecidos das versões anteriores que foram resolvidos
<a name="w2aac11c29d181b7"></a>
+ Corrigido um problema com a CLI do EMRFS em que ela não usava o nome da tabela de metadados padrão.
+ Corrigido um problema encontrado ao serem usadas tabelas com ORC no Amazon S3.
+ Corrigido um problema encontrado com uma divergência de versão do Python na configuração do Spark.
+ Corrigido um problema quando havia falha de um status de nó YARN em relatar problemas de DNS para clusters em uma VPC.
+ Corrigido um problema encontrado quando o YARN desativava nós, resultando em aplicativos suspensos ou na incapacidade de agendar novos aplicativos.
+ Corrigido um problema encontrado quando os clusters eram encerrados com o status TIMED\$1OUT\$1STARTING.
+ Corrigido um problema encontrado quando dependência Scala do EMRFS Scala era incluída em outras compilações. A dependência Scala foi removida.