Der Workflow für den Spark-Upgrade-Agenten im Detail - Amazon EMR

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Der Workflow für den Spark-Upgrade-Agenten im Detail

Um den Upgrade-Prozess einzuleiten, müssen Sie den Spark-Anwendungscode in Ihre Entwicklerumgebung (lokal EC2 oder Amazon SageMaker Unified Studio IDE Spaces) klonen, vorzugsweise mit initialisierter Git-Versionskontrolle. Darüber hinaus muss ein EMR-Cluster, auf dem die Spark-Zielversion ausgeführt wird, bereitgestellt und zugänglich sein. Schließlich sollte ein ausgewiesener Amazon S3 S3-Bucket-Pfad konfiguriert werden, um während des gesamten Upgrade-Vorgangs Bereitstellungsartefakte und eine Upgrade-Zusammenfassung zu speichern.

Sobald diese Anforderungen festgelegt sind, können Sie eine Aufforderung wie die folgende einreichen, um den Upgrade-Workflow zu starten:

Upgrade my Spark application <local-project-path> from EMR version 6.0.0 to 7.12.0.   
Use EMR-EC2 Cluster <cluster-id> to run the validation and s3 paths   
s3://<please fill in your staging bucket path> to store updated application artifacts.

Zu diesem Zeitpunkt orchestriert der Agent das Upgrade mithilfe spezieller Tools (weitere Informationen finden Sie hier). Der Workflow folgt diesen Schritten:

  1. Plan generieren: Der Agent analysiert Ihre Projektstruktur und erstellt einen Upgrade-Plan. Überprüfen Sie den Plan und stimmen Sie dem Fortfahren zu.

  2. Überprüfung und Anpassung des Plans: Wenn Sie aufgefordert werden, den Plan zu überprüfen, haben Sie mehrere Möglichkeiten:

    1. Unverändert weitermachen: Akzeptieren Sie den Plan und fahren Sie mit der Ausführung fort

    2. Feedback geben: Passen Sie den Plan an, indem Sie:

      1. Unnötige Schritte entfernen — Beispiel: Entfernen Sie jegliche Ausführung von Integrationstests. Nur compile/build lokal, dann fahren Sie mit der EMR-Validierung fort.

      2. Zusätzliche Schritte hinzufügen — Beispiel: Fügen Sie einen Schritt hinzu, um die Testdatei tests/test_jobs/test_etl_job_x.py vor der EMR-Validierung auszuführen.

      3. Änderung des Upgrade-Ansatzes — Beispiel: Erzwingen Sie Python 3.10 und Java 17 während der Build- und Validierungsschritte.

  3. Der Mitarbeiter wird den Plan auf der Grundlage Ihres Feedbacks erneut erstellen und erneut um Zustimmung bitten. Dieser Vorgang wird fortgesetzt, bis Sie den endgültigen Plan genehmigen

  4. Kompilieren und erstellen: Der Agent nimmt iterative Änderungen vor, um Buildfehler zu beheben, bis die Anwendung erfolgreich kompiliert und erstellt wurde.

  5. Einheiten- und Integrationstests ausführen: Wenn das Projekt Tests umfasst, führt der Agent die Tests nach einem erfolgreichen Build durch. Wenn Tests fehlschlagen, ändert der Agent den Quellcode iterativ, bis die Tests bestanden sind, bevor er mit der EMR-Validierung fortfährt.

  6. Runtime-Korrekturen und Validierung: Der Agent validiert die Anwendung auf dem EMR-Zielcluster und behebt iterativ alle Laufzeitfehler, bis die Validierung erfolgreich ist. Nach Abschluss des Vorgangs wird eine Zusammenfassung aller Änderungen angezeigt, die aus Kompatibilitätsgründen vorgenommen wurden.

  7. Zusammenfassung des Upgrades: Sobald das Upgrade abgeschlossen ist, stellt Ihnen der Agent eine Zusammenfassung aller Code- und Konfigurationsänderungen, Aktualisierungen der abhängigen Versionen und aller festgestellten Datenqualitätsunterschiede zur Überprüfung bereit.