Dataproc Persistent History Server

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Übersicht

Der Dataproc Persistent History Server (PHS) bietet Weboberflächen, um den Jobverlauf für Jobs anzusehen, die in aktiven oder gelöschten Dataproc-Clustern ausgeführt werden. Sie ist ab Dataproc-Image-Version 1.5 verfügbar und kann in einem Dataproc-Cluster mit einem einzelnen Knoten ausgeführt werden. Es bietet Weboberflächen für die folgenden Dateien und Daten:

  • Historie- und Spark-Jobverlaufsdateien

  • Datendateien zur Anwendungszeitachse, die vom YARN-Zeitachsendienst v2 erstellt und in einer Bigtable-Instanz gespeichert werden.

  • Bayerische Aggregationslogs

Der Persistent History Server greift auf Spark- und Memorystore-Jobverlaufsdateien sowie auf die in Cloud Storage geschriebenen Maven-Logdateien während der Lebensdauer von Dataproc-Jobclustern zu und zeigt sie an.

PHS-Cluster erstellen

Sie können den folgenden gcloud dataproc clusters create-Befehl in einem lokalen Terminal oder in Cloud Shell mit den folgenden Flags und Clusterattributen ausführen, um einen Dataproc Persistent History Server-Cluster mit einem einzelnen Knoten zu erstellen.

Hinweise:

  • Kerberos und persönliche Authentifizierung werden im Persistent History Server nicht unterstützt.

  • Die Hauptversion des PHS-Cluster-Images und die Jobversion des Jobcluster-Images sollten übereinstimmen. Wenn sie nicht übereinstimmen, z.B.wenn ein PHS-Cluster mit 2,0 Images mit einem 1,5-Image-Jobcluster verwendet wird, können nicht unterstützte Probleme auftreten.

gcloud dataproc clusters create cluster-name \
    --region=region \
    --single-node \
    --enable-component-gateway \
    --properties=properties

Hinweise:

  • --enable-component-gateway: Erforderlich, um Weboberflächen von Component Gateway im PHS-Cluster zu aktivieren.

  • Fügen Sie eines oder mehrere der folgenden Clusterattribute hinzu, um das Speichern und Aufrufen des Jobverlaufs und anderer Logs mit dem Persistent History Server zu ermöglichen.

    Beispiel:

    --properties=spark:spark.history.fs.logDirectory=gs://bucket-name/*/spark-job-history 
    
--properties=mapred:mapreduce.jobhistory.read-only.dir-pattern=gs://bucket-name/*/mapreduce-job-history/done

    • yarn:yarn.nodemanager.remote-app-log-dir=gs://bucket-name/*/yarn-logs: Füge dieses Attribut hinzu, um den Cloud Storage-Speicherort anzugeben, an dem der PHS auf von Logs von Jobclustern geschriebene Firestore-Logs zugreift (siehe Jobcluster erstellen). Der angezeigte Wert verwendet das Platzhalterzeichen „*“, damit PHS mehrere Verzeichnisse im angegebenen Bucket abgleichen kann, auf die von verschiedenen Jobclustern geschrieben wird. Weitere Informationen finden Sie unter Hinweise zur Effizienz der Platzhalter.
    • spark:spark.history.fs.logDirectory=gs://bucket-name/*/spark-job-history: Fügen Sie dieses Attribut hinzu, um den persistenten Spark-Jobverlauf zu aktivieren. Dieses Attribut gibt den Speicherort an, an dem der PHS auf Logs zum Spark-Jobverlauf zugreift, die von Jobclustern geschrieben wurden (siehe Jobcluster erstellen). Der angezeigte Wert verwendet das Platzhalterzeichen „*“, damit PHS mehrere Verzeichnisse im angegebenen Bucket abgleichen kann, auf die von verschiedenen Jobclustern geschrieben wird. Weitere Informationen finden Sie unter Hinweise zur Effizienz der Platzhalter.

      Hinweis: In Dataproc 2.0+-Clustern müssen die folgenden Attribute ebenfalls festgelegt werden, um PHS-Spark-Verlaufslogs zu aktivieren (siehe Konfigurationsoptionen für den Spark-Verlaufsserver). Der Wert spark.history.custom.executor.log.url ist ein Literalwert, der {{PLACEHOLDERS}} für Variablen enthält, die vom Persistent History Server festgelegt werden. Diese Variablen werden nicht von Nutzern festgelegt. Übergeben Sie den Attributwert wie gezeigt.

      --properties=spark:spark.history.custom.executor.log.url.applyIncompleteApplication=false
--properties=spark:spark.history.custom.executor.log.url={{YARN_LOG_SERVER_URL}}/{{NM_HOST}}:{{NM_PORT}}/{{CONTAINER_ID}}/{{CONTAINER_ID}}/{{USER}}/{{FILE_NAME}}

    • mapred:mapreduce.jobhistory.read-only.dir-pattern=gs://bucket-name/*/mapreduce-job-history/done: Fügen Sie diese Property hinzu, um den persistenten Map-Jobverlauf zu aktivieren. Dieses Attribut gibt den Cloud Storage-Speicherort an, an dem der PHS auf von Job-Clustern geschriebene Historienlogs von Firestore zugreift (siehe Jobcluster erstellen). Der angezeigte Wert verwendet das Platzhalterzeichen „*“, damit PHS mehrere Verzeichnisse im angegebenen Bucket abgleichen kann, auf die von verschiedenen Jobclustern geschrieben wird. Weitere Informationen finden Sie unter Hinweise zur Effizienz der Platzhalter.

    • dataproc:yarn.atsv2.bigtable.instance=projects/project-id/instance_id/bigtable-instance-id: Fügen Sie nach dem Konfigurieren des Yarn-Zeitachse-Diensts v2 dieses Attribut hinzu, um mit dem PHS-Cluster Zeitachsendaten auf den Weboberflächen des YARN-Anwendungszeitachsens Version 2 und des Tez zu sehen (siehe Weboberflächen von Weboberflächen).

Dataproc-Jobcluster erstellen

Sie können den folgenden Befehl in einem lokalen Terminal oder in Cloud Shell ausführen, um einen Dataproc-Jobcluster zu erstellen, der Jobverlaufsdateien auf einen Persistent History Server (PHS) schreibt.

gcloud dataproc clusters create cluster-name \
    --region=region \
    --enable-component-gateway \
    --properties=properties
    other args ...

Hinweise:

  • --enable-component-gateway: Dieses Flag ist erforderlich, um die Weboberflächen von Component Gateway im Jobcluster zu aktivieren.
  • Fügen Sie eines oder mehrere der folgenden Clusterattribute hinzu, um PHS-bezogene nicht standardmäßige Cloud Storage-Standorte und andere Jobclusterattribute festzulegen.

    Beispiel:

    --properties=spark:spark.history.fs.logDirectory=gs://bucket-name/job-cluster-1/spark-job-history 
    
--properties=yarn:yarn.nodemanager.remote-app-log-dir=gs://bucket-name/job-cluster-1/yarn-logs
    • yarn:yarn.nodemanager.remote-app-log-dir: Standardmäßig sind zusammengefasste KMS-Logs für Dataproc-Jobcluster aktiviert und in den temp-Bucket des Clusters geschrieben. Fügen Sie dieses Attribut hinzu, um einen anderen Cloud Storage-Speicherort anzugeben, an dem der Cluster Aggregationslogs für den Zugriff durch den Persistent History Server schreibt. 
      yarn:yarn.nodemanager.remote-app-log-dir=gs://bucket-name/directory-name/yarn-logs
    • spark:spark.history.fs.logDirectory und spark:spark.eventLog.dir: Spark-Jobverlaufsdateien werden standardmäßig im Cluster temp bucket im Verzeichnis /spark-job-history gespeichert. Sie können diese Attribute hinzufügen, um verschiedene Cloud Storage-Speicherorte für diese Dateien anzugeben. Wenn beide Properties verwendet werden, müssen sie auf Verzeichnisse im selben Bucket verweisen. 
      spark:spark.history.fs.logDirectory=gs://bucket-name/directory-name/spark-job-history,
spark:spark.eventLog.dir=gs://bucket-name/directory-name/spark-job-history
    • mapred:mapreduce.jobhistory.done-dir und mapred:mapreduce.jobhistory.intermediate-done-dir: Standardmäßig werden die Historiedateien des Horween-Jobs im Cluster temp bucket in den Verzeichnissen /mapreduce-job-history/done und /mapreduce-job-history/intermediate-done gespeichert. Der Zwischenspeicherort mapreduce.jobhistory.intermediate-done-dir ist ein temporärer Speicher. Zwischendateien werden an den Speicherort mapreduce.jobhistory.done-dir verschoben, wenn der Firestore-Job abgeschlossen ist. Sie können diese Attribute hinzufügen, um verschiedene Cloud Storage-Speicherorte für diese Dateien anzugeben. Wenn beide Properties verwendet werden, müssen sie auf Verzeichnisse im selben Bucket verweisen. 
      mapred:mapreduce.jobhistory.done-dir=gs://bucket-name/directory-name/mapreduce-job-history/done,
mapred:mapreduce.jobhistory.intermediate-done-dir=gs://bucket-name/directory-name/mapreduce-job-history/intermediate-done
    • spark:spark.history.fs.gs.outputstream.type und spark:spark.history.fs.gs.outputstream.sync.min.interval.ms: Fügen Sie diese Cloud Storage-Connector-Attribute hinzu, um das Standardverhalten des Jobclusters zu ändern, mit dem Daten an Cloud Storage gesendet werden. Der Standardwert für spark:spark.history.fs.gs.outputstream.type ist BASIC. Damit werden Daten nach Abschluss des Jobs an Cloud Storage gesendet. Sie können diese Einstellung in FLUSHABLE_COMPOSITE ändern, um das Löschen zu ändern und Daten in regelmäßigen Abständen in Cloud Storage zu kopieren, während der Job ausgeführt wird. 
      spark:spark.history.fs.gs.outputstream.type=FLUSHABLE_COMPOSITE
      Die Standardeinstellung spark:spark.history.fs.gs.outputstream.sync.min.interval.ms, die die Häufigkeit bestimmt, mit der Daten an Cloud Storage übertragen werden, ist 5000ms. Sie kann in ein anderes ms-Zeitintervall geändert werden: 
      spark:spark.history.fs.gs.outputstream.sync.min.interval.ms=intervalms
      Hinweis: Zum Festlegen dieser Attribute muss die Image-Version des Dataproc-Jobclusters die Cloud Storage-Connector-Version 2.2.0 oder höher verwenden. Auf der Seite Dataproc-Image-Versionsliste können Sie prüfen, welche Connector-Version auf den Image-Versionen installiert ist.
    • dataproc:yarn.atsv2.bigtable.instance: Fügen Sie nach der Konfiguration des Yarn-Zeitachse-Diensts v2 dieses Attribut hinzu, um Daten der Chromium-Zeitachse in die angegebene Bigtable-Instanz zu schreiben, damit sie im PHS-Cluster YARN Application Zeitachse-Dienst V2 und Tez-Weboberflächen angezeigt werden. Hinweis: Die Clustererstellung schlägt fehl, wenn die Bigtable-Instanz nicht vorhanden ist. 
      dataproc:yarn.atsv2.bigtable.instance=projects/project-id/instance_id/bigtable-instance-id

PHS mit Spark-Batcharbeitslasten verwenden

So verwenden Sie den Persistent History Server mit Dataproc für Batch-Arbeitslasten von Spark:

  1. Erstellen Sie einen PHS-Cluster.

  2. Wählen Sie den PHS-Cluster aus oder geben Sie ihn an, wenn Sie eine Spark-Batch-Arbeitslast einreichen.

PHS mit Dataproc in Google Kubernetes Engine verwenden

So verwenden Sie den Persistent History Server mit Dataproc in GKE:

  1. Erstellen Sie einen PHS-Cluster.

  2. Wählen Sie den PHS-Cluster aus oder geben Sie ihn an, wenn Sie einen virtuellen Dataproc on GKE-Cluster erstellen.

Component Gateway-Weboberflächen

Klicken Sie in der Google Cloud Console auf der Dataproc-Seite Cluster auf den PHS-Clusternamen, um die Seite Clusterdetails zu öffnen. Wählen Sie auf dem Tab Weboberflächen die Links „Komponentengateway“ aus, um Weboberflächen zu öffnen, die im PHS-Cluster ausgeführt werden.

Weboberfläche des Spark-Verlaufsservers

Der folgende Screenshot zeigt die Weboberfläche des Spark-Verlaufsservers. Sie zeigt Links zu Spark-Jobs an, die auf „job-cluster-1“ und „job-cluster-2“ ausgeführt werden, nachdem die Standorte der spark.history.fs.logDirectory und spark:spark.eventLog.dir und des PHS-Clusters so eingerichtet wurden:

job-cluster-1 gs://example-cloud-storage-bucket/job-cluster-1/spark-job-history
job-cluster-2 gs://example-cloud-storage-bucket/job-cluster-2/spark-job-history
phs-cluster gs://example-cloud-storage-bucket/*/spark-job-history

Sie können Jobs auf der Weboberfläche des Spark History Server nach App-Name auflisten. Geben Sie dazu einen App-Namen in das Suchfeld ein. Der App-Name kann auf eine der folgenden Arten festgelegt werden (nach Priorität aufgelistet):

  1. Wird im Anwendungscode beim Erstellen des Spark-Kontexts festgelegt
  2. Wird vom Attribut spark.app.name festgelegt, wenn der Job gesendet wird
  3. Setzen Sie von Dataproc den vollständigen REST-Ressourcennamen für den Job (projects/project-id/regions/region/jobs/job-id).

Nutzer können einen App- oder Ressourcennamen in das Feld Suchen eingeben, um Jobs zu finden und aufzulisten.

Ereignisprotokolle

Die Weboberfläche des Spark-Verlaufsservers enthält die Schaltfläche Ereignisprotokoll, auf die Sie klicken können, um Spark-Ereignislogs herunterzuladen. Diese Logs sind nützlich, um den Lebenszyklus der Spark-Anwendung zu untersuchen.

Spark-Jobs

Spark-Anwendungen sind in mehrere Jobs unterteilt, die weiter in mehrere Phasen unterteilt werden. Jede Phase kann mehrere Aufgaben enthalten, die auf Executor-Knoten (Workern) ausgeführt werden.

  • Klicken Sie in der Weboberfläche auf eine Spark-App-ID, um die Seite „Spark-Jobs“ mit einer Ereigniszeitachse und einer Zusammenfassung der Jobs in der Anwendung zu öffnen.

  • Klicken Sie auf einen Job, um die Seite "Jobdetails" mit einem gerichteten azyklischen Graphen (Directed Acyclic Graph, DAG) und einer Zusammenfassung der Jobphasen zu öffnen.

  • Klicken Sie auf eine Phase oder verwenden Sie den Tab "Phasen", um eine Phase auszuwählen, um die Seite "Phasendetails" zu öffnen.

    Stage Details umfassen eine DAG-Visualisierung, eine Ereigniszeitachse und Messwerte für die Aufgaben innerhalb der Phase. Auf dieser Seite können Sie Probleme mit strangulierten Aufgaben, Planerverzögerungen und Speichermangel beheben. Der DAG-Visualisierer zeigt die Codezeile, aus der die Phase abgeleitet ist, sodass Sie Probleme wieder im Code verfolgen können.

  • Klicken Sie auf den Tab Executors für Informationen über die Treiber- und Executor-Knoten der Spark-Anwendung.

    Wichtige Informationen auf dieser Seite umfassen die Anzahl der Kerne und die Anzahl der Aufgaben, die auf jedem Executor ausgeführt wurden.

Tez-Weboberfläche

Tez ist die standardmäßige Ausführungs-Engine für Hive und Pig in Dataproc. Wenn Sie einen Hive-Job an einen Dataproc-Jobcluster senden, wird eine Tez-Anwendung gestartet (siehe Apache Hive in Dataproc verwenden).

Wenn Sie den Yara-Zeitachsendienst v2 konfiguriert und beim Erstellen der PHS- und Dataproc-Jobcluster das Attribut dataproc:yarn.atsv2.bigtable.instance festgelegt haben, schreibt Bazel generierte Hive- und Pig-Jobzeitachsen in die angegebene Bigtable-Instanz, um diese auf der Tez-Weboberfläche, die auf dem PHS-Server ausgeführt wird, abzurufen und anzuzeigen.

Web-Oberfläche der Zeitachse für die Anwendung Anwendung X2

Wenn Sie den Yara-Zeitachsendienst v2 konfiguriert und beim Erstellen der PHS- und Dataproc-Jobcluster das Attribut dataproc:yarn.atsv2.bigtable.instance festgelegt haben, schreibt Bazel generierte Jobzeitachsen in die angegebene Bigtable-Instanz, um diese abzurufen und auf der Weboberfläche des Dienstes für die Anwendung zum Verwalten von Anwendungen auf dem PHS-Server anzuzeigen. Dataproc-Jobs werden auf der Weboberfläche auf dem Tab Ablaufaktivität aufgelistet.

Yarn Zeitachse-Dienst v2 konfigurieren

Richten Sie zum Konfigurieren von Yarn Zeitachse Service v2 eine Bigtable-Instanz ein und prüfen Sie bei Bedarf die Dienstkontorollen so:

  1. Bigtable-Instanz erstellen

  2. Prüfen Sie bei Bedarf die Dienstkontorollen. Das standardmäßige VM-Dienstkonto, das von Dataproc-Cluster-VMs verwendet wird, hat die erforderlichen Berechtigungen zum Erstellen und Konfigurieren der Bigtable-Instanz für den Firestore-Zeitachsendienst. Wenn Sie Ihren Job oder PHS-Cluster mit einem nutzerverwalteten VM-Dienstkonto erstellen, muss das Konto entweder die Rolle Administrator oder Bigtable User haben.

Erforderliches Tabellenschema

Für die Dataproc PHS-Unterstützung für den YARN-Zeitachsendienst v2 ist ein bestimmtes Schema erforderlich, das in der Bigtable-Instanz erstellt wird. Dataproc erstellt das erforderliche Schema, wenn ein Jobcluster oder ein PHS-Cluster mit dem Attribut dataproc:yarn.atsv2.bigtable.instance erstellt wird, das auf die Bigtable-Instanz verweist.

Im Folgenden finden Sie das erforderliche Bigtable-Instanzschema:

Tabellen Spaltenfamilien
prod.timelineservice.anwendung c,i,m
prod.Zeitdienst.app_flow m
prod.timelineservice.entity c,i,m
prod.timelineservice.flowactivity i
prod.timelineservice.flowrun i
prod.timelineservice.subapplication c,i,m

Bigtable automatische Speicherbereinigung

Sie können die altersabhängige Speicherbereinigung für Bigtable für ATSv2-Tabellen konfigurieren:

  • Installieren Sie cbt, einschließlich der Erstellung von .cbrtc file.

  • Erstellen Sie die ATSv2-Richtlinie für die automatische Speicherbereinigung:

export NUMBER_OF_DAYS = number \
cbt setgcpolicy prod.timelineservice.application c maxage=${NUMBER_OF_DAYS} \
cbt setgcpolicy prod.timelineservice.application i maxage=${NUMBER_OF_DAYS} \
cbt setgcpolicy prod.timelineservice.application m maxage=${NUMBER_OF_DAYS} \
cbt setgcpolicy prod.timelineservice.app_flow m maxage=${NUMBER_OF_DAYS} \
cbt setgcpolicy prod.timelineservice.entity c maxage=${NUMBER_OF_DAYS} \
cbt setgcpolicy prod.timelineservice.entity i maxage=${NUMBER_OF_DAYS} \
cbt setgcpolicy prod.timelineservice.entity m maxage=${NUMBER_OF_DAYS} \
cbt setgcpolicy prod.timelineservice.flowactivity i maxage=${NUMBER_OF_DAYS} \
cbt setgcpolicy prod.timelineservice.flowrun i maxage=${NUMBER_OF_DAYS} \
cbt setgcpolicy prod.timelineservice.subapplication c maxage=${NUMBER_OF_DAYS} \
cbt setgcpolicy prod.timelineservice.subapplication i maxage=${NUMBER_OF_DAYS} \
cbt setgcpolicy prod.timelineservice.subapplication m maxage=${NUMBER_OF_DAYS}

Hinweise:

NUMBER_OF_DAYS: Die maximale Anzahl an Tagen beträgt 30d.