Batch-Arbeitslasten und interaktive Sitzungen mit der nativen Abfrageausführung beschleunigen

In diesem Dokument wird beschrieben, wann und wie Sie die native Abfrageausführung aktivieren, um Serverless für Apache Spark-Batcharbeitslasten und interaktive Sitzungen zu beschleunigen.

Anforderungen für die Ausführung nativer Abfragen

Die native Abfrageausführung für serverloses Apache Spark ist nur für Batcharbeitslasten und interaktive Sitzungen mit 1.2.26+, 2.2.26+ oder einer späteren Spark-Laufzeitversion verfügbar, die im Premium-Tarif für serverloses Apache Spark ausgeführt werden. Die Preise für die Premium-Stufe sind höher als die Preise für die Standard-Stufe. Für die Ausführung nativer Abfragen fallen jedoch keine zusätzlichen Kosten an. Preisinformationen finden Sie unter Preise für Serverless für Apache Spark.

Attribute für die Ausführung nativer Abfragen

In diesem Abschnitt werden die erforderlichen und optionalen Spark-Attribute für die Ressourcenzuweisung aufgeführt, mit denen Sie die native Abfrageausführung für Ihre Batcharbeitslast oder interaktive Sitzung aktivieren und anpassen können.

Erforderliche Einstellungen für Unterkünfte

• spark.dataproc.runtimeEngine=native: Die Laufzeit-Engine für die Arbeitslast muss auf native festgelegt werden, um die Standardlaufzeit-Engine spark zu überschreiben.

• spark.dataproc.spark.driver.compute.tier=premium und spark.dataproc.executor.compute.tier=premium: Diese Eigenschaften der Preisstufe müssen auf die Premium-Preisstufe festgelegt werden.

Optionale Eigenschaften für die Ressourcenaufteilung

• spark.dataproc.driver.disk.tier, spark.dataproc.driver.disk.size, spark.dataproc.executor.disk.tier und spark.dataproc.executor.disk.size: Mit diesen Properties können Sie die Premium-Laufwerkstufe und -Größe für die Spark-Treiber- und Executor-Prozesse festlegen und konfigurieren.

  Bei Premium-Festplattenstufen wird spaltenbasierter anstelle von zeilenbasiertem Shuffle verwendet, um eine bessere Leistung zu erzielen. Um den Shuffle-E/A-Durchsatz zu verbessern, verwenden Sie die Premium-Laufwerkstufen für Treiber und Executors mit einer ausreichend großen Laufwerksgröße für Shuffle-Dateien.

• spark.driver.memory, spark.driver.memoryOverhead, spark.executor.memory, spark.executor.memoryOverhead und spark.memory.offHeap.size: Mit diesen Eigenschaften können Sie den Speicher anpassen, der für Spark-Treiber- und Executor-Prozesse bereitgestellt wird.

  Sie haben zwei Möglichkeiten, das Gedächtnis zu konfigurieren:

  • Option 1: Nur Off-Heap-Speicher (spark.memory.offHeap.size) mit einem angegebenen Wert konfigurieren. Bei der Ausführung nativer Abfragen wird der angegebene Wert als Off-Heap-Speicher verwendet und zusätzlich 1/7th des Off-Heap-Speicherwerts als On-Heap-Speicher (spark.executor.memory) zugewiesen.

  • Option 2: Konfigurieren Sie sowohl den On-Heap-Speicher (spark.executor.memory) als auch den Off-Heap-Speicher (spark.memory.offHeap.size). Der für den Off-Heap-Speicher zugewiesene Betrag muss größer sein als der für den On-Heap-Speicher zugewiesene Betrag.

  Wenn Sie weder Off-Heap-Speicher (spark.memory.offHeap.size) noch On-Heap-Speicher (spark.executor.memory) konfigurieren, teilt die Engine für die Ausführung nativer Abfragen eine Standardmenge von 4g Arbeitsspeicher im Verhältnis 6:1 zwischen Off-Heap- und On-Heap-Speicher auf.

  Empfehlung: Weisen Sie Off-Heap-Speicher im Verhältnis 6:1 zu On-Heap-Speicher zu.

  Beispiele:

  Speichereinstellungen ohne Native Query Execution	Empfohlene Speichereinstellungen bei der Ausführung nativer Abfragen
  spark.executor.memory	spark.memory.offHeap.size	spark.executor.memory
  7g	6G	1G
  14g	12 g	2G
  28 g	24g	4G
  56g	48 g	8g

Qualifikationstool ausführen

Mit dem Qualifizierungstool können Sie Batcharbeitslasten ermitteln, die mit der Ausführung nativer Abfragen (Native Query Execution, NQE) schneller ausgeführt werden können. Das Tool analysiert Spark-Ereignisprotokolle, um potenzielle Laufzeitersparnisse zu schätzen und alle Vorgänge zu identifizieren, die von der NQE-Engine nicht unterstützt werden.

Google Cloud bietet zwei Methoden zum Ausführen der Qualifizierungsanalyse: Qualifizierungsjob und Qualifizierungsskript. Für die meisten Nutzer wird der Qualifizierungsjob empfohlen, da er die Ermittlung und Analyse von Batcharbeitslasten automatisiert. Das alternative Qualifizierungsscript ist für den speziellen Anwendungsfall der Analyse einer bekannten Ereignisprotokolldatei verfügbar. Wählen Sie die Methode aus, die am besten zu Ihrem Anwendungsfall passt:

• Qualifizierungsjob (empfohlen): Dies ist die primäre und empfohlene Methode. Es handelt sich um einen PySpark-Job, der aktuelle Batcharbeitslasten in einem oder mehreren Google Cloud Projekten und ‑Regionen automatisch erkennt und analysiert. Verwenden Sie diese Methode, wenn Sie eine umfassende Analyse durchführen möchten, ohne einzelne Ereignisprotokolldateien manuell suchen zu müssen. Dieser Ansatz eignet sich ideal für die groß angelegte Bewertung der Eignung von NQE.

• Qualifizierungsskript (Alternative): Dies ist eine alternative Methode für erweiterte oder spezifische Anwendungsfälle. Es handelt sich um ein Shell-Script, mit dem eine einzelne Spark-Ereignisprotokolldatei oder alle Ereignisprotokolle in einem bestimmten Cloud Storage-Verzeichnis analysiert werden. Verwenden Sie diese Methode, wenn Sie den Cloud Storage-Pfad zu den Ereignisprotokollen haben, die Sie analysieren möchten.

Qualifikationsjob

Der Qualifizierungsjob vereinfacht die Analyse im großen Maßstab, indem er programmatisch nach Serverless for Apache Spark-Batcharbeitslasten sucht und einen verteilten Analysejob sendet. Das Tool bewertet Jobs in Ihrer gesamten Organisation, sodass Sie Ereignisprotokollpfade nicht mehr manuell suchen und angeben müssen.

IAM-Rollen zuweisen

Damit der Qualifizierungsjob auf Batch-Arbeitslastmetadaten zugreifen und Spark-Ereignislogs in Cloud Logging lesen kann, muss dem Dienstkonto, mit dem die Arbeitslast ausgeführt wird, in allen zu analysierenden Projekten die folgenden IAM-Rollen zugewiesen sein:

• Dataproc-Betrachter (roles/dataproc.viewer)
• Loganzeige (roles/logging.viewer)

Qualifizierungsjob senden

Sie reichen den Qualifizierungsjob mit dem gcloud CLI-Tool ein. Der Job enthält ein PySpark-Script und eine JAR-Datei, die in einem öffentlichen Cloud Storage-Bucket gehostet werden.

Sie können den Job in einer der folgenden Ausführungsumgebungen ausführen:

• Als Serverless for Apache Spark-Batcharbeitslast. Dies ist eine einfache, eigenständige Ausführung von Jobs.

• Als Job, der in einem Dataproc in Compute Engine-Cluster ausgeführt wird. Diese Vorgehensweise kann nützlich sein, um den Job in einen Workflow einzubinden.

Jobargumente

Argument	Beschreibung	Erforderlich/Optional?	Standardwert
--project-ids	Eine einzelne Projekt-ID oder eine durch Kommas getrennte Liste von Google Cloud-Projekt-IDs, nach denen Batch-Workloads gescannt werden sollen.	Nein	Das Projekt, in dem der Qualifizierungsjob ausgeführt wird.
--regions	Eine einzelne Region oder eine durch Kommas getrennte Liste von Regionen, die in den angegebenen Projekten gescannt werden sollen.	Nein	Alle Regionen in den angegebenen Projekten.
--start-time	Das Startdatum für das Filtern von Batches. Nur Batches, die an oder nach diesem Datum (Format: JJJJ-MM-TT) erstellt wurden, werden analysiert.	Nein	Es wird kein Filter für das Startdatum angewendet.
--end-time	Das Enddatum zum Filtern von Batches. Es werden nur Batches analysiert, die an oder vor diesem Datum (Format: JJJJ-MM-TT) erstellt wurden.	Nein	Es wird kein Filter für das Enddatum angewendet.
--limit	Die maximale Anzahl der zu analysierenden Batches pro Region. Die neuesten Batches werden zuerst analysiert.	Nein	Alle Batches, die den anderen Filterkriterien entsprechen, werden analysiert.
--output-gcs-path	Der Cloud Storage-Pfad (z. B. gs://your-bucket/output/), in den die Ergebnisdateien geschrieben werden.	Ja	Keine.
--input-file	Der Cloud Storage-Pfad zu einer Textdatei für die Bulk-Analyse. Falls angegeben, überschreibt dieses Argument alle anderen Argumente, die den Bereich definieren (--project-ids, --regions, --start-time, --end-time, --limit).	Nein	Keine.

Beispiele für Qualifizierungsjobs

• Ein Serverless for Apache Spark-Batchjob für einfache Ad-hoc-Analysen. Jobargumente werden nach dem Trennzeichen -- aufgeführt.

  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
  

• Ein Serverless for Apache Spark-Batchjob zur Analyse von bis zu 50 der letzten Batches, die in sample_project in der Region us-central1 gefunden wurden. Die Ergebnisse werden in einen Bucket in Cloud Storage geschrieben. Jobargumente werden nach dem Trennzeichen -- aufgeführt.

  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/
  

• Ein Dataproc on Compute Engine-Job, der an einen Dataproc-Cluster für die Bulk-Analyse in einem groß angelegten, wiederholbaren oder automatisierten Analyseworkflow gesendet wird. Jobargumente werden in einem INPUT_FILE platziert, der in einen BUCKET in Cloud Storage hochgeladen wird. Diese Methode eignet sich ideal, um in einem einzigen Lauf verschiedene Zeiträume oder Batchlimits für verschiedene Projekte und Regionen zu scannen.

  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
  

  Hinweise:

  INPUT_FILE: Jede Zeile in der Datei steht für eine separate Analyseanfrage und verwendet ein Format mit Ein-Buchstaben-Flags, gefolgt von ihren Werten, z. B. -p PROJECT-ID -r REGION -s START_DATE -e END_DATE -l LIMITS.

  Beispiel für den Inhalt einer Eingabedatei:

  -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
  

  Mit diesen Argumenten wird das Tool angewiesen, die folgenden beiden Bereiche zu analysieren:

  • Bis zu 100 Batches in „project1“ in der Region us-central1, die zwischen dem 1. Dezember 2025 und dem 15. Dezember 2025 erstellt wurden.
  • Bis zu 50 Batches in Projekt2 in der Region europe-west1, die am oder nach dem 15. November 2025 erstellt wurden.

Qualifizierungsskript

Verwenden Sie diese Methode, wenn Sie den direkten Cloud Storage-Pfad zu einem bestimmten Spark-Ereignislog haben, das Sie analysieren möchten. Bei diesem Ansatz müssen Sie ein Shell-Skript (run_qualification_tool.sh) auf einen lokalen Computer oder eine Compute Engine-VM herunterladen und ausführen, die für den Zugriff auf die Ereignislogdatei in Cloud Storage konfiguriert ist.

Führen Sie die folgenden Schritte aus, um das Script für Ereignisdateien von Serverless for Apache Spark-Batcharbeitslasten auszuführen.

1.Kopieren Sie run_qualification_tool.sh in ein lokales Verzeichnis, das die zu analysierenden Spark-Ereignisdateien enthält.

1. Führen Sie das Qualifizierungsskript aus, um eine oder mehrere Ereignisdateien im Skriptverzeichnis zu analysieren.

   ./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 und Werte:

   -f (erforderlich): Informationen zum Auffinden von Ereignisdateien für Spark-Arbeitslasten finden Sie unter Speicherorte von Spark-Ereignisdateien.

   • EVENT_FILE_PATH (erforderlich, sofern EVENT_FILE_NAME nicht angegeben ist): Pfad der zu analysierenden Ereignisdatei. Wenn nicht angegeben, wird davon ausgegangen, dass sich der Event-Dateipfad im aktuellen Verzeichnis befindet.

   • EVENT_FILE_NAME (erforderlich, sofern EVENT_FILE_PATH nicht angegeben ist): Name der zu analysierenden Ereignisdatei. Wenn kein Pfad angegeben ist, werden die Ereignisdateien analysiert, die rekursiv im Verzeichnis EVENT_FILE_PATH gefunden werden.

   -o(optional): Wenn nicht angegeben, erstellt das Tool ein output-Verzeichnis unter dem aktuellen Verzeichnis oder verwendet ein vorhandenes Verzeichnis, um Ausgabedateien zu speichern.

   • CUSTOM_OUTPUT_DIRECTORY_PATH: Ausgabeverzeichnispfad für Ausgabedateien.

   -k (optional):

   • SERVICE_ACCOUNT_KEY: Der Dienstkontoschlüssel im JSON-Format, falls für den Zugriff auf die EVENT_FILE_PATH erforderlich.

   -x (optional):

   • MEMORY_ALLOCATED: Arbeitsspeicher in Gigabyte, der dem Tool zugewiesen werden soll. Standardmäßig verwendet das Tool 80% des im System verfügbaren freien Arbeitsspeichers und alle verfügbaren Maschinenkerne.

   -t(optional):

   • PARALLEL_THREADS_TO_RUN: Die Anzahl der parallelen Threads, die für die Ausführung des Tools verwendet werden. Standardmäßig werden alle Cores ausgeführt.

   Beispiel für die Verwendung von Befehlen:

   ./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 diesem Beispiel durchläuft das Qualifizierungstool das Verzeichnis gs://dataproc-temp-us-east1-9779/spark-job-history und analysiert die darin und in seinen Unterverzeichnissen enthaltenen Spark-Ereignisdateien. Der Zugriff auf das Verzeichnis erfolgt über /keys/event-file-key. Das Tool verwendet 34 GB memory für die Ausführung und führt 5 parallele Threads aus.

   Speicherorte von Spark-Ereignisdateien

Führen Sie einen der folgenden Schritte aus, um die Spark-Ereignisdateien für Serverless for Apache Spark-Batcharbeitslasten zu finden:

1. Suchen Sie in Cloud Storage nach der spark.eventLog.dir für die Arbeitslast und laden Sie sie herunter.

   1. Wenn Sie spark.eventLog.dir nicht finden, legen Sie spark.eventLog.dir auf einen Cloud Storage-Speicherort fest, führen Sie die Arbeitslast noch einmal aus und laden Sie spark.eventLog.dir herunter.

2. Wenn Sie den Spark History Server für den Batchjob konfiguriert haben:

   1. Rufen Sie den Spark History Server auf und wählen Sie die Arbeitslast aus.
   2. Klicken Sie in der Spalte Ereignisprotokoll auf Herunterladen.

Tipp :Analyse von Spark-Jobs in Dataproc in Compute Engine: So führen Sie das Qualifizierungstool für Dataproc in Compute Engine-Spark-Jobs aus:

• Suchen Sie in Cloud Storage nach der spark.eventLog.dir für die Dataproc on Compute Engine-Spark-Jobs und laden Sie sie herunter.
• Führen Sie das Tool für die Ereignisprotokolle aus. Wenn das Tool die Verwendung von Native Query Execution empfiehlt, migrieren Sie die Jobs zu Serverless für Apache Spark-Batcharbeitslasten und führen Sie die Arbeitslasten dann mit Native Query Execution aus.

Ausgabedateien des Qualifizierungstools

Sobald der Qualifizierungsjob oder die Scriptanalyse abgeschlossen ist, werden die folgenden Ausgabedateien vom Qualifizierungstool in einem perfboost-output-Verzeichnis im aktuellen Verzeichnis platziert:

• AppsRecommendedForBoost.tsv: Eine tabulatorgetrennte Liste von Anwendungen, die für die Verwendung mit der Ausführung nativer Abfragen empfohlen werden.

• UnsupportedOperators.tsv: Eine tabulatorgetrennte Liste von Anwendungen, die nicht für die Verwendung mit der Ausführung nativer Abfragen empfohlen werden.

Der Inhalt der Ausgabedatei des Qualifizierungstools ist tabulatorgetrennt. Sie können die Dateien mit einem CSV- oder TSV-Dateireader wie Google Sheets aufrufen.

Hinweis :Wenn das Qualifizierungstool versucht, eine Ausgabedatei zu speichern und die Datei im Ausgabeverzeichnis vorhanden ist, fügt das Tool dem Dateinamen ein inkrementelles Suffix hinzu, bevor die neue Datei gespeichert wird.

AppsRecommendedForBoost.tsv-Ausgabedatei

Die folgende Tabelle zeigt den Inhalt einer Beispiel-Ausgabedatei AppsRecommendedForBoost.tsv. Sie enthält eine Zeile für jede analysierte Anwendung.

Beispiel für die AppsRecommendedForBoost.tsv-Ausgabedatei:

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

Spaltenbeschreibungen:

• applicationId: Die ApplicationID der Spark-Anwendung. Damit können Sie die entsprechende Batch-Arbeitslast identifizieren.

• applicationName: Der Name der Spark-Anwendung.

• rddPercentage: Der Prozentsatz der RDD-Vorgänge in der Anwendung. RDD-Vorgänge werden von der nativen Abfrageausführung nicht unterstützt.

• unsupportedSqlPercentage: Prozentsatz der SQL-Vorgänge, die von der nativen Abfrageausführung nicht unterstützt werden.

• totalTaskTime: Kumulative Aufgabenzeit aller Aufgaben, die während der Ausführung der Anwendung ausgeführt wurden.

• supportedTaskTime: Die gesamte Aufgabenzeit, die von der nativen Abfrageausführung unterstützt wird.

Die folgenden Spalten enthalten wichtige Informationen, mit denen Sie feststellen können, ob die Ausführung nativer Abfragen für Ihre Batcharbeitslast von Vorteil sein kann:

• supportedSqlPercentage:Der Prozentsatz der SQL-Vorgänge, die von der nativen Abfrageausführung unterstützt werden. Je höher der Prozentsatz, desto größer die Laufzeitverkürzung, die durch die Ausführung der Anwendung mit der nativen Abfrageausführung erzielt werden kann.

• recommendedForBoost:Wenn TRUE, wird empfohlen, die Anwendung mit der nativen Abfrageausführung auszuführen. Wenn recommendedForBoost gleich FALSE ist, verwenden Sie die native Abfrageausführung nicht für die Batcharbeitslast.

• expectedRuntimeReduction:Die erwartete prozentuale Reduzierung der Laufzeit der Anwendung, wenn Sie die Anwendung mit der Ausführung nativer Abfragen ausführen.

UnsupportedOperators.tsv-Ausgabedatei.

Die Ausgabedatei UnsupportedOperators.tsv enthält eine Liste der Operatoren, die in Arbeitslastanwendungen verwendet werden und von der Ausführung nativer Abfragen nicht unterstützt werden. In jeder Zeile der Ausgabedatei wird ein nicht unterstützter Operator aufgeführt.

Hinweis :Wenn Sie ein Google Cloud Support-Ticket öffnen und die Datei UnsupportedOperators.tsv anhängen, kann Dataproc die Unterstützung zusätzlicher Operatoren prüfen. Weitere Informationen

Spaltenbeschreibungen:

• unsupportedOperator: Der Name des Operators, der von der Ausführung nativer Abfragen nicht unterstützt wird.

• cumulativeCpuMs: Die Anzahl der CPU-Millisekunden, die während der Ausführung des Operators verbraucht wurden. Dieser Wert gibt die relative Bedeutung des Operators in der Anwendung an.

• count: Die Häufigkeit, mit der der Operator in der Anwendung verwendet wird.

Native Abfrageausführung verwenden

Sie können die Ausführung nativer Abfragen mit Ihrer Anwendung verwenden, indem Sie Eigenschaften für die Ausführung nativer Abfragen festlegen, wenn Sie die Batch-Arbeitslast, die interaktive Sitzung> oder die Sitzungsvorlage erstellen, in der Ihre Anwendung ausgeführt wird.

Tipp Für Batch-Arbeitslasten: Führen Sie das Qualifizierungstool aus, um festzustellen, ob die Ausführung Ihrer Batch-Arbeitslast mit der nativen Abfrageausführung empfohlen wird oder nicht.

Native Query Execution mit Batch-Arbeitslasten verwenden

Sie können die Google Cloud Console, die Google Cloud CLI oder die Dataproc API verwenden, um die Ausführung nativer Abfragen für eine Batcharbeitslast zu aktivieren.

Console

Verwenden Sie die Google Cloud Console, um die Ausführung nativer Abfragen für eine Batcharbeitslast zu aktivieren.

1. In der Google Cloud Console:

   1. Zu Dataproc-Batches
   2. Klicken Sie auf Erstellen, um die Seite Batch erstellen zu öffnen.

2. Wählen Sie die folgenden Felder aus und füllen Sie sie aus, um den Batch für die Ausführung nativer Abfragen zu konfigurieren:

   • Container:
     • Laufzeitversion:Wählen Sie 1.2, 2.2 oder eine höhere major.minor-Versionsnummer aus. Weitere Informationen finden Sie unter Unterstützte Serverless for Apache Spark-Laufzeitversionen.
   • Konfiguration der Executor- und Treiberstufe:
     • Wählen Sie Premium für alle Stufen (Computing-Stufe für Treiber, Computing-Stufe für Executor) aus.
   • Properties (Eigenschaften): Geben Sie Paare aus Key (Eigenschaftsname) und Value ein, um Eigenschaften für die Ausführung nativer Abfragen anzugeben:

     Schlüssel	Wert
     spark.dataproc.runtimeEngine	Einheimischer / Einheimische / Ureinwohner / Ureinwohnerin / gebürtig / einheimisch

3. Füllen Sie die anderen Einstellungen für Batch-Arbeitslasten aus, wählen Sie sie aus oder bestätigen Sie sie. Weitere Informationen finden Sie unter Spark-Batcharbeitslast senden.

4. Klicken Sie auf Senden, um die Spark-Batcharbeitslast auszuführen.

gcloud

Legen Sie die folgenden gcloud CLI-Befehlsflags gcloud dataproc batches submit spark fest, um eine Batcharbeitslast für die Ausführung nativer Abfragen zu konfigurieren:

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

Hinweise:

• PROJECT_ID: Ihre Google Cloud -Projekt-ID Projekt-IDs werden im Bereich Projektinformationen im Dashboard der Google Cloud Console aufgeführt.
• REGION: Eine verfügbare Compute Engine-Region zum Ausführen der Arbeitslast.
• OTHER_FLAGS_AS_NEEDED: Weitere Informationen finden Sie unter Spark-Batcharbeitslast senden.

API

Legen Sie die folgenden Dataproc API-Felder fest, um eine Batcharbeitslast für die Ausführung nativer Abfragen zu konfigurieren:

• RuntimeConfig.properties:Legen Sie die folgenden Eigenschaften für die Ausführung nativer Abfragen fest:

  "spark.dataproc.runtimeEngine":"native"
  "spark.dataproc.driver.compute.tier":"premium"
  "spark.dataproc.executor.compute".tier:"premium"
  

  Hinweise:

  • Informationen zum Festlegen anderer API-Felder für Batcharbeitslasten finden Sie unter Spark-Batcharbeitslast senden.

Wann sollte die Ausführung nativer Abfragen verwendet werden?

Verwenden Sie die Ausführung nativer Abfragen in den folgenden Szenarien:

• Spark-DataFrame-APIs, Spark-Dataset-APIs und Spark-SQL-Abfragen, mit denen Daten aus Parquet- und ORC-Dateien gelesen werden. Das Ausgabedateiformat hat keine Auswirkungen auf die Leistung der Ausführung nativer Abfragen.

• Arbeitslasten, die vom Qualifizierungstool für die Ausführung nativer Abfragen empfohlen werden.

Wann sollte die Ausführung nativer Abfragen nicht verwendet werden?

Eingaben der folgenden Datentypen:

• Byte: ORC und Parquet
• Zeitstempel: ORC
• Struct, Array, Map: Parquet

Beschränkungen

Das Aktivieren der Ausführung nativer Abfragen in den folgenden Szenarien kann zu Ausnahmen, Spark-Inkompatibilitäten oder einem Fallback der Arbeitslast auf die standardmäßige Spark-Engine führen.

Fallbacks

Die Ausführung nativer Abfragen kann dazu führen, dass die Arbeitslast auf die Spark-Ausführungs-Engine zurückfällt, was zu Regressionen oder Fehlern führt.

• ANSI:Wenn der ANSI-Modus aktiviert ist, wird die Ausführung auf Spark zurückgesetzt.

• Modus mit Berücksichtigung der Groß-/Kleinschreibung:Die Ausführung nativer Abfragen unterstützt nur den Spark-Standardmodus ohne Berücksichtigung der Groß-/Kleinschreibung. Wenn der Modus „Groß-/Kleinschreibung beachten“ aktiviert ist, können falsche Ergebnisse auftreten.

• Scan partitionierter Tabellen:Die native Abfrageausführung unterstützt den Scan partitionierter Tabellen nur, wenn der Pfad die Partitionsinformationen enthält. Andernfalls wird die Arbeitslast auf die Spark-Ausführungs-Engine zurückgesetzt.

Inkompatibles Verhalten

Inkompatibles Verhalten oder falsche Ergebnisse können auftreten, wenn die Ausführung nativer Abfragen in den folgenden Fällen verwendet wird:

• JSON-Funktionen:Bei der Ausführung nativer Abfragen werden Strings unterstützt, die von doppelten Anführungszeichen umgeben sind, nicht von einfachen Anführungszeichen. Bei einfachen Anführungszeichen werden falsche Ergebnisse angezeigt. Wenn Sie „*“ im Pfad mit der Funktion get_json_object verwenden, wird NULL zurückgegeben.

• Parquet-Lesekonfiguration:

  • Bei der Ausführung nativer Abfragen wird spark.files.ignoreCorruptFiles als auf den Standardwert false festgelegt behandelt, auch wenn der Wert true ist.
  • Bei der Ausführung nativer Abfragen wird spark.sql.parquet.datetimeRebaseModeInRead ignoriert und es werden nur die Inhalte der Parquet-Datei zurückgegeben. Unterschiede zwischen dem alten Hybridkalender (julianisch-gregorianisch) und dem proleptischen gregorianischen Kalender werden nicht berücksichtigt. Die Ergebnisse von Spark können abweichen.

• NaN:Nicht unterstützt. Unerwartete Ergebnisse können beispielsweise auftreten, wenn Sie NaN in einem numerischen Vergleich verwenden.

• Spaltenweises Lesen in Spark:Ein schwerwiegender Fehler kann auftreten, da der spaltenweise Spark-Vektor nicht mit der nativen Abfrageausführung kompatibel ist.

• Spill:Wenn die Anzahl der Shuffle-Partitionen auf einen hohen Wert festgelegt ist, kann die Funktion „Spill-to-Disk“ einen OutOfMemoryException auslösen. Wenn dies der Fall ist, kann diese Ausnahme durch Reduzieren der Anzahl der Partitionen behoben werden.