Probleme in Athena beheben - Amazon Athena
CREATE TABLE AS SELECT (CTAS)Probleme mit DatendateienDelta-Lake-Tabellen von Linux FoundationVerbundabfragenJSON-bezogene FehlerMSCK REPAIR TABLEProbleme mit der AusgabeProbleme mit ParquetPartitionierungsproblemeBerechtigungenProbleme mit der AbfragesyntaxProbleme mit dem Abfrage-TimeoutProbleme mit DrosselungAnsichtenArbeitsgruppenWeitere Ressourcen

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.

Probleme in Athena beheben

Das Athena-Team hat die folgenden Informationen zur Fehlerbehebung von Kundenproblemen gesammelt. Obwohl sie nicht umfassend ist, enthält sie Ratschläge zu einigen häufigen Leistungs-, Timeout- und Speicherproblemen.

Themen

CREATE TABLE AS SELECT (CTAS)

Duplizierte Daten treten mit gleichzeitigen CTAS-Anweisungen auf

Athena führt keine gleichzeitige Validierung für CTAS durch. Stellen Sie sicher, dass für denselben Speicherort keine doppelte CTAS-Anweisung zur gleichen Zeit vorhanden ist. Selbst wenn eine CTAS- oder INSERT-INTO-Anweisung fehlschlägt, können verwaiste Daten an dem in der Anweisung angegebenen Datenspeicherort verbleiben.

HIVE_TOO_MANY_OPEN_PARTITIONS

Wenn Sie eine CTAS-Anweisung verwenden, um eine Tabelle mit mehr als 100 Partitionen zu erstellen, wird möglicherweise der Fehler HIVE_TOO_MANY_OPEN_PARTITIONS: Exceeded limit of 100 open writers for partitions/buckets angezeigt. Um diese Einschränkung zu umgehen, können Sie eine CTAS-Anweisung und eine Reihe von INSERT INTO-Anweisungen verwenden, die jeweils bis zu 100 Partitionen erstellen oder einfügen. Weitere Informationen finden Sie unter Verwenden Sie CTAS und INSERTINTO, um das Limit von 100 Partitionen zu umgehen.

Probleme mit Datendateien

Athena kann versteckte Dateien nicht lesen

Athena behandelt Quelldateien, die mit einem Unterstrich (_) oder einem Punkt (.) beginnen, als ausgeblendet. Benennen Sie die Dateien um, um diese Einschränkung zu umgehen.

Athena liest Dateien, die ich vom Crawler ausgeschlossen habe AWS Glue

Athena erkennt keine Ausschlussmuster, die Sie für einen AWS Glue Crawler angeben. Wenn Sie beispielsweise über einen Amazon-S3-Bucket verfügen, der sowohl .csv- als auch .json-Dateien enthält und Sie die .json-Dateien vom Crawler ausschließen, fragt Athena beide Dateigruppen ab. Um dies zu vermeiden, platzieren Sie die Dateien, die Sie ausschließen möchten, an einem anderen Speicherort.

HIVE_BAD_DATA: Fehler beim Analysieren des Feldwerts

Dieser Fehler kann in folgenden Szenarien auftreten:

HIVE_CANNOT_OPEN_SPLIT: Fehler beim Öffnen des Hive-Splits s3://amzn-s3-demo-bucket

Dieser Fehler kann auftreten, wenn Sie ein Amazon-S3-Bucket-Präfix abfragen, das eine große Anzahl von Objekten aufweist. Weitere Informationen finden Sie unter Wie behebe ich den Fehler „HIVE_CANNOT_OPEN_SPLIT: Fehler beim Öffnen von Hive Split s3://amzn-s3-demo-bucket/: Verlangsamen“ in Athena? im Knowledge Center. AWS

HIVE_CURSOR_ERROR: com.amazonaws.services.s3.model.Amazons3Exception: Der angegebene Schlüssel ist nicht vorhanden

Dieser Fehler tritt normalerweise auf, wenn eine Datei entfernt wird, wenn eine Abfrage ausgeführt wird. Führen Sie entweder die Abfrage erneut aus, oder überprüfen Sie Ihren Workflow, um festzustellen, ob ein anderer Auftrag oder Prozess die Dateien ändert, wenn die Abfrage ausgeführt wird.

HIVE_CURSOR_ERROR: Unerwartetes Ende des Eingabedatenstreams

Diese Meldung zeigt an, dass die Datei beschädigt oder leer ist. Überprüfen Sie die Integrität der Datei und führen Sie die Abfrage erneut aus.

HIVE_FILESYSTEM_ERROR: Falsche Dateigröße für Datei 1234567

Diese Meldung kann auftreten, wenn sich eine Datei zwischen Abfrageplanung und Abfrageausführung geändert hat. Es tritt normalerweise auf, wenn eine Datei auf Amazon S3 direkt ersetzt wird (z. B. wird ein PUT für einen Schlüssel ausgeführt, in dem bereits ein Objekt existiert). Athena unterstützt das Löschen oder Ersetzen des Inhalts einer Datei nicht, wenn eine Abfrage ausgeführt wird. Um diesen Fehler zu vermeiden, planen Sie Aufträge, die Dateien zu Zeiten überschreiben oder löschen, in denen Abfragen nicht ausgeführt werden, oder schreiben Sie nur Daten in neue Dateien oder Partitionen.

HIVE_UNKNOWN_ERROR: Eingabeformat kann nicht erstellt werden

Dieser Fehler kann auf Probleme wie die folgenden zurückzuführen sein:

  • Der AWS Glue Crawler konnte das Datenformat nicht klassifizieren

  • Bestimmte Eigenschaften der AWS Glue Tabellendefinition sind leer

  • Athena unterstützt das Datenformat der Dateien in Amazon S3 nicht

Weitere Informationen finden Sie unter Wie behebe ich den Fehler „Eingabeformat kann nicht erstellt werden“ in Athena? im AWS -Wissenscenter oder sehen Sie sich das Wissenscenter-Video an.

Der zum Speichern der Abfrageergebnisse bereitgestellte S3-Speicherort ist ungültig.

Stellen Sie sicher, dass Sie einen gültigen S3-Speicherort für Ihre Abfrageergebnisse angegeben haben. Weitere Informationen finden Sie unter Geben Sie einen Speicherort für die Abfrageergebnisse an im Thema Arbeiten Sie mit Abfrageergebnissen und aktuellen Abfragen.

Delta-Lake-Tabellen von Linux Foundation

Das Delta-Lake-Tabellenschema ist nicht synchron

Wenn Sie eine Delta Lake-Tabelle abfragen AWS Glue , deren Schema veraltet ist, kann die folgende Fehlermeldung angezeigt werden:

INVALID_GLUE_SCHEMA: Delta Lake table schema in Glue does not match the most recent schema of the 
Delta Lake transaction log. Please ensure that you have the correct schema defined in Glue.

Das Schema kann veraltet sein, wenn es AWS Glue nach dem Hinzufügen zu Athena geändert wird. Führen Sie einen der folgenden Schritte aus, um das Schema zu aktualisieren:

Verbundabfragen

Timeout beim Telefonieren ListTableMetadata

Bei einem ListTableMetadataAPI-Aufruf kann es zu einer Zeitüberschreitung kommen, wenn die Datenquelle viele Tabellen enthält, wenn die Datenquelle langsam ist oder wenn das Netzwerk langsam ist. Sie lösen dieses Problem, indem Sie die folgenden Schritte ausführen.

  • Anzahl der Tabellen überprüfen – Wenn Sie mehr als 1 000 Tabellen haben, versuchen Sie, die Anzahl der Tabellen zu reduzieren. Für eine möglichst schnelle ListTableMetadata-Antwort empfehlen wir, weniger als 1 000 Tabellen pro Katalog zu haben.

  • Überprüfen Sie die Lambda-Konfiguration – Die Überwachung des Verhaltens der Lambda-Funktion ist von entscheidender Bedeutung. Wenn Sie Verbundkataloge verwenden, sollten Sie unbedingt die Ausführungsprotokolle der Lambda-Funktion überprüfen. Passen Sie auf der Grundlage der Ergebnisse die Arbeitsspeicher- und Timeout-Werte entsprechend an. Um mögliche Probleme mit Timeouts zu identifizieren, überprüfen Sie Ihre Lambda-Konfiguration erneut. Weitere Informationen finden Sie unter Konfigurieren von Funktions-Timeout (Konsole) im AWS Lambda -Entwicklerhandbuch.

  • Überprüfen Sie die Protokolle der Verbunddatenquellen – Untersuchen Sie die Protokolle und Fehlermeldungen der verbundenen Datenquelle, um festzustellen, ob Probleme oder Fehler vorliegen. Die Protokolle können wertvolle Einblicke in die Ursache des Timeouts liefern.

  • StartQueryExecution zum Abrufen von Metadaten verwenden – Wenn Sie über mehr als 1 000 Tabellen verfügen, kann es länger als erwartet dauern, Metadaten über Ihren Verbundkonnektor abzurufen. Da die asynchrone Natur von StartQueryExecutionsicherstellt, dass Athena die Abfrage optimal ausführt, sollten Sie die Verwendung StartQueryExecution als Alternative zu in Betracht ziehen. ListTableMetadata Die folgenden AWS CLI Beispiele zeigen, wie StartQueryExecution Sie anstelle von ListTableMetadata alle Metadaten von Tabellen in Ihrem Datenkatalog abrufen können.

    Führen Sie zunächst eine Abfrage aus, die alle Tabellen abruft, wie im folgenden Beispiel.

    aws athena start-query-execution --region us-east-1 \
--query-string "SELECT table_name FROM information_schema.tables LIMIT 50" \
--work-group "your-work-group-name"

    Als Nächstes rufen Sie die Metadaten einer einzelnen Tabelle ab, wie im folgenden Beispiel.

    aws athena start-query-execution --region us-east-1 \
--query-string "SELECT * FROM information_schema.columns \
WHERE table_name = 'your-table-name' AND \
table_catalog = 'your-catalog-name'" \
--work-group "your-work-group-name"

    Wie lange es dauert, bis die Ergebnisse abgerufen werden, hängt von der Anzahl der Tabellen in Ihrem Katalog ab.

Weitere Informationen zur Problembehandlung bei Verbundabfragen finden Sie unter Common_Problems im aws-athena-query-federation Abschnitt awslabs/ von oder in der GitHub Dokumentation zu den einzelnen Athena-Datenquellenconnectors.

NULL oder falsche Datenfehler beim Versuch, JSON-Daten zu lesen

NULL oder falsche Datenfehler, wenn Sie versuchen, JSON-Daten zu lesen, können auf eine Reihe von Ursachen zurückzuführen sein. Um Leitungen zu identifizieren, die bei der Verwendung von OpenX Fehler verursachen SerDe, setzen Sie ignore.malformed.json auftrue. Fehlgeformte Datensätze werden als NULL zurückgegeben. Weitere Informationen finden Sie unter Ich erhalte Fehler, wenn ich versuche, JSON-Daten in Amazon Athena zu lesen im AWS -Wissenscenter oder sehen Sie sich das Wissenscenter-Video an.

HIVE_BAD_DATA: Fehler beim Analysieren des Feldwerts für Feld 0: java.lang.String kann nicht in org.openx.data.jsonserde.json umgewandelt werden. JSONObject

Das OpenX JSON SerDe löst diesen Fehler aus, wenn eine Spalte in einer Athena-Abfrage nicht analysiert werden kann. Dies kann passieren, wenn Sie eine Spalte als map oder struct definieren, die zugrunde liegenden Daten jedoch tatsächlich ein string, int oder ein anderer primitiver Typ sind.

HIVE_CURSOR_ERROR: Zeile ist kein gültiges JSON-Objekt -: Doppelter Schlüssel JSONException

Dieser Fehler tritt auf, wenn Sie Athena verwenden, um AWS Config Ressourcen mit mehreren Tags mit demselben Namen in unterschiedlichen Groß- und Kleinschreibung abzufragen. Die Lösung besteht darin, CREATE TABLE mit WITH SERDEPROPERTIES 'case.insensitive'='false' auszuführen und die Namen zuzuordnen. Weitere Informationen zu case.insensitive und Mapping finden Sie unter JSON SerDe bibliotheken. Weitere Informationen finden Sie unter Wie behebe ich „HIVE_CURSOR_ERROR: Zeile ist kein gültiges JSON-Objekt - JSONException: Doppelter Schlüssel“ beim Lesen von Dateien aus Athena? AWS Config im Knowledge Center. AWS

HIVE_CURSOR_ERROR Nachrichten mit hübsch gedrucktem JSON

Die Bienenstock JSON SerDe- und OpenX JSON SerDe-Bibliotheken erwarten, dass sich jedes JSON-Dokument auf einer einzigen Textzeile befindet, ohne Zeilenabschlusszeichen, die die Felder im Datensatz trennen. Wenn der JSON-Text ein hübsches Druckformat hat, erhalten Sie möglicherweise eine Fehlermeldung wie HIVE_CURSOR_ERROR: Row is not a valid JSON Object oder HIVE_CURSOR_ERROR:: Unexpected JsonParseException end-of-input: expected close marker for OBJECT, wenn Sie versuchen, die Tabelle abzufragen, nachdem Sie sie erstellt haben. Weitere Informationen finden Sie unter JSON-Datendateien in der SerDe OpenX-Dokumentation unter GitHub.

Mehrere JSON-Datensätze geben einen SELECT COUNT von 1 zurück

Wenn Sie das OpenX JSON SerDe verwenden, stellen Sie sicher, dass die Datensätze durch ein Zeilenumbruchzeichen getrennt sind. Weitere Informationen finden Sie unter Die SELECT COUNT-Abfrage in Amazon Athena gibt nur einen Datensatz zurück, obwohl die JSON-Eingabedatei mehrere Datensätze im AWS Knowledge Center enthält.

Eine Tabelle, die von einem AWS Glue Crawler erstellt wurde, der einen benutzerdefinierten JSON-Klassifikator verwendet, kann nicht abgefragt werden

Die Athena-Engine unterstützt keine benutzerdefinierten JSON-Klassifikatoren. Um dieses Problem zu umgehen, erstellen Sie eine neue Tabelle ohne den benutzerdefinierten Klassifikator. Um den JSON zu transformieren, können Sie CTAS verwenden oder eine Ansicht erstellen. Wenn Sie beispielsweise mit Arrays arbeiten, können Sie die Option UNNEST verwenden, um den JSON zu reduzieren. Eine weitere Option besteht darin, einen AWS Glue ETL-Job zu verwenden, der den benutzerdefinierten Klassifikator unterstützt, die Daten in Amazon S3 in Parquet zu konvertieren und sie dann in Athena abzufragen.

MSCK REPAIR TABLE

Informationen zu Problemen im Zusammenhang mit MSCK REPAIR TABLE finden Sie in den Abschnitten Überlegungen und Einschränkungen und Fehlerbehebung der Seite MSCK REPAIR TABLE.

Probleme mit der Ausgabe

Ausgabe-Bucket konnte nicht verifiziert/erstellt werden

Dieser Fehler kann auftreten, wenn der angegebene Abfrageergebnisspeicherort nicht vorhanden ist oder wenn die richtigen Berechtigungen nicht vorhanden sind. Weitere Informationen finden Sie unter Wie behebe ich den Fehler „Unable to verify/create output bucket“ in Amazon Athena? im Knowledge Center. AWS

TIMESTAMP-Ergebnis ist leer

Athena benötigt das Java–TIMESTAMP-Format. Weitere Informationen finden Sie unter Wenn ich eine Tabelle in Amazon Athena abfrage, ist das TIMESTAMP-Ergebnis leer im AWS -Wissenscenter.

Speichern der Athena Abfrageausgabe in einem anderen Format als CSV

Standardmäßig gibt Athena Dateien nur im CSV-Format aus. Um die Ergebnisse einer SELECT-Abfrage in einem anderen Format auszugeben, können Sie die UNLOAD-Anweisung verwenden. Weitere Informationen finden Sie unter UNLOAD. Sie können auch eine CTAS-Abfrage verwenden, die die format Tabelleneigenschaft verwendet, um das Ausgabeformat zu konfigurieren. Im Gegensatz zu UNLOAD erfordert die CTAS-Technik die Erstellung einer Tabelle. Weitere Informationen finden Sie unter Wie kann ich eine Athena-Abfrageausgabe in einem anderen Format als CSV speichern, z. B. in einem komprimierten Format? im AWS Knowledge Center.

Der zum Speichern der Abfrageergebnisse bereitgestellte S3-Speicherort ist ungültig

Sie können diese Fehlermeldung erhalten, wenn sich Ihr Ausgabe-Bucket-Speicherort nicht in derselben Region befindet wie die Region, in der Sie Ihre Abfrage ausführen. Um dies zu vermeiden, geben Sie einen Abfrageergebnisspeicherort in der Region an, in der Sie die Abfrage ausführen. Informationen zu den erforderlichen Schritten finden Sie unter Geben Sie einen Speicherort für die Abfrageergebnisse an.

Probleme mit Parquet

org.apache.parquet.io. GroupColumnIO kann nicht nach org.apache.parquet.io umgewandelt werden. PrimitiveColumnIO

Dieser Fehler wird durch eine Nichtübereinstimmung des Parquet-Schemas verursacht. Eine Spalte mit einem nicht-primitiven Typ (z. B. array) wurde in AWS Glue als primitiver Typ (z. B. string) deklariert. Um dieses Problem zu beheben, überprüfen Sie das Datenschema in den Dateien und vergleichen Sie es mit dem in AWS Glue deklarierten Schema.

Probleme mit Statistiken in Parquet

Wenn Sie Parquet-Daten lesen, erhalten Sie möglicherweise Fehlermeldungen wie die folgenden:

HIVE_CANNOT_OPEN_SPLIT: Index x out of bounds for length y
HIVE_CURSOR_ERROR: Failed to read x bytes
HIVE_CURSOR_ERROR: FailureException at Malformed input: offset=x
HIVE_CURSOR_ERROR: FailureException at java.io.IOException: 
can not read class org.apache.parquet.format.PageHeader: Socket is closed by peer.

Um dieses Problem zu umgehen, verwenden Sie die ALTER TABLE SET TBLPROPERTIES Anweisung CREATE TABLE or, um die SerDe parquet.ignore.statistics Parquet-Eigenschaft auf zu setzentrue, wie in den folgenden Beispielen.

Beispiel für CREATE TABLE

...
ROW FORMAT SERDE  
'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' 
WITH SERDEPROPERTIES ('parquet.ignore.statistics'='true')  
STORED AS PARQUET 
...

Beispiel für ALTER TABLE

ALTER TABLE ... SET TBLPROPERTIES ('parquet.ignore.statistics'='true')

Weitere Informationen zu Parquet Hive finden Sie SerDe unter. Parkett SerDe

Partitionierungsprobleme

MSCK REPAIR TABLE entfernt keine veralteten Partitionen

Wenn Sie eine Partition manuell in Amazon S3 löschen und dann MSCK REPAIR TABLE ausführen, erhalten Sie möglicherweise die Fehlermeldung Partitions missing from filesystem (Partitionen fehlen im Dateisystem). Dies tritt auf, weil MSCK REPAIR TABLE nicht veraltete Partitionen aus Tabellenmetadaten entfernt. Verwenden Sie ALTER TABLE DROP PARTITION, um die veralteten Partitionen manuell zu entfernen. Weitere Informationen finden Sie im Abschnitt „Fehlerbehebung“ des MSCK REPAIR TABLE-Themas.

Fehler MSCK REPAIR TABLE

Wenn einer bestimmten Tabelle eine große Anzahl von Partitionen (z. B. mehr als 100.000) zugeordnet ist, kann MSCK REPAIR TABLE aufgrund von Speicherbeschränkungen fehlschlagen. Verwenden Sie stattdessen ALTER TABLE ADD PARTITION, um dieses Limit zu umgehen.

MSCK REPAIR TABLE erkennt Partitionen, fügt sie aber nicht hinzu AWS Glue

Dieses Problem kann auftreten, wenn ein Amazon-S3-Pfad in Camel statt in Kleinbuchstaben angegeben ist oder eine IAM-Richtlinie die Aktion glue:BatchCreatePartition nicht zulässt. Weitere Informationen finden Sie unter MSCK REPAIR TABLE erkennt Partitionen in Athena, fügt sie aber nicht zu den AWS Glue Data Catalog im AWS Knowledge Center hinzu.

Partitionsprojektionsbereiche mit dem Datumsformat dd-MM-yyyy-HH -mm-ss oder funktionieren nicht yyyy-MM-dd

Um korrekt zu funktionieren, muss das Datumsformat auf yyyy-MM-dd HH:00:00 eingestellt sein. Weitere Informationen finden Sie im Stack-Überlauf-Beitrag Athena-Partitionsprojektion funktioniert nicht wie erwartet.

PARTITION BY unterstützt den BIGINT-Typ nicht

Konvertieren Sie den Datentyp in stringund versuchen Sie es erneut.

Keine aussagekräftigen Partitionen verfügbar

Diese Fehlermeldung bedeutet in der Regel, dass die Partitionseinstellungen beschädigt wurden. Um dieses Problem zu beheben, löschen Sie die Tabelle und erstellen Sie eine Tabelle mit neuen Partitionen.

Partitionsprojektion funktioniert nicht in Verbindung mit Bereichspartitionen

Vergewissern Sie sich, dass die Projektion des Zeitbereichs eine Einheit darstellt. <columnName>.interval.unit entspricht dem Trennzeichen für die Partitionen. Wenn Partitionen beispielsweise durch Tage getrennt sind, funktioniert eine Bereichseinheit von Stunden nicht.

Fehler bei der Partitionsprojektion, wenn der Bereich mit einem Bindestrich angegeben wird

Die Angabe der range Tabelleneigenschaft mit einem Bindestrich anstelle eines Kommas erzeugt einen Fehler wie INVALID_TABLE_PROPERTY: Für die Eingabezeichenfolge: "-". number number Beachten Sie, dass die Werte durch Kommata voneinander getrennt werden müssen, nicht durch einen Bindestrich. Weitere Informationen finden Sie unter Ganzzahl-Typ.

HIVE_UNKNOWN_ERROR: Eingabeformat kann nicht erstellt werden

Eine oder mehrere der Glue-Partitionen werden in einem anderen Format deklariert, da jede Glue-Partition unabhängig über ihr eigenes spezifisches Eingabeformat verfügt. Bitte überprüfen Sie, wie Ihre Partitionen in definiert sind. AWS Glue

HIVE_PARTITION_SCHEMA_MISMATCH

Unterscheidet sich das Schema einer Partition vom Schema der Tabelle, kann eine Abfrage mit der Fehlermeldung HIVE_PARTITION_SCHEMA_MISMATCH fehlschlagen.

Für jede Tabelle im AWS Glue Datenkatalog, die Partitionsspalten enthält, wird das Schema auf Tabellenebene und für jede einzelne Partition innerhalb der Tabelle gespeichert. Das Schema für Partitionen wird von einem AWS Glue Crawler auf der Grundlage der Datenstichprobe aufgefüllt, die er innerhalb der Partition liest.

Wenn Athena eine Abfrage ausführt, werden das Schema der Tabelle und das Schema der für die Abfrage erforderlichen Partitionen geprüft. Dabei werden die Spaltendatentypen der Reihe nach verglichen und es wird sichergestellt, dass sie für überlappende Spalten übereinstimmen. So wird verhindert, dass es zu unerwartetem Hinzufügen oder Entfernen von Spalten in der Mitte der Tabelle kommt. Wenn Athena erkennt, dass das Schema einer Partition vom Schema der Tabelle abweicht, kann Athena die Abfrage nicht verarbeiten und bricht mit dem Fehler HIVE_PARTITION_SCHEMA_MISMATCH ab.

Es gibt mehrere Möglichkeiten, dieses Problem zu beheben. Wenn die Daten versehentlich hinzugefügt wurden, können Sie die Datendateien, die zu der Schemaabweichung geführt haben, entfernen, die Partition verwerfen und die Daten erneut durchsuchen. Sie können auch die einzelne Partition verwerfen und dann mit Athena MSCK REPAIR ausführen, um die Partition mit dem Schema der Tabelle neu zu erstellen. Diese zweite Option funktioniert jedoch nur, wenn Sie sicher sind, dass das angewendete Schema die Daten weiterhin korrekt ausliest.

SemanticException Die Tabelle ist nicht partitioniert, aber die Partitionsspezifikation ist vorhanden

Dieser Fehler kann auftreten, wenn in der CREATE TABLE-Anweisung keine Partitionen definiert wurden. Weitere Informationen finden Sie unter Wie kann ich den Fehler „FAILED: SemanticException table is not partitioned but partition spec exists“ in Athena beheben? im Knowledge Center AWS .

Null Byte _$folder$-Datei

Wenn du eine ALTER TABLE ADD PARTITION-Anweisung ausführst und fälschlicherweise eine Partition angibts, die bereits vorhanden ist, und einen falschen Ort für Simple Storage Service (Amazon S3), Null-Byte-Platzhalterdateien des Formats partition_value_$folder$ werden in Simple Storage Service (Amazon S3) erstellt. Sie müssen diese Dateien manuell entfernen.

Um dies zu verhindern, verwenden Sie die ADD IF NOT EXISTS-Syntax in Ihrer ALTER TABLE ADD PARTITION-Aussage, wie folgt:

ALTER TABLE table_name ADD IF NOT EXISTS PARTITIION […]

Aus partitionierten Daten zurückgegebene Datensätze

Dieses Problem kann aus einer Vielzahl von Gründen auftreten. Mögliche Ursachen und Lösungen finden Sie unter Ich habe in Amazon Athena eine Tabelle mit definierten Partitionen erstellt, aber wenn ich die Tabelle abfrage, werden im AWS Knowledge Center keine Datensätze zurückgegeben.

Siehe auch HIVE_TOO_MANY_OPEN_PARTITIONS.

Berechtigungen

Zugriffsverweigerter Fehler beim Abfragen von Amazon S3

Dies kann auftreten, wenn Sie nicht über die Berechtigung zum Lesen der Daten im Bucket oder zum Schreiben in den Ergebnis-Bucket verfügen oder der Amazon-S3-Pfad einen Regionsendpunkt wie us-east-1.amazonaws.com enthält. Weitere Informationen finden Sie unter Wenn ich eine Athena-Abfrage ausführe, erhalte ich die Fehlermeldung „Zugriff verweigert“ im AWS -Wissenscenter.

Zugriff verweigert mit Statuscode: 403 Fehler beim Ausführen von DDL-Abfragen für verschlüsselte Daten in Amazon S3

Wenn Sie möglicherweise die Fehlermeldung Zugriff verweigert (Service: Amazon S3; Statuscode: 403; Fehlercode:; AccessDenied Anforderungs-ID:<request_id>) erhalten, wenn die folgenden Bedingungen zutreffen:

  1. Sie führen eine DDL-Abfrage wie ALTER TABLE ADD PARTITIONoder MSCK REPAIR TABLE aus.

  2. Sie haben einen Bucket, dessen Standardverschlüsselung für die Verwendung von SSE-S3 konfiguriert ist.

  3. Der Bucket verfügt auch über eine Bucket-Richtlinie wie die folgende, die PutObject-Anforderungen erzwingt, die PUT-Header "s3:x-amz-server-side-encryption": "true" und "s3:x-amz-server-side-encryption": "AES256" anzugeben.

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::<resource-name>/*",
            "Condition": {
                "Null": {
                    "s3:x-amz-server-side-encryption": "true"
                }
            }
        },
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::<resource-name>/*",
            "Condition": {
                "StringNotEquals": {
                    "s3:x-amz-server-side-encryption": "AES256"
                }
            }
        }
    ]
}

In einem solchen Fall besteht die empfohlene Lösung darin, die Bucket-Richtlinie wie die oben genannte zu entfernen, da die Standardverschlüsselung des Buckets bereits vorhanden ist.

Zugriff verweigert mit Statuscode: 403 beim Abfragen eines Amazon-S3-Buckets in einem anderen Konto

Dieser Fehler kann auftreten, wenn Sie versuchen, Logs abzufragen, die von einem anderen Konto geschrieben wurden AWS-Service und das zweite Konto zwar der Bucket-Besitzer ist, aber nicht Eigentümer der Objekte im Bucket ist. Weitere Informationen finden Sie im AWS Knowledge Center unter Ich erhalte die Amazon S3 S3-Ausnahme „Zugriff verweigert mit Statuscode: 403“ in Amazon Athena, wenn ich einen Bucket in einem anderen Konto abfrage.

IAM-Rollenanmeldeinformationen zum Herstellen einer Verbindung mit dem Athena-JDBC-Treiber

Sie können die temporären Anmeldeinformationen einer Rolle abrufen, um die JDBC-Verbindung zu Athena zu authentifizieren. Temporäre Anmeldeinformationen haben eine maximale Lebensdauer von 12 Stunden. Weitere Informationen finden Sie unter Wie kann ich meine IAM-Rollenanmeldedaten verwenden oder zu einer anderen IAM-Rolle wechseln, wenn ich mit dem JDBC-Treiber eine Verbindung zu Athena herstelle? im Knowledge Center. AWS

Der erforderliche Tabellenspeicherdeskriptor ist nicht gefüllt

Dies kann auftreten, wenn Sie versuchen, eine Tabelle abzufragen oder anzuzeigen, für die Sie keine Berechtigungen haben. Zu diesem Zweck besteht die empfohlene Lösung darin, SELECT Berechtigungen DESCRIBE für die Ressourcen über zu erteilen AWS Lake Formation. Wenn Ihre Ressource von mehreren Konten gemeinsam genutzt wird, wobei die ursprüngliche Ressource in Konto A vorhanden ist und Sie eine verknüpfte Ressource in Konto B abfragen möchten, müssen Sie sicherstellen, dass Ihre Rolle über DESCRIBE Berechtigungen für die ursprüngliche Ressource in Konto A und über SELECT Berechtigungen für die verknüpfte Ressource in Konto B verfügt.

Probleme mit der Abfragesyntax

FEHLGESCHLAGEN: NullPointerException Name ist Null

Wenn Sie die AWS Glue CreateTableAPI-Operation oder die AWS CloudFormation AWS::Glue::TableVorlage verwenden, um eine Tabelle für die Verwendung in Athena zu erstellen, ohne die TableType Eigenschaft anzugeben, und dann eine DDL-Abfrage wie SHOW CREATE TABLE oder ausführenMSCK REPAIR TABLE, können Sie die Fehlermeldung FAILED: NullPointerException Name is null erhalten.

Um den Fehler zu beheben, geben Sie im Rahmen des AWS GlueCreateTable API-Aufrufs oder AWS CloudFormation der Vorlage einen Wert für das TableInputTableTypeAttribut an. Mögliche Werte für TableType sind EXTERNAL_TABLE oder VIRTUAL_VIEW.

Diese Anforderung gilt nur, wenn Sie eine Tabelle mithilfe der AWS Glue CreateTable API-Operation oder der AWS::Glue::Table Vorlage erstellen. Wenn Sie eine Tabelle für Athena mithilfe einer DDL-Anweisung oder eines AWS Glue -Crawlers erstellen, wird die TableType-Eigenschaft automatisch für Sie definiert.

Funktion nicht registriert

Dieser Fehler tritt auf, wenn Sie versuchen, eine Funktion zu verwenden, die Athena nicht unterstützt. Eine Liste der von Athena unterstützten Funktionen finden Sie unter Funktionen in Amazon Athena oder führen Sie die SHOW FUNCTIONS-Anweisung im Abfrage-Editor aus. Sie können auch Ihre eigene benutzerdefinierte Funktion (UDF) schreiben. Weitere Informationen finden Sie unter Wie behebe ich den Syntaxfehler „Funktion nicht registriert“ in Athena? im AWS -Wissenscenter.

GENERIC_INTERNAL_ERROR Ausnahmen

GENERIC_INTERNAL_ERROR-Ausnahmen können verschiedene Ursachen haben, z. B. die folgenden:

  • GENERIC_INTERNAL_ERROR: null – Sie können diese Ausnahme unter den folgenden Bedingungen sehen:

    • Sie haben eine Schema-Nichtübereinstimmung zwischen dem Datentyp einer Spalte in der Tabellendefinition und dem tatsächlichen Datentyp des Datensatzes.

    • So leiten Sie eine CREATE TABLE AS SELECT(CTAS)-Abfrage mit ungenauer Syntax ein.

  • GENERIC_INTERNAL_ERROR: Parent Builder ist Null — Diese Ausnahme tritt möglicherweise auf, wenn Sie eine Tabelle mit Spalten des Datentyps abfragen und die Open array De-Bibliothek verwenden. CSVSer Das CSVSerde Open-Format unterstützt den Datentyp nicht. array

  • GENERIC_INTERNAL_ERROR: Wert überschreitet MAX_INT – Diese Ausnahme wird möglicherweise angezeigt, wenn die Quelldatenspalte mit dem Datentyp INT definiert ist und einen numerischen Wert größer als 2.147.483.647 hat.

  • GENERIC_INTERNAL_ERROR: Wert überschreitet MAX_BYTE – Diese Ausnahme wird möglicherweise angezeigt, wenn die Quelldatenspalte einen numerischen Wert aufweist, der die zulässige Größe für den Datentyp BYTE überschreitet. Der Datentyp BYTE ist gleich TINYINT. TINYINT ist eine 8-Bit-Vorzeichen-Ganzzahl im Zweierkomplement-Format mit einem Mindestwert von -128 und einem Höchstwert von 127.

  • GENERIC_INTERNAL_ERROR: Die Anzahl der Partitionswerte stimmt nicht mit der Anzahl der Filter überein – Diese Ausnahme wird möglicherweise angezeigt, wenn Sie inkonsistente Partitionen für Amazon Simple Storage Service (Amazon S3)-Daten haben. Unter den folgenden Bedingungen haben Sie möglicherweise inkonsistente Partitionen:

    • Partitionen auf Amazon S3 haben sich geändert (Beispiel: Neue Partitionen wurden hinzugefügt).

    • Die Anzahl der Partitionsspalten in der Tabelle stimmt nicht mit denen in den Partitionsmetadaten überein.

Ausführlichere Informationen zu jedem dieser Fehler finden Sie unter Wie behebe ich den Fehler „GENERIC_INTERNAL_ERROR“, wenn ich eine Tabelle in Amazon Athena abfrage? im Knowledge Center. AWS

Anzahl übereinstimmender Gruppen stimmt nicht mit der Anzahl der Spalten überein

Dieser Fehler tritt auf, wenn Sie das Regex SerDe in einer CREATE-TABLE-Anweisung verwenden und die Anzahl der Regex-Übereinstimmungsgruppen nicht mit der Anzahl der Spalten übereinstimmt, die Sie für die Tabelle angegeben haben. Weitere Informationen finden Sie unter Wie behebe ich den RegexSerDe Fehler „Anzahl der passenden Gruppen entspricht nicht der Anzahl der Spalten“ in Amazon Athena? im AWS Knowledge Center.

queryString konnte Einschränkung nicht erfüllen: Mitglied muss eine Länge von höchstens 262144 haben

Die maximale Länge der Abfragezeichenfolge in Athena (262.144 Byte) ist kein einstellbares Kontingent. AWS -Support kann das Kontingent nicht für Sie erhöhen, aber Sie können das Problem umgehen, indem Sie lange Abfragen in kleinere aufteilen. Weitere Informationen finden Sie unter Wie kann ich die maximale Abfragezeichenfolgenlänge in Athena erhöhen? im AWS -Wissenscenter.

SYNTAX_ERROR: Spalte kann nicht gelöst werden

Dieser Fehler kann auftreten, wenn Sie eine von einem AWS Glue Crawler erstellte Tabelle anhand einer UTF-8-codierten CSV-Datei mit einer Bytereihenfolge-Markierung (BOM) abfragen. AWS Glue erkennt die nicht BOMs und ändert sie in Fragezeichen, die Amazon Athena nicht erkennt. Die Lösung besteht darin, das Fragezeichen in Athena oder in AWS Glue zu entfernen.

Zu viele Argumente für den Funktionsaufruf

In Athena-Engine-Version 3 können Funktionen nicht mehr als 127 Argumente akzeptieren. Diese Einschränkung ist konstruktionsbedingt. Wenn Sie eine Funktion mit mehr als 127 Parametern verwenden, wird eine Fehlermeldung wie die folgende angezeigt:

TOO_MANY_ARGUMENTS: line: nnnnn: Zu viele Argumente für die Funktion call (). function_name

Sie lösen dieses Problem, indem Sie weniger Parameter pro Funktionsaufruf verwenden.

Probleme mit dem Abfrage-Timeout

Wenn bei Ihren Athena-Abfragen Timeout-Fehler auftreten, überprüfen Sie Ihre CloudTrail Protokolle. Bei Abfragen kann es aufgrund von Drosselung AWS Glue oder Lake Formation zu Timeouts kommen. APIs Wenn diese Fehler auftreten, können die entsprechenden Fehlermeldungen eher auf ein Problem mit dem Abfrage-Timeout als auf ein Drosselungsproblem hinweisen. Um das Problem zu beheben, können Sie Ihre CloudTrail Protokolle überprüfen, bevor Sie Kontakt aufnehmen. Support Weitere Informationen erhalten Sie unter AWS CloudTrail Logs abfragen und Amazon Athena API Athena-Anrufe protokollieren mit AWS CloudTrail.

Informationen zu Problemen mit dem Abfrage-Timeout bei Verbundabfragen beim Aufrufen der ListTableMetadata-API finden Sie unter Timeout beim Telefonieren ListTableMetadata.

Probleme mit Drosselung

Wenn Ihre Abfragen die Grenzwerte abhängiger Dienste wie Amazon S3, AWS KMS AWS Glue, oder überschreiten AWS Lambda, sind die folgenden Meldungen zu erwarten. Um diese Probleme zu beheben, reduzieren Sie die Anzahl der gleichzeitigen Anrufe, die von demselben Konto stammen.

Service Fehlermeldung
AWS Glue AWSGlueAusnahme: Rate überschritten.
AWS KMS Sie haben die Rate überschritten, mit der Sie KMS aufrufen können. Verringern Sie die Häufigkeit Ihrer Aufrufe.
AWS Lambda

Quote überschritten.

TooManyRequestsException
Amazon S3 Amazons3Exception: Bitte reduzieren Sie Ihre Anfragequote.

Informationen darüber, wie Sie die Drosselung von Amazon S3 bei der Verwendung von Athena verhindern können, finden Sie unter Drosselung durch Amazon S3 verhindern.

Ansichten

Ansichten, die in der Apache-Hive-Shell erstellt wurden, funktionieren in Athena nicht

Aufgrund ihrer grundlegend unterschiedlichen Implementierungen sind Ansichten, die in der Apache-Hive-Shell erstellt wurden, nicht mit Athena kompatibel. Um dieses Problem zu beheben, erstellen Sie die Ansichten in Athena erneut.

Ansicht ist veraltet; sie muss neu erstellt werden

Sie können diesen Fehler erhalten, wenn die Tabelle, die einer Ansicht zugrunde liegt, geändert oder gelöscht wurde. Die Auflösung besteht darin, die Ansicht neu zu erstellen. Weitere Informationen finden Sie unter Wie kann ich den Fehler „Ansicht ist veraltet; sie muss neu erstellt werden“ in Athena beheben? im Knowledge Center AWS .

Arbeitsgruppen

Informationen zum Beheben von Problemen mit Arbeitsgruppen finden Sie unter Beheben Sie Arbeitsgruppenfehler.

Weitere Ressourcen

Auf den folgenden Seiten finden Sie zusätzliche Informationen zur Behebung von Problemen mit Amazon Athena.

Die folgenden AWS Ressourcen können ebenfalls hilfreich sein:

Die Fehlerbehebung erfordert oft eine iterative Abfrage und Erkennung durch einen Experten oder eine Community von Helfern. Wenn Sie nach dem Ausprobieren der Vorschläge auf dieser Seite weiterhin Probleme haben, wenden Sie sich an AWS -Support (klicken Sie auf Support AWS Management Console, Support Center) oder stellen Sie mithilfe des Amazon Athena Athena-Tags eine Frage auf AWS re:POST.