Batcharbeitslasten überwachen und Fehler beheben

In diesem Dokument werden die Tools und Dateien beschrieben, die Sie zum Monitoring und zur Fehlerbehebung bei Batcharbeitslasten von Managed Service for Apache Spark verwenden können.

Fehlerbehebung bei Arbeitslasten über die Google Cloud Console

Wenn ein Batchjob fehlschlägt oder eine schlechte Leistung aufweist, wird empfohlen, zuerst die Seite Jobdetails (Batchdetails) zu öffnen. Klicken Sie dazu auf dem Tab Serverloses Spark der Seite Jobs in der Google Cloud -Console auf die Job-ID des Batches.

Tab „Zusammenfassung“: Ihr Hub zur Fehlerbehebung

Auf dem Tab Zusammenfassung, der standardmäßig ausgewählt ist, wenn die Seite Jobdetails für den Batch geöffnet wird, werden wichtige Messwerte und gefilterte Logs angezeigt, mit denen Sie den Zustand des Batchs schnell beurteilen können. Nach dieser ersten Bewertung können Sie eine tiefergehende Analyse mit spezielleren Tools durchführen, die auf der Seite Jobdetails für den Batch verfügbar sind, z. B. der Spark-UI, dem Log-Explorer und Gemini Cloud Assist.

Batch-Messwert-Highlights

Die Tabs Zusammenfassung und Monitoring auf der Seite Jobdetails für den Batch enthalten Diagramme mit wichtigen Messwerten für die Batcharbeitslast. Die Messwertdiagramme werden nach Abschluss des Jobs ausgefüllt und bieten eine visuelle Darstellung potenzieller Probleme wie Ressourcenkonflikte, Datenverzerrung oder Speicherauslastung.

Messwerttabelle

In der folgenden Tabelle sind die Spark-Arbeitslastmesswerte aufgeführt, die in der Google Cloud Console auf der Seite Jobdetails für den Batch angezeigt werden. Außerdem wird beschrieben, wie Messwerte Aufschluss über den Status und die Leistung der Arbeitslast geben können.

Messwert	Was wird angezeigt?
Messwerte auf Executor-Ebene
Verhältnis von JVM-GC-Zeit zu Laufzeit	Dieser Messwert zeigt das Verhältnis der JVM-GC-Zeit (Garbage Collection) zur Laufzeit pro Executor. Hohe Verhältnisse können auf Speicherlecks in Aufgaben hinweisen, die auf bestimmten Executors ausgeführt werden, oder auf ineffiziente Datenstrukturen, was zu einer hohen Objektfluktuation führen kann.
An Laufwerk übergebene Byte	Dieser Messwert gibt die Gesamtzahl der Laufwerk-Bytes an, die auf verschiedene Executors verteilt wurden. Wenn ein Executor eine hohe Anzahl von auf die Festplatte ausgelagerten Byte aufweist, kann dies auf eine Datenverzerrung hindeuten. Wenn der Messwert im Laufe der Zeit steigt, kann dies darauf hindeuten, dass es Phasen mit Arbeitsspeicherdruck oder Speicherlecks gibt.
Gelesene und geschriebene Byte	Dieser Messwert zeigt die geschriebenen Bytes im Vergleich zu den gelesenen Bytes pro Executor. Große Abweichungen bei den gelesenen oder geschriebenen Byte können auf Szenarien hinweisen, in denen replizierte Joins zu einer Datenverstärkung auf bestimmten Executors führen.
Gelesene und geschriebene Einträge	Dieser Messwert zeigt die pro Executor gelesenen und geschriebenen Datensätze. Eine große Anzahl gelesener Datensätze bei einer geringen Anzahl geschriebener Datensätze kann auf einen Engpass in der Verarbeitungslogik bestimmter Executors hinweisen, was dazu führt, dass Datensätze während des Wartens gelesen werden. Executors, die bei Lese- und Schreibvorgängen ständig hinterherhinken, können auf Ressourcenkonflikte auf diesen Knoten oder auf executorspezifische Codeineffizienzen hinweisen.
Verhältnis von Shuffle-Schreibzeit zu Laufzeit	Der Messwert gibt an, wie viel Zeit der Executor im Vergleich zur Gesamtlaufzeit in der Shuffle-Laufzeit verbracht hat. Wenn dieser Wert für einige Executors hoch ist, kann dies auf eine Datenverzerrung oder eine ineffiziente Datenserialisierung hinweisen. In der Spark-UI können Sie Phasen mit langen Shuffle-Schreibzeiten identifizieren. Suchen Sie in diesen Phasen nach Ausreißeraufgaben, die länger als die durchschnittliche Zeit dauern. Prüfen Sie, ob die Executors mit hohen Shuffle-Schreibzeiten auch eine hohe Laufwerks-E/A-Aktivität aufweisen. Eine effizientere Serialisierung und zusätzliche Partitionierungsschritte können helfen. Sehr viele Schreibvorgänge im Vergleich zu Lesevorgängen können auf eine unbeabsichtigte Datenduplizierung aufgrund ineffizienter Joins oder fehlerhafter Transformationen hinweisen.
Messwerte auf Anwendungsebene
Phasenfortschritt	Dieser Messwert gibt die Anzahl der Phasen mit dem Status „Fehlgeschlagen“, „Wartend“ und „Wird ausgeführt“ an. Eine große Anzahl fehlgeschlagener oder wartender Phasen kann auf eine Datenverzerrung hinweisen. Prüfen Sie, ob Datenpartitionen vorhanden sind, und beheben Sie die Ursache für den Phasenfehler auf dem Tab Phasen in der Spark-Benutzeroberfläche.
Batch-Spark-Executors	Dieser Messwert zeigt die Anzahl der möglicherweise erforderlichen Executors im Vergleich zur Anzahl der ausgeführten Executors. Ein großer Unterschied zwischen erforderlichen und ausgeführten Executors kann auf Probleme mit dem Autoscaling hinweisen.
Messwerte auf VM-Ebene
Verwendeter Arbeitsspeicher	Dieser Messwert gibt den Prozentsatz des verwendeten VM-Arbeitsspeichers an. Wenn der Prozentsatz des Masters hoch ist, kann dies darauf hindeuten, dass der Treiber unter Arbeitsspeicherdruck steht. Bei anderen VM-Knoten kann ein hoher Prozentsatz darauf hindeuten, dass den Executors der Arbeitsspeicher ausgeht. Dies kann zu einem hohen Festplatten-Spillover und einer langsameren Laufzeit der Arbeitslast führen. Mit der Spark-Benutzeroberfläche können Sie Executors analysieren, um nach hoher GC-Zeit und hohen Taskfehlern zu suchen. Außerdem debuggen Sie Spark-Code für das Caching großer Datasets und die unnötige Übertragung von Variablen.

Jobprotokolle

Die Seite Jobdetails für den Batch enthält den Tab Joblogs (und Log-Highlights), auf dem Warnungen und Fehler aufgeführt sind, die aus den Logs des Jobs (Batcharbeitslast) gefiltert wurden. So lassen sich kritische Probleme schnell identifizieren, ohne dass umfangreiche Logdateien manuell analysiert werden müssen. Sie können im Drop-down-Menü einen Schweregrad für das Log auswählen (z. B. Error) und einen Textfilter hinzufügen, um die Ergebnisse einzugrenzen. Wenn Sie eine detailliertere Analyse durchführen möchten, klicken Sie auf das Symbol Im Log-Explorer ansehen, um die ausgewählten Batch-Logs im Log-Explorer zu öffnen.

Batch-Logs in Cloud Logging ansehen

Beispiel: Der Log-Explorer wird geöffnet, nachdem Sie auf der Seite Jobdetails für den Batch in der Google Cloud Console im Auswahlfeld für den Schweregrad die Option Errors ausgewählt haben.

Spark-UI

Die Spark-Benutzeroberfläche erfasst Apache Spark-Ausführungsdetails aus Managed Service for Apache Spark-Batcharbeitslasten. Für die Spark-UI-Funktion, die standardmäßig aktiviert ist, fallen keine Gebühren an.

Daten, die über die Spark-UI-Funktion erfasst werden, werden 90 Tage lang aufbewahrt. Mit dieser Weboberfläche können Sie Spark-Arbeitslasten überwachen und Fehler beheben, ohne einen Persistent History Server erstellen zu müssen.

Hinweis: Die Spark-UI erfasst und zeigt auch Ausführungsdetails aus interaktiven Sitzungen von Managed Service for Apache Spark an. Weitere Informationen finden Sie unter Interaktive Sitzungen von Managed Service for Apache Spark überwachen und Fehler beheben.

Erforderliche IAM-Berechtigungen und -Rollen (Identity and Access Management)

Die folgenden Berechtigungen sind erforderlich, um die Spark-UI-Funktion mit Batcharbeitslasten zu verwenden.

• Berechtigung zur Datenerhebung: dataproc.batches.sparkApplicationWrite. Diese Berechtigung muss dem Dienstkonto gewährt werden, das Batch-Arbeitslasten ausführt. Diese Berechtigung ist in der Rolle Managed Service for Apache Spark Worker enthalten, die automatisch dem Compute Engine-Standarddienstkonto zugewiesen wird, das Managed Service for Apache Spark standardmäßig verwendet (siehe Managed Service for Apache Spark-Dienstkonto). Wenn Sie jedoch ein benutzerdefiniertes Dienstkonto für Ihre Batcharbeitslast angeben, müssen Sie diesem Dienstkonto die Berechtigung dataproc.batches.sparkApplicationWrite hinzufügen. In der Regel weisen Sie dem Dienstkonto dazu die Rolle „Managed Service for Apache Spark“ (Worker) zu.

• Zugriffsberechtigung für Spark-UI: dataproc.batches.sparkApplicationRead. Diese Berechtigung muss einem Nutzer gewährt werden, um auf die Spark-UI in derGoogle Cloud Console zuzugreifen. Diese Berechtigung ist in den Rollen Dataproc Viewer, Dataproc Editor und Dataproc Administrator enthalten. Wenn Sie die Spark-UI in der Google Cloud -Konsole öffnen möchten, benötigen Sie eine dieser Rollen oder eine benutzerdefinierte Rolle, die diese Berechtigung enthält.

Spark-UI öffnen

Die Spark-UI-Seite ist in den Batcharbeitslasten der Google Cloud Console verfügbar.

1. Rufen Sie in der Google Cloud Console die Seite Jobs von Managed Service for Apache Spark auf.

   Zu Managed Service for Apache Spark-Jobs

2. Wählen Sie den Tab Serverless Spark aus und klicken Sie auf eine Job-ID für den Batch, um die Seite Jobdetails zu öffnen.

3. Klicken Sie auf In Spark-UI ansehen (neben Spark-Anwendungs-ID) oder auf Spark-UI ansehen.

Der Link In Spark-UI ansehen ist in den folgenden Fällen deaktiviert:

• Wenn eine erforderliche Berechtigung nicht gewährt wird
• Wenn die Spark-UI auf der Seite Jobdetails des Batches nicht aktiviert ist
• Wenn Sie das Attribut spark.dataproc.appContext.enabled auf false festlegen, wenn Sie eine Batcharbeitslast einreichen

Managed Service for Apache Spark-Logs

Logging ist in Managed Service for Apache Spark standardmäßig aktiviert und Arbeitslastlogs bleiben nach Abschluss einer Arbeitslast erhalten. Managed Service for Apache Spark erfasst Arbeitslastlogs in Cloud Logging. Sie können im Log-Explorer unter der Ressource Cloud Dataproc Batch auf Managed Service for Apache Spark-Logs zugreifen.

Managed Service for Apache Spark-Logs abfragen

Der Log-Explorer in der Google Cloud Console bietet einen Abfragebereich, mit dem Sie eine Abfrage zum Prüfen von Batch-Arbeitslastlogs erstellen können. So erstellen Sie eine Abfrage, um Logs von Batch-Arbeitslasten zu untersuchen:

1. Zum Log-Explorer

2. Ihr aktuelles Projekt ist ausgewählt. Sie können auf Bereich des Projekts eingrenzen klicken, um ein anderes Projekt auszuwählen.

3. Definieren Sie eine Batch-Logabfrage.

   • Verwenden Sie Filtermenüs, um nach einer Batcharbeitslast zu filtern.

     1. Wählen Sie unter Alle Ressourcen die Ressource Cloud Managed Service for Apache Spark Batch aus.

        

        1. Wählen Sie im Bereich Ressource auswählen den STANDORT des Batches und dann die BATCH-ID aus. Diese Batchparameter sind in der Google Cloud Console auf der Seite Jobs von Managed Service for Apache Spark auf dem Tab Serverless Spark aufgeführt.

           

        2. Klicken Sie auf Übernehmen.

        3. Geben Sie unter Lognamen auswählen im Feld Lognamen suchen den Wert dataproc.googleapis.com ein, um die Logtypen für die Abfrage einzuschränken. Wählen Sie einen oder mehrere der aufgeführten Protokolldateinamen aus.

           

   • Verwenden Sie den Abfrageeditor, um nach VM-spezifischen Logs zu filtern.

     1. Geben Sie den Ressourcentyp und den Namen der VM-Ressource an, wie im folgenden Beispiel gezeigt:

        resource.type="cloud_dataproc_batch"
        labels."dataproc.googleapis.com/resource_name"="VM_NAME_PREFIX-BATCH_UUID-VM_SUFFIX"
        

        Hinweise:
        • VM_NAME_PREFIX: Verwenden Sie gdpic-rm für Batcharbeitslasten, die auf Managed Service for Apache Spark 3.0 und höheren Laufzeitversionen ausgeführt werden. Verwenden Sie gdpic-srvls-batch für Batcharbeitslasten, die auf früheren Laufzeitversionen ausgeführt werden.
        • BATCH_UUID: Die Job-UUID des Batches wird auf der Seite Jobdetails (Batchdetails) in der Google Cloud -Konsole aufgeführt. Diese Seite wird geöffnet, wenn Sie auf der Seite Jobs auf dem Tab Serverloses Spark auf die Job-ID des Batches klicken.

          

        In den Batchlogs wird die Batch-UUID auch im VM-Ressourcennamen aufgeführt. Hier ein Beispiel aus einer Batch-driver.log-Datei:

        

4. Klicken Sie auf Abfrage ausführen.

Managed Service for Apache Spark-Protokolltypen und Beispielabfragen

In der folgenden Liste werden die verschiedenen Logtypen von Managed Service for Apache Spark beschrieben und Beispielabfragen für den Log-Explorer für jeden Logtyp bereitgestellt.

1. dataproc.googleapis.com/output: Diese Logdatei enthält die Ausgabe der Batch-Arbeitslast. Managed Service for Apache Spark streamt die Batchausgabe in den Namespace output und legt den Dateinamen auf JOB_ID.driver.log fest.

   Beispiel für eine Log-Explorer-Abfrage für Ausgabelogs:

   resource.type="cloud_dataproc_batch"
   resource.labels.location="REGION"
   resource.labels.batch_id="BATCH_ID"
   logName="projects/PROJECT_ID/logs/dataproc.googleapis.com%2Foutput"
   

2. dataproc.googleapis.com/spark: Der Namespace spark fasst Spark-Logs für Daemons und Executors zusammen, die auf Clustermaster- und Worker-VMs von Managed Service for Apache Spark ausgeführt werden. Jeder Logeintrag enthält ein Komponentenlabel master, worker oder executor, um die Logquelle zu identifizieren:

   • executor: Logs von Nutzercode-Executoren. In der Regel handelt es sich dabei um verteilte Logs.
   • master: Logs vom Master des eigenständigen Spark-Ressourcenmanagers, die den ResourceManager-Logs von Managed Service for Apache Spark YARN ähneln.
   • worker: Logs vom eigenständigen Ressourcenmanager-Worker von Spark, die den NodeManager-Logs von Managed Service for Apache Spark YARN ähneln.

   Beispiel für eine Log-Explorer-Abfrage für alle Logs im Namespace spark:

   resource.type="cloud_dataproc_batch"
   resource.labels.location="REGION"
   resource.labels.batch_id="BATCH_ID"
   logName="projects/PROJECT_ID/logs/dataproc.googleapis.com%2Fspark"
   

   Beispiel für eine Log-Explorer-Abfrage für Logs von eigenständigen Spark-Komponenten im Namespace spark:

   resource.type="cloud_dataproc_batch"
   resource.labels.location="REGION"
   resource.labels.batch_id="BATCH_ID"
   logName="projects/PROJECT_ID/logs/dataproc.googleapis.com%2Fspark"
   jsonPayload.component="COMPONENT"
   

3. dataproc.googleapis.com/startup: Der Namespace startup enthält die Startlogs für den Batch (Cluster). Alle Initialisierungsskript-Logs sind enthalten. Komponenten werden durch Labels identifiziert, z. B.:

   startup-script[855]: ... activate-component-spark[3050]: ... enable spark-worker
   

   Beispiel für eine Log-Explorer-Abfrage für Startlogs auf einer bestimmten VM:

   resource.type="cloud_dataproc_batch"
   resource.labels.location="REGION"
   resource.labels.batch_id="BATCH_ID"
   logName="projects/PROJECT_ID/logs/dataproc.googleapis.com%2Fstartup"
   labels."dataproc.googleapis.com/resource_name"="VM_NAME_PREFIX-BATCH_UUID-VM_SUFFIX"
   

4. dataproc.googleapis.com/agent: Der Namespace agent fasst die Agent-Logs von Managed Service for Apache Spark zusammen. Jeder Logeintrag enthält ein Dateinamenlabel, das die Logquelle identifiziert.

   Beispiel für eine Log-Explorer-Abfrage für Agent-Logs, die von einer bestimmten Worker-VM generiert wurden:

   resource.type="cloud_dataproc_batch"
   resource.labels.location="REGION"
   resource.labels.batch_id="BATCH_ID"
   logName="projects/PROJECT_ID/logs/dataproc.googleapis.com%2Fagent"
   labels."dataproc.googleapis.com/resource_name"="VM_NAME_PREFIX-BATCHUUID-wWORKER#"
   

5. dataproc.googleapis.com/autoscaler: Der Namespace autoscaler aggregiert Logs des Autoscalers von Managed Service for Apache Spark.

   Beispiel für eine Log-Explorer-Abfrage für Autoscaling-Logs, die von einer bestimmten Worker-VM generiert wurden:

   resource.type="cloud_dataproc_batch"
   resource.labels.location="REGION"
   resource.labels.batch_id="BATCH_ID"
   logName="projects/PROJECT_ID/logs/dataproc.googleapis.com%2Fautoscaler"
   labels."dataproc.googleapis.com/resource_name"="VM_NAME_PREFIX-BATCHUUID-wWORKER#"
   

Weitere Informationen finden Sie unter Logs für Managed Service for Apache Spark.

Informationen zu Audit-Logs für Managed Service for Apache Spark finden Sie unter Audit-Logging für Managed Service for Apache Spark.

Arbeitslastmesswerte

Managed Service for Apache Spark bietet Batch- und Spark-Messwerte, die Sie im Metrics Explorer oder auf der Seite Jobdetails für Batches in der Google Cloud Console aufrufen können.

Batchmesswerte

Ressourcenmesswerte für Managed Service for Apache Spark batch bieten Einblicke in Batchressourcen, z. B. die Anzahl der Batch-Executors. Batchmesswerte haben das Präfix dataproc.googleapis.com/batch.

Spark-Messwerte

Standardmäßig aktiviert Managed Service for Apache Spark die Erfassung von verfügbaren Spark-Messwerten, es sei denn, Sie verwenden Eigenschaften für die Erfassung von Spark-Messwerten, um die Erfassung eines oder mehrerer Spark-Messwerte zu deaktivieren oder zu überschreiben.

Verfügbare Spark-Messwerte umfassen Spark-Treiber- und Executor-Messwerte sowie Systemmesswerte. Verfügbare Spark-Messwerte haben das Präfix custom.googleapis.com/.

Messwertbenachrichtigungen einrichten

Sie können Messwertbenachrichtigungen für Managed Service for Apache Spark erstellen, um über Probleme mit Arbeitslasten informiert zu werden.

Diagramme erstellen

Sie können Diagramme erstellen, die Arbeitslastmesswerte visualisieren, indem Sie den Metrics Explorer in derGoogle Cloud Console verwenden. Sie können beispielsweise ein Diagramm erstellen, um disk:bytes_used anzuzeigen, und dann nach batch_id filtern.

Cloud Monitoring

Das Monitoring verwendet Metadaten und Messwerte zu Arbeitslasten, um Einblicke in den Zustand und die Leistung von Managed Service for Apache Spark-Arbeitslasten zu gewähren. Arbeitslastmesswerte umfassen Spark-Messwerte, Batchmesswerte und Vorgangsmesswerte.

Sie können Cloud Monitoring in der Google Cloud Console verwenden, um Messwerte zu untersuchen, Diagramme hinzuzufügen, Dashboards zu erstellen und Benachrichtigungen einzurichten.

Dashboards erstellen

Sie können ein Dashboard erstellen, um Arbeitslasten mithilfe von Messwerten aus mehreren Projekten und verschiedenen Google Cloud Produkten zu überwachen. Weitere Informationen finden Sie unter Benutzerdefinierte Dashboards erstellen und verwalten.

Persistent History Server

Managed Service for Apache Spark erstellt die Rechenressourcen, die zum Ausführen einer Arbeitslast erforderlich sind, führt die Arbeitslast auf diesen Ressourcen aus und löscht die Ressourcen dann, wenn die Arbeitslast abgeschlossen ist. Arbeitslastmesswerte und -ereignisse bleiben nach Abschluss einer Arbeitslast nicht erhalten. Sie können jedoch einen Persistent History Server (PHS) verwenden, um den Verlauf der Arbeitslastanwendungen (Ereignisprotokolle) in Cloud Storage beizubehalten.

So verwenden Sie einen PHS mit einer Batcharbeitslast:

1. Erstellen Sie einen Persistent History Server (PHS) für Managed Service for Apache Spark.

   Hinweis: Auf der Seite Spark-UI in der Google Cloud Console werden Details zur Ausführung von Spark-Arbeitslasten erfasst und angezeigt. So können Sie Ihre Arbeitslasten überwachen und Fehler beheben, ohne einen PHS-Cluster erstellen zu müssen.

2. Geben Sie Ihren PHS an, wenn Sie eine Arbeitslast einreichen.

3. Verwenden Sie das Komponenten-Gateway, um eine Verbindung zum PHS herzustellen und Anwendungsdetails, Planerphasen, Details auf Aufgabenebene sowie Informationen zu Umgebung und Executor aufzurufen.

Automatische Abstimmung

• Autotuning für Managed Service for Apache Spark aktivieren: Sie können Autotuning für Managed Service for Apache Spark aktivieren, wenn Sie jede wiederkehrende Spark-Batcharbeitslast über die Google Cloud Console, die gcloud CLI oder die Managed Service for Apache Spark API senden.

Console

Führen Sie die folgenden Schritte aus, um die automatische Abstimmung für jede wiederkehrende Spark-Batcharbeitslast zu aktivieren:

1. Rufen Sie in der Google Cloud Console die Seite Jobs von Managed Service for Apache Spark auf.

   Zu Managed Service for Apache Spark-Jobs

2. Klicken Sie zum Erstellen einer Batcharbeitslast auf Job senden, um die Seite Job senden zu öffnen.

3. Prüfen Sie, ob unter Computing-Typ für Job auswählen die Option Serverloses Spark ausgewählt ist.

4. Im Abschnitt Details zum serverlosen Job:

   1. Geben Sie eine Job-ID an oder übernehmen Sie die Standard-ID.
   2. Wählen Sie ein Laufzeitprofil aus oder behalten Sie die Standarddienstkonfiguration für Ihre Region bei. Klicken Sie dann auf der Karte Zusammenfassung auf Konfigurieren oder im Menü Laufzeitprofil auf Neues Profil erstellen, um den Konfigurationsbereich für das Laufzeitprofil zu öffnen.
   3. Maximieren Sie im Konfigurationsbereich für das Laufzeitprofil die Option Zusätzliche Konfiguration und klicken Sie dann neben Weitere Anpassungen auf Bearbeiten.
   4. Klicken Sie im Bereich Weitere Anpassungen unter Automatische Abstimmung auf den Schalter Aktivieren und geben Sie die Kohorten-ID ein, die den Batch als Teil einer Reihe wiederkehrender Arbeitslasten identifiziert. Die Gemini-gestützte Analyse wird auf die zweite und nachfolgende Arbeitslasten angewendet, die mit dieser Kohorten-ID gesendet werden. Geben Sie beispielsweise tpch-query1 als Kohorten-ID für eine geplante Arbeitslast an, die täglich eine TPC-H-Abfrage ausführt.
   5. Klicken Sie im Bereich Weitere Anpassungen auf Speichern und dann im Bereich für die Konfiguration des Laufzeitprofils auf Konfiguration verwenden (oder Neues Profil speichern).

5. Füllen Sie auf der Seite Job senden die Abschnitte Dateien und Artefakte und Jobausführung und -eigenschaften nach Bedarf aus und klicken Sie dann auf Senden. Weitere Informationen finden Sie unter Batcharbeitslast senden.

gcloud

Führen Sie den folgenden gcloud CLI-Befehl gcloud dataproc batches submit lokal in einem Terminalfenster oder in Cloud Shell aus, um die automatische Optimierung für jede wiederkehrende Spark-Batcharbeitslast zu aktivieren:

gcloud dataproc batches submit COMMAND \
    --region=REGION \
    --cohort=COHORT \
    other arguments ...

Ersetzen Sie Folgendes:

• COMMAND: der Spark-Arbeitslasttyp, z. B. Spark, PySpark, Spark-Sql oder Spark-R.
• REGION: die Region, in der Ihre Arbeitslast ausgeführt wird.
• COHORT: der Name der Kohorte, die den Batch als eine von mehreren wiederkehrenden Arbeitslasten identifiziert. Die Gemini-gestützte Analyse wird auf die zweite und nachfolgende Arbeitslasten angewendet, die mit diesem Kohortennamen gesendet werden. Geben Sie beispielsweise TPCH Query 1 als Kohortenname für eine geplante Arbeitslast an, die eine tägliche TPC-H-Abfrage ausführt.

API

Geben Sie den Namen RuntimeConfig.cohort in einer batches.create-Anfrage an, um die automatische Abstimmung für jede wiederkehrende Spark-Batcharbeitslast zu aktivieren. Die automatische Abstimmung wird auf die zweite und nachfolgende Arbeitslasten angewendet, die mit diesem Kohortennamen gesendet werden. Geben Sie beispielsweise TPCH-Query1 als Kohortenname für eine geplante Arbeitslast an, die eine tägliche TPC-H-Abfrage ausführt.

Beispiel:

...
runtimeConfig:
  cohort: TPCH-Query1
...