Warum schlägt mein Spark- oder Hive-Job auf Amazon EMR mit einer Amazons3-Ausnahme mit HTTP 503 „Slow Down“ fehl?

Kurzbeschreibung

Dieser Fehler tritt auf, wenn die Anforderungsrate von Amazon Simple Storage Service (Amazon S3) für deine Anwendung die normalerweise anhaltenden Raten von über 5.000 Anfragen pro Sekunde übersteigt und Amazon S3 intern die Leistung optimiert.

Versuche die folgenden Methoden, um die Erfolgsquote deiner Anfragen beim Zugriff auf die S3-Daten mit Amazon EMR zu verbessern:

• Ändere die Wiederholungsstrategie für S3-Anfragen.
• Passe die Anzahl gleichzeitiger S3-Anfragen an.

Behebung

Um das Problem mit zu vielen Anfragen zu identifizieren, empfiehlt es sich, Amazon CloudWatch-Anforderungsmetriken für den S3-Bucket zu konfigurieren. Anhand dieser CloudWatch-Metriken kannst du die Lösung ermitteln, die für deinen Anwendungsfall am besten geeignet ist.

CloudWatch-Anforderungsmetriken konfigurieren

Um Amazon S3-Anfragen zu überwachen, aktiviere die CloudWatch-Anforderungsmetriken für den Bucket. Definiere dann einen Filter für das Präfix. Eine Liste nützlicher Metriken zur Überwachung findest du unter Überwachen von Metriken mit Amazon CloudWatch.

Ändere die Wiederholungsstrategie für S3-Anfragen

Standardmäßig verwendet EMRFS eine exponentielle Backoff-Strategie, um Anfragen an Amazon S3 erneut zu versuchen. Das standardmäßige EMRFS-Wiederholungslimit ist 15. Du kannst jedoch das Wiederholungslimit für einen neuen Cluster, einen laufenden Cluster oder zur Anwendungslaufzeit erhöhen.

Um das Wiederholungslimit zu erhöhen, ändere den Wert des Parameters fs.s3.maxRetries. Wenn du für diesen Parameter einen sehr hohen Wert festlegst, kann es zu einer längeren Auftragsdauer kommen. Versuche, diesen Parameter auf einen hohen Wert (z. B. 20) zu setzen, überwache den Zeitaufwand der Jobs und passe diesen Parameter dann an deinen Anwendungsfall an.

Für einen neuen Cluster kannst du beim Starten des Clusters ein Konfigurationsobjekt hinzufügen, das dem folgenden ähnelt:

[
  {
    "Classification": "emrfs-site",
    "Properties": {
      "fs.s3.maxRetries": "20"
    }
  }
]

Nach dem Start des Clusters verwenden Spark- und Hive-Anwendungen, die auf Amazon EMR ausgeführt werden, das neue Limit.

Gehe wie folgt vor, um das Wiederholungslimit für einen laufenden Cluster zu erhöhen:

1.Öffne die Amazon-EMR-Konsole.

2.Wähle in der Clusterliste unter Name den aktiven Cluster aus, den du neu konfigurieren möchtest.

3.Öffne die Cluster-Detailseite für den Cluster und wähle die Registerkarte Konfigurationen.

4.Wähle in der Dropdownliste Filter die Instance-Gruppe aus, die du neu konfigurieren möchtest.

5.Wähle in der Dropdownliste Neu konfigurieren die Option In Tabelle bearbeiten.

6.Wähle in der Tabelle mit der Konfigurationsklassifizierung die Option Konfiguration hinzufügen aus, und gib dann Folgendes ein:

Zur Klassifizierung: emrfs-site

Für Eigenschaft: fs.s3.maxRetries

Für Wert: der neue Wert für das Wiederholungslimit (z. B. 20)

7.Wähle Diese Konfiguration auf alle aktiven Instance-Gruppen anwenden.

8.Wähle Save changes (Änderungen speichern).

Nach der Bereitstellung der Konfiguration verwenden Spark- und Hive-Anwendungen das neue Limit.

Um das Wiederholungslimit zur Laufzeit zu erhöhen, verwende eine Spark-Shell-Sitzung, die der folgenden ähnelt:

spark> sc.hadoopConfiguration.set("fs.s3.maxRetries", "20")
spark> val source_df = spark.read.csv("s3://awsexamplebucket/data/")
spark> source_df.write.save("s3://awsexamplebucket2/output/")

Hier ist ein Beispiel dafür, wie du das Wiederholungslimit zur Laufzeit für eine Hive-Anwendung erhöhen kannst:

hive> set fs.s3.maxRetries=20;
hive> select ....

Passe die Anzahl gleichzeitiger S3-Anfragen an

• Wenn du mehrere Jobs (Spark, Apache Hive oder s-dist-cp) hast, die in dasselbe S3-Präfix lesen und schreiben, kannst du die Parallelität anpassen. Beginne mit den Aufgaben mit den meisten Lese- und Schreibvorgängen und reduziere deren Parallelität, um übermäßige Parallelität zu vermeiden. Wenn du den kontenübergreifenden Zugriff für Amazon S3 konfiguriert hast, denke daran, dass andere Konten möglicherweise auch Jobs an dasselbe Präfix senden.
• Wenn beim Versuch des Jobs, in den Ziel-Bucket zu schreiben, Fehler auftreten, reduziere die übermäßige Schreibparallelität. Verwende beispielsweise die Spark-Operationen .coalesce() oder .repartition(), um die Anzahl der Spark-Ausgabepartitionen zu reduzieren, bevor du in Amazon S3 schreibst. Du kannst auch die Anzahl der Kerne pro Executor oder die Anzahl der Executoren reduzieren.
• Wenn beim Versuch des Jobs, aus dem Quell-Bucket zu lesen, Fehler auftreten, passe die Größe der Objekte an. Du kannst kleinere Objekte zu größeren zusammenfassen, sodass die Anzahl der Objekte, die vom Job gelesen werden sollen, reduziert wird. Auf diese Weise musst du Datensätze mit weniger Leseanforderungen lesen. Verwende beispielsweise s3-dist-cp, um eine große Anzahl kleiner Dateien zu einer kleineren Anzahl großer Dateien zusammenzuführen.

Verwandte Informationen

Bewährte Methoden zur Gestaltung von Mustern: Optimierung der Amazon S3-Leistung

Warum schlägt meine Amazon EMR-Anwendung bei einer Amazons3Exception vom Typ HTTP 403 „Access Denied“ fehl?

Warum schlägt meine Amazon EMR-Anwendung bei einer Amazons3Exception vom Typ HTTP 404 „Not Found“ fehl?