Initialisierungsaktionen

Beim Erstellen eines Dataproc-Clusters können Sie Initialisierungsaktionen in ausführbaren Dateien oder Skripts angeben, die von Dataproc auf allen Knoten im Dataproc-Cluster ausgeführt werden, unmittelbar nachdem der Cluster eingerichtet wurde. Initialisierungsaktionen richten häufig Jobabhängigkeiten ein, beispielsweise die Installation von Python-Paketen, sodass Jobs an den Cluster gesendet werden können, ohne Abhängigkeiten bei der Ausführung der Jobs zu installieren.

Hier finden Sie Beispielskripts für Initialisierungsaktionen:

Wichtige Hinweise und Richtlinien

  • Erstellen Sie keine Produktionscluster, die auf Initialisierungsaktionen in den öffentlichen gs://goog-dataproc-initialization-actions-REGION-Buckets verweisen. Diese Skripts werden als Referenzimplementierungen bereitgestellt und mit laufenden Änderungen am GitHub-Repository synchronisiert. Eine neue Version einer Initialisierungsaktion in öffentlichen Buckets kann die Erstellung des Clusters beeinträchtigen. Kopieren Sie stattdessen die Initialisierungsaktion aus öffentlichen Buckets in Ihren Bucket, wie im folgenden Beispiel gezeigt:

    REGION=region
    
    gsutil cp gs://goog-dataproc-initialization-actions-${REGION}/tez/tez.sh gs://my-bucket
    
    Erstellen Sie dann den Cluster, indem Sie auf die Kopie verweisen:
    gcloud dataproc clusters create cluster-name \
        --region=${REGION} \
        --initialization-actions=gs://my-bucket/tez.sh \
        ... other flags ...
    
    Sie können entscheiden, wann Ihre Kopie der Initialisierungsaktion mit Änderungen an der Initialisierungsaktion im öffentlichen Bucket oder im GitHub-Repository synchronisiert werden soll.

  • Initialisierungsaktionen werden auf jedem Knoten während der Clustererstellung ausgeführt. Sie werden auch auf jedem neu hinzugefügten Knoten ausgeführt, wenn Cluster skaliert oder automatisch skaliert werden.

  • Initialisierungsaktionen werden als root-Nutzer ausgeführt. Es ist also nicht erforderlich, sudo zu verwenden.

  • Es wird empfohlen, absolute Pfade in Initialisierungsaktionen zu verwenden.

  • Bei den Initialisierungsaktionen sollte mithilfe einer shebang-Zeile angegeben werden, wie das Skript interpretiert werden muss (z. B. #!/bin/bash oder #!/usr/bin/python).

  • Wenn eine Initialisierungsaktion mit einem Exit-Code ungleich null beendet wird, meldet der Vorgang der Clustererstellung den Status "ERROR" (Fehler). Zur Fehlerbehebung der Initialisierungsaktion stellen Sie eine SSH-Verbindung zu den VM-Instanzen des Clusters her und überprüfen die Logs. Nachdem Sie das Problem mit der Initialisierungsaktion behoben haben, können Sie den Cluster löschen und anschließend neu erstellen.

  • Wenn Sie einen Dataproc-Cluster mit nur mit internen IP-Adressen erstellen, schlagen Versuche, bei einer Initialisierungsaktion auf das Internet zuzugreifen, fehl. Dies ist nicht der Fall, wenn Sie Routen zur Weiterleitung des Traffics über Cloud NAT oder ein Cloud VPN konfiguriert haben. Ohne Zugriff auf das Internet können Sie den privaten Google-Zugriff aktivieren und Jobabhängigkeiten in Cloud Storage platzieren. Clusterknoten können die Abhängigkeiten von Cloud Storage über interne IP-Adressen herunterladen.

  • Sie können benutzerdefinierte Dataproc-Images anstelle von Initialisierungsaktionen verwenden, um Jobabhängigkeiten einzurichten.

  • Initialisierungsverarbeitung:

    • Image-Cluster vor Version 2.0:
      • Master: Die Initialisierung des Masterknotens wird erst gestartet, wenn HDFS beschreibbar ist (bis HDFS den abgesicherten Modus beendet und mindestens zwei HDFS DataNodes hinzugefügt wurden). Dadurch können auf Mastern ausgeführte Initialisierungsaktionen Dateien in HDFS schreiben.
      • Mitarbeiter: Wenn der Nutzer die dataproc:dataproc.worker.custom.init.actions.mode Clusterattribut bisRUN_BEFORE_SERVICES enthält, führt jeder Worker die Initialisierungsaktionen aus, bevor er seine HDFS-DataNode- und YARN-NodeManager-Daemons startet. Da Dataproc erst Masterinitialisierungsaktionen ausführt, wenn HDFS beschreibbar ist, wodurch zwei HDFS-Datenknoten-Daemons ausgeführt werden müssen, kann das Festlegen dieses Attributs die Zeit für die Clustererstellung erhöhen.
    • Image-Cluster ab Version 2.0:

      • Master: Master-Initialisierungsaktionen können ausgeführt werden, bevor HDFS beschreibbar ist. Wenn Sie Initialisierungsaktionen ausführen, die Dateien in HDFS bereitstellen oder von der Verfügbarkeit von HDFS-abhängigen Diensten wie Ranger abhängen, können Sie Folgendes festlegen: dataproc.master.custom.init.actions.mode Clusterattribut in RUN_AFTER_SERVICES. Hinweis: Da diese Attributeinstellung die Zeit zur Erstellung des Clusters erhöhen kann (siehe Erläuterung der Verzögerung bei der Clustererstellung für Image-Worker vor Version 2.0), verwenden Sie es nur, wenn erforderlich (im Allgemeinen sollten Sie auf die Standardeinstellung RUN_BEFORE_SERVICES für dieses Attribut zurückgreifen.)
      • Worker: Das Clusterattribut dataproc:dataproc.worker.custom.init.actions.mode ist auf RUN_BEFORE_SERVICES gesetzt und kann nicht an den Cluster übergeben werden. Der Cluster wird erstellt (kann nicht vom Nutzer geändert werden). Jeder Worker führt die Initialisierungsaktionen aus, bevor der HDFS-DataNode- und der YARN-NodeManager-Daemon gestartet werden. Da Dataproc vor der Ausführung von Masterinitialisierungsaktionen nicht auf das Schreiben von HDFS wartet, werden die Master- und Worker-Initialisierungsaktionen parallel ausgeführt.
    • Empfehlungen

      • Verwenden Sie Metadaten, um die Rolle eines Knotens zur bedingten Ausführung einer Initialisierungsaktion für Knoten zu ermitteln (siehe Clustermetadaten verwenden).
      • Erstellen Sie aus Gründen der Stabilität eine Kopie einer Initialisierungsaktion in einem Cloud Storage-Bucket. Weitere Informationen zur Verwendung von Initialisierungsaktionen
      • Fügen Sie beim Herunterladen aus dem Internet Wiederholungsversuche hinzu, um die Initialisierungsaktion zu stabilisieren.

Initialisierungsaktionen verwenden

Cluster-Initialisierungsaktionen können unabhängig davon angegeben werden, mit welcher Methode der Cluster erstellt wird:

Befehl "gcloud"

Geben Sie beim Erstellen eines Clusters mit dem Befehl gcloud dataproc clusters create einen oder mehrere kommagetrennte Cloud Storage-Speicherorte (URIs) der ausführbaren Initialisierungsdateien oder Skripts mit dem Flag --initialization-actions an. Hinweis: Mehrere aufeinanderfolgende "/"s in einem Cloud Storage-Standort-URI nach dem ersten "gs://", z. B. "gs://bucket/my//object//name", werden nicht unterstützt.

Die Syntax für die Verwendung dieses Flags wird unten angezeigt. Sie können sie über die Befehlszeile aufrufen, indem Sie gcloud dataproc clusters create --help ausführen.

gcloud dataproc clusters create cluster-name \
    --region=${REGION} \
    --initialization-actions=Cloud Storage URI(s) (gs://bucket/...) \
    --initialization-action-timeout=timeout-value (default=10m) \
    ... other flags ...
Hinweise:
  • Verwenden Sie das Flag --initialization-action-timeout, um ein Zeitlimit für die Initialisierungsaktion anzugeben. Das standardmäßige Zeitlimit beträgt 10 Minuten. Wenn die ausführbare Datei oder das Skript der Initialisierung bei Ablauf der Zeitüberschreitung noch nicht abgeschlossen ist, wird die Initialisierungsaktion abgebrochen.
  • Führen Sie mit dem Clusterattribut dataproc:dataproc.worker.custom.init.actions.mode die Initialisierungsaktion auf primären Workern aus, bevor Sie den Knotenmanager und die Datenknoten-Daemons starten.

REST API

Geben Sie ein oder mehrere Skripts oder ausführbare Dateien in einem ClusterConfig.initialActions-Array als Teil einer clusters.create-API-Anfrage an.

Beispiel

POST /v1/projects/my-project-id/regions/us-central1/clusters/
{
  "projectId": "my-project-id",
  "clusterName": "example-cluster",
  "config": {
    "configBucket": "",
    "gceClusterConfig": {
      "subnetworkUri": "default",
      "zoneUri": "us-central1-b"
    },
    "masterConfig": {
      "numInstances": 1,
      "machineTypeUri": "n1-standard-4",
      "diskConfig": {
        "bootDiskSizeGb": 500,
        "numLocalSsds": 0
      }
    },
    "workerConfig": {
      "numInstances": 2,
      "machineTypeUri": "n1-standard-4",
      "diskConfig": {
        "bootDiskSizeGb": 500,
        "numLocalSsds": 0
      }
    },
    "initializationActions": [
      {
        "executableFile": "gs://cloud-example-bucket/my-init-action.sh"
      }
    ]
  }
}

Console

  • Öffnen Sie die Dataproc-Seite Cluster erstellen und wählen Sie dann das Fenster „Cluster anpassen“ aus.
  • Geben Sie im Abschnitt „Initialisierungsaktionen“ die Speicherorte der Cloud Storage-Buckets jeder Initialisierungsaktion in das jeweilige Feld der ausführbaren Datei ein. Klicken Sie auf BROWSER, um die Browser-Seite von Cloud Storage in der Cloud Console zu öffnen, um ein Skript oder eine ausführbare Datei auszuwählen. Klicken Sie auf „INITIALIZATION ACTION“, um jede neue Datei hinzuzufügen.
  • Argumente an Initialisierungsaktionen übergeben

    Dataproc legt spezielle Metadatenwerte für die Instanzen fest, die in Ihrem Cluster ausgeführt werden. Sie können Ihre eigenen benutzerdefinierten Metadaten festlegen, um Argumente an Initialisierungsaktionen zu übergeben.

    gcloud dataproc clusters create cluster-name \
        --region=${REGION} \
        --initialization-actions=Cloud Storage URI(s) (gs://bucket/...) \
        --metadata=name1=value1,name2=value2... \
        ... other flags ...
    

    Metadatenwerte können auf folgende Weise in Initialisierungsaktionen gelesen werden:

    var1=$(/usr/share/google/get_metadata_value attributes/name1)
    

    Knotenauswahl

    Wenn Sie die Initialisierungsaktionen auf Master- oder Worker-Knoten beschränken möchten, können Sie der ausführbaren Datei oder dem Skript eine einfache Knotenauswahllogik hinzufügen.

    ROLE=$(/usr/share/google/get_metadata_value attributes/dataproc-role)
    if [[ "${ROLE}" == 'Master' ]]; then
      ... master specific actions ...
    else
      ... worker specific actions ...
    fi
    

    Staging von Binärdateien

    Ein gängiges Szenario der Cluster-Initialisierung ist das Staging von binären Jobdateien auf einem Cluster. Hierdurch wird vermieden, dass die Binärdateien bei jeder Jobausführung einem Staging-Prozess unterzogen werden. Nehmen Sie beispielsweise an, dass das folgende Initialisierungsskript unter gs://my-bucket/download-job-jar.sh (ein Speicherort für Cloud Storage-Buckets) gespeichert wird:

    #!/bin/bash
    ROLE=$(/usr/share/google/get_metadata_value attributes/dataproc-role)
    if [[ "${ROLE}" == 'Master' ]]; then
      gsutil cp gs://my-bucket/jobs/sessionalize-logs-1.0.jar home/username
    fi
    

    Der Speicherort dieses Skripts kann an den Befehl gcloud dataproc clusters create übergeben werden:

    gcloud dataproc clusters create my-dataproc-cluster \
        --region=${REGION} \
        --initialization-actions=gs://my-bucket/download-job-jar.sh
    

    Dataproc führt dieses Skript auf allen Knoten aus. Die JAR-Datei wird entsprechend der Knotenauswahllogik des Skripts auf den Master-Knoten heruntergeladen. Gesendete Jobs können dann die JAR-Datei in der Vor-Staging-Phase verwenden:

    gcloud dataproc jobs submit hadoop \
        --cluster=my-dataproc-cluster \
        --region=${REGION} \
        --jar=file:///home/username/sessionalize-logs-1.0.jar
    

    Beispiele für Initialisierungsaktionen

    Häufig verwendete und sonstige Beispielinitialisierungsaktionen werden in einem regionalen öffentlichen Cloud Storage-Bucket (gs://goog-dataproc-initialization-actions-<REGION>) und in einem GitHub-Repository bereitgestellt. Wenn Sie ein Skript beitragen möchten, lesen Sie das Dokument CONTRIBUTING.md und senden Sie eine Pull-Anfrage.

    Logging

    Die Ausgabe der einzelnen Initialisierungsaktionen wird für jede Instanz im Log /var/log/dataproc-initialization-script-X.log erfasst, wobei X der nullbasierte Index jedes nachfolgenden Skripts mit Initialisierungsaktionen ist. Wenn Ihr Cluster beispielsweise zwei Initialisierungsaktionen hat, werden die Ausgaben in /var/log/dataproc-initialization-script-0.log und /var/log/dataproc-initialization-script-1.log protokolliert.

    Nächste Schritte

    GitHub-Initialisierungsaktionen