Serverlose Dataproc-Batcharbeitslasten und interaktive Sitzungen mit nativer Abfrageausführung beschleunigen

Die native Abfrageausführung ist jetzt allgemein verfügbar. Sie unterstützt Spark Dataframe APIs, Spark SQL-Abfragen, die Daten aus Parquet- und ORC-Dateien lesen, sowie Workloads, die vom Tool zur Qualifizierung der nativen Abfrageausführung empfohlen werden. Bei Fragen zu weiteren Anwendungsfällen wenden Sie sich bitte an [e-mail].

In diesem Dokument wird beschrieben, wie Sie die native Abfrageausführung für Dataproc-Serverless-Batch-Arbeitslasten und interaktive Sitzungen aktivieren, die im Rahmen der Premium-Preisstufe ausgeführt werden.

Native Abfrageausführung mit Preisen der Premium-Stufe verwenden

Die native Abfrageausführung in Dataproc Serverless ist nur für Batcharbeitslasten und interaktive Sitzungen verfügbar, die im Dataproc Serverless-Premiumpreismodell ausgeführt werden. Die Preise für die Premium-Stufe sind höher als die für die Standardstufe. Für die Ausführung nativer Abfragen fallen jedoch keine zusätzlichen Kosten an. Weitere Informationen finden Sie unter Dataproc Serverless-Preise.

Sie können die Ressourcenzuweisung und die Preise für die Premium-Stufe für die Ressourcen von Batch- und interaktiven Sitzungen aktivieren, indem Sie die folgenden Eigenschaften der Ressourcenzuweisungsstufe auf premium festlegen, wenn Sie eine Spark-Batcharbeitslast oder eine interaktive Sitzung einreichen.

Sie konfigurieren die native Abfrageausführung, indem Sie die entsprechenden Eigenschaften für eine Batcharbeitslast, eine interaktive Sitzung oder eine Sitzungsvorlage festlegen und die Arbeitslast dann einreichen oder die interaktive Sitzung in einem Notebook ausführen.

Console

1. In der Google Cloud Console:

   1. Gehen Sie 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 native Abfrageausführung zu konfigurieren:

   • Container:
     • Laufzeitversion:Wählen Sie 1.2, 2.2 oder, falls verfügbar, eine höhere major.minor-Version aus. Weitere Informationen finden Sie unter Unterstützte Dataproc Serverless-Spark-Laufzeitversionen.
   • Konfiguration der Executor- und Treiberstufe:
     • Wählen Sie Premium für alle Stufen aus (Compute-Stufe für Treiber, Compute-Stufe für Executor).
   • Properties (Properties): Geben Sie die folgenden Paare aus Key (Property-Name) und Value für die folgenden Eigenschaften für die Ausführung nativer Abfragen ein:

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

3. Geben Sie die Einstellungen für andere Batch-Arbeitslasten ein, wählen Sie sie aus oder bestätigen Sie sie. Weitere Informationen finden Sie unter Spark-Batcharbeitslast einreichen.

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

gcloud

Legen Sie die folgenden gcloud CLI-Befehlsflags fest, um die Batch-Arbeitslast für die native Abfrageausführung zu konfigurieren:gcloud dataproc batches submit spark

gcloud dataproc batches submit spark \
    --project=PROJECT_ID \
    --region=REGION \
    --version=VERSION \
    --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.
• VERSION: Geben Sie 1.2, 2.2 oder, falls verfügbar, eine höhere major.minor-Version an. Weitere Informationen finden Sie unter Unterstützte serverlose Dataproc-Laufzeitversionen für Spark.
• OTHER_FLAGS_AS_NEEDED: Spark-Batcharbeitslast einreichen

API

Legen Sie die folgenden Dataproc API-Felder fest, um die Batcharbeitslast für die native Abfrageausführung zu konfigurieren:

• RuntimeConfig.version:Geben Sie 1.2, 2.2 oder, falls verfügbar, eine höhere major.minor-Versionsnummer an. Weitere Informationen finden Sie unter Unterstützte Dataproc Serverless-Spark-Laufzeitversionen.

• 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:

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

Arbeitslast für die native Abfrageausführung optimieren

Die native Abfrageausführung von Dataproc Serverless kann mit den folgenden Eigenschaften weiter optimiert werden:

Batch-Property	Geeignet für
spark.driver.memory spark.driver.memoryOverhead	To tune the memory provided to spark driver process
spark.executor.memory spark.executor.memoryOverhead spark.memory.offHeap.size	To tune the memory provided to onheap/offheap memory of executor process
spark.dataproc.driver.disk.tier spark.dataproc.driver.disk.size	To configure premium disk tier and size for driver
spark.dataproc.executor.disk.tier spark.dataproc.executor.disk.size	To configure premium disk tier and size for executor

Eigenschaften für die native Abfrageausführung

• spark.dataproc.runtimeEngine=native (erforderlich): Die Laufzeit-Engine für Arbeitslasten muss auf native festgelegt werden, um die Standard-Laufzeit-Engine spark zu überschreiben.

• version (Erforderlich): Für die Arbeitslast muss die Spark-Laufzeitversion 1.2.26 oder höher, 2.2.26 oder höher oder eine spätere Hauptlaufzeitversion verwendet werden.

• Premium-Rechenebenen (erforderlich): Die Properties spark.dataproc.spark.driver.compute.tier und spark.dataproc.executor.compute.tier müssen auf premium festgelegt sein.

• Premium-Speicherebenen (optional und empfohlen): Bei Premium-Speicherebenen wird statt eines zeilenbasierten Zufallsmixes ein spaltenbasierter Zufallsmix verwendet, um eine bessere Leistung zu erzielen. Für einen besseren I/O-Durchsatz beim Zufallsmix sollten Sie die Premium-Laufwerkebenen für Treiber und Executor mit einer ausreichend großen Laufwerkkapazität verwenden, um Zufallsmixdateien aufzunehmen.

• Arbeitsspeicher (Optional): Wenn Sie die Native Query Execution Engine konfiguriert haben, ohne sowohl Off-Heap-Speicher (spark.memory.offHeap.size) als auch On-Heap-Speicher (spark.executor.memory) zu konfigurieren, verwendet die Native Query Execution Engine einen standardmäßigen 4g Arbeitsspeicher und teilt ihn im Verhältnis 6:1 zwischen Off-Heap- und On-Heap-Speicher auf.

  Wenn Sie den Arbeitsspeicher bei der nativen Abfrageausführung konfigurieren möchten, haben Sie folgende Möglichkeiten:

  • Konfigurieren Sie nur Off-Heap-Speicher (spark.memory.offHeap.size) mit einem bestimmten Wert. Bei der nativen Abfrageausführung wird der angegebene Wert als Off-Heap-Speicher verwendet und ein zusätzlicher 1/7th des Off-Heap-Speicherwerts wird als On-Heap-Speicher zugewiesen.

  • Konfigurieren Sie sowohl On-Heap-Speicher (spark.executor.memory) als auch Off-Heap-Speicher (spark.memory.offHeap.size). Die Menge, die Sie dem Off-Heap-Speicher zuweisen, muss größer sein als die Menge, die Sie dem On-Heap-Speicher zuweisen. Empfehlung: Weisen Sie Off-Heap-Arbeitsspeicher im Verhältnis 6:1 zum On-Heap-Arbeitsspeicher zu.

  Beispielwerte:

  Speichereinstellungen ohne native Abfrageausführung	Empfohlene Speichereinstellungen bei nativer Abfrageausführung
  spark.executor.memory	spark.memory.offHeap.size	spark.executor.memory
  7 g	6 g	1 g
  14 g	12 g	2 g
  28 g	24 g	4 g
  56 g	48 g	8 g

Tool zur Qualifizierung der nativen Abfrageausführung

Mit dem Tool zur Qualifizierung der nativen Abfrageausführung von Dataproc, run_qualification_tool.sh, können Sie Arbeitslasten ermitteln, bei denen mit der nativen Abfrageausführung kürzere Laufzeiten möglich sind. Das Tool analysiert die von Batch-Arbeitslastanwendungen generierten Spark-Ereignisdateien und schätzt dann die potenziellen Laufzeiteinsparungen ab, die mit der nativen Abfrageausführung für jede Arbeitslastanwendung erzielt werden können.

Tool zur Gerätequalifikation ausführen

Führen Sie die folgenden Schritte aus, um das Tool mit Ereignisdateien für Dataproc Serverless-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 Qualifizierungstool aus, um eine oder mehrere Ereignisdateien im Scriptverzeichnis 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 Speicherort von Spark-Ereignisdateien finden Sie unter Speicherorte von Spark-Ereignisdateien.

   • EVENT_FILE_PATH (erforderlich, sofern EVENT_FILE_NAME nicht angegeben ist): Pfad zur zu analysierenden Ereignisdatei. Wenn kein Pfad angegeben ist, wird davon ausgegangen, dass der Pfad der Ereignisdatei das aktuelle Verzeichnis ist.

   • EVENT_FILE_NAME (erforderlich, sofern EVENT_FILE_PATH nicht angegeben ist): Name der zu analysierenden Ereignisdatei. Wenn keine angegeben wird, werden die Ereignisdateien analysiert, die rekursiv in EVENT_FILE_PATH gefunden werden.

   -o(optional): Wenn Sie diesen Parameter nicht angeben, erstellt das Tool ein output-Verzeichnis im aktuellen Verzeichnis oder verwendet ein vorhandenes output-Verzeichnis, um Ausgabedateien dort abzulegen.

   • CUSTOM_OUTPUT_DIRECTORY_PATH: Pfad zum Ausgabeverzeichnis 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: „N“ steht für die Anzahl der parallelen Threads, die das Tool ausführen soll. Standardmäßig werden alle Kerne ausgeführt.

   Beispiel für die Verwendung des Befehls:

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

Ausgabedateien des Qualifizierungstools

Nach Abschluss der Analyse platziert das Tool die folgenden Ausgabedateien im aktuellen Verzeichnis im Verzeichnis perfboost-output:

• AppsRecommendedForBoost.tsv: Eine durch Tabulatoren getrennte Liste von Anwendungen, die für die native Abfrageausführung empfohlen werden.

• UnsupportedOperators.tsv: Eine durch Tabulatoren getrennte Liste von Anwendungen, die für die native Abfrageausführung nicht empfohlen werden.

Der Inhalt der Ausgabedatei des Qualifizierungstools ist durch Tabulatoren getrennt. Sie können die Dateien mit einem CSV- oder TSV-Dateireader wie Google Tabellen ansehen.

Hinweis :Wenn das Qualifizierungstool versucht, eine Ausgabedatei zu speichern, und die Datei bereits 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-AppsRecommendedForBoost.tsv-Ausgabedatei. Sie enthält eine Zeile für jede analysierte Anwendung.

Beispiel für eine 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. Anhand dieser ID können Sie die entsprechende Batch-Arbeitslast ermitteln.

• 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: Die kumulative Aufgabenzeit aller Aufgaben, die während der Ausführung der Anwendung ausgeführt wurden.

• supportedTaskTime: Die Gesamtzeit der Aufgabe, die von der Ausführung nativer Abfragen unterstützt wird.

In den folgenden Spalten finden Sie wichtige Informationen, mit denen Sie feststellen können, ob die native Abfrageausführung für Ihre Batcharbeitslast von Vorteil ist:

• supportedSqlPercentage:Der Prozentsatz der SQL-Vorgänge, die von der nativen Abfrageausführung unterstützt werden. Je höher der Prozentsatz, desto mehr kann die Laufzeit durch die Ausführung der Anwendung mit nativer Abfrageausführung reduziert werden.

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

• expectedRuntimeReduction:Die erwartete prozentuale Verringerung der Anwendungslaufzeit, wenn die Anwendung mit der nativen Abfrageausführung ausgeführt wird.

UnsupportedOperators.tsv-Ausgabedatei.

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

Hinweis: Wenn Sie ein Google Cloud-Supportticket erstellen und die Datei UnsupportedOperators.tsv anhängen, kann Dataproc prüfen, ob zusätzliche Operatoren unterstützt werden. Weitere Informationen finden Sie unter Support kontaktieren.

Spaltenbeschreibungen:

• unsupportedOperator: Der Name des Operators, der von der nativen Abfrageausführung nicht unterstützt wird.

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

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

Qualifikationstool projektübergreifend ausführen

In diesem Abschnitt wird beschrieben, wie Sie ein Script ausführen, um das Qualifizierungstool zu starten und Batch-Arbeitslasten von Spark-Ereignisdateien aus mehreren Projekten zu analysieren.

Anforderungen und Einschränkungen für Scripts:

• Führen Sie das Script auf Linux-Computern aus:
  • Die Java-Version >=11 muss als Standard-Java-Version installiert sein.
• Da Logs in Cloud Logging eine TTL von 30 Tagen haben, können Spark-Ereignisdateien aus Batch-Arbeitslasten, die vor mehr als 30 Tagen ausgeführt wurden, nicht analysiert werden.

So führen Sie das Tool zur Qualifikation projektübergreifend aus:

1. Laden Sie das Script list-batches-and-run-qt.sh herunter und kopieren Sie es auf Ihren lokalen Computer.

2. Ändern Sie die Scriptberechtigungen.

   chmod +x list-batches-and-run-qt.sh
   

3. Erstellen Sie eine Liste der Projekt-Eingabedateien, die an das Script zur Analyse übergeben werden sollen. Erstellen Sie die Textdatei, indem Sie für jedes Projekt und jede Region mit Spark-Ereignisdateien für die Batch-Arbeitslast eine Zeile im folgenden Format hinzufügen.

   -r REGION -s START_DATE -e END_DATE -p PROJECT_ID -l LIMIT_MAX_BATCHES -k KEY_PATH
   

   Hinweise:

   -r (erforderlich):

   • REGION: Region, in der die Batches im Projekt eingereicht werden.

   -s (erforderlich): Format: yyyy-mm-dd. Sie können optional ein Zeitsegment vom Typ 00:00:00 hinzufügen.

   • START_DATE: Es werden nur Batch-Arbeitslasten analysiert, die nach dem Startdatum erstellt wurden. Batches werden in absteigender Reihenfolge der Erstellungszeit analysiert. Die neuesten Batches werden zuerst analysiert.

   -e (optional): Format: yyyy-mm-dd. Sie können optional ein Zeitsegment vom Typ 00:00:00 hinzufügen.

   • END_DATE: Wenn Sie dies angeben, werden nur Batch-Arbeitslasten analysiert, die vor oder am Enddatum erstellt wurden. Wenn Sie nichts angeben, werden alle Batches analysiert, die nach dem START_DATE erstellt wurden. Batches werden in absteigender Reihenfolge der Erstellungszeit analysiert. Die neuesten Batches werden zuerst analysiert.

   -l (optional):

   • LIMIT_MAX_BATCHES: Die maximale Anzahl der zu analysierenden Batches. Sie können diese Option in Kombination mit START-DATE und END-DATE verwenden, um eine begrenzte Anzahl von Batches zu analysieren, die zwischen den angegebenen Datumsangaben erstellt wurden.

     Wenn „-l“ nicht angegeben ist, werden standardmäßig bis zu 100 Batches analysiert.

   -k (optional):

   • KEY_PATH: Ein lokaler Pfad mit Cloud Storage-Zugriffsschlüsseln für die Spark-Ereignisdateien der Arbeitslast.

   Beispiel für eine Eingabedatei:

   -r us-central1 -s 2024-08-21 -p project1 -k key1
   -r us-east1 -s 2024-08-21 -e 2024-08-23 -l 50 -p project2 -k key2
   

   Hinweise:

   • Zeile 1:Es werden bis zu 100 (Standard) der neuesten Spark-Ereignisdateien in project1 in der Region us-central1 mit einer Erstellungszeit nach dem 2024-08-21 00:00:00 AM analysiert. key1 ermöglicht den Zugriff auf die Dateien in Cloud Storage.

   • Zeile 2:Es werden bis zu 50 aktuellste Spark-Ereignisdateien in project2 in der Region us-eastl1 mit einer Erstellungszeit nach dem 2024-08-21 00:00:00 AM und vor oder am 23. August 2024 um 23:59:59 Uhr analysiert. key2 ermöglicht den Zugriff auf die Ereignisdateien in Cloud Storage.

4. Führen Sie das Skriptlist-batches-and-run-qt.sh aus: Die Analyseergebnisse werden in den Dateien AppsRecommendedForBoost.tsv und UnsupportedOperators.tsv ausgegeben.

   ./list-batches-and-run-qt.sh PROJECT_INPUT_FILE_LIST \
       -x MEMORY_ALLOCATED \
       -o CUSTOM_OUTPUT_DIRECTORY_PATH \
       -t PARALLEL_THREADS_TO_RUN
   

   Hinweise:

   • PROJECT_INPUT_FILE_LIST: Siehe Anleitung unter 3.

   • -x, -o und -t: Weitere Informationen finden Sie unter Qualifikationstool ausführen.

Speicherorte von Spark-Ereignisdateien

Führen Sie einen der folgenden Schritte aus, um die Spark-Ereignisdateien für serverlose Dataproc-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 die spark.eventLog.dir nicht finden, legen Sie sie auf einen Cloud Storage-Speicherort fest, führen Sie die Arbeitslast dann noch einmal aus und laden Sie die spark.eventLog.dir herunter.spark.eventLog.dir

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: Dataproc on Compute Engine Spark-Job-Analyse: So führen Sie das Qualifizierungstool für Spark-Jobs in Dataproc on Compute Engine 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 auf den Ereignisprotokollen aus. Wenn das Tool die Verwendung der nativen Abfrageausführung empfiehlt, migrieren Sie die Jobs zu Dataproc Serverless-Batcharbeitslasten und führen Sie die Arbeitslasten dann mit der nativen Abfrageausführung aus.

Wann sollte die native Abfrageausführung verwendet werden?

Verwenden Sie die native Abfrageausführung in den folgenden Fällen:

Spark DataFrame APIs und Spark SQL-Abfragen, die Daten aus Parquet- und ORC-Dateien lesen.
Arbeitslasten, die vom Qualifizierungstool für die native Abfrageausführung empfohlen werden.

Wann die Ausführung nativer Abfragen nicht verwendet werden sollte

Verwenden Sie die native Abfrageausführung nicht in den folgenden Fällen, da dies möglicherweise nicht zu einer Verringerung der Laufzeit der Arbeitslast führt und zu Fehlern oder Rückschritten führen kann:

• Arbeitslasten, die vom Tool zur Qualifizierung der nativen Abfrageausführung nicht empfohlen werden.
• Spark-RDDs, UDFs und ML-Arbeitslasten
• Arbeitslasten schreiben
• Andere Dateiformate als Parquet und ORC
• Eingaben der folgenden Datentypen:
• Timestamp, TinyInt, Byte, Struct, Array, Map: ORC und Parquet
• VarChar, Char: ORC
• Abfragen mit regulären Ausdrücken
• Arbeitslasten, die einen „Anforderer bezahlt“-Bucket verwenden
• Nicht standardmäßige Cloud Storage-Konfigurationseinstellungen Bei der Ausführung nativer Abfragen werden viele Standardwerte verwendet, auch wenn sie überschrieben werden.

Beschränkungen

Wenn Sie die native Abfrageausführung in den folgenden Fällen aktivieren, kann dies zu Ausnahmen, Spark-Inkompatibilitäten oder zum Rückfall auf die Standard-Spark-Engine führen.

Fallbacks

Die Ausführung nativer Abfragen kann zu einem Fallback der Arbeitslast auf die Spark-Ausführungs-Engine führen, was zu einer Regression oder einem Fehler führen kann.

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

• Groß- und Kleinschreibung berücksichtigen:Die native Abfrageausführung unterstützt nur den Spark-Standardmodus, bei dem die Groß- und Kleinschreibung nicht berücksichtigt wird. Wenn die Groß- und Kleinschreibung berücksichtigt wird, können falsche Ergebnisse auftreten.

• Scan der partitionierten Tabelle:Die native Abfrageausführung unterstützt den Scan der partitionierten Tabelle nur, wenn der Pfad die Partitionsinformationen enthält. Andernfalls greift die Arbeitslast auf die Spark-Ausführungs-Engine zurück.

Inkompatibles Verhalten

In den folgenden Fällen kann die Ausführung nativer Abfragen zu inkompatiblem Verhalten oder falschen Ergebnissen führen:

• JSON-Funktionen:Die native Abfrageausführung unterstützt Strings, die in doppelte Anführungszeichen eingeschlossen sind, nicht in einfache Anführungszeichen. Bei einfachen Anführungszeichen werden falsche Ergebnisse ausgegeben. Wenn Sie „*“ im Pfad mit der get_json_object-Funktion verwenden, wird NULL zurückgegeben.

• Konfiguration für das Lesen von Parquet-Dateien:

  • Bei der nativen Abfrageausführung wird spark.files.ignoreCorruptFiles als Standardwert false behandelt, auch wenn er auf true gesetzt ist.
  • Bei der nativen Abfrageausführung wird spark.sql.parquet.datetimeRebaseModeInRead ignoriert und nur der Inhalt der Parquet-Datei zurückgegeben. Unterschiede zwischen dem alten Hybridkalender (Julianisch-Gregorianisch) und dem proleptischen Gregorianischen Kalender werden nicht berücksichtigt. Die Spark-Ergebnisse können abweichen.

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

• Spark-spaltenweise Lesefunktion:Ein schwerwiegender Fehler kann auftreten, da der Spark-spaltenweise Vektor nicht mit der Ausführung nativer Abfragen kompatibel ist.

• Spill:Wenn die Anzahl der Zufallsmix-Partitionen hoch ist, kann die Funktion „Spill-to-Disk“ einen OutOfMemoryException auslösen. In diesem Fall kann diese Ausnahme durch Reduzierung der Anzahl der Partitionen beseitigt werden.