Kündigung der serverlosen EMR-Auftragsausführung mit Übergangsfrist - 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.

Kündigung der serverlosen EMR-Auftragsausführung mit Übergangsfrist

In Datenverarbeitungssystemen können abrupte Abbrüche zu Ressourcenverschwendung, unvollständigen Vorgängen und potenziellen Dateninkonsistenzen führen. Amazon EMR Serverless ermöglicht es Ihnen, einen Übergangszeitraum für das Abbrechen von Auftragsausführungen festzulegen. Diese Funktion bietet ausreichend Zeit für die ordnungsgemäße Reinigung und den Abschluss laufender Arbeiten, bevor der Auftrag beendet wird.

Wenn Sie eine Auftragsausführung abbrechen, können Sie mithilfe des Parameters shutdownGracePeriodInSeconds einen Kulanzzeitraum (in Sekunden) angeben, innerhalb dessen der Job Bereinigungsvorgänge durchführen kann, bevor er endgültig beendet wird. Das Verhalten und die Standardeinstellungen variieren je nach Batch- und Streaming-Auftrag.

Übergangsfrist für Batch-Jobs

Für Batch-Jobs können Sie mit EMR Serverless benutzerdefinierte Bereinigungsvorgänge implementieren, die während der Kulanzzeit ausgeführt werden. Sie können diese Bereinigungsvorgänge als Teil des JVM-Shutdown-Hooks in Ihrem Anwendungscode registrieren.

Standardverhalten

Das Standardverhalten beim Herunterfahren besteht darin, dass es keine Übergangsfrist gibt. Es besteht aus den folgenden zwei Aktionen:

  • Sofortige Kündigung

  • Ressourcen werden sofort freigegeben

Konfigurationsoptionen

Sie können Einstellungen angeben, die zu einem ordnungsgemäßen Herunterfahren führen:

  • Gültiger Zeitraum für den Shutdown Grace-Zeitraum: 15-1800 Sekunden (optional)

  • Sofortige Kündigung (ohne Nachfrist): 0 Sekunden

Ordnungsgemäßes Herunterfahren aktivieren

Gehen Sie wie folgt vor, um das ordnungsgemäße Herunterfahren für Batch-Jobs zu implementieren:

  1. Fügen Sie Ihrem Anwendungscode einen Shutdown-Hook hinzu, der eine benutzerdefinierte Shutdown-Logik enthält.

    Example in Scala
    import org.apache.hadoop.util.ShutdownHookManager // Register shutdown hook with priority (second argument) // Higher priority hooks run first ShutdownHookManager.get().addShutdownHook(() => { logger.info("Performing cleanup operations...") }, 100)

    Verwenden von ShutdownHookManager

    Example in PySpark
    import atexit def cleanup(): # Your cleanup logic here print("Performing cleanup operations...") # Register the cleanup function atexit.register(cleanup)
  2. Geben Sie beim Abbrechen des Jobs eine Übergangsfrist an, um genügend Zeit für die Ausführung der oben hinzugefügten Hooks zu haben

    Beispiel

    # Default (immediate termination) aws emr-serverless cancel-job-run \ --application-id APPLICATION_ID \ --job-run-id JOB_RUN_ID # With 5-minute grace period aws emr-serverless cancel-job-run \ --application-id APPLICATION_ID \ --job-run-id JOB_RUN_ID \ --shutdown-grace-period-in-seconds 300

Nachfrist für Streaming-Jobs

In Spark Structured Streaming, wo Berechnungen das Lesen von oder Schreiben in externe Datenquellen beinhalten, können abrupte Abschaltungen zu unerwünschten Ergebnissen führen. Streaming-Jobs verarbeiten Daten in Mikrostapeln, und wenn diese Vorgänge auf halbem Weg unterbrochen werden, kann es bei nachfolgenden Versuchen zu einer doppelten Verarbeitung kommen. Dies passiert, wenn der letzte Checkpoint aus dem vorherigen Micro-Batch nicht geschrieben wurde, was dazu führt, dass dieselben Daten erneut verarbeitet werden, wenn der Streaming-Job neu gestartet wird. Eine solche doppelte Verarbeitung verschwendet nicht nur Rechenressourcen, sondern kann sich auch auf den Geschäftsbetrieb auswirken. Daher ist es wichtig, abrupte Abschaltungen zu vermeiden.

EMR Serverless bietet integrierte Unterstützung für ein ordnungsgemäßes Herunterfahren über einen Streaming-Abfrage-Listener. Dadurch wird gewährleistet, dass die laufenden Mikrobatches ordnungsgemäß abgeschlossen werden, bevor der Auftrag beendet wird. Der Dienst sorgt bei Streaming-Anwendungen automatisch für ein ordnungsgemäßes Herunterfahren zwischen Mikrobatches und stellt so sicher, dass der aktuelle Mikrobatch die Verarbeitung abschließt, die Checkpoints korrekt geschrieben werden und der Streaming-Kontext sauber beendet wird, ohne dass während des Shutdown-Vorgangs neue Daten aufgenommen werden.

Standardverhalten

  • Die Kulanzzeit von 120 Sekunden ist standardmäßig aktiviert.

  • Der integrierte Listener für Streaming-Abfragen sorgt für ein ordnungsgemäßes Herunterfahren.

Konfigurationsoptionen

  • Gültiger Zeitraum für den Shutdown Grace-Zeitraum: 15-1800 Sekunden (optional)

  • Sofortige Kündigung: 0 Sekunden

Aktivieren Sie Graceful Shutdown

So implementieren Sie ein ordnungsgemäßes Herunterfahren für Streaming-Jobs:

Geben Sie beim Abbrechen des Jobs einen Übergangszeitraum an, um genügend Zeit für die Fertigstellung des laufenden Mikrobatches zu haben.

Beispiel

# Default graceful shutdown (120 seconds) aws emr-serverless cancel-job-run \ --application-id APPLICATION_ID \ --job-run-id JOB_RUN_ID # Custom grace period (e.g. 300 seconds) aws emr-serverless cancel-job-run \ --application-id APPLICATION_ID \ --job-run-id JOB_RUN_ID \ --shutdown-grace-period-in-seconds 300 # Immediate Termination aws emr-serverless cancel-job-run \ --application-id APPLICATION_ID \ --job-run-id JOB_RUN_ID \ --shutdown-grace-period-in-seconds 0

Fügen Sie benutzerdefinierte Shutdown-Hooks hinzu (optional)

Während EMR Serverless das ordnungsgemäße Herunterfahren standardmäßig über seinen integrierten Streaming-Abfrage-Listener verwaltet, können Sie optional eine benutzerdefinierte Shutdown-Logik für einzelne Streaming-Abfragen implementieren. EMR Serverless registriert seinen Graceful Shutdown-Listener mit Priorität 60 (using). ShutdownHookManager Da Hooks mit höherer Priorität zuerst ausgeführt werden, können Sie Ihre benutzerdefinierten Bereinigungsvorgänge mit einer Priorität von mehr als 60 registrieren, um sicherzustellen, dass sie ausgeführt werden, bevor der Shutdown-Vorgang von EMR Serverless beginnt.

Informationen zum Hinzufügen eines benutzerdefinierten Hooks finden Sie im ersten Beispiel in diesem Thema. Es zeigt, wie Sie einen Shutdown-Hook in Ihren Anwendungscode einfügen. Hier ist 100 die Priorität, die größer als 60 ist. Daher wird ein solcher Shutdown-Hook zuerst ausgeführt.

Anmerkung

Benutzerdefinierte Shutdown-Hooks sind optional und für die Funktionalität zum ordnungsgemäßen Herunterfahren, die automatisch von EMR Serverless ausgeführt wird, nicht erforderlich.

Gebühren für die Nachfrist und Batchdauer

Wenn der Standardwert für die Nachfrist (120 Sekunden) verwendet wird:

  • Wenn Ihre Batchdauer weniger als 120 Sekunden beträgt, wird Ihnen nur die tatsächliche Zeit in Rechnung gestellt, die für die Fertigstellung des Stapels benötigt wird.

  • Wenn Ihre Batchdauer 120 Sekunden überschreitet, wird Ihnen die maximale Kulanzzeit (120 Sekunden) in Rechnung gestellt, aber die Abfrage wird möglicherweise nicht ordnungsgemäß beendet, da sie dann zwangsweise beendet wird.

So optimieren Sie die Kosten und sorgen für ein ordnungsgemäßes Herunterfahren:

  • Für Batchdauern > 120 Sekunden: Erwägen Sie, die Kulanzzeit entsprechend Ihrer Batchdauer zu verlängern

  • Für Batchdauern < 120 Sekunden: Sie müssen den Kulanzzeitraum nicht anpassen, da Ihnen nur die tatsächliche Verarbeitungszeit in Rechnung gestellt wird

Überlegungen

Verhalten im Rahmen der Nachfrist

  • Die Übergangszeit gibt Ihnen Zeit, bis Ihre registrierten Shutdown-Hooks abgeschlossen sind.

  • Der Job wird beendet, sobald der Shutdown-Hook beendet ist, auch wenn er weit vor der Kulanzfrist liegt.

  • Wenn die Bereinigungsvorgänge den Kulanzzeitraum überschreiten, wird der Job gewaltsam beendet.

Verhalten der Dienste

  • Das Herunterfahren im Grace Period ist nur für Jobs im Status RUNNING verfügbar.

  • Nachfolgende Stornierungsanfragen im Status CANCELING werden ignoriert.

  • Wenn EMR Serverless aufgrund interner Dienstfehler das Herunterfahren im Grace Period nicht initiieren kann:

    • Der Dienst versucht es für bis zu 2 Minuten erneut.

    • Wenn die Wiederholungsversuche nicht erfolgreich sind, wird der Job gewaltsam beendet.

Fakturierung

Aufträgen werden die verbrauchten Rechenressourcen in Rechnung gestellt, bis der Job vollständig beendet wird. Dies gilt auch für die Zeit, die während der Übergangszeit in Anspruch genommen wurde.