Accelera i carichi di lavoro batch e le sessioni interattive con l'esecuzione di query nativa

Questo documento descrive quando e come attivare l'esecuzione di query native per accelerare i workload batch e le sessioni interattive di Serverless per Apache Spark.

Requisiti di esecuzione delle query native

L'esecuzione di query native di Serverless per Apache Spark è disponibile solo con carichi di lavoro batch e sessioni interattive che utilizzano 1.2.26+, 2.2.26+ o una versione del runtime Spark successiva in esecuzione nel livello di prezzo premium di Serverless per Apache Spark. I prezzi del livello Premium vengono addebitati a un costo superiore rispetto a quelli del livello Standard, ma non sono previsti costi aggiuntivi per l'esecuzione di query native. Per informazioni sui prezzi, consulta Prezzi di Serverless per Apache Spark.

Proprietà di esecuzione delle query native

Questa sezione elenca le proprietà di allocazione delle risorse Spark obbligatorie e facoltative che puoi utilizzare per attivare e personalizzare l'esecuzione di query native per il tuo carico di lavoro batch o la tua sessione interattiva.

Impostazioni proprietà obbligatorie

  • spark.dataproc.runtimeEngine=native: il motore di runtime del workload deve essere impostato su native per ignorare il motore di runtime spark predefinito.

  • spark.dataproc.spark.driver.compute.tier=premium e spark.dataproc.executor.compute.tier=premium: queste proprietà del livello di prezzo devono essere impostate sul livello di prezzo premium.

Proprietà di allocazione delle risorse facoltative

  • spark.dataproc.driver.disk.tier, spark.dataproc.driver.disk.size, spark.dataproc.executor.disk.tier e spark.dataproc.executor.disk.size: utilizza queste proprietà per impostare e configurare il livello e le dimensioni del disco premium per i processi del driver e dell'executor Spark.

    I livelli di dischi premium utilizzano lo shuffling basato su colonne anziché su righe per offrire prestazioni migliori. Per un migliore throughput I/O di shuffle, utilizza i livelli premium del disco del driver e dell'executor con una dimensione del disco sufficientemente grande da ospitare i file di shuffle.

  • spark.driver.memory, spark.driver.memoryOverhead, spark.executor.memory, spark.executor.memoryOverhead e spark.memory.offHeap.size: utilizza queste proprietà per ottimizzare la memoria fornita ai processi del driver e dell'executor Spark.

    Puoi configurare la memoria in uno dei seguenti modi:

    • Opzione 1: configura solo la memoria off-heap (spark.memory.offHeap.size) con un valore specificato. Native Query Execution utilizzerà il valore specificato come memoria off-heap e allocherà un ulteriore 1/7th del valore della memoria off-heap come memoria on-heap (spark.executor.memory).

    • Opzione 2: configura sia la memoria on-heap (spark.executor.memory) sia la memoria off-heap (spark.memory.offHeap.size). La quantità che allochi alla memoria off-heap deve essere maggiore della quantità che allochi alla memoria on-heap.

    Se non configuri sia la memoria off-heap (spark.memory.offHeap.size) sia la memoria on-heap (spark.executor.memory), il motore di esecuzione delle query native divide una quantità predefinita di memoria 4g in un rapporto 6:1 tra memoria off-heap e on-heap.

    Suggerimento: alloca la memoria off-heap a quella on-heap in un rapporto di 6:1.

    Esempi:

    Impostazioni di memoria senza esecuzione di query native Impostazioni di memoria consigliate con l'esecuzione di query nativa
    spark.executor.memory spark.memory.offHeap.size spark.executor.memory
    7g 6g 1g
    14g 12g 2g
    28g 24g 4g
    56g 48g 8g

Esegui lo strumento di qualificazione

Per identificare i carichi di lavoro batch che possono ottenere tempi di esecuzione più rapidi con l'esecuzione di query nativa (NQE), puoi utilizzare lo strumento di qualificazione. Lo strumento analizza i log eventi Spark per stimare i potenziali risparmi di runtime e identificare le operazioni non supportate dal motore NQE.

Google Cloud fornisce due metodi per eseguire l'analisi di qualificazione: job di qualificazione e script di qualificazione. L'approccio consigliato per la maggior parte degli utenti è il job di qualificazione, che automatizza l'individuazione e l'analisi dei workload batch. Lo script di qualificazione alternativo è disponibile per il caso d'uso specifico dell'analisi di un file di log degli eventi noto. Scegli il metodo più adatto al tuo caso d'uso:

  • Lavoro di qualificazione (consigliato): questo è il metodo principale e consigliato. Si tratta di un job PySpark che rileva e analizza automaticamente i recenti workload batch in uno o più progetti e regioni Google Cloud . Utilizza questo metodo quando vuoi eseguire un'analisi generale senza dover individuare manualmente i singoli file di log degli eventi. Questo approccio è ideale per la valutazione su larga scala dell'idoneità della NQE.

  • Script di qualificazione (alternativo): si tratta di un metodo alternativo per casi d'uso avanzati o specifici. Si tratta di uno script shell che analizza un singolo file di log degli eventi Spark o tutti i log degli eventi all'interno di una directory Cloud Storage specifica. Utilizza questo metodo se disponi del percorso Cloud Storage ai log degli eventi che vuoi analizzare.

Job di qualificazione

Il job di qualificazione semplifica l'analisi su larga scala eseguendo la scansione a livello di programmazione dei workload batch di Serverless per Apache Spark e inviando un job di analisi distribuita. Lo strumento valuta i job in tutta l'organizzazione, eliminando la necessità di trovare e specificare manualmente i percorsi dei log eventi.

Concedi ruoli IAM

Affinché il job di qualificazione possa accedere ai metadati del batch di lavoro e leggere i log eventi Spark in Cloud Logging, ilaccount di serviziot che esegue il workload deve disporre dei seguenti ruoli IAM concessi in tutti i progetti da analizzare:

Invia il job di qualifica

Invii il job di qualificazione utilizzando lo strumento gcloud CLI. Il job include uno script PySpark e un file JAR ospitati in un bucket Cloud Storage pubblico.

Puoi eseguire il job in uno dei seguenti ambienti di esecuzione:

  • Come carico di lavoro batch Serverless per Apache Spark. Si tratta di un'esecuzione semplice e autonoma del job.

  • Come job eseguito su un cluster Dataproc su Compute Engine. Questo approccio può essere utile per integrare il job in un flusso di lavoro.

Argomenti del job

Argomento Descrizione Obbligatorio? Valore predefinito
--project-ids Un singolo ID progetto o un elenco separato da virgole di ID progetto Google Cloud da analizzare per i carichi di lavoro batch. No Il progetto in cui viene eseguito il job di qualificazione.
--regions Una singola regione o un elenco di regioni separate da virgole da scansionare all'interno dei progetti specificati. No Tutte le regioni all'interno dei progetti specificati.
--start-time La data di inizio per il filtraggio dei batch. Verranno analizzati solo i batch creati a partire da questa data (formato: AAAA-MM-GG). No Non è applicato alcun filtro della data di inizio.
--end-time La data di fine per il filtro dei batch. Verranno analizzati solo i batch creati in questa data o prima (formato: AAAA-MM-GG). No Non viene applicato alcun filtro per la data di fine.
--limit Il numero massimo di batch da analizzare per regione. Vengono analizzati per primi i batch più recenti. No Vengono analizzati tutti i batch che corrispondono agli altri criteri di filtro.
--output-gcs-path Il percorso Cloud Storage (ad esempio gs://your-bucket/output/) in cui verranno scritti i file dei risultati. Nessuno.
--input-file Il percorso Cloud Storage di un file di testo per l'analisi collettiva. Se fornito, questo argomento sostituisce tutti gli altri argomenti che definiscono l'ambito (--project-ids, --regions, --start-time, --end-time, --limit). No Nessuno.

Esempi di lavori di qualifica

  • Un job batch Serverless per Apache Spark per eseguire analisi semplici e ad hoc. Gli argomenti del job sono elencati dopo il separatore --.

    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
    
  • Un job batch Serverless per Apache Spark per analizzare fino a 50 batch più recenti trovati in sample_project nella regione us-central1. I risultati vengono scritti nel bucket in Cloud Storage. Gli argomenti del job sono elencati dopo il separatore --.

    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/
    
  • Un job Dataproc su Compute Engine inviato a un cluster Dataproc per l'analisi collettiva in un flusso di lavoro di analisi su larga scala, ripetibile o automatizzato. Gli argomenti del job vengono inseriti in un INPUT_FILE caricato in un BUCKET in Cloud Storage. Questo metodo è ideale per analizzare diversi intervalli di date o limiti batch in diversi progetti e regioni in una singola esecuzione.

    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
    

    Note:

    INPUT_FILE: ogni riga del file rappresenta una richiesta di analisi distinta e utilizza un formato di flag di una sola lettera seguiti dai relativi valori, ad esempio -p PROJECT-ID -r REGION -s START_DATE -e END_DATE -l LIMITS.

    Esempio di contenuti del file di input:

    -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
    

    Questi argomenti indirizzano lo strumento ad analizzare i seguenti due ambiti:

    • Fino a 100 batch nel progetto1 nella regione us-central1 creati tra il 1° dicembre 2025 e il 15 dicembre 2025.
    • Fino a 50 batch nel progetto 2 nella regione europe-west1 creati a partire dal 15 novembre 2025.

Script di qualificazione

Utilizza questo metodo se disponi del percorso Cloud Storage diretto a un log eventi Spark specifico che vuoi analizzare. Questo approccio richiede di scaricare ed eseguire uno script shell, run_qualification_tool.sh, su una macchina locale o una VM Compute Engine configurata con accesso al file di log degli eventi in Cloud Storage.

Per eseguire lo script sui file di eventi del carico di lavoro batch Serverless per Apache Spark, segui questi passaggi.

1.Copia run_qualification_tool.sh in una directory locale che contiene i file di eventi Spark da analizzare.

  1. Esegui lo script di qualificazione per analizzare un file di eventi o un insieme di file di eventi contenuti nella directory dello 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
    

    Flag e valori:

    -f (obbligatorio): consulta Posizioni dei file di eventi Spark per individuare i file di eventi del carico di lavoro Spark.

    • EVENT_FILE_PATH (obbligatorio a meno che non sia specificato EVENT_FILE_NAME): percorso del file di eventi da analizzare. Se non viene fornito, si presume che il percorso del file di eventi sia la directory corrente.

    • EVENT_FILE_NAME (obbligatorio a meno che non sia specificato EVENT_FILE_PATH): nome del file di eventi da analizzare. Se non vengono forniti, vengono analizzati i file di eventi trovati in modo ricorsivo in EVENT_FILE_PATH.

    -o(facoltativo): se non viene fornita, lo strumento crea o utilizza una directory output esistente nella directory corrente per inserire i file di output.

    • CUSTOM_OUTPUT_DIRECTORY_PATH: Percorso della directory di output dei file di output.

    -k (facoltativo):

    -x (facoltativo):

    • MEMORY_ALLOCATED: la memoria in gigabyte da allocare allo strumento. Per impostazione predefinita, lo strumento utilizza l'80% della memoria libera disponibile nel sistema e tutti i core della macchina disponibili.

    -t(facoltativo):

    • PARALLEL_THREADS_TO_RUN: Il numero di thread paralleli che lo strumento deve eseguire. Per impostazione predefinita, lo strumento esegue tutti i core.

    Esempio di utilizzo del 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
    

    In questo esempio, lo strumento di qualificazione attraversa la directory gs://dataproc-temp-us-east1-9779/spark-job-history e analizza i file di eventi Spark contenuti in questa directory e nelle relative sottodirectory. L'accesso alla directory viene fornito il giorno /keys/event-file-key. Lo strumento utilizza 34 GB memory per l'esecuzione ed esegue 5 thread paralleli.

    Posizioni dei file degli eventi Spark

Esegui uno dei seguenti passaggi per trovare i file di eventi Spark per i carichi di lavoro batch di Serverless per Apache Spark:

  1. In Cloud Storage, individua il file spark.eventLog.dir per il carico di lavoro, quindi scaricalo.

    1. Se non riesci a trovare spark.eventLog.dir, imposta spark.eventLog.dir su una posizione Cloud Storage, quindi esegui di nuovo il carico di lavoro e scarica spark.eventLog.dir.
  2. Se hai configurato Spark History Server per il job batch:

    1. Vai al server di cronologia Spark, quindi seleziona il workload.
    2. Fai clic su Scarica nella colonna Log eventi.

File di output dello strumento di qualificazione

Una volta completata l'analisi del job di qualificazione o dello script, lo strumento di qualificazione inserisce i seguenti file di output in una directory perfboost-output nella directory corrente:

  • AppsRecommendedForBoost.tsv: Un elenco separato da tabulazioni di applicazioni consigliate per l'utilizzo con l'esecuzione di query native.

  • UnsupportedOperators.tsv: Un elenco separato da tabulazioni di applicazioni non consigliate per l'utilizzo con l'esecuzione di query native.

AppsRecommendedForBoost.tsv file di output

La seguente tabella mostra i contenuti di un file di output AppsRecommendedForBoost.tsv di esempio. Contiene una riga per ogni applicazione analizzata.

File di output AppsRecommendedForBoost.tsv di esempio:

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% VERO 30%
app-2024081/batches/60381cab738021457-000 projects/example.com:dev/locations/us-central1
474113a1462b426bf
b3aeb
0% 0% 514401703 514401703 100% VERO 30%

Descrizioni delle colonne:

  • applicationId: il ApplicationID dell'applicazione Spark. Utilizza questo campo per identificare il carico di lavoro batch corrispondente.

  • applicationName: il nome dell'applicazione Spark.

  • rddPercentage: la percentuale di operazioni RDD nell'applicazione. Le operazioni RDD non sono supportate dall'esecuzione di query native.

  • unsupportedSqlPercentage: Percentuale di operazioni SQL non supportate dall'esecuzione di query native.

  • totalTaskTime: tempo cumulativo di tutte le attività eseguite durante l'esecuzione dell'applicazione.

  • supportedTaskTime: il tempo totale dell'attività supportato dall'esecuzione di query native.

Le seguenti colonne forniscono informazioni importanti per aiutarti a determinare se l'esecuzione di query native può essere utile per il tuo carico di lavoro batch:

  • supportedSqlPercentage: la percentuale di operazioni SQL supportate dall'esecuzione di query nativa. Maggiore è la percentuale, maggiore è la riduzione del runtime che si può ottenere eseguendo l'applicazione con l'esecuzione di query nativa.

  • recommendedForBoost: se TRUE, è consigliabile eseguire l'applicazione con l'esecuzione di query nativa. Se recommendedForBoost è FALSE, non utilizzare l'esecuzione di query nativa sul carico di lavoro batch.

  • expectedRuntimeReduction: la riduzione percentuale prevista del runtime dell'applicazione quando esegui l'applicazione con l'esecuzione di query native.

UnsupportedOperators.tsv file di output.

Il file di output UnsupportedOperators.tsv contiene un elenco di operatori utilizzati nelle applicazioni del carico di lavoro che non sono supportati dall'esecuzione di query nativa. Ogni riga del file di output elenca un operatore non supportato.

Descrizioni delle colonne:

  • unsupportedOperator: il nome dell'operatore non supportato da Native Query Execution.

  • cumulativeCpuMs: il numero di millisecondi di CPU consumati durante l'esecuzione dell'operatore. Questo valore riflette l'importanza relativa dell'operatore nell'applicazione.

  • count: il numero di volte in cui l'operatore viene utilizzato nell'applicazione.

Utilizzare l'esecuzione di query native

Puoi utilizzare l'esecuzione di query native con la tua applicazione impostando le proprietà di esecuzione di query native quando crei il carico di lavoro batch, la sessione interattiva o il modello di sessione che esegue l'applicazione.

Utilizzare l'esecuzione di query native con carichi di lavoro batch

Puoi utilizzare la console Google Cloud , Google Cloud CLI o l'API Dataproc per attivare l'esecuzione di query native in un carico di lavoro batch.

Console

Utilizza la console Google Cloud per abilitare l'esecuzione di query native su un carico di lavoro batch.

  1. Nella console Google Cloud :

    1. Vai a Batch Dataproc.
    2. Fai clic su Crea per aprire la pagina Crea batch.
  2. Seleziona e compila i seguenti campi per configurare il batch per l'esecuzione di query native:

  3. Compila, seleziona o conferma le altre impostazioni dei carichi di lavoro batch. Vedi Inviare un carico di lavoro batch Spark.

  4. Fai clic su Invia per eseguire il carico di lavoro batch Spark.

gcloud

Imposta i seguenti flag di comando gcloud dataproc batches submit spark gcloud CLI per configurare un carico di lavoro batch per l'esecuzione di query native:

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

Note:

  • PROJECT_ID: il tuo ID progetto Google Cloud . Gli ID progetto sono elencati nella sezione Informazioni sul progetto della Google Cloud console Dashboard.
  • REGION: una regione di Compute Engine disponibile per l'esecuzione del carico di lavoro.
  • OTHER_FLAGS_AS_NEEDED: consulta Invio di un carico di lavoro batch Spark.

API

Imposta i seguenti campi dell'API Dataproc per configurare un carico di lavoro batch per l'esecuzione di query native:

Quando utilizzare l'esecuzione di query native

Utilizza l'esecuzione di query native nei seguenti scenari:

Quando non utilizzare l'esecuzione di query native

Input dei seguenti tipi di dati:

  • Byte: ORC e Parquet
  • Timestamp: ORC
  • Struct, Array, Map: Parquet

Limitazioni

L'attivazione dell'esecuzione di query native nei seguenti scenari può causare eccezioni, incompatibilità di Spark o fallback del workload al motore Spark predefinito.

Fallback

L'esecuzione di query native può comportare il fallback del carico di lavoro al motore di esecuzione Spark, con conseguente regressione o errore.

  • ANSI:se la modalità ANSI è attivata, l'esecuzione torna a Spark.

  • Modalità sensibile alle maiuscole e minuscole:l'esecuzione di query native supporta solo la modalità predefinita di Spark che non fa distinzione tra maiuscole e minuscole. Se la modalità sensibile alle maiuscole/minuscole è attivata, possono verificarsi risultati errati.

  • Scansione della tabella partizionata: l'esecuzione di query native supporta la scansione della tabella partizionata solo quando il percorso contiene le informazioni sulla partizione. In caso contrario, il carico di lavoro torna al motore di esecuzione Spark.

Comportamento incompatibile

Un comportamento incompatibile o risultati errati possono verificarsi quando si utilizza l'esecuzione di query native nei seguenti casi:

  • Funzioni JSON: l'esecuzione di query native supporta le stringhe racchiuse tra virgolette doppie, non singole. I risultati errati si verificano con gli apici singoli. L'utilizzo di "*" nel percorso con la funzione get_json_object restituisce NULL.

  • Configurazione di lettura Parquet:

    • L'esecuzione di query native considera spark.files.ignoreCorruptFiles come impostato sul valore predefinito false, anche se impostato su true.
    • L'esecuzione di query native ignora spark.sql.parquet.datetimeRebaseModeInRead e restituisce solo i contenuti del file Parquet. Le differenze tra il calendario ibrido precedente (giuliano gregoriano) e il calendario gregoriano prolettico non vengono prese in considerazione. I risultati di Spark possono variare.
  • NaN: non supportato. Possono verificarsi risultati imprevisti, ad esempio quando si utilizza NaN in un confronto numerico.

  • Lettura colonnare di Spark: può verificarsi un errore irreversibile perché il vettore colonnare di Spark non è compatibile con l'esecuzione di query native.

  • Spill:quando le partizioni di shuffling sono impostate su un numero elevato, la funzionalità di spill-to-disk può attivare un OutOfMemoryException. Se si verifica questo problema, la riduzione del numero di partizioni può eliminare questa eccezione.