

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

# Configurar o Spark
<a name="emr-spark-configure"></a>

Você pode configurar o [Spark no Amazon EMR](https://aws.amazon.com/elasticmapreduce/details/spark/) com classificações de configuração. Para obter mais informações sobre classificações de configuração, consulte [Configurar aplicações](emr-configure-apps.md).

As classificações de configuração para o Spark no Amazon EMR incluem o seguinte:
+ **`spark`**: define a propriedade `maximizeResourceAllocation` como verdadeira ou falsa. Quando verdadeira, o Amazon EMR configura automaticamente as propriedades `spark-defaults` com base na configuração de hardware do cluster. Para obter mais informações, consulte [Usar o `maximizeResourceAllocation`](#emr-spark-maximizeresourceallocation).
+ **`spark-defaults`**: define valores no arquivo `spark-defaults.conf`. Para obter mais informações, consulte [Configuração do Spark](https://spark.apache.org/docs/latest/configuration.html) na documentação do Spark.
+ **`spark-env`**: define valores no arquivo `spark-env.sh`. Para obter mais informações, consulte [Variáveis de ambiente](https://spark.apache.org/docs/latest/configuration.html#environment-variables) na documentação do Spark.
+ **`spark-hive-site`**: define os valores no `hive-site.xml` para o Spark.
+ **`spark-log4j`**— (Amazon EMR versões 6.7.x e inferiores) Define valores no arquivo. `log4j.properties` Para obter mais informações, consulte o arquivo [log4j.properties.template](https://github.com/apache/spark/blob/branch-3.2/conf/log4j.properties.template) no GitHub.
+ **`spark-log4j2`**: (versões 6.8.0 e superiores do Amazon EMR) define valores no arquivo `log4j2.properties`. Para obter mais informações, consulte o arquivo [log4j2.properties.template](https://github.com/apache/spark/blob/v3.3.0/conf/log4j2.properties.template) no GitHub.
+ **`spark-metrics`**: define valores no arquivo `metrics.properties`. Para obter configurações e mais informações, consulte o arquivo [metrics.properties.template](https://github.com/apache/spark/blob/master/conf/metrics.properties.template) no Github e as [Métricas](https://spark.apache.org/docs/latest/monitoring.html#metrics) na documentação do Spark.

**nota**  
Se você estiver migrando workloads do Spark para o Amazon EMR de outra plataforma, recomendamos que você teste suas workloads com o [Padrões do Spark definidos pelo Amazon EMR](#spark-defaults) antes de adicionar configurações personalizadas. A maioria dos clientes observa uma melhor performance com nossas configurações padrão.

**Topics**
+ [Padrões do Spark definidos pelo Amazon EMR](#spark-defaults)
+ [Configurar a coleta de resíduos do Spark no Amazon EMR 6.1.0](#spark-gc-config)
+ [Usar o `maximizeResourceAllocation`](#emr-spark-maximizeresourceallocation)
+ [Configurar o comportamento de desativação de nós](#spark-decommissioning)
+ [Variável de ThriftServer ambiente Spark](#spark-thriftserver)
+ [Alterar as configurações padrão do Spark](#spark-change-defaults)
+ [Migrar do Apache Log4j 1.x para Log4j 2.x](#spark-migrate-logj42)

## Padrões do Spark definidos pelo Amazon EMR
<a name="spark-defaults"></a>

A tabela a seguir mostra como o Amazon EMR define valores padrão no `spark-defaults` que afetam aplicações.


**Padrões do Spark definidos pelo Amazon EMR**  

| Configuração | Description | Valor padrão  | 
| --- | --- | --- | 
| spark.executor.memory | A quantidade de memória a ser usada por processo de executor. Por exemplo: `1g`, `2g`. |  Essa configuração é determinada pelos tipos de instância core e de tarefa no cluster.   | 
| spark.executor.cores | O número de núcleos para uso em cada executor. | Essa configuração é determinada pelos tipos de instância core e de tarefa no cluster. | 
| spark.dynamicAllocation.enabled | Quando verdadeira, use alocação dinâmica de recursos para aumentar e diminuir a escala verticalmente do número de executores registrados em uma aplicação com base na workload. |  `true` (com as versões 4.4.0 e superiores do Amazon EMR)  O serviço de shuffle do Spark é automaticamente configurado pelo Amazon EMR.   | 
| spark.sql.hive.advancedPartitionPredicatePushdown.enabled | Quando verdadeiro, o pushdown avançado de predicados de partição para o metastore do Hive é habilitado. | true | 
| spark.sql.hive.stringLikePartitionPredicatePushdown.enabled | Envia os filtros `startsWith`, `contains` e `endsWith` para o metastore do Hive.  O Glue não é compatível com o pushdown de predicados para `startsWith`, `contains` ou `endsWith`. Se você estiver usando o metastore do Glue e encontrar erros devido ao pushdown de predicados para essas funções, defina essa configuração como `false`.   | true | 

## Configurar a coleta de resíduos do Spark no Amazon EMR 6.1.0
<a name="spark-gc-config"></a>

Definir configurações personalizadas de coleta de resíduos com `spark.driver.extraJavaOptions` e `spark.executor.extraJavaOptions` resulta em falha na inicialização do driver ou do executor com o Amazon EMR 6.1 devido a uma configuração de coleta de resíduos conflitante com o Amazon EMR 6.1.0. Para o Amazon EMR 6.1.0, a configuração padrão de coleta de resíduos é definida por meio de `spark.driver.defaultJavaOptions` e `spark.executor.defaultJavaOptions`. Essa configuração só se aplica ao Amazon EMR 6.1.0. As opções da JVM não relacionadas à coleta de resíduos, como aquelas para configurar registro em log (`-verbose:class`), ainda podem ser configuradas por meio de `extraJavaOptions`. Para obter mais informações, consulte [Propriedades das aplicações do Spark](https://spark.apache.org/docs/latest/configuration.html#application-properties). 

## Usar o `maximizeResourceAllocation`
<a name="emr-spark-maximizeresourceallocation"></a>

Para configurar os executores para usarem o máximo de recursos possível em cada nó em um cluster, defina `maximizeResourceAllocation` como `true` na classificação de configuração do `spark`. O `maximizeResourceAllocation` é específico para o Amazon EMR. Quando você habilita `maximizeResourceAllocation`, o Amazon EMR calcula os recursos máximos de computação e memória disponíveis para um executor em uma instância no grupo de instâncias centrais. Em seguida, ele define as configurações `spark-defaults` correspondentes com base nos valores máximos calculados.

O Amazon EMR calcula os recursos máximos de computação e memória disponíveis para um executor com base em um tipo de instância da frota de instâncias centrais. Como cada frota de instâncias pode ter diferentes tipos e tamanhos de instância em uma frota, a configuração do executor usada pelo Amazon EMR pode não ser a melhor para os clusters, por isso não recomendamos utilizar as configurações padrão com a alocação máxima de recursos. Defina configurações personalizadas para os clusters da frota de instâncias.

**nota**  
Você não deve usar a `maximizeResourceAllocation` opção em clusters com outros aplicativos distribuídos, como HBase o. O Amazon EMR usa configurações personalizadas do YARN para aplicações distribuídas, que podem entrar em conflito com `maximizeResourceAllocation` e causar falhas nas aplicações do Spark.

Veja a seguir um exemplo de classificação de configuração do Spark com `maximizeResourceAllocation` definido como `true`.

```
[
  {
    "Classification": "spark",
    "Properties": {
      "maximizeResourceAllocation": "true"
    }
  }
]
```


**Configurações configuradas em `spark-defaults` quando `maximizeResourceAllocation`está habilitado**  

| Configuração | Description | Valor | 
| --- | --- | --- | 
| spark.default.parallelism | O número padrão de partições é RDDs retornado por transformações como join reduceByKey, e paralelize quando não definido pelo usuário. |  2X o número de cores de CPU disponíveis para contêineres do YARN.  | 
| spark.driver.memory | Quantidade de memória a ser usada para o processo do driver, ou seja, onde SparkContext é inicializado. (por exemplo, 1g, 2g). |  A configuração é definida com base nos tipos de instância do cluster. No entanto, como a aplicação do driver do Spark pode ser executada na instância primária ou em uma das instâncias core (por exemplo, nos modos de cliente do YARN e de cluster, respectivamente), isso é definido com base no menor tipo de instância desses dois grupos de instâncias.  | 
| spark.executor.memory | Quantidade de memória para uso por processo de executor. (por exemplo, 1g, 2g) |  A configuração é definida com base nos tipos de instância core e de tarefa do cluster.   | 
| spark.executor.cores | O número de núcleos para uso em cada executor.  | A configuração é definida com base nos tipos de instância core e de tarefa do cluster.  | 
| spark.executor.instances |  O número de executores. |  A configuração é definida com base nos tipos de instância core e de tarefa do cluster. Defina a menos que `spark.dynamicAllocation.enabled` seja explicitamente definido como true ao mesmo tempo.  | 

## Configurar o comportamento de desativação de nós
<a name="spark-decommissioning"></a>

Com as versões 5.9.0 e superiores do Amazon EMR, o Spark no Amazon EMR inclui um conjunto de recursos para ajudar a garantir que o Spark lide tranquilamente com o encerramento de nós devido a um redimensionamento manual ou a uma solicitação de política de ajuste de escala automática. O Amazon EMR implementa um mecanismo de lista de negação no Spark criado com base no mecanismo de desativação do YARN. Esse mecanismo ajuda a garantir que não haja novas tarefas programadas em um nó que esteja sendo desativado, permitindo ao mesmo tempo que tarefas que já estão em execução sejam concluídas. Além disso, há recursos para ajudar a recuperar trabalhos do Spark com mais rapidez se os shuffle blocks forem perdidos no encerramento de um nó. O processo de recálculo é acionado mais cedo e otimizado para recalcular com mais rapidez e menos tentativas de fase, e é possível evitar falhas nos trabalhos provenientes de falhas de busca que são causadas por shuffle blocks ausentes.

**Importante**  
A configuração `spark.decommissioning.timeout.threshold` foi adicionada ao Amazon EMR versão 5.11.0 para melhorar a resiliência do Spark ao serem usadas instâncias spot. Nas versões anteriores, quando um nó usa uma instância spot e a instância é encerrada devido ao preço da oferta, o Spark pode não ser capaz de lidar com o encerramento com tranquilidade. Os trabalhos podem falhar e os novos cálculos de shuffle podem levar um tempo significativo. Por esse motivo, recomendamos o uso da versão 5.11.0, ou posterior, se você usar instâncias spot.


**Configurações de desativação de nós do Spark**  

| Configuração | Description | Valor padrão  | 
| --- | --- | --- | 
|  `spark.blacklist.decommissioning.enabled`  |  Quando definido como `true`, o Spark coloca na lista de negação os nós que estão no estado `decommissioning` no YARN. O Spark não programa novas tarefas em executores que estejam em execução nesse nó. É permitido que as tarefas já em execução sejam concluídas.  |  `true`  | 
|  `spark.blacklist.decommissioning.timeout`  |  O período em que um nó no estado `decommissioning` permanece na lista de negação. Por padrão, esse valor é definido como uma hora, que também é o padrão para `yarn.resourcemanager.decommissioning.timeout`. Para garantir que um nó permaneça na lista de negação por todo o período de desativação, defina esse valor como igual ou maior do que `yarn.resourcemanager.decommissioning.timeout`. Depois que o tempo limite da desativação expira, o nó muda para o estado `decommissioned`, e o Amazon EMR pode encerrar a instância do EC2 do nó. Se alguma tarefa ainda estiver em execução após o tempo limite expirar, ela será perdida ou eliminada e reprogramada em executores executados em outros nós.  |  `1h`  | 
|  `spark.decommissioning.timeout.threshold`  |  Disponível nas versões 5.11.0 ou posteriores do Amazon EMR. Especificado em segundos. Quando um nó muda para o estado de desativação, se o host é desativado em um período igual ou menor que esse valor, o Amazon EMR não apenas insere o nó em uma lista de negação, mas também limpa o estado do host (conforme especificado por `spark.resourceManager.cleanupExpiredHost`) sem esperar que o nó mude para um estado de desativação. Isso permite que o Spark lide melhor com o encerramento de instâncias spot, pois as instâncias spot são desativadas dentro de um tempo de espera de 20 segundos, independentemente do valor do `yarn.resourcemager.decommissioning.timeout`, o que pode não dar aos outros nós tempo suficiente para que eles leiam arquivos embaralhados.  |  `20s`  | 
|  `spark.resourceManager.cleanupExpiredHost`  |  Quando definido como `true`, o Spark cancela o registro de todos os dados em cache e os shuffle blocks armazenados nos executores nos nós que estejam no estado `decommissioned`. Isso acelera o processo de recuperação.  |  `true`  | 
|  `spark.stage.attempt.ignoreOnDecommissionFetchFailure`  |  Quando definido como `true`, ajuda a evitar falhas do Spark nas fases e a falha no trabalho devido ao excesso de falhas de busca dos nós desativados. As buscas com falha de shuffle blocks de nó no estado `decommissioned` não são contabilizadas para o número máximo de falhas de busca consecutivas.  | true | 

## Variável de ThriftServer ambiente Spark
<a name="spark-thriftserver"></a>

O Spark define a variável de ambiente da Porta do servidor Thrift do Hive, `HIVE_SERVER2_THRIFT_PORT`, como 10001.

## Alterar as configurações padrão do Spark
<a name="spark-change-defaults"></a>

Você altera os padrões em `spark-defaults.conf` usando a classificação de configuração `spark-defaults` ou a configuração `maximizeResourceAllocation` na classificação de configuração `spark`.

Os procedimentos a seguir mostram como modificar as configurações usando a CLI ou o console.

**Criar um cluster com spark.executor.memory definido como 2g usando a CLI**
+ Crie um cluster com o Spark instalado e com `spark.executor.memory` definido como 2g usando o comando a seguir, que faz referência a um arquivo, `myConfig.json`, armazenado no Amazon S3.

  ```
  aws emr create-cluster --release-label emr-7.12.0 --applications Name=Spark \
  --instance-type m5.xlarge --instance-count 2 --service-role EMR_DefaultRole_V2 --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole --configurations https://s3.amazonaws.com/amzn-s3-demo-bucket/myfolder/myConfig.json
  ```
**nota**  
Os caracteres de continuação de linha do Linux (\$1) são incluídos para facilitar a leitura. Eles podem ser removidos ou usados ​​em comandos do Linux. No Windows, remova-os ou substitua-os por um sinal de interpolação (^).

  `myConfig.json`:

  ```
  [
      {
        "Classification": "spark-defaults",
        "Properties": {
          "spark.executor.memory": "2G"
        }
      }
    ]
  ```

**Criar um cluster com spark.executor.memory definido como 2g usando o console**

1. Navegue até o novo console do Amazon EMR e selecione **Alternar para o console antigo** na navegação lateral. Para obter mais informações sobre o que esperar ao alternar para o console antigo, consulte [Usar o console antigo](https://docs.aws.amazon.com/emr/latest/ManagementGuide/whats-new-in-console.html#console-opt-in).

1. Escolha **Create cluster (Criar cluster)**, **Go to advanced options (Ir para opções avançadas)**.

1. Escolha **Spark**. 

1. Em **Edit software settings (Editar configurações de software)**, deixe **Enter configuration (Inserir configuração)** selecionado e insira a seguinte configuração:

   ```
   classification=spark-defaults,properties=[spark.executor.memory=2G]
   ```

1. Selecione outras opções, escolha **** e **Criar cluster**.

**Para definir maximizeResourceAllocation**
+ Crie um cluster com o Spark instalado e `maximizeResourceAllocation` definido como verdadeiro usando o AWS CLI, referenciando um arquivo`myConfig.json`, armazenado no Amazon S3.

  ```
  aws emr create-cluster --release-label emr-7.12.0 --applications Name=Spark \
  --instance-type m5.xlarge --instance-count 2 --service-role EMR_DefaultRole_V2 --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole --configurations https://s3.amazonaws.com/amzn-s3-demo-bucket/myfolder/myConfig.json
  ```
**nota**  
Os caracteres de continuação de linha do Linux (\$1) são incluídos para facilitar a leitura. Eles podem ser removidos ou usados ​​em comandos do Linux. No Windows, remova-os ou substitua-os por um sinal de interpolação (^).

  `myConfig.json`:

  ```
  [
    {
      "Classification": "spark",
      "Properties": {
        "maximizeResourceAllocation": "true"
      }
    }
  ]
  ```

**nota**  
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).

## Migrar do Apache Log4j 1.x para Log4j 2.x
<a name="spark-migrate-logj42"></a>

As versões 3.2.x e anteriores do [Apache Spark](https://aws.amazon.com/emr/features/spark/) usam o Apache Log4j 1.x herdado e o arquivo `log4j.properties` para configurar o Log4j nos processos do Spark. As versões 3.3.0 e posteriores do Apache Spark usam o Apache Log4j 2.x e o arquivo `log4j2.properties` para configurar o Log4j nos processos do Spark.

Se você tiver configurado o Apache Spark Log4j usando uma versão do Amazon EMR inferior à 6.8.0, deverá remover a classificação de configuração `spark-log4j` herdada e migrar para a classificação de configuração `spark-log4j2` e o formato da chave antes de poder atualizar para o Amazon EMR 6.8.0 ou posterior. A classificação `spark-log4j` herdada faz com que a criação do cluster apresente falha com um erro de `ValidationException` nas versões 6.8.0 e posteriores do Amazon EMR. Você não será cobrado por uma falha relacionada à incompatibilidade do Log4j, mas deverá remover a classificação de configuração `spark-log4j` extinta para continuar.

Para obter mais informações sobre a migração do Apache Log4j 1.x para o Log4j 2.x, consulte o [Guia de migração do Apache Log4j](https://logging.apache.org/log4j/2.x/manual/migration.html) e o [Modelo do Spark Log4j 2](https://github.com/apache/spark/blob/master/conf/log4j2.properties.template) no GitHub. 

**nota**  
Com o Amazon EMR, o Apache Spark usa um arquivo `log4j2.properties` em vez do arquivo .xml descrito no [Guia de migração do Apache Log4j](https://logging.apache.org/log4j/2.x/manual/migration.html). Além disso, não recomendamos o uso do método de ponte do Log4j 1.x para conversão para Log4j 2.x. 