Configurar o Spark - Amazon EMR
Padrões do SparkConfiguração da coleta de resíduosmaximizeResourceAllocationComportamento de desativaçãoVariável de ambiente ThriftServer do SparkAlterar as configurações padrão do SparkMigrar do Apache Log4j 1.x para Log4j 2.x

Configurar o Spark

Você pode configurar o Spark no Amazon EMR com classificações de configuração. Para obter mais informações sobre classificações de configuração, consulte Configurar aplicações.

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 ter mais informações, consulte Utilizar o maximizeResourceAllocation.

  • spark-defaults: define valores no arquivo spark-defaults.conf. Para obter mais informações, consulte Configuração do Spark na documentação do Spark.

  • spark-env: define valores no arquivo spark-env.sh. Para obter mais informações, consulte Variáveis de ambiente 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 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 no GitHub.

  • spark-metrics: define valores no arquivo metrics.properties. Para obter configurações e mais informações, consulte o arquivo metrics.properties.template no Github e as Métricas 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 antes de adicionar configurações personalizadas. A maioria dos clientes observa uma melhor performance com nossas configurações padrão.

Padrões do Spark definidos pelo Amazon EMR

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 Descrição 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)

nota

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.

nota

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

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.

Utilizar o maximizeResourceAllocation

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 opção maximizeResourceAllocation em clusters com outras aplicações distribuídas, como o HBase. 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 Descrição Valor
spark.default.parallelism Número padrão de partições em RDDs retornadas por transformações como join, reduceByKey e parallelize, quando não definidas 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 o 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

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 Descrição 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 ambiente ThriftServer do Spark

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

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.3.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 (\) 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.

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

  3. Escolha Spark.

  4. 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]

  5. Selecione outras opções, escolha eCreate cluster (Criar cluster).

Para definir maximizeResourceAllocation

  • Crie um cluster com o Spark instalado e com maximizeResourceAllocation definido como verdadeiro usando a AWS CLI, que faz referência a um arquivo, myConfig.json, armazenado no Amazon S3.

    aws emr create-cluster --release-label emr-7.3.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 (\) 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ê pode fazer isso usando o console do Amazon EMR, a 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.

Migrar do Apache Log4j 1.x para Log4j 2.x

As versões 3.2.x e anteriores do Apache 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 e o Modelo do Spark Log4j 2 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. Além disso, não recomendamos o uso do método de ponte do Log4j 1.x para conversão para Log4j 2.x.