Esta página foi traduzida pela API Cloud Translation.

Acelere cargas de trabalho em lote e sessões interativas com a execução de consultas nativas

Neste documento, descrevemos quando e como ativar a execução de consultas nativas para acelerar as cargas de trabalho em lote e as sessões interativas do Serverless para Apache Spark.

Requisitos de execução de consultas nativas

A execução de consultas nativas do Dataproc sem servidor para Apache Spark está disponível apenas com cargas de trabalho em lote e sessões interativas usando 1.2.26+, 2.2.26+ ou uma versão do ambiente de execução do Spark mais recente no nível de preços premium do Dataproc sem servidor para Apache Spark. Os preços do nível Premium são cobrados a um custo mais alto do que os do nível Standard, mas não há cobrança extra para a execução de consultas nativas. Para informações sobre preços, consulte Preços do Serverless para Apache Spark.

Propriedades de execução de consultas nativas

Esta seção lista as propriedades de alocação de recursos do Spark obrigatórias e opcionais que podem ser usadas para ativar e personalizar a execução de consultas nativas para sua carga de trabalho em lote ou sessão interativa.

Configurações obrigatórias da propriedade

spark.dataproc.runtimeEngine=native: o ambiente de execução da carga de trabalho precisa ser definido como native para substituir o ambiente de execução padrão spark.
spark.dataproc.spark.driver.compute.tier=premium e spark.dataproc.executor.compute.tier=premium: essas propriedades de nível de preços precisam ser definidas como o nível de preços premium.

Propriedades opcionais de alocação de recursos

spark.dataproc.driver.disk.tier, spark.dataproc.driver.disk.size, spark.dataproc.executor.disk.tier e spark.dataproc.executor.disk.size: use essas propriedades para definir e configurar o nível e o tamanho do disco premium para os processos de driver e executor do Spark.

Os níveis de disco Premium usam o embaralhamento colunar em vez do baseado em linhas para oferecer melhor desempenho. Para melhorar a capacidade de processamento de E/S de embaralhamento, use os níveis premium de disco do driver e do executor com um tamanho de disco suficientemente grande para acomodar arquivos de embaralhamento.

spark.driver.memory, spark.driver.memoryOverhead, spark.executor.memory, spark.executor.memoryOverhead e spark.memory.offHeap.size: use essas propriedades para ajustar a memória fornecida aos processos de driver e executor do Spark.

É possível configurar a memória de uma das seguintes maneiras:

Opção 1: configure apenas a memória fora do heap (spark.memory.offHeap.size) com um valor especificado. A execução de consultas nativas vai usar o valor especificado como memória fora do heap e alocar mais 1/7th do valor da memória fora do heap como memória no heap (spark.executor.memory).
Opção 2: configure a memória no heap (spark.executor.memory) e fora do heap (spark.memory.offHeap.size). A quantidade alocada para a memória fora do heap precisa ser maior do que a alocada para a memória no heap.

Se você não configurar a memória fora do heap (spark.memory.offHeap.size) e no heap (spark.executor.memory), o mecanismo de execução de consultas nativas vai dividir uma quantidade padrão de memória 4g em uma proporção 6:1 entre a memória fora do heap e no heap.

Recomendação: aloque memória off-heap para on-heap em uma proporção de 6:1.

Exemplos:

Configurações de memória sem execução de consultas nativas	Configurações de memória recomendadas com a execução de consultas nativas
`spark.executor.memory`	`spark.memory.offHeap.size`	`spark.executor.memory`
7g	6g	1g
14g	12g	2g
28g	24g	4g
56g	48g	8g

Executar a ferramenta de qualificação

Para identificar cargas de trabalho em lote que podem alcançar tempos de execução mais rápidos com a execução de consultas nativas (NQE, na sigla em inglês), use a ferramenta de qualificação. A ferramenta analisa os registros de eventos do Spark para estimar possíveis economias de tempo de execução e identificar operações que não são compatíveis com o mecanismo NQE.

OGoogle Cloud oferece dois métodos para executar a análise de qualificação: job de qualificação e script de qualificação. A abordagem recomendada para a maioria dos usuários é o job de qualificação, que automatiza a descoberta e a análise de cargas de trabalho em lote. O script de qualificação alternativo está disponível para o caso de uso específico de análise de um arquivo de registro de eventos conhecido. Escolha o método que melhor se adapta ao seu caso de uso:

Vaga de qualificação (recomendado): este é o método principal e recomendado. É um job do PySpark que descobre e analisa automaticamente as cargas de trabalho em lote recentes em um ou mais projetos e regiões do Google Cloud . Use esse método quando quiser fazer uma análise ampla sem precisar localizar manualmente arquivos de registro de eventos individuais. Essa abordagem é ideal para avaliação em grande escala da adequação do NQE.
Script de qualificação (alternativo): um método alternativo para casos de uso avançados ou específicos. É um script shell que analisa um único arquivo de registro de eventos do Spark ou todos os registros de eventos em um diretório específico do Cloud Storage. Use esse método se você tiver o caminho do Cloud Storage para os registros de eventos que quer analisar.

Job de qualificação

O job de qualificação simplifica a análise em grande escala ao verificar programaticamente as cargas de trabalho em lote do Serverless para Apache Spark e enviar um job de análise distribuída. A ferramenta avalia os trabalhos em toda a organização, eliminando a necessidade de encontrar e especificar manualmente os caminhos dos registros de eventos.

Conceder papéis do IAM

Para que o job de qualificação acesse os metadados da carga de trabalho em lote e leia os registros de eventos do Spark no Cloud Logging, a conta de serviço que executa a carga de trabalho precisa ter os seguintes papéis do IAM concedidos em todos os projetos a serem analisados:

Enviar o job de qualificação

Você envia o job de qualificação usando a ferramenta de CLI gcloud. O job inclui um script PySpark e um arquivo JAR hospedados em um bucket público do Cloud Storage.

É possível executar o job em um dos seguintes ambientes de execução:

Como uma carga de trabalho em lote do Serverless para Apache Spark. Essa é uma execução de trabalho simples e independente.
Como um job executado em um cluster do Dataproc no Compute Engine. Essa abordagem pode ser útil para integrar o job a um fluxo de trabalho.

Argumentos de job

Argumento	Descrição	Obrigatório?	Valor padrão
`--project-ids`	Um único ID do projeto ou uma lista separada por vírgulas de IDs de projetos do Google Cloud para verificar cargas de trabalho em lote.	Não	O projeto em que o job de qualificação está sendo executado.
`--regions`	Uma única região ou uma lista separada por vírgulas de regiões para verificar nos projetos especificados.	Não	Todas as regiões nos projetos especificados.
`--start-time`	A data de início para filtrar lotes. Somente os lotes criados a partir dessa data (formato: AAAA-MM-DD) serão analisados.	Não	Nenhum filtro de data de início é aplicado.
`--end-time`	A data de término para filtrar lotes. Somente os lotes criados até essa data (formato: AAAA-MM-DD) serão analisados.	Não	Nenhum filtro de data de término é aplicado.
`--limit`	O número máximo de lotes a serem analisados por região. Os lotes mais recentes são analisados primeiro.	Não	Todos os lotes que correspondem aos outros critérios de filtro são analisados.
`--output-gcs-path`	O caminho do Cloud Storage (por exemplo, `gs://your-bucket/output/`) em que os arquivos de resultado serão gravados.	Sim	Nenhuma.
`--input-file`	O caminho do Cloud Storage para um arquivo de texto para análise em massa. Se fornecido, esse argumento vai substituir todos os outros argumentos que definem o escopo (`--project-ids`, `--regions`, `--start-time`, `--end-time`, `--limit`).	Não	Nenhuma.

Exemplos de tarefas de qualificação

Um job em lote do Serverless para Apache Spark para realizar análises simples e ad hoc. Os argumentos do job são listados após o separador --.

gcloud dataproc batches submit pyspark gs://qualification-tool/performance-boost-qualification.py \
    --project=PROJECT_ID \
    --region=REGION \
    --jars=gs://qualification-tool/dataproc-perfboost-qualification-1.2.jar \
    -- \
    --project-ids=COMMA_SEPARATED_PROJECT_IDS \
    --regions=COMMA_SEPARATED_REGIONS \
    --limit=MAX_BATCHES \
    --output-gcs-path=gs://BUCKET

Um job em lote do Serverless para Apache Spark para analisar até 50 dos lotes mais recentes encontrados em sample_project na região us-central1. Os resultados são gravados em um bucket no Cloud Storage. Os argumentos do job são listados após o separador --.

gcloud dataproc batches submit pyspark gs://qualification-tool/performance-boost-qualification.py \
    --project=PROJECT_ID \
    --region=US-CENTRAL1 \
    --jars=gs://qualification-tool/dataproc-perfboost-qualification-1.2.jar \
    -- \
    --project-ids=PROJECT_ID \
    --regions=US-CENTRAL1 \
    --limit=50 \
    --output-gcs-path=gs://BUCKET/

Um job do Dataproc no Compute Engine enviado a um cluster do Dataproc para análise em massa em um fluxo de trabalho de análise em grande escala, repetível ou automatizado. Os argumentos do job são colocados em um INPUT_FILE que é enviado para um BUCKET no Cloud Storage. Esse método é ideal para verificar diferentes períodos ou limites de lote em vários projetos e regiões em uma única execução.
```
gcloud dataproc jobs submit pyspark gs://qualification-tool/performance-boost-qualification.py \
    --cluster=CLUSTER_NAME \
    --region=REGION \
    --jars=gs://qualification-tool/dataproc-perfboost-qualification-1.2.jar \
    -- \
    --input-file=gs://INPUT_FILE \
    --output-gcs-path=gs://BUCKET
```
Observações:

INPUT_FILE: cada linha do arquivo representa uma solicitação de análise distinta e usa um formato de flags de uma única letra seguidas pelos valores, como -p PROJECT-ID -r REGION -s START_DATE -e END_DATE -l LIMITS.

Exemplo de conteúdo do arquivo de entrada:
```
-p project1 -r us-central1 -s 2024-12-01 -e 2024-12-15 -l 100
-p project2 -r europe-west1 -s 2024-11-15 -l 50
```
Esses argumentos direcionam a ferramenta para analisar os dois escopos a seguir:
- Até 100 lotes no projeto1 na região us-central1 criados entre 1º e 15 de dezembro de 2025.
- Até 50 lotes no projeto2 na região europe-west1 criados a partir de 15 de novembro de 2025.

Script de qualificação

Use esse método se você tiver o caminho direto do Cloud Storage para um registro de eventos específico do Spark que quer analisar. Essa abordagem exige que você faça o download e execute um script shell, run_qualification_tool.sh, em uma máquina local ou em uma VM do Compute Engine configurada com acesso ao arquivo de registro de eventos no Cloud Storage.

Siga estas etapas para executar o script nos arquivos de eventos da carga de trabalho em lote do Serverless para Apache Spark.

1.Copie o run_qualification_tool.sh para um diretório local que contenha os arquivos de eventos do Spark a serem analisados.

Execute o script de qualificação para analisar um arquivo de evento ou um conjunto deles contidos no diretório do script.
```
./run_qualification_tool.sh -f EVENT_FILE_PATH/EVENT_FILE_NAME \
    -o CUSTOM_OUTPUT_DIRECTORY_PATH \
    -k SERVICE_ACCOUNT_KEY  \
    -x MEMORY_ALLOCATEDg  \
    -t PARALLEL_THREADS_TO_RUN
```
Flags e valores:

-f (obrigatório): consulte Locais dos arquivos de eventos do Spark para encontrar os arquivos de eventos da carga de trabalho do Spark.
- EVENT_FILE_PATH (obrigatório, a menos que EVENT_FILE_NAME seja especificado): caminho do arquivo de evento a ser analisado. Se não for fornecido, o caminho do arquivo de evento será considerado o diretório atual.
- EVENT_FILE_NAME (obrigatório, a menos que EVENT_FILE_PATH seja especificado): nome do arquivo de evento a ser analisado. Se não for fornecido, os arquivos de evento encontrados recursivamente no EVENT_FILE_PATH serão analisados.
-o(opcional): se não for fornecido, a ferramenta vai criar ou usar um diretório output no diretório atual para colocar os arquivos de saída.
- CUSTOM_OUTPUT_DIRECTORY_PATH: caminho do diretório de saída para arquivos de saída.
-k (opcional):
- SERVICE_ACCOUNT_KEY: a chave da conta de serviço no formato JSON, se necessário para acessar o EVENT_FILE_PATH.
-x (opcional):
- MEMORY_ALLOCATED: memória em gigabytes a ser alocada para a ferramenta. Por padrão, a ferramenta usa 80% da memória livre disponível no sistema e todos os núcleos de máquina disponíveis.
-t(opcional):
- PARALLEL_THREADS_TO_RUN: o número de linhas de execução paralelas que a ferramenta vai executar. Por padrão, a ferramenta executa todos os núcleos.
Exemplo de uso do comando:
```
./run_qualification_tool.sh -f gs://dataproc-temp-us-east1-9779/spark-job-history \
    -o perfboost-output -k /keys/event-file-key -x 34g -t 5
```
Neste exemplo, a ferramenta de qualificação percorre o diretório gs://dataproc-temp-us-east1-9779/spark-job-history e analisa os arquivos de eventos do Spark contidos nele e nos subdiretórios. O acesso ao diretório é fornecido pelo /keys/event-file-key. A ferramenta usa 34 GB memory para execução e executa 5 linhas de execução paralelas.

Locais dos arquivos de eventos do Spark

Siga uma destas etapas para encontrar os arquivos de eventos do Spark para cargas de trabalho em lote do Serverless para Apache Spark:

No Cloud Storage, encontre e faça o download do spark.eventLog.dir da carga de trabalho.
1. Se você não encontrar o spark.eventLog.dir, defina o spark.eventLog.dir como um local do Cloud Storage, execute novamente a carga de trabalho e faça o download do spark.eventLog.dir.
Se você tiver configurado o servidor de histórico do Spark para o job em lote:
1. Acesse o servidor de histórico do Spark e selecione a carga de trabalho.
2. Clique em Download na coluna Registro de eventos.

Arquivos de saída da ferramenta de qualificação

Quando o job de qualificação ou a análise de script for concluída, a ferramenta de qualificação colocará os seguintes arquivos de saída em um diretório perfboost-output no diretório atual:

AppsRecommendedForBoost.tsv: uma lista separada por tabulação de aplicativos recomendados para uso com a execução de consultas nativas.
UnsupportedOperators.tsv: uma lista separada por tabulação de aplicativos não recomendados para uso com a execução de consultas nativas.

Arquivo de saída `AppsRecommendedForBoost.tsv`

A tabela a seguir mostra o conteúdo de um arquivo de saída AppsRecommendedForBoost.tsv de exemplo. Ela contém uma linha para cada aplicativo analisado.

Exemplo de arquivo de saída AppsRecommendedForBoost.tsv:

applicationId	applicationName	rddPercentage	unsupportedSqlPercentage	totalTaskTime	supportedTaskTime	supportedSqlPercentage	recommendedForBoost	expectedRuntimeReduction
app-2024081/batches/083f6196248043938-000	projects/example.com:dev/locations/us-central1 6b4d6cae140f883c0 11c8e	0%	0%	548924253	548924253	100%	TRUE	30%
app-2024081/batches/60381cab738021457-000	projects/example.com:dev/locations/us-central1 474113a1462b426bf b3aeb	0%	0%	514401703	514401703	100%	TRUE	30%

Descrições de colunas:

applicationId: o ApplicationID do aplicativo Spark. Use isso para identificar a carga de trabalho em lote correspondente.
applicationName: o nome do aplicativo Spark.
rddPercentage: a porcentagem de operações de RDD no aplicativo. As operações de RDD não são compatíveis com a execução de consultas nativas.
unsupportedSqlPercentage: Porcentagem de operações SQL não compatíveis com a execução de consultas nativas.
totalTaskTime: tempo cumulativo de todas as tarefas executadas durante a execução do aplicativo.
supportedTaskTime: o tempo total de tarefa compatível com a execução de consultas nativas.

As colunas a seguir fornecem informações importantes para ajudar você a determinar se a execução de consultas nativas pode beneficiar sua carga de trabalho em lote:

supportedSqlPercentage:a porcentagem de operações SQL compatíveis com a execução de consultas nativas. Quanto maior a porcentagem, maior a redução no tempo de execução que pode ser alcançada ao executar o aplicativo com a execução de consultas nativas.
recommendedForBoost:se TRUE, recomendamos executar o aplicativo com a execução de consultas nativas. Se recommendedForBoost for FALSE, não use a execução de consultas nativas na carga de trabalho em lote.
expectedRuntimeReduction:a redução esperada na porcentagem do tempo de execução do aplicativo ao executar o aplicativo com a execução de consultas nativas.

Arquivo de saída `UnsupportedOperators.tsv`.

O arquivo de saída UnsupportedOperators.tsv contém uma lista de operadores usados em aplicativos de carga de trabalho que não são compatíveis com a execução de consultas nativas. Cada linha no arquivo de saída lista um operador sem suporte.

Descrições de colunas:

unsupportedOperator: o nome do operador que não é compatível com a execução de consultas nativas.
cumulativeCpuMs: o número de milissegundos de CPU consumidos durante a execução do operador. Esse valor reflete a importância relativa do operador no aplicativo.
count: o número de vezes que o operador é usado no aplicativo.

Usar a execução de consultas nativas

Você pode usar a execução de consultas nativas com seu aplicativo definindo propriedades de execução de consultas nativas ao criar a carga de trabalho em lote, a sessão interativa ou o modelo de sessão que executa seu aplicativo.

Usar a execução de consultas nativas com cargas de trabalho em lote

É possível usar o console Google Cloud , a Google Cloud CLI ou a API Dataproc para ativar a execução de consultas nativas em uma carga de trabalho em lote.

Console

Use o console Google Cloud para ativar a execução de consultas nativas em uma carga de trabalho em lote.

No console do Google Cloud :
1. Acessar Lotes do Dataproc.
2. Clique em Criar para abrir a página Criar lote.
Selecione e preencha os seguintes campos para configurar o lote para execução de consultas nativas:
- Contêiner:
  - Versão do ambiente de execução:selecione 1.2, 2.2 ou um número de versão major.minor mais alto. Consulte Versões de ambiente de execução sem servidor para Apache Spark compatíveis.
- Configuração do nível do executor e do driver:
  - Selecione Premium para todos os níveis (Nível de computação do driver, Nível de computação de execução).
- Propriedades:insira pares Key (nome da propriedade) e Value para especificar propriedades de execução de consultas nativas:
  
  Chave Valor
  
  spark.dataproc.runtimeEngine nativo
Preencha, selecione ou confirme outras configurações de cargas de trabalho em lote. Consulte Enviar uma carga de trabalho em lote do Spark.
Clique em Enviar para executar a carga de trabalho em lote do Spark.

Chave	Valor
`spark.dataproc.runtimeEngine`	nativo

gcloud

Defina as seguintes flags de comando da CLI gcloud gcloud dataproc batches submit spark para configurar uma carga de trabalho em lote para a execução de consultas nativas:

gcloud dataproc batches submit spark \
    --project=PROJECT_ID \
    --region=REGION \
    --jars=file:///usr/lib/spark/examples/jars/spark-examples.jar \
    --class=org.apache.spark.examples.SparkPi \
    --properties=spark.dataproc.runtimeEngine=native,spark.dataproc.driver.compute.tier=premium,spark.dataproc.executor.compute.tier=premium \
    OTHER_FLAGS_AS_NEEDED

Observações:

PROJECT_ID: o ID do projeto do Google Cloud . Os IDs do projeto estão listados na seção Informações do projeto do painel do console Google Cloud .
REGION: uma região do Compute Engine disponível para executar a carga de trabalho.
OTHER_FLAGS_AS_NEEDED: consulte Enviar uma carga de trabalho em lote do Spark.

API

Defina os seguintes campos da API Dataproc para configurar uma carga de trabalho em lote para a execução de consultas nativas:

RuntimeConfig.properties:defina as seguintes propriedades de execução de consultas nativas:
```
"spark.dataproc.runtimeEngine":"native"
"spark.dataproc.driver.compute.tier":"premium"
"spark.dataproc.executor.compute".tier:"premium"
```
Observações:
- Consulte Enviar uma carga de trabalho em lote do Spark para definir outros campos da API de carga de trabalho em lote.

Quando usar a execução de consultas nativas

Use a execução de consultas nativas nos seguintes cenários:

APIs DataFrame e Dataset do Spark e consultas do Spark SQL que leem dados de arquivos Parquet e ORC. O formato do arquivo de saída não afeta o desempenho da execução de consultas nativas.
Cargas de trabalho recomendadas pela ferramenta de qualificação de execução de consultas nativas.

Quando não usar a execução de consultas nativas

Entradas dos seguintes tipos de dados:

Byte: ORC e Parquet
Carimbo de data/hora: ORC
Struct, Array, Map: Parquet

Limitações

Ativar a execução de consultas nativas nos seguintes cenários pode causar exceções, incompatibilidades do Spark ou fallback da carga de trabalho para o mecanismo padrão do Spark.

Substitutos

A execução de consultas nativas pode resultar em um fallback da carga de trabalho para o mecanismo de execução do Spark, causando regressão ou falha.

ANSI:se o modo ANSI estiver ativado, a execução vai voltar para o Spark.
Modo sensível a maiúsculas e minúsculas:a execução de consultas nativas aceita apenas o modo padrão do Spark que não diferencia maiúsculas de minúsculas. Se o modo sensível a maiúsculas e minúsculas estiver ativado, poderão ocorrer resultados incorretos.
Verificação de tabela particionada:a execução de consultas nativas é compatível com a verificação de tabela particionada somente quando o caminho contém as informações de partição. Caso contrário, a carga de trabalho volta para o mecanismo de execução do Spark.

Comportamento incompatível

Comportamento incompatível ou resultados incorretos podem ocorrer ao usar a execução de consultas nativas nos seguintes casos:

Funções JSON:a execução de consultas nativas é compatível com strings entre aspas duplas, não simples. Resultados incorretos ocorrem com aspas simples. Usar "*" no caminho com a função get_json_object retorna NULL.
Configuração de leitura do Parquet:
- A execução de consultas nativas trata spark.files.ignoreCorruptFiles como definido com o valor padrão false, mesmo quando definido como true.
- A execução de consultas nativas ignora spark.sql.parquet.datetimeRebaseModeInRead e retorna apenas o conteúdo do arquivo Parquet. As diferenças entre o calendário híbrido legado (juliano gregoriano) e o calendário gregoriano proleptico não são consideradas. Os resultados do Spark podem variar.
NaN:não compatível. Resultados inesperados podem ocorrer, por exemplo, ao usar NaN em uma comparação numérica.
Leitura colunar do Spark:um erro fatal pode ocorrer porque o vetor colunar do Spark é incompatível com a execução de consultas nativas.
Transbordamento:quando as partições de embaralhamento são definidas como um número grande, o recurso de transbordamento para disco pode acionar um OutOfMemoryException. Se isso acontecer, reduza o número de partições para eliminar essa exceção.