Wie löse ich das Problem „HIVE_CANNOT_OPEN_SPLIT: Fehler beim Öffnen von Hive split s3://awsdoc-example-bucket/: Slow Down (Service: Amazon S3; Statuscode: 503; Fehlercode: 503 Slow Down;“ Fehler in Athena?

Lesedauer: 6 Minute
0

Meine Amazon Athena-Anfrage schlägt mit einem der folgenden Fehler fehl: "HIVE_CANNOT_OPEN_SPLIT: Fehler beim Öffnen von Hive Split s3://awsdoc-example-bucket/date=2020-05-29/ingest_date=2020-04-25/part-00000.snappy.parquet (offset=0, length=18614): Slow Down (Service: Amazon S3; Statuscode: 503; Fehlercode: 503 Slow Down;“ -oder- „Unbekannter Fehler (Statuscode = 1003, java.sql.SQLException: [Simba] [AthenaJDBC] (100071) Ein Fehler wurde vom AWS Athena client.HIVE_CANNOT_OPEN_SPLIT ausgelöst: Fehler beim Öffnen von Hive Split s3://awsdoc-example-bucket/date=2020-05-29/ingest_date=2020-04-25/part-00000.snappy.parquet (offset=0, length=18614): Slow Down (Service: Amazon S3; Statuscode: 503; Fehlercode: 503 Slow Down;"

Kurzbeschreibung

Ein Amazon Simple Storage Service (Amazon S3) -Bucket kann 3.500 PUT/COPY/POST/DELETE- oder 5.500 GET/HEAD-Anfragen pro Sekunde und Präfix in einem Bucket verarbeiten. Diese Fehler treten auf, wenn dieser Anforderungsschwellenwert überschritten wird. Dieses Limit ist ein kombiniertes Limit für alle Benutzer und Dienste eines Kontos.

Standardmäßig skaliert Amazon S3 automatisch, um sehr hohe Anforderungsraten zu unterstützen. Wenn Ihre Anforderungsrate steigt, wird Ihr S3-Bucket automatisch partitioniert, um höhere Anforderungsraten zu unterstützen. Wenn der Schwellenwert für Anfragen jedoch überschritten wird, erhalten Sie 5xx-Fehler, in denen Sie aufgefordert werden, langsamer zu werden oder es später zu versuchen.

Das Präfix s3://my-athena-bucket/month=jan/ kann beispielsweise nur 3.500 PUT/COPY/POST/DELETE-Anfragen pro Sekunde oder 5.500 GET/HEAD-Anfragen pro Sekunde unterstützen. Wenn Sie 10.000 Dateien in diesem Präfix haben und eine Athena-Abfrage für dieses Präfix ausführen, erhalten Sie den Fehler 503 Slow Down. Dies liegt daran, dass Athena versucht, mithilfe der GET/HEAD-Anfragen alle 10.000 Dateien im Präfix gleichzeitig zu lesen, aber das Präfix kann nur bis zu 5.500 GET/HEAD-Anfragen pro Sekunde unterstützen. Dies kann dazu führen, dass Ihre S3-Anfragen gedrosselt werden und der Fehler 503 Slow Down angezeigt wird.

Lösung

Verwenden Sie eine oder mehrere der folgenden Methoden, um eine Drosselung von Anfragen zu verhindern:

Verteilen Sie S3-Objekte und Anfragen auf mehrere Präfixe

Die Partitionierung Ihrer Daten kann dazu beitragen, die Objekte und Anfragen auf mehrere Präfixe zu verteilen. Vermeiden Sie es, viele Dateien unter einem einzigen S3-Präfix zu speichern. Erwägen Sie die Verwendung mehrerer Präfixe, damit Sie die S3-Objekte auf diese Präfixe verteilen können. Durch die Partitionierung Ihrer Daten können Sie die Datenmenge reduzieren, die bei jeder Abfrage gescannt wird. Weitere Informationen finden Sie unter Partitionierung von Daten.

Anstatt beispielsweise alle Dateien unter s3://my-athena-bucket/my-athena-data-files zu speichern, partitionieren Sie die Daten und speichern Sie sie unter den folgenden individuellen Präfixen:

s3://my-athena-bucket/jan

s3://my-athena-bucket/feb

s3://my-athena-bucket/mar

Die Daten in diesen Dateien können weiter partitioniert werden, um die Verteilung der Objekte zu erhöhen (Beispiel: s3://my-athena-bucket/jan/01).

Weitere Informationen zur Festlegung der Ordnerstruktur Ihrer Athena-Partition finden Sie unter Tipps und Tricks zur Leistung von Amazon S3.

Reduzieren Sie die Anzahl der Dateien in jedem Präfix

Dieser Fehler kann auftreten, wenn Sie einen S3-Bucket mit einer großen Anzahl kleiner Objekte abfragen. Befindet sich beispielsweise eine 100-MB-Datei in einem S3-Bucket, muss Athena eine GET-Anfrage stellen, um die Datei zu lesen. Wenn es jedoch 1.000 Dateien mit jeweils 100 KB gibt, muss Athena 1.000 GET-Anfragen stellen, um dieselben 100 MB an Daten zu lesen. Dies führt dazu, dass die Anfragen die S3-Anforderungslimits überschreiten.

Um die Anzahl der Amazon S3-Anfragen zu reduzieren, reduzieren Sie die Anzahl der Dateien. Verwenden Sie beispielsweise das Tool s3DistCP, um eine große Anzahl kleiner Dateien (weniger als 128 MB) zu einer kleineren Anzahl großer Dateien zusammenzuführen. Weitere Informationen finden Sie unter Die 10 wichtigsten Tipps zur Leistungsoptimierung für Amazon Athena, und lesen Sie die 4. Abschnitt Dateigrößen optimieren.

Beispiel:

s3-dist-cp --src=s3://my_athena_bucket_source/smallfiles/ --dest=s3://my_athena_bucket_target/largefiles/ --groupBy='.*(.csv)'

Stellen Sie sicher, dass Sie im obigen Befehl Folgendes ersetzen:

  • my\ _athena\ _bucket\ _source mit dem Quell-S3-Bucket, in dem die kleinen Dateien existieren.
  • my\ _athena\ _bucket\ _target mit dem Ziel-S3-Bucket, in dem die Ausgabe gespeichert wird.

Sie können die Option groupBy verwenden, um kleine Dateien zu weniger großen Dateien mit einer von Ihnen gewählten Größe zusammenzufassen. Dies kann Ihnen helfen, sowohl die Abfrageleistung als auch die Kosten zu optimieren.

Hinweis: S3DistCP unterstützt keine Verkettung von Parquet-Dateien. Verwenden Sie stattdessen PySpark. Weitere Informationen finden Sie unter Wie kann ich Parquet-Dateien in Amazon EMR verketten?

Überprüfen Sie, ob die Versionierung für Ihren S3-Bucket aktiviert ist

Wenn Sie Objekte aus einem versionsfähigen Bucket löschen, fügt Amazon S3 eine Löschmarkierung ein, anstatt das Objekt dauerhaft zu entfernen. Wenn Sie in Ihrem S3-Bucket viele Dateien mit Löschmarkierungen haben, wird möglicherweise dieser Fehler angezeigt. Wenn Sie eine Abfrage in einem versionsfähigen Bucket ausführen, muss Athena die verschiedenen Versionen jedes Objekts überprüfen. Dann entscheidet Athena, ob ein bestimmtes Objekt in die Abfrageverarbeitung einbezogen werden soll.

Um diesen Fehler zu beheben, sollten Sie erwägen, die Löschmarkierungen aus Ihrem S3-Bucket zu entfernen. Sie können die Löschmarkierungen entfernen, indem Sie einen der folgenden Schritte ausführen:

Überprüfen Sie, ob andere Anwendungen dasselbe S3-Präfix verwenden

Verwenden Sie die Amazon CloudWatch 5xxErrors-Metrik und die S3-Serverzugriffsprotokolle, um zu überprüfen, ob andere Anwendungen wie Hive on EMR, Spark oder AWS Glue dasselbe S3-Präfix verwendeten, als Sie die Athena-Abfrage ausgeführt haben. Wenn mehrere Anwendungen versuchen, die Daten aus demselben S3-Präfix zu lesen, können die Anfragen gedrosselt werden und Abfragen mit dem Slow-Down-Fehler fehlschlagen. Vermeiden Sie die Planung von Anwendungen, die gleichzeitig auf dasselbe Präfix zugreifen. Verwenden Sie außerdem unterschiedliche S3-Präfixe für die Athena-Datenquelle und die Anwendungsdatenquelle.

Sie können eine CloudWatch-Metrikkonfiguration für alle Objekte in Ihrem S3-Bucket erstellen. Verwenden Sie diese Metriken, um die API-Aufrufraten für ein bestimmtes Präfix zu einem bestimmten Zeitpunkt zu überwachen. Die Aktivierung von S3-Anforderungsmetriken für ein Präfix kann helfen, die allgemeine API-Treffrate für ein Präfix zu einem bestimmten Zeitpunkt zu verstehen. Sie können diese Informationen zusammen mit den S3-Serverzugriffsprotokollen verwenden, um herauszufinden, welche Anwendung den API-Aufruf für das Präfix verwendet hat.


Ähnliche Informationen

Wie kann ich die Amazon S3-Anforderungslimits erhöhen, um eine Drosselung meines Amazon S3-Buckets zu vermeiden?

Problembehandlung in Athena

Leistungssteigerung in Athena

AWS OFFICIAL
AWS OFFICIALAktualisiert vor 3 Jahren