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.

# Optimieren der Leistung von Athena
<a name="performance-tuning"></a>

Dieses Thema enthält allgemeine Informationen und spezifische Vorschläge zur Verbesserung der Leistung Ihrer Athena-Abfragen und zur Umgehung von Fehlern im Zusammenhang mit Beschränkungen und der Ressourcennutzung.

Im Großen und Ganzen können Optimierungen in Service-, Abfrage- und Datenstrukturkategorien eingeteilt werden. Entscheidungen, die auf Serviceebene getroffen werden, darüber, wie Sie Ihre Abfragen schreiben und wie Sie Ihre Daten und Tabellen strukturieren, können sich alle auf die Leistung auswirken.

**Topics**
+ [

# Nutzung des Dienstes optimieren
](performance-tuning-service-level-considerations.md)
+ [

# Abfragen optimieren
](performance-tuning-query-optimization-techniques.md)
+ [

# Daten optimieren
](performance-tuning-data-optimization-techniques.md)
+ [

# Spaltenbasierte Speicherformate verwenden
](columnar-storage.md)
+ [

# Partitionierung und Bucketing verwenden
](ctas-partitioning-and-bucketing.md)
+ [

# Ihre Daten partitionieren
](partitions.md)
+ [

# Partitionsprojektion mit Amazon Athena verwenden
](partition-projection.md)
+ [

# Drosselung durch Amazon S3 verhindern
](performance-tuning-s3-throttling.md)
+ [

# Weitere Ressourcen
](performance-tuning-additional-resources.md)

# Nutzung des Dienstes optimieren
<a name="performance-tuning-service-level-considerations"></a>

Zu den Überlegungen zum Service Level gehören die Anzahl der Workloads, die Sie pro Konto ausführen, Service Quotas nicht nur für Athena, sondern für alle Dienste sowie Überlegungen zur Reduzierung von Fehlern „Nicht genügend Ressourcen“.

**Topics**
+ [

## Mehrere Workloads innerhalb desselben Kontos betreiben
](#performance-tuning-service-quotas)
+ [

## Reduzieren Sie Fehler „Nicht genügend Ressourcen“
](#performance-tuning-resource-limits)

## Mehrere Workloads innerhalb desselben Kontos betreiben
<a name="performance-tuning-service-quotas"></a>

Athena verwendet Kontingente, um die Parallelität von Abfragen und die API-Anforderungsraten auf Kontoebene zu begrenzen. Eine Überschreitung dieser Kontingente kann dazu führen, dass Abfragen während der Ausführung oder bei der Übermittlung fehlschlagen. Weitere Hinweise zu diesen Kontingenten finden Sie unter [Service Quotas](service-limits.md). 

Wenn Sie mehrere Workloads innerhalb desselben AWS Kontos betreiben, konkurrieren Ihre Workloads um dasselbe Kontingent auf Kontoebene. Wenn beispielsweise bei einem Workload ein unerwarteter Anstieg von Abfragen auftritt, kann es bei einem anderen Workload, der auf demselben Konto ausgeführt wird, zu erhöhten Wartezeiten kommen, oder im schlimmsten Fall schlägt die Abfrageübermittlung aufgrund von Drosselung fehl.

Wir empfehlen Ihnen, die Nutzung Ihrer Dienste mithilfe von Grafiken und Dashboards CloudWatch zu überwachen. Sie können auch CloudWatch Alarme konfigurieren, die Sie benachrichtigen, wenn sich Ihre Nutzung dem Servicekontingent für gleichzeitige Abfragen nähert, sodass Sie Maßnahmen ergreifen können, bevor die Kontingentgrenzen erreicht werden. Weitere Informationen finden Sie unter [Überwachen Sie die Nutzungsmetriken von Athena mit CloudWatch](monitoring-athena-usage-metrics.md).

Verwenden Sie Kapazitätsreservierungen, um die Gleichzeitigkeit von Abfragen zu kontrollieren und Workloads innerhalb Ihres Kontos zu isolieren. Kapazitätsreservierungen bieten dedizierte Kapazität zur Abfrageverarbeitung innerhalb eines einzigen Kontos. Die Kapazität wird in Datenverarbeitungseinheiten (DPUs) gemessen und kann hinzugefügt oder entfernt werden, um die Parallelität von Abfragen zu erhöhen bzw. zu verringern. Kapazitätsreservierungen ermöglichen Ihnen Workloads innerhalb Ihres Kontos voneinander zu isolieren, indem Sie einer oder mehreren Arbeitsgruppen Kapazität zuweisen. Weitere Informationen finden Sie unter [Kapazität zur Abfrageverarbeitung verwalten](capacity-management.md).

Sie sollten zwar Workloads, die nicht miteinander in Beziehung stehen, in verschiedenen AWS Konten isolieren (z. B. wenn Sie Entwicklungs- und Produktionsumgebungen isolieren), aber dieser Ansatz bietet keine skalierbare Möglichkeit, die Parallelität von Abfragen zu erhöhen. Verwenden Sie stattdessen Kapazitätsreservierungen, um Ihre Anforderungen an die Abfrageverarbeitung innerhalb eines einzigen Kontos zu verwalten und zu skalieren.

### Kontingente in anderen Diensten in Betracht ziehen
<a name="performance-tuning-quotas-in-other-services"></a>

Wenn Athena eine Abfrage ausführt, kann es andere Services aufrufen, die Kontingente durchsetzen. Während der Abfrageausführung kann Athena API-Aufrufe an Amazon S3 und andere AWS Dienste wie IAM und tätigen. AWS Glue Data Catalog AWS KMS Wenn Sie [föderierte Abfragen verwenden, ruft](federated-queries.md) Athena auch auf. AWS Lambda Alle diese Services haben ihre eigenen Grenzwerte und Kontingente, die überschritten werden können. Wenn bei der Ausführung einer Abfrage Fehler von diesen Services auftreten, schlägt sie fehl und schließt den Fehler des Quellservices mit ein. Behebbare Fehler werden wiederholt, aber Abfragen können trotzdem fehlschlagen, wenn sich das Problem nicht rechtzeitig von selbst löst. Lesen Sie sich die Fehlermeldungen sorgfältig durch, um festzustellen, ob sie von Athena oder einem anderen Service stammen. Einige der relevanten Fehler werden in diesem Abschnitt zur Leistungsoptimierung behandelt.

Weitere Informationen zur Umgehung von Fehlern, die durch Amazon-S3-Servicekontingente verursacht werden, finden Sie unter [Zu viele Dateien vermeiden](performance-tuning-data-optimization-techniques.md#performance-tuning-avoid-having-too-many-files) weiter unten in diesem Dokument. Weitere Informationen zur Amazon-S3-Leistungsoptimierung finden Sie unter [Bewährte Entwurfsmuster: Optimierung der Leistung von Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) im *Amazon-S3-Benutzerhandbuch*.

## Reduzieren Sie Fehler „Nicht genügend Ressourcen“
<a name="performance-tuning-resource-limits"></a>

Athena führt Abfragen in einer verteilten Abfrage-Engine aus. Wenn Sie eine Abfrage einreichen, schätzt der Athena-Engine-Abfrageplaner die Rechenkapazität, die für die Ausführung der Abfrage erforderlich ist, und bereitet entsprechend einen Cluster von Rechenknoten vor. Einige Abfragen wie DDL-Abfragen werden nur auf einem Knoten ausgeführt. Komplexe Abfragen über große Datensätze werden auf viel größeren Clustern ausgeführt. Die Knoten sind einheitlich und haben dieselben Speicher-, CPU- und Festplattenkonfigurationen. Athena aufskaliert, nicht ab, um anspruchsvollere Anfragen zu bearbeiten.

Manchmal übersteigen die Anforderungen einer Abfrage die Ressourcen, die dem Cluster zur Verfügung stehen, auf dem die Abfrage ausgeführt wird. In diesem Fall schlägt die Abfrage fehl und es wird folgende Fehlermeldung angezeigt: Abfrage erschöpfte Ressourcen mit diesem Skalierungsfaktor.

Die am häufigsten erschöpfte Ressource ist Arbeitsspeicher, in seltenen Fällen kann es sich aber auch um Festplattenspeicher handeln. Speicherfehler treten häufig auf, wenn die Engine eine Join- oder Fensterfunktion ausführt. Sie können jedoch auch in unterschiedlichen Zählungen und Aggregationen auftreten.

Selbst wenn eine Abfrage einmal mit dem Fehler „Nicht genügend Ressourcen“ fehlschlägt, kann sie erfolgreich sein, wenn Sie sie erneut ausführen. Die Abfrageausführung ist nicht deterministisch. Faktoren wie die Dauer des Ladens von Daten und die Verteilung der Zwischendatensätze auf die Knoten können zu einer unterschiedlichen Ressourcennutzung führen. Stellen Sie sich beispielsweise eine Abfrage vor, die zwei Tabellen miteinander verbindet und die Verteilung der Werte für die Join-Bedingung stark verzerrt ist. Eine solche Abfrage kann in den meisten Fällen erfolgreich sein, schlägt aber gelegentlich fehl, wenn die häufigsten Werte von demselben Knoten verarbeitet werden.

Verwenden Sie die in diesem Dokument genannten Tipps zur Leistungsoptimierung, um zu verhindern, dass Ihre Abfragen die verfügbaren Ressourcen überschreiten. Insbesondere Tipps zur Optimierung von Abfragen, die die verfügbaren Ressourcen erschöpfen, finden Sie unter [Verknüpfungen optimieren](performance-tuning-query-optimization-techniques.md#performance-tuning-optimizing-joins), [Umfang der Fensterfunktionen reduzieren oder diese entfernen](performance-tuning-query-optimization-techniques.md#performance-tuning-optimizing-window-functions) und [Optimieren von Abfragen mithilfe von Näherungen](performance-tuning-query-optimization-techniques.md#performance-tuning-optimizing-queries-by-using-approximations). 

# Abfragen optimieren
<a name="performance-tuning-query-optimization-techniques"></a>

Verwenden Sie die in diesem Abschnitt beschriebenen Techniken zur Abfrageoptimierung, um Abfragen schneller ausführen zu lassen oder um das Problem für Abfragen zu umgehen, die die Ressourcenlimits in Athena überschreiten.

## Verknüpfungen optimieren
<a name="performance-tuning-optimizing-joins"></a>

Es gibt viele verschiedene Strategien für die Ausführung von Verknüpfungen in einer verteilten Abfrage-Engine. Zwei der gängigsten sind verteilte Hash-Joins und Abfragen mit komplexen Join-Bedingungen.

### Bei einem verteilten Hash-Join, große Tabellen links und kleine Tabellen rechts platzieren
<a name="performance-tuning-distributed-hash-join"></a>

Der gebräuchlichste Join-Typ verwendet einen Gleichheitsvergleich als Join-Bedingung. Athena führt diese Art von Join als verteilten Hash-Join aus.

Bei einem verteilten Hash-Join erstellt die Engine aus einer der Seiten des Joins eine Nachschlagetabelle (Hashtabelle). Diese Seite wird die *Build-Seite* genannt. Die Datensätze der Build-Seite sind auf die Knoten verteilt. Jeder Knoten erstellt eine Nachschlagetabelle für seine Teilmenge. Die andere Seite des Joins, die so genannte *Test-Seite*, wird dann durch die Knoten gestreamt. Die Datensätze von der Testseite werden auf die gleiche Weise wie auf der Build-Seite auf die Knoten verteilt. Auf diese Weise kann jeder Knoten die Verknüpfung durchführen, indem er die entsprechenden Datensätze in seiner eigenen Nachschlagetabelle nachschlägt.

Wenn die auf der Build-Seite der Verknüpfung erstellten Nachschlagetabellen nicht in den Arbeitsspeicher passen, können Abfragen fehlschlagen. Selbst wenn die Gesamtgröße der Build-Seite kleiner als der verfügbare Speicher ist, können Abfragen fehlschlagen, wenn die Verteilung der Datensätze stark verzerrt ist. Im Extremfall könnten alle Datensätze denselben Wert für die Join-Bedingung haben und müssen in den Speicher eines einzelnen Knotens passen. Selbst eine Abfrage mit weniger Verzerrungen kann fehlschlagen, wenn ein Satz von Werten an denselben Knoten gesendet wird und die Summe der Werte den verfügbaren Speicher übersteigt. Knoten können zwar Datensätze auf die Festplatte übertragen, aber ein Datenverlust verlangsamt die Abfrageausführung und kann nicht ausreichen, um zu verhindern, dass die Abfrage fehlschlägt.

Athena versucht, Verbindungen neu anzuordnen, um die größere Relation als Testseite und die kleinere Relation als Build-Seite zu verwenden. Da Athena die Daten in Tabellen jedoch nicht verwaltet, verfügt es nur über begrenzte Informationen und muss häufig davon ausgehen, dass die erste Tabelle größer und die zweite Tabelle kleiner ist.

Gehen Sie beim Schreiben von Verknüpfungen mit gleichheitsbasierten Join-Bedingungen davon aus, dass die Tabelle links vom `JOIN`-Schlüsselwort die Testseite und die Tabelle rechts die Build-Seite ist. Stellen Sie sicher, dass die rechte Tabelle, die Build-Seite, die kleinere der Tabellen ist. Wenn es nicht möglich ist, die Build-Seite der Verknüpfung so klein zu machen, dass sie in den Arbeitsspeicher passt, sollten Sie mehrere Abfragen ausführen, die Teilmengen der Build-Tabelle verknüpfen.

### EXPLAIN verwenden, um Abfragen mit komplexen Verknüpfungen zu analysieren
<a name="performance-tuning-other-join-types"></a>

Abfragen mit komplexen Verbindungsbedingungen (z. B. Abfragen, die `LIKE`, `>` oder andere Operatoren verwenden) sind häufig rechenintensiv. Im schlimmsten Fall muss jeder Datensatz von einer Seite der Verknüpfung mit jedem Datensatz auf der anderen Seite der Verknüpfung verglichen werden. Da die Ausführungszeit mit dem Quadrat der Anzahl der Datensätze wächst, besteht bei solchen Abfragen das Risiko, dass die maximale Ausführungszeit überschritten wird.

Um im Voraus herauszufinden, wie Athena Ihre Anfrage ausführt, können Sie die `EXPLAIN`-Anweisung verwenden. Weitere Informationen erhalten Sie unter [Verwenden von EXPLAIN und EXPLAIN ANALYZE in Athena](athena-explain-statement.md) und [Die Ergebnisse der Athena-EXPLAIN-Anweisung verstehen](athena-explain-statement-understanding.md).

## Umfang der Fensterfunktionen reduzieren oder diese entfernen
<a name="performance-tuning-optimizing-window-functions"></a>

Da es sich bei Fensterfunktionen um ressourcenintensive Vorgänge handelt, können sie dazu führen, dass Abfragen langsam ausgeführt werden oder sogar fehlschlagen und die Meldung Erschöpfte Ressourcen bei diesem Skalierungsfaktor abfragen angezeigt wird. Fensterfunktionen behalten alle Datensätze, mit denen sie arbeiten, im Speicher, um ihr Ergebnis zu berechnen. Wenn das Fenster sehr groß ist, kann der Speicherplatz der Fensterfunktion knapp werden.

Um sicherzustellen, dass Ihre Abfragen innerhalb der verfügbaren Speichergrenzen ausgeführt werden, reduzieren Sie die Größe der Fenster, in denen Ihre Fensterfunktionen ausgeführt werden. Dazu können Sie eine `PARTITIONED BY`-Klausel hinzufügen oder den Geltungsbereich vorhandener Partitionierungsklauseln einschränken.

### Verwenden Sie Funktionen die keine Fenster sind
<a name="performance-tuning-optimizing-window-functions-rewrite"></a>

Manchmal können Abfragen mit Fensterfunktionen ohne Fensterfunktionen neu geschrieben werden. So können Sie z. B. anstelle von `row_number` für die Suche nach den ersten `N` Datensätzen `ORDER BY` und `LIMIT` verwenden. Anstatt `row_number` oder `rank` zu verwenden, um Datensätze zu deduplizieren, können Sie Aggregatfunktionen wie [max\$1by](https://trino.io/docs/current/functions/aggregate.html#max_by), [min\$1by](https://trino.io/docs/current/functions/aggregate.html#min_by) und [arbiträr ](https://trino.io/docs/current/functions/aggregate.html#arbitrary)verwenden.

Nehmen wir zum Beispiel an, Sie haben einen Datensatz mit Aktualisierungen von einem Sensor. Der Sensor meldet regelmäßig seinen Batteriestatus und enthält einige Metadaten wie den Standort. Wenn Sie den letzten Batteriestatus für jeden Sensor und seinen Standort wissen möchten, können Sie diese Abfrage verwenden:

```
SELECT sensor_id,
       arbitrary(location) AS location,
       max_by(battery_status, updated_at) AS battery_status
FROM sensor_readings
GROUP BY sensor_id
```

Da Metadaten wie der Standort für jeden Datensatz identisch sind, können Sie die `arbitrary`-Funktion verwenden, um einen beliebigen Wert aus der Gruppe auszuwählen. 

Um den letzten Batteriestatus abzurufen, können Sie die `max_by`-Funktion verwenden. Die `max_by`-Funktion wählt den Wert für eine Spalte aus dem Datensatz aus, in dem der Maximalwert einer anderen Spalte gefunden wurde. In diesem Fall gibt sie den Batteriestatus für den Datensatz mit dem Zeitpunkt der letzten Aktualisierung innerhalb der Gruppe zurück. Diese Abfrage wird schneller ausgeführt und benötigt weniger Speicher als eine entsprechende Abfrage mit einer Fensterfunktion. 

## Aggregationen optimieren
<a name="performance-tuning-optimizing-aggregations"></a>

Wenn Athena eine Aggregation durchführt, verteilt es die Datensätze mithilfe der Spalten in der `GROUP BY`-Klausel auf die Worker-Knoten. Um die Zuordnung von Datensätzen zu Gruppen so effizient wie möglich zu gestalten, versuchen die Knoten, Datensätze im Speicher zu behalten, sie aber bei Bedarf auf die Festplatte zu übertragen.

Es ist auch eine gute Idee, die Aufnahme überflüssiger Spalten in `GROUP BY`-Klauseln zu vermeiden. Da weniger Spalten weniger Speicher benötigen, ist eine Abfrage, die eine Gruppe mit weniger Spalten beschreibt, effizienter. Numerische Spalten verbrauchen auch weniger Speicher als Zeichenketten. Wenn Sie beispielsweise einen Datensatz aggregieren, der sowohl eine numerische Kategorie-ID als auch einen Kategorienamen hat, verwenden Sie in der `GROUP BY`-Klausel nur die Kategorie-ID-Spalte.

Manchmal enthalten Abfragen Spalten in der `GROUP BY`-Klausel, um die Tatsache zu umgehen, dass eine Spalte entweder Teil der `GROUP BY`-Klausel oder ein Aggregatausdruck sein muss. Wenn diese Regel nicht befolgt wird, erhalten Sie möglicherweise eine Fehlermeldung wie die folgende:

 EXPRESSION\$1NOT\$1AGGREGATE: Zeile 1:8: 'Kategorie' muss ein Aggregatausdruck sein oder in der GROUP-BY-Klausel vorkommen 

Um zu vermeiden, dass der `GROUP BY`-Klausel redundante Spalten hinzugefügt werden müssen, können Sie die [arbitrary](https://trino.io/docs/current/functions/aggregate.html#arbitrary)-Funktion verwenden, wie im folgenden Beispiel.

```
SELECT country_id,
       arbitrary(country_name) AS country_name,
       COUNT(*) AS city_count
FROM world_cities
GROUP BY country_id
```

Die `ARBITRARY`-Funktion gibt einen beliebigen Wert aus der Gruppe zurück. Die Funktion ist nützlich, wenn Sie wissen, dass alle Datensätze in der Gruppe denselben Wert für eine Spalte haben, der Wert die Gruppe jedoch nicht identifiziert.

## Die wichtigsten N-Abfragen optimieren
<a name="performance-tuning-optimizing-top-n-queries"></a>

Die `ORDER BY`-Klausel gibt die Ergebnisse einer Abfrage in sortierter Reihenfolge zurück. Athena verwendet verteilte Sortierung, um den Sortiervorgang parallel auf mehreren Knoten auszuführen.

Wenn Sie nicht unbedingt möchten, dass Ihr Ergebnis sortiert wird, vermeiden Sie das Hinzufügen einer `ORDER BY`-Klausel. Vermeiden Sie auch, innere Abfragen mit `ORDER BY` zu versehen, wenn sie nicht unbedingt notwendig sind. In vielen Fällen kann der Abfrageplaner überflüssige Sortierungen entfernen, dies kann jedoch nicht garantiert werden. Eine Ausnahme von dieser Regel ist, wenn eine interne Abfrage einen wichtigen `N`-Vorgang ausführt, z. B. die Suche nach den `N` neuesten oder `N` gängigsten Werten.

Wenn Athena `ORDER BY` zusammen mit `LIMIT` sieht, versteht es, dass Sie eine `N`-Top-Abfrage ausführen, und verwendet entsprechend dedizierte Vorgänge.

**Anmerkung**  
Obwohl Athena häufig auch Fensterfunktionen wie `row_number`, die Top-`N` verwendet, erkennen kann, empfehlen wir die einfachere Version, die `ORDER BY` und `LIMIT` verwendet. Weitere Informationen finden Sie unter [Umfang der Fensterfunktionen reduzieren oder diese entfernen](#performance-tuning-optimizing-window-functions).

## Nur die erforderlichen Spalten einschließen
<a name="performance-tuning-include-only-required-columns"></a>

Wenn Sie eine Spalte nicht unbedingt benötigen, nehmen Sie sie nicht in Ihre Abfrage auf. Je weniger Daten eine Abfrage verarbeiten muss, desto schneller wird sie ausgeführt. Dies reduziert sowohl den benötigten Speicher als auch die Datenmenge, die zwischen den Knoten gesendet werden muss. Wenn Sie ein spaltenorientiertes Dateiformat verwenden, reduziert die Reduzierung der Anzahl der Spalten auch die Datenmenge, die aus Amazon S3 gelesen wird.

Athena hat keine spezifische Begrenzung für die Anzahl der Spalten in einem Ergebnis, aber die Art und Weise, wie Abfragen ausgeführt werden, begrenzt die mögliche kombinierte Größe von Spalten. Die kombinierte Größe von Spalten umfasst ihre Namen und Typen.

Der folgende Fehler wird beispielsweise durch eine Beziehung verursacht, die die Größenbeschränkung für einen Beziehungsdeskriptor überschreitet:

 GENERIC\$1INTERNAL\$1ERROR: io.airlift.bytecode. CompilationException 

Um dieses Problem zu umgehen, reduzieren Sie die Anzahl der Spalten in der Abfrage, oder erstellen Sie Unterabfragen und verwenden Sie eine `JOIN`, die eine kleinere Datenmenge abruft. Wenn Sie Abfragen haben, die `SELECT *` in der äußersten Abfrage ausführen, sollten Sie die `*` in eine Liste mit nur den Spalten ändern, die Sie brauchen.

## Optimieren von Abfragen mithilfe von Näherungen
<a name="performance-tuning-optimizing-queries-by-using-approximations"></a>

Athena unterstützt [Näherungsaggregatfunktionen](https://trino.io/docs/current/functions/aggregate.html#appro) zum Zählen verschiedener Werte, der häufigsten Werte, Perzentile (einschließlich ungefährer Mediane) und zum Erstellen von Histogrammen. Verwenden Sie diese Funktionen immer dann, wenn keine exakten Werte benötigt werden.

Im Gegensatz zu `COUNT(DISTINCT col)`-Vorgängen benötigt [approx\$1distinct](https://trino.io/docs/current/functions/aggregate.html#approx_distinct) viel weniger Speicher und läuft schneller. In ähnlicher Weise werden bei der Verwendung von [numeric\$1histogram](https://trino.io/docs/current/functions/aggregate.html#numeric_histogram) anstelle von [Histogramm](https://trino.io/docs/current/functions/aggregate.html#histogram) Näherungsmethoden und damit weniger Speicher verwendet.

## LIKE optimieren
<a name="performance-tuning-optimizing-like"></a>

Sie können `LIKE` es verwenden, um passende Zeichenketten zu finden, aber bei langen Zeichenketten ist das rechenintensiv. Die Funktion [regexp\$1like](https://trino.io/docs/current/functions/regexp.html#regexp_like) ist in den meisten Fällen eine schnellere Alternative und bietet auch mehr Flexibilität.

Oft können Sie eine Suche optimieren, indem Sie die gesuchte Teilzeichenfolge verankern. Wenn Sie beispielsweise nach einem Präfix suchen, ist es viel besser, '%' anstelle von '% *substr* *substr* %' zu verwenden. Oder, wenn Sie '^' verwenden`regexp_like`. *substr*

## Verwenden Sie UNION ALL anstelle von UNION
<a name="performance-tuning-use-union-all-instead-of-union"></a>

 `UNION ALL` und `UNION` sind zwei Möglichkeiten, die Ergebnisse von zwei Abfragen zu einem Ergebnis zu kombinieren. `UNION ALL` verkettet die Datensätze aus der ersten Abfrage mit der zweiten und `UNION` macht dasselbe, entfernt aber auch Duplikate. `UNION` muss alle Datensätze verarbeiten und die Duplikate finden, was speicher- und rechenintensiv ist, aber `UNION ALL` ist ein relativ schneller Vorgang. Sofern Sie Datensätze nicht deduplizieren müssen, verwenden Sie `UNION ALL`, um die beste Leistung zu erzielen.

## Verwenden Sie UNLOAD für große Ergebnismengen
<a name="performance-tuning-use-unload-for-large-result-sets"></a>

Wenn die Ergebnisse einer Abfrage voraussichtlich umfangreich sein werden (z. B. Zehntausende von Zeilen oder mehr), verwenden Sie UNLOAD, um die Ergebnisse zu exportieren. In den meisten Fällen ist dies schneller als das Ausführen einer normalen Abfrage, und die Verwendung von `UNLOAD` gibt Ihnen auch mehr Kontrolle über die Ausgabe.

Wenn die Ausführung einer Abfrage abgeschlossen ist, speichert Athena das Ergebnis als einzelne unkomprimierte CSV-Datei auf Amazon S3. Dies dauert länger als `UNLOAD`, nicht nur, weil das Ergebnis unkomprimiert ist, sondern auch, weil der Vorgang nicht parallelisiert werden kann. Im Gegensatz dazu schreibt `UNLOAD` die Ergebnisse direkt von den Worker-Knoten und nutzt die Parallelität des Rechenclusters voll aus. Darüber hinaus können Sie `UNLOAD` so konfigurieren, dass die Ergebnisse in komprimiertem Format und in anderen Dateiformaten wie JSON und Parquet geschrieben werden.

Weitere Informationen finden Sie unter [UNLOAD](unload.md). 

## Verwenden Sie CTAS oder Glue ETL, um häufig verwendete Aggregationen zu materialisieren
<a name="performance-tuning-use-ctas-or-glue-etl-to-materialize-frequently-used-aggregations"></a>

Das „Materialisieren“ einer Abfrage ist eine Möglichkeit, die Abfrageleistung zu beschleunigen, indem vorab berechnete komplexe Abfrageergebnisse (z. B. Aggregationen und Verknüpfungen) zur Wiederverwendung in nachfolgenden Abfragen gespeichert werden.

Wenn viele Ihrer Abfragen dieselben Verknüpfungen und Aggregationen enthalten, können Sie die allgemeine Unterabfrage als neue Tabelle materialisieren und dann Abfragen für diese Tabelle ausführen. Sie können die neue Tabelle mit [Erstellen einer Tabelle aus Abfrageergebnissen (CTAS)](ctas.md) oder einem speziellen ETL-Tool wie [Glue ETL](https://aws.amazon.com/glue) erstellen.

Nehmen wir zum Beispiel an, Sie haben ein Dashboard mit Widgets, die verschiedene Aspekte eines Auftragsdatensatzes zeigen. Jedes Widget hat seine eigene Abfrage, aber die Abfragen verwenden alle dieselben Verknüpfungen und Filter. Eine Bestelltabelle wird mit einer Einzelpostentabelle verknüpft, und es gibt einen Filter, der nur die letzten drei Monate anzeigt. Wenn Sie die gemeinsamen Features dieser Abfragen identifizieren, können Sie eine neue Tabelle erstellen, die von den Widgets verwendet werden kann. Dadurch wird Duplikation reduziert und die Leistung verbessert. Der Nachteil ist, dass Sie die neue Tabelle auf dem neuesten Stand halten müssen.

## Abfrageergebnisse wiederverwenden
<a name="performance-tuning-reuse-query-results"></a>

Es ist üblich, dass dieselbe Abfrage innerhalb eines kurzen Zeitraums mehrmals ausgeführt wird. Dies kann beispielsweise der Fall sein, wenn mehrere Personen dasselbe Daten-Dashboard öffnen. Wenn Sie eine Abfrage ausführen, können Sie Athena anweisen, zuvor berechnete Ergebnisse wiederzuverwenden. Sie geben das maximale Alter der Ergebnisse an, die wiederverwendet werden sollen. Wenn dieselbe Abfrage zuvor innerhalb dieses Zeitrahmens ausgeführt wurde, gibt Athena diese Ergebnisse zurück, anstatt die Abfrage erneut auszuführen. Weitere Informationen finden Sie unter [Abfrageergebnisse in Athena wiederverwenden](reusing-query-results.md) hier im *Amazon-Athena-Benutzerhandbuch* und im *AWS -Big-Data-Blog* [Kosten reduzieren und die Abfrageleistung verbessern mit Amazon Athena Query Result Reuse](https://aws.amazon.com/blogs/big-data/reduce-cost-and-improve-query-performance-with-amazon-athena-query-result-reuse/).

# Daten optimieren
<a name="performance-tuning-data-optimization-techniques"></a>

Die Leistung hängt nicht nur von Abfragen ab, sondern vor allem auch davon, wie Ihr Datensatz organisiert ist und welches Dateiformat und welche Komprimierung er verwendet.

## Ihre Daten partitionieren
<a name="performance-tuning-partition-your-data"></a>

Durch die Partitionierung wird Ihre Tabelle in Teile aufgeteilt und die zugehörigen Daten werden auf der Grundlage von Eigenschaften wie Datum, Land oder Region zusammengefasst. Partitionsschlüssel fungieren als virtuelle Spalten. Sie definieren Partitionsschlüssel bei der Tabellenerstellung und verwenden sie zum Filtern Ihrer Abfragen. Wenn Sie nach Partitionsschlüsselspalten filtern, werden nur Daten aus übereinstimmenden Partitionen gelesen. Wenn Ihr Datensatz beispielsweise nach Datum partitioniert ist und Ihre Abfrage über einen Filter verfügt, der nur auf die letzte Woche zutrifft, werden nur die Daten der letzten Woche gelesen. Weitere Informationen zur Partitionierung finden Sie unter [Ihre Daten partitionieren](partitions.md).

## Wählen Sie Partitionsschlüssel aus, die Ihre Abfragen unterstützen
<a name="performance-tuning-pick-partition-keys-that-will-support-your-queries"></a>

Da die Partitionierung erhebliche Auswirkungen auf die Abfrageleistung hat, sollten Sie beim Entwerfen Ihres Datensatzes und Ihrer Tabellen darauf achten, wie Sie partitionieren. Zu viele Partitionsschlüssel können zu fragmentierten Datensätzen mit zu vielen und zu kleinen Dateien führen. Umgekehrt führen zu wenige Partitionsschlüssel oder gar keine Partitionierung zu Abfragen, bei denen mehr Daten gescannt werden als nötig.

### Vermeiden Sie die Optimierung für seltene Abfragen
<a name="performance-tuning-avoid-optimizing-for-rare-queries"></a>

Eine gute Strategie besteht darin, für die häufigsten Abfragen zu optimieren und die Optimierung für seltene Abfragen zu vermeiden. Wenn sich Ihre Abfragen beispielsweise auf Zeiträume von Tagen beziehen, sollten Sie sie nicht nach Stunden partitionieren, auch wenn einige Abfragen auf diese Ebene filtern. Wenn Ihre Daten über eine detaillierte Zeitstempelspalte verfügen, können die seltenen Abfragen, die nach Stunden filtern, die Zeitstempelspalte verwenden. Auch wenn in seltenen Fällen etwas mehr Daten als nötig gescannt werden, ist eine Reduzierung der Gesamtleistung in seltenen Fällen in der Regel kein guter Kompromiss.

Um die Datenmenge, die Abfragen scannen müssen, zu reduzieren und dadurch die Leistung zu verbessern, sollten Sie ein spaltenförmiges Dateiformat verwenden und die Datensätze sortiert halten. Anstatt nach Stunden zu partitionieren, sollten Sie die Datensätze nach Zeitstempel sortieren. Bei Abfragen mit kürzeren Zeitfenstern ist die Sortierung nach Zeitstempel fast so effizient wie die Partitionierung nach Stunden. Darüber hinaus beeinträchtigt die Sortierung nach Zeitstempeln in der Regel nicht die Leistung von Abfragen in Zeitfenstern, die in Tagen gezählt werden. Weitere Informationen finden Sie unter [Spaltenorientierte Dateiformate verwenden](#performance-tuning-use-columnar-file-formats).

Beachten Sie, dass Abfragen in Tabellen mit Zehntausenden von Partitionen besser abschneiden, wenn alle Partitionsschlüssel Prädikate enthalten. Dies ist ein weiterer Grund, Ihr Partitionierungsschema für die häufigsten Abfragen zu entwerfen. Weitere Informationen finden Sie unter [Partitionen nach Gleichheit abfragen](#performance-tuning-query-partitions-by-equality).

## Partitionsprojektion verwenden
<a name="performance-tuning-use-partition-projection"></a>

Die Partitionsprojektion ist eine Athena-Funktion, die Partitionsinformationen nicht in der AWS Glue Data Catalog, sondern als Regeln in den Eigenschaften der Tabelle in AWS Glue speichert. Wenn Athena eine Abfrage für eine mit Partitionsprojektion konfigurierte Tabelle plant, liest es die Partitionsprojektionsregeln der Tabelle. Athena berechnet die Partitionen, die im Speicher gelesen werden sollen, basierend auf der Abfrage und den Regeln, anstatt nach Partitionen in der AWS Glue Data Catalog zu suchen.

Die Partitionsprojektion vereinfacht nicht nur die Partitionsverwaltung, sondern kann auch die Leistung von Datensätzen mit einer großen Anzahl von Partitionen verbessern. Wenn eine Abfrage Bereiche anstelle bestimmter Werte für Partitionsschlüssel enthält, dauert die Suche nach passenden Partitionen im Katalog umso länger, je mehr Partitionen vorhanden sind. Mit der Partitionsprojektion kann der Filter im Speicher berechnet werden, ohne den Katalog aufrufen zu müssen, und das kann viel schneller sein.

Unter bestimmten Umständen kann die Partitionsprojektion zu einer schlechteren Leistung führen. Ein Beispiel ist, wenn eine Tabelle „spärlich“ ist. Eine spärliche Tabelle enthält nicht Daten für jede Permutation der Partitionsschlüsselwerte, die in der Konfiguration der Partitionsprojektion beschrieben werden. Bei einer spärlichen Tabelle werden die anhand der Abfrage berechneten Partitionen und die Konfiguration der Partitionsprojektion alle in Amazon S3 aufgeführt, auch wenn sie keine Daten enthalten.

Wenn Sie die Partitionsprojektion verwenden, stellen Sie sicher, dass alle Partitionsschlüssel Prädikate enthalten. Grenzen Sie den Umfang der möglichen Werte ein, um unnötige Amazon-S3-Auflistungen zu vermeiden. Stellen Sie sich einen Partitionsschlüssel mit einem Bereich von einer Million Werten und eine Abfrage ohne Filter für diesen Partitionsschlüssel vor. Um die Abfrage auszuführen, muss Athena mindestens eine Million Amazon-S3-Listenoperationen ausführen. Abfragen sind am schnellsten, wenn Sie bestimmte Werte abfragen, unabhängig davon, ob Sie Partitionsprojektion verwenden oder Partitionsinformationen im Katalog speichern. Weitere Informationen finden Sie unter [Partitionen nach Gleichheit abfragen](#performance-tuning-query-partitions-by-equality).

Wenn Sie eine Tabelle für die Partitionsprojektion konfigurieren, stellen Sie sicher, dass die von Ihnen angegebenen Bereiche angemessen sind. Wenn eine Abfrage kein Prädikat für einen Partitionsschlüssel enthält, werden alle Werte im Bereich für diesen Schlüssel verwendet. Wenn Ihr Datensatz an einem bestimmten Datum erstellt wurde, verwenden Sie dieses Datum als Ausgangspunkt für alle Datumsbereiche. Verwenden Sie `NOW` als das Ende von Datumsbereichen. Vermeiden Sie numerische Bereiche mit einer großen Anzahl von Werten und ziehen Sie in Betracht, stattdessen den [injizierten](partition-projection-dynamic-id-partitioning.md#partition-projection-injection) Typ zu verwenden.

Weitere Informationen zur Partitionsprojektion finden Sie unter [Partitionsprojektion mit Amazon Athena verwenden](partition-projection.md).

## Verwenden Sie Partitionsindizes
<a name="performance-tuning-use-partition-indexes"></a>

Partitionsindizes sind eine Funktion in der AWS Glue Data Catalog , die Leistung bei der Partitionssuche für Tabellen mit einer großen Anzahl von Partitionen verbessert.

Die Liste der Partitionen im Katalog ist wie eine Tabelle in einer relationalen Datenbank. Die Tabelle enthält Spalten für die Partitionsschlüssel und eine zusätzliche Spalte für den Speicherort der Partition. Wenn Sie eine partitionierte Tabelle abfragen, werden die Partitionsspeicherorte durch Scannen dieser Tabelle gesucht.

Wie bei relationalen Datenbanken können Sie die Leistung von Abfragen erhöhen, indem Sie Indizes hinzufügen. Sie können mehrere Indizes hinzufügen, um unterschiedliche Abfragemuster zu unterstützen. Der AWS Glue Data Catalog Partitionsindex unterstützt sowohl Gleichheits- als auch Vergleichsoperatoren wie `>``>=`,, in `<` Kombination mit dem `AND` Operator. Weitere Informationen finden Sie unter [Arbeiten mit Partitionsindizes AWS Glue im AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html) *Entwicklerhandbuch* und [Verbessern der Abfrageleistung von Amazon Athena mithilfe von AWS Glue Data Catalog Partitionsindizes](https://aws.amazon.com/blogs/big-data/improve-amazon-athena-query-performance-using-aws-glue-data-catalog-partition-indexes/) im *AWS Big* Data-Blog.

## Immer STRING als Typ für Partitionsschlüssel verwenden
<a name="performance-tuning-always-use-string-as-the-type-for-partition-keys"></a>

Wenn Sie Partitionsschlüssel abfragen, denken Sie daran, dass Athena verlangt, dass die Partitionsschlüssel vom Typ `STRING` sind, um die Partitionsfilterung nach unten in AWS Glue zu schieben. Wenn die Anzahl der Partitionen nicht gering ist, kann die Verwendung anderer Typen zu einer schlechteren Leistung führen. Wenn Ihre Partitionsschlüsselwerte einem Datum oder einer Zahl ähneln, wandeln Sie sie in Ihrer Abfrage in den entsprechenden Typ um.

## Alte und leere Partitionen entfernen
<a name="performance-tuning-remove-old-and-empty-partitions"></a>

Wenn Sie Daten aus einer Partition auf Amazon S3 entfernen (z. B. mithilfe des Amazon-S3-[Lebenszyklus](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)), sollten Sie auch den Partitionseintrag aus dem AWS Glue Data Catalog entfernen. Während der Abfrageplanung wird jede Partition, der die Abfrage entspricht, in Amazon S3 aufgeführt. Wenn Sie viele leere Partitionen haben, kann sich der Mehraufwand beim Auflisten dieser Partitionen nachteilig auswirken.

Wenn Sie viele tausend Partitionen haben, sollten Sie außerdem in Erwägung ziehen, Partitionsmetadaten für alte Daten zu entfernen, die nicht mehr relevant sind. Wenn Abfragen beispielsweise nie Daten berücksichtigen, die älter als ein Jahr sind, können Sie in regelmäßigen Abständen Partitionsmetadaten für die älteren Partitionen entfernen. Wenn die Anzahl der Partitionen auf Zehntausende ansteigt, kann das Entfernen ungenutzter Partitionen Abfragen beschleunigen, die nicht für alle Partitionsschlüssel Prädikate enthalten. Hinweise zum Einbeziehen von Prädikaten für alle Partitionsschlüssel in Ihre Abfragen finden Sie unter [Partitionen nach Gleichheit abfragen](#performance-tuning-query-partitions-by-equality).

## Partitionen nach Gleichheit abfragen
<a name="performance-tuning-query-partitions-by-equality"></a>

Abfragen, die Gleichheitsprädikate für alle Partitionsschlüssel enthalten, werden schneller ausgeführt, da die Partitionsmetadaten direkt geladen werden können. Vermeiden Sie Abfragen, bei denen einer oder mehrere Partitionsschlüssel kein Prädikat haben oder bei denen das Prädikat einen Wertebereich auswählt. Für solche Abfragen muss die Liste aller Partitionen gefiltert werden, um passende Werte zu finden. Bei den meisten Tabellen ist der Overhead minimal, bei Tabellen mit Zehntausenden oder mehr Partitionen kann der Overhead jedoch erheblich werden.

Wenn es nicht möglich ist, Ihre Abfragen so umzuschreiben, dass Partitionen nach Gleichheit gefiltert werden, können Sie es mit Partitionsprojektion versuchen. Weitere Informationen finden Sie unter [Partitionsprojektion verwenden](#performance-tuning-use-partition-projection).

## Vermeiden Sie es, MSCK REPAIR TABLE für die Partitionsverwaltung zu verwenden
<a name="performance-tuning-avoid-using-msck-repair-table-for-partition-maintenance"></a>

Da die Ausführung von `MSCK REPAIR TABLE` sehr lange dauern kann, nur neue Partitionen hinzugefügt und alte Partitionen nicht entfernt werden, ist dies keine effiziente Methode zur Verwaltung von Partitionen (siehe [Überlegungen und Einschränkungen](msck-repair-table.md#msck-repair-table-considerations)).

[Partitionen lassen sich besser manuell mit den Crawlern [AWS Glue Data Catalog APIs](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-catalog.html)[ALTER TABLE ADD PARTITION](alter-table-add-partition.md), oder verwalten.AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/crawler-running.html) Als Alternative können Sie die Partitionsprojektion verwenden, sodass Sie keine Partitionen mehr verwalten müssen. Weitere Informationen finden Sie unter [Partitionsprojektion mit Amazon Athena verwenden](partition-projection.md).

## Stellen Sie sicher, dass Ihre Abfragen mit dem Partitionierungsschema kompatibel sind
<a name="performance-tuning-validate-that-your-queries-are-compatible-with-the-partitioning-scheme"></a>

Mithilfe der Anweisung [`EXPLAIN`](athena-explain-statement.md) können Sie im Voraus überprüfen, welche Partitionen eine Abfrage scannt. Stellen Sie Ihrer Abfrage das `EXPLAIN`-Schlüsselwort voran und suchen Sie dann am Ende der `EXPLAIN`-Ausgabe nach dem Quellfragment (z. B. `Fragment 2 [SOURCE]`) für jede Tabelle. Suchen Sie nach Zuweisungen, bei denen die rechte Seite als Partitionsschlüssel definiert ist. Die Zeile darunter enthält eine Liste aller Werte für diesen Partitionsschlüssel, die bei der Ausführung der Abfrage gescannt werden.

Angenommen, Sie haben eine Abfrage für eine Tabelle mit einem `dt`-Partitionsschlüssel und dem Präfix `EXPLAIN`. Wenn es sich bei den Werten in der Abfrage um Datumswerte handelt und ein Filter einen Bereich von drei Tagen auswählt, könnte die `EXPLAIN` Ausgabe etwa so aussehen:

```
dt := dt:string:PARTITION_KEY
    :: [[2023-06-11], [2023-06-12], [2023-06-13]]
```

Die `EXPLAIN`-Ausgabe zeigt, dass der Planer drei Werte für diesen Partitionsschlüssel gefunden hat, die der Abfrage entsprachen. Sie zeigt Ihnen auch, was diese Werte sind. Weitere Informationen zur Verwendung von `EXPLAIN` und [Verwenden von EXPLAIN und EXPLAIN ANALYZE in Athena](athena-explain-statement.md) finden Sie unter [Die Ergebnisse der Athena-EXPLAIN-Anweisung verstehen](athena-explain-statement-understanding.md).

## Spaltenorientierte Dateiformate verwenden
<a name="performance-tuning-use-columnar-file-formats"></a>

Spaltenförmige Dateiformate wie Parquet und ORC sind für verteilte Analyse-Workloads konzipiert. Sie organisieren Daten nach Spalten statt nach Zeilen. Das Organisieren von Daten im Spaltenformat bietet die folgenden Vorteile:
+ Nur die für die Abfrage benötigten Spalten werden geladen
+ Die Gesamtmenge der Daten, die geladen werden müssen, wird reduziert
+ Spaltenwerte werden zusammen gespeichert, sodass Daten effizient komprimiert werden können 
+ Dateien können Metadaten enthalten, die es der Engine ermöglichen, das Laden nicht benötigter Daten zu überspringen

Als Beispiel dafür, wie Dateimetadaten verwendet werden können, können Dateimetadaten Informationen über die Mindest- und Höchstwerte auf einer Datenseite enthalten. Wenn die abgefragten Werte nicht in dem in den Metadaten angegebenen Bereich liegen, kann die Seite übersprungen werden.

Eine Möglichkeit, diese Metadaten zur Verbesserung der Leistung zu verwenden, besteht darin, sicherzustellen, dass die Daten in den Dateien sortiert sind. Angenommen, Sie haben Abfragen, die nach Datensätzen suchen, bei denen sich der `created_at`-Eintrag innerhalb einer kurzen Zeitspanne befindet. Wenn Ihre Daten nach der `created_at`-Spalte sortiert sind, kann Athena die Minimal- und Maximalwerte in den Dateimetadaten verwenden, um die nicht benötigten Teile der Datendateien zu überspringen.

Achten Sie bei der Verwendung von spaltenorientierten Dateiformaten darauf, dass Ihre Dateien nicht zu klein sind. Wie in [Zu viele Dateien vermeiden](#performance-tuning-avoid-having-too-many-files) erwähnt, verursachen Datensätze mit vielen kleinen Dateien Leistungsprobleme. Dies gilt insbesondere für spaltenförmige Dateiformate. Bei kleinen Dateien überwiegt der Aufwand des spaltenförmigen Dateiformats die Vorteile.

Beachten Sie, dass Parquet und ORC intern nach Zeilengruppen (Parquet) und Streifen (ORC) organisiert sind. Die Standardgröße für Zeilengruppen beträgt 128 MB und für Streifen 64 MB. Wenn Sie viele Spalten haben, können Sie die Zeilengruppe und die Streifen-Größe erhöhen, um die Leistung zu verbessern. Es wird nicht empfohlen, die Zeilengruppen- oder Streifen-Größe auf weniger als die Standardwerte zu reduzieren.

Um andere Datenformate in Parquet oder ORC zu konvertieren, können Sie AWS Glue ETL oder Athena verwenden. Weitere Informationen finden Sie unter [Konvertieren in spaltenbasierte Formate](columnar-storage.md#convert-to-columnar).

## Daten komprimieren
<a name="performance-tuning-compress-data"></a>

Athena unterstützt eine Vielzahl von Komprimierungsformaten. Das Abfragen komprimierter Daten ist schneller und auch günstiger, da Sie für die Anzahl der vor der Dekomprimierung gescannten Byte zahlen.

Das [GZIP](https://www.gnu.org/software/gzip/)-Format bietet gute Komprimierungsraten und bietet eine breite Unterstützung für andere Tools und Services. Das Format [zstd](https://facebook.github.io/zstd/) (Zstandard) ist ein neueres Komprimierungsformat mit einem ausgewogenen Verhältnis zwischen Leistung und Kompressionsrate.

Versuchen Sie beim Komprimieren von Textdateien wie JSON- und CSV-Daten, ein Gleichgewicht zwischen der Anzahl der Dateien und der Größe der Dateien zu erreichen. Bei den meisten Komprimierungsformaten muss der Leser Dateien von Anfang an lesen. Das bedeutet, dass komprimierte Textdateien im Allgemeinen nicht parallel verarbeitet werden können. Große unkomprimierte Dateien werden häufig zwischen Workern aufgeteilt, um eine höhere Parallelität bei der Abfrageverarbeitung zu erreichen. Dies ist jedoch bei den meisten Komprimierungsformaten nicht möglich.

Wie in [Zu viele Dateien vermeiden](#performance-tuning-avoid-having-too-many-files) diskutiert, ist es besser, weder zu viele noch zu wenige Dateien zu haben. Da die Anzahl der Dateien das Limit dafür ist, wie viele Worker die Abfrage verarbeiten können, gilt diese Regel insbesondere für komprimierte Dateien.

Weitere Informationen zur Verwendung der Komprimierung in Athena finden Sie unter [Komprimierung in Athena verwenden](compression-formats.md).

## Verwenden Sie Bucketing für die Suche nach Schlüsseln mit hoher Kardinalität
<a name="performance-tuning-use-bucketing-for-lookups-on-keys-with-high-cardinality"></a>

Beim Bucketing handelt es sich um eine Technik zur Verteilung von Datensätzen in separate Dateien, die auf dem Wert einer der Spalten basieren. Dadurch wird sichergestellt, dass sich alle Datensätze mit demselben Wert in derselben Datei befinden. Bucketing ist nützlich, wenn Sie einen Schlüssel mit hoher Kardinalität haben und viele Ihrer Abfragen nach bestimmten Werten des Schlüssels suchen.

Nehmen wir beispielsweise an, Sie fragen eine Reihe von Datensätzen für einen bestimmten Benutzer ab. Wenn die Daten nach Benutzer-IDs zusammengefasst sind, weiß Athena im Voraus, welche Dateien Datensätze für eine bestimmte ID enthalten und welche nicht. Dadurch kann Athena nur die Dateien lesen, die die ID enthalten können, wodurch die Menge der gelesenen Daten erheblich reduziert wird. Es reduziert auch die Rechenzeit, die andernfalls erforderlich wäre, um die Daten nach der spezifischen ID zu durchsuchen.

### Bucketing vermeiden, wenn Abfragen häufig nach mehreren Werten in einer Spalte suchen
<a name="performance-tuning-disadvantages-of-bucketing"></a>

Bucketing ist weniger nützlich, wenn Abfragen häufig nach mehreren Werten in der Spalte suchen, nach der die Daten gruppiert sind. Je mehr Werte abgefragt werden, desto höher ist die Wahrscheinlichkeit, dass alle oder die meisten Dateien gelesen werden müssen. Wenn Sie beispielsweise drei Buckets haben und eine Abfrage nach drei verschiedenen Werten sucht, müssen möglicherweise alle Dateien gelesen werden. Bucketing funktioniert am besten, wenn Abfragen nach einzelnen Werten suchen.

Weitere Informationen finden Sie unter [Partitionierung und Bucketing verwenden](ctas-partitioning-and-bucketing.md).

## Zu viele Dateien vermeiden
<a name="performance-tuning-avoid-having-too-many-files"></a>

Datensätze, die aus vielen kleinen Dateien bestehen, führen insgesamt zu einer schlechten Abfrageleistung. Wenn Athena eine Abfrage plant, listet es alle Partitionsspeicherorte auf, was einige Zeit in Anspruch nimmt. Die Bearbeitung und Anforderung jeder Datei ist ebenfalls mit einem Rechenaufwand verbunden. Daher ist das Laden einer einzigen größeren Datei aus Amazon S3 schneller als das Laden derselben Datensätze aus vielen kleineren Dateien.

In extremen Fällen können Sie auf Servicebeschränkungen in Amazon S3 stoßen. Amazon S3 unterstützt bis zu 5 500 Anfragen pro Sekunde an eine einzelne Indexpartition. Anfänglich wird ein Bucket als eine einzelne Indexpartition behandelt, aber wenn die Anforderungslast zunimmt, kann er in mehrere Indexpartitionen aufgeteilt werden.

Amazon S3 untersucht Anforderungsmuster und Aufteilungen auf der Grundlage von Schlüsselpräfixen. Wenn Ihr Datensatz aus vielen tausend Dateien besteht, können die Anfragen von Athena das Anforderungskontingent überschreiten. Selbst bei weniger Dateien kann das Kontingent überschritten werden, wenn mehrere gleichzeitige Abfragen für denselben Datensatz durchgeführt werden. Andere Anwendungen, die auf dieselben Dateien zugreifen, können zur Gesamtzahl der Anfragen beitragen.

Wenn die Anforderungsrate `limit` überschritten wird, gibt Amazon S3 den folgenden Fehler zurück. Dieser Fehler ist in den Statusinformationen für die Abfrage in Athena enthalten.

 SlowDown: Bitte reduzieren Sie Ihre Anfragerate 

Stellen Sie zur Fehlerbehebung zunächst fest, ob der Fehler durch eine einzelne Abfrage oder durch mehrere Abfragen verursacht wurde, die dieselben Dateien lesen. Wenn letzteres der Fall ist, koordinieren Sie die Ausführung von Abfragen, sodass sie nicht gleichzeitig ausgeführt werden. Um dies zu erreichen, fügen Sie Ihrer Anwendung einen Warteschlangenmechanismus oder sogar Wiederholungsversuche hinzu.

Wenn das Ausführen einer einzelnen Abfrage den Fehler auslöst, versuchen Sie, Datendateien zu kombinieren oder die Abfrage so zu ändern, dass weniger Dateien gelesen werden. Kleine Dateien lassen sich am besten kombinieren, bevor sie geschrieben werden. Ziehen Sie dazu die folgenden Techniken in Betracht:
+ Ändern Sie den Prozess, der die Dateien schreibt, um größere Dateien zu schreiben. Sie könnten beispielsweise Datensätze für einen längeren Zeitraum zwischenspeichern, bevor sie geschrieben werden. 
+ Speichern Sie Dateien an einem Speicherort auf Amazon S3 und verwenden Sie ein Tool wie Glue ETL, um sie zu größeren Dateien zu kombinieren. Verschieben Sie dann die größeren Dateien an den Speicherort, auf den die Tabelle verweist. Weitere Informationen finden Sie unter [Lesen von Eingabedateien in größeren Gruppen](https://docs.aws.amazon.com/glue/latest/dg/grouping-input-files.html) im *AWS Glue Entwicklerhandbuch* und [Wie kann ich einen AWS Glue ETL-Job für die Ausgabe größerer Dateien konfigurieren?](https://repost.aws/knowledge-center/glue-job-output-large-files) im *AWS re:POST Knowledge Center*.
+ Reduzieren Sie die Anzahl der Partitionsschlüssel. Wenn Sie zu viele Partitionsschlüssel haben, enthält jede Partition möglicherweise nur wenige Datensätze, was zu einer übermäßigen Anzahl kleiner Dateien führt. Hinweise zur Entscheidung, welche Partitionen erstellt werden sollen, finden Sie unter [Wählen Sie Partitionsschlüssel aus, die Ihre Abfragen unterstützen](#performance-tuning-pick-partition-keys-that-will-support-your-queries).

## Vermeiden Sie zusätzliche Speicherhierarchien außerhalb der Partition
<a name="performance-tuning-avoid-additional-storage-hierarchies-beyond-the-partition"></a>

Um den Aufwand bei der Planung von Abfragen zu vermeiden, speichern Sie Dateien in einer flachen Struktur an jedem Partitionsspeicherort. Verwenden Sie keine zusätzlichen Verzeichnishierarchien.

Wenn Athena eine Abfrage plant, listet es alle Dateien in allen Partitionen auf, denen die Abfrage entspricht. Obwohl Amazon S3 per se keine Verzeichnisse hat, ist es üblich, den `/`-Schrägstrich als Verzeichnistrennzeichen zu interpretieren. Wenn Athena Partitionsspeicherorte auflistet, listet es rekursiv alle gefundenen Verzeichnisse auf. Wenn Dateien innerhalb einer Partition in einer Hierarchie organisiert sind, kommt es zu mehreren Auflistungsrunden.

Wenn sich alle Dateien direkt am Speicherort der Partition befinden, muss meistens nur ein Listenvorgang ausgeführt werden. Allerdings sind mehrere sequentielle Listenoperationen erforderlich, wenn Sie mehr als 1 000 Dateien in einer Partition haben, da Amazon S3 nur 1 000 Objekte pro Listenvorgang zurückgibt. Mehr als 1 000 Dateien in einer Partition können auch zu anderen, schwerwiegenderen Leistungsproblemen führen. Weitere Informationen finden Sie unter [Zu viele Dateien vermeiden](#performance-tuning-avoid-having-too-many-files). 

## SymlinkTextInputFormat nur bei Bedarf verwenden
<a name="performance-tuning-use-symlinktextinputformat-only-when-necessary"></a>

Die Verwendung der [https://athena.guide/articles/stitching-tables-with-symlinktextinputformat](https://athena.guide/articles/stitching-tables-with-symlinktextinputformat)-Technik kann eine Möglichkeit sein, Situationen zu umgehen, in denen die Dateien für eine Tabelle nicht übersichtlich in Partitionen organisiert sind. Beispielsweise können Symlinks nützlich sein, wenn sich alle Dateien im selben Präfix oder Dateien mit unterschiedlichen Schemas am selben Ort befinden.

Durch die Verwendung von Symlinks wird die Abfrageausführung jedoch um ein gewisses Maß an Indirektion erweitert. Diese Ebenen der Indirektion wirken sich auf die Gesamtleistung aus. Die Symlink-Dateien müssen gelesen und die Speicherorte, die sie definieren, müssen aufgelistet werden. Dadurch werden mehrere Roundtrips zu Amazon S3 hinzugefügt, die für herkömmliche Hive-Tabellen nicht erforderlich sind. Zusammenfassend lässt sich sagen, dass Sie `SymlinkTextInputFormat` nur verwenden sollten, wenn bessere Optionen wie das Reorganisieren von Dateien nicht verfügbar sind.

# Spaltenbasierte Speicherformate verwenden
<a name="columnar-storage"></a>

[Apache Parquet](https://parquet.apache.org) und [ORC](https://orc.apache.org/) sind spaltenförmige Speicherformate, die für den schnellen Abruf von Daten optimiert und in AWS analytischen Anwendungen verwendet werden.

Spaltenbasierte Speicherformate haben die folgenden Eigenschaften, wodurch sie sich für die Verwendung mit Athena eignen: 
+ *Komprimierung nach Spalten, wobei der Komprimierungsalgorithmus für den Spaltendatentyp ausgewählt wurde*, um Speicherplatz in Amazon S3 zu sparen und den Festplattenspeicher sowie I/O während der Abfrageverarbeitung zu reduzieren.
+ *Prädikat-Pushdown* in Parquet und ORC ermöglicht Athena-Abfragen, um nur die tatsächlich benötigten Blöcke abzurufen, wobei die Abfrageleistung verbessert wird. Wenn eine Athena-Abfrage bestimmte Spaltenwerte aus Ihren Daten erhält, verwendet sie Statistiken aus Datenblockprädikaten, z. B. max/min Werten, um zu bestimmen, ob der Block gelesen oder übersprungen werden soll. 
+ *Das Aufteilen von Daten* in Parquet und ORC ermöglicht Athena das Lesen von Daten an mehrere Leser und die Erhöhung der Parallelität während der Abfrageverarbeitung. 

Um Ihre vorhandenen Rohdaten aus anderen Speicherformaten in Parquet oder ORC zu konvertieren, können Sie [CREATE TABLE AS SELECT (CTAS)](ctas.md) -Abfragen in Athena ausführen und ein Datenspeicherformat als Parquet oder ORC angeben oder den Crawler verwenden. AWS Glue 

## Wählen Sie zwischen Parquet und ORC
<a name="columnar-storage-choosing"></a>

Die Wahl zwischen ORC (Optimized Row Columnar) und Parquet hängt von Ihren spezifischen Nutzungsanforderungen ab.

Apache Parquet bietet effiziente Datenkomprimierungs- und Kodierungsschemata und ist ideal für die Ausführung komplexer Abfragen und die Verarbeitung großer Datenmengen. Parquet ist für die Verwendung mit [Apache Arrow](https://arrow.apache.org/) optimiert. Dies kann von Vorteil sein, wenn Sie Tools verwenden, die sich auf Arrow beziehen.

ORC bietet eine effiziente Möglichkeit, Hive-Daten zu speichern. ORC-Dateien sind oft kleiner als Parquet-Dateien, und ORC-Indizes können Abfragen beschleunigen. Darüber hinaus unterstützt ORC komplexe Typen wie Strukturen, Maps und Listen.

Wenn Sie zwischen Parquet und ORC wählen, sollten Sie die folgenden Faktoren berücksichtigen:

**Abfrageleistung** – Da Parquet eine breitere Palette von Abfragetypen unterstützt, ist Parquet möglicherweise die bessere Wahl, wenn Sie komplexe Abfragen ausführen möchten. 

**Komplexe Datentypen** – Wenn Sie komplexe Datentypen verwenden, ist ORC möglicherweise die bessere Wahl, da es ein breiteres Spektrum an komplexen Datentypen unterstützt.

**Dateigröße** – Wenn der Speicherplatz ein Problem darstellt, führt ORC in der Regel zu kleineren Dateien, wodurch die Speicherkosten gesenkt werden können.

**Komprimierung** – Sowohl Parquet als auch ORC bieten eine gute Komprimierung, aber welches Format für Sie am besten geeignet ist, hängt von Ihrem spezifischen Anwendungsfall ab.

**Evolution** – Sowohl Parquet als auch ORC unterstützen die Schemaentwicklung, was bedeutet, dass Sie im Laufe der Zeit Spalten hinzufügen, entfernen oder ändern können.

Sowohl Parquet als auch ORC sind eine gute Wahl für Big-Data-Anwendungen. Berücksichtigen Sie jedoch die Anforderungen Ihres Szenarios, bevor Sie sich entscheiden. Möglicherweise möchten Sie Benchmarks für Ihre Daten und Abfragen durchführen, um herauszufinden, welches Format für Ihren Anwendungsfall besser geeignet ist.

## Konvertieren in spaltenbasierte Formate
<a name="convert-to-columnar"></a>

Optionen zum einfachen Konvertieren von Quelldaten wie JSON oder CSV in ein Säulenformat, umfassen die Verwendung von [CREATE TABLE AS](ctas.md)-Abfragen oder das Ausführen von Aufträgen in AWS Glue.
+ Sie können `CREATE TABLE AS`(CTAS)-Abfragen verwenden, um Daten in Parquet oder ORC in einem Schritt zu konvertieren. Ein Beispiel finden Sie unter [Beispiel: Schreiben von Abfrageergebnissen in ein anderes Format](https://docs.aws.amazon.com/athena/latest/ug/ctas-examples.html#ctas-example-format) auf der [Beispiele für CTAS-Abfragen](ctas-examples.md)-Seite.
+ Informationen zur Verwendung von Athena für ETL zur Umwandlung von Daten aus CSV in Parquet finden Sie unter [Verwenden von CTAS und INSERT INTO für ETL und Datenanalyse](ctas-insert-into-etl.md).
+ Informationen zur Ausführung eines AWS Glue Jobs zur Transformation von CSV-Daten in das Parquet-Format finden Sie im Abschnitt „Transformieren der Daten vom CSV- in das Parquet-Format“ im AWS Big-Data-Blogbeitrag [Build a Data Lake Foundation with AWS Glue and Amazon S3](https://aws.amazon.com/blogs/big-data/build-a-data-lake-foundation-with-aws-glue-and-amazon-s3/). AWS Glue unterstützt die Verwendung derselben Technik zur Konvertierung von CSV-Daten in ORC oder von JSON-Daten in Parquet oder ORC.

# Partitionierung und Bucketing verwenden
<a name="ctas-partitioning-and-bucketing"></a>

Partitionierung und Bucketing sind zwei Möglichkeiten, die Datenmenge zu reduzieren, die Athena scannen muss, wenn Sie eine Abfrage ausführen. Partitionierung und Bucketing ergänzen sich und können zusammen verwendet werden. Durch die Reduzierung der Datenmenge, die gescannt werden muss, wird die Leistung verbessert und die Kosten gesenkt. Allgemeine Hinweise zur Athena-Abfrageleistung finden Sie unter [Top 10 der Leistungsoptimierungstipps für Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/).

**Topics**
+ [

# Was ist Partitionierung?
](ctas-partitioning-and-bucketing-what-is-partitioning.md)
+ [

# Was ist Bucketing?
](ctas-partitioning-and-bucketing-what-is-bucketing.md)
+ [

# Weitere Ressourcen
](ctas-partitioning-and-bucketing-additional-resources.md)

# Was ist Partitionierung?
<a name="ctas-partitioning-and-bucketing-what-is-partitioning"></a>

Partitionierung bedeutet, Daten auf Amazon S3 auf der Grundlage einer bestimmten Eigenschaft der Daten in Verzeichnissen (oder „Präfixen“) zu organisieren. Solche Eigenschaften werden Partitionsschlüssel genannt. Ein üblicher Partitionsschlüssel ist das Datum oder eine andere Zeiteinheit wie das Jahr oder der Monat. Ein Datensatz kann jedoch nach mehr als einem Schlüssel partitioniert werden. Beispielsweise können Daten über Produktverkäufe nach Datum, Produktkategorie und Markt partitioniert werden.

## Entscheiden, wie partitioniert werden soll
<a name="ctas-partitioning-and-bucketing-deciding-how-to-partition"></a>

Gute Kandidaten für Partitionsschlüssel sind Eigenschaften, die in Abfragen immer oder häufig verwendet werden und eine geringe Kardinalität aufweisen. Es gibt einen Kompromiss zwischen zu vielen Partitionen und zu wenigen. Bei zu vielen Partitionen führt die erhöhte Anzahl von Dateien zu Mehraufwand. Außerdem entsteht durch das Filtern der Partitionen selbst ein gewisser Mehraufwand. Bei zu wenigen Partitionen müssen Abfragen oft mehr Daten scannen.

## Eine partitionierte Tabelle erstellen
<a name="ctas-partitioning-and-bucketing-creating-a-partitioned-table"></a>

Wenn ein Datensatz partitioniert ist, können Sie in Athena eine partitionierte Tabelle erstellen. Eine partitionierte Tabelle ist eine Tabelle mit Partitionsschlüsseln. Wenn Sie `CREATE TABLE` verwenden, fügen Sie der Tabelle Partitionen hinzu. Wenn Sie `CREATE TABLE AS` verwenden, werden die Partitionen, die auf Amazon S3 erstellt wurden, automatisch zur Tabelle hinzugefügt.

In einer `CREATE TABLE`-Anweisung geben Sie die Partitionsschlüssel in der `PARTITIONED BY (column_name data_type)`-Klausel an. In einer `CREATE TABLE AS` Anweisung geben Sie die Partitionsschlüssel in einer `WITH (partitioned_by = ARRAY['partition_key'])`-Klausel oder `WITH (partitioning = ARRAY['partition_key'])` für Iceberg-Tabellen an. Aus Leistungsgründen sollten Partitionsschlüssel immer vom Typ `STRING` sein. Weitere Informationen finden Sie unter [String als Datentyp für Partitionsschlüssel verwenden](data-types-timestamps.md#data-types-timestamps-partition-key-types).

Weitere Informationen `CREATE TABLE` und Informationen zur `CREATE TABLE AS`-Syntax finden Sie unter [CREATE TABLE](create-table.md) und [CTAS-Tabelleneigenschaften](create-table-as.md#ctas-table-properties).

## Partitionierte Tabellen abfragen
<a name="ctas-partitioning-and-bucketing-querying-partitioned-tables"></a>

Wenn Sie eine partitionierte Tabelle abfragen, verwendet Athena die Prädikate in der Abfrage, um die Liste der Partitionen zu filtern. Anschließend verwendet es die Speicherorte der passenden Partitionen, um die gefundenen Dateien zu verarbeiten. Athena kann die Menge der gescannten Daten effizient reduzieren, indem es einfach keine Daten in den Partitionen liest, die nicht den Abfrageprädikaten entsprechen.

### Beispiele
<a name="ctas-partitioning-and-bucketing-partitioned-table-example-queries"></a>

Angenommen, Sie haben eine Tabelle, die nach `sales_date` und `product_category` partitioniert ist und möchten den Gesamtumsatz einer Woche in einer bestimmten Kategorie ermitteln. Sie fügen Prädikate in die `sales_date`- und `product_category`-Spalten ein, um sicherzustellen, dass Athena nur die minimale Datenmenge scannt, wie im folgenden Beispiel.

```
SELECT SUM(amount) AS total_revenue 
FROM sales 
WHERE sales_date BETWEEN '2023-02-27' AND '2023-03-05' 
AND product_category = 'Toys'
```

Angenommen, Sie haben einen Datensatz, der nach Datum partitioniert ist, aber auch über einen detaillierten Zeitstempel verfügt.

Bei Iceberg-Tabellen können Sie einen Partitionsschlüssel so deklarieren, dass er eine Beziehung zu einer Spalte hat, aber bei Hive-Tabellen hat die Abfrage-Engine keine Kenntnis von den Beziehungen zwischen Spalten und Partitionsschlüsseln. Aus diesem Grund müssen Sie sowohl für die Spalte als auch für den Partitionsschlüssel in Ihrer Abfrage ein Prädikat angeben, um sicherzustellen, dass die Abfrage nicht mehr Daten scannt als nötig.

Nehmen wir beispielsweise an, dass die `sales`-Tabelle im vorherigen Beispiel auch eine `sold_at`-Spalte des `TIMESTAMP`-Datentyps enthält. Wenn Sie den Umsatz nur für einen bestimmten Zeitraum ermitteln möchten, würden Sie die Abfrage wie folgt schreiben:

```
SELECT SUM(amount) AS total_revenue 
FROM sales 
WHERE sales_date = '2023-02-28' 
AND sold_at BETWEEN TIMESTAMP '2023-02-28 10:00:00' AND TIMESTAMP '2023-02-28 12:00:00' 
AND product_category = 'Toys'
```

Weitere Informationen zu diesem Unterschied zwischen der Abfrage von Hive- und Iceberg-Tabellen finden Sie unter [Wie Sie Abfragen für Zeitstempelfelder schreiben, die ebenfalls zeitpartitioniert sind](data-types-timestamps.md#data-types-timestamps-how-to-write-queries-for-timestamp-fields-that-are-also-time-partitioned).

# Was ist Bucketing?
<a name="ctas-partitioning-and-bucketing-what-is-bucketing"></a>

Bucketing ist eine Möglichkeit, die Inhalte eines Datensatzes in Kategorien zu organisieren, die als Buckets bezeichnet werden.

Die Bedeutung von Bucket und Bucketing unterscheidet sich von Amazon-S3-Buckets und sollte nicht mit diesen verwechselt werden. Beim Daten-Bucketing werden Datensätze, die denselben Wert für eine Eigenschaft haben, in denselben Bucket verschoben. Datensätze werden so gleichmäßig wie möglich auf die Buckets verteilt, sodass jeder Bucket ungefähr die gleiche Datenmenge enthält.

In der Praxis handelt es sich bei den Buckets um Dateien, und eine Hash-Funktion bestimmt, in welchen Bucket ein Datensatz aufgenommen wird. Ein bucketierter Datensatz enthält eine oder mehrere Dateien pro Bucket und Partition. Der Bucket, zu dem eine Datei gehört, ist im Dateinamen kodiert.

## Vorteile von Bucketing
<a name="ctas-partitioning-and-bucketing-bucketing-benefits"></a>

Bucketing ist nützlich, wenn eine Datenmenge einer bestimmten Eigenschaft bucketiert ist und Sie Datensätze abrufen möchten, in denen diese Eigenschaft einen bestimmten Wert hat. Da die Daten bucketiert sind, kann Athena anhand des Werts bestimmen, welche Dateien betrachtet werden sollen. Nehmen wir zum Beispiel an, dass ein Datensatz nach `customer_id` bucketiert ist und Sie alle Datensätze für einen bestimmten Kunden suchen möchten. Athena bestimmt den Bucket, der diese Datensätze enthält, und liest nur die Dateien in diesem Bucket.

Gute Kandidaten für das Bucketing sind Spalten mit hoher Kardinalität (d. h. mit vielen unterschiedlichen Werten), die gleichmäßig verteilt sind und die Sie häufig nach bestimmten Werten abfragen.

**Anmerkung**  
Athena unterstützt nicht die Verwendung von `INSERT INTO` zum Hinzufügen neuer Datensätze zu bucketierten Tabellen.

## Unterstützte Datentypen für das Filtern von Spalten mit Zeiträumen
<a name="ctas-partitioning-and-bucketing-data-types-supported-for-filtering-on-bucketed-columns"></a>

Sie können Filter für bucketierte Spalten mit bestimmten Datentypen hinzufügen. Athena unterstützt eine solche Filterung nur für bucketierte Spalten mit den folgenden Datentypen:
+ BOOLEAN
+ BYTE
+ DATE
+ DOUBLE
+ FLOAT
+ INT
+ LONG
+ SHORT
+ STRING
+ VARCHAR

## Unterstützung für Hive und Spark
<a name="ctas-partitioning-and-bucketing-hive-and-spark-support"></a>

Athena-Engine-Version 2 unterstützt Datensätze, die mit dem Hive-Bucket-Algorithmus in Buckets zusammengefasst wurden, und Athena-Engine-Version 3 unterstützt auch den Apache-Spark-Bucketing-Algorithmus. Hive-Bucketing ist die Standardeinstellung. Wenn Ihr Datensatz mithilfe des Spark-Algorithmus in einem Bucket zusammengefasst wird, verwenden Sie die `TBLPROPERTIES`-Klausel, um den `bucketing_format`-Eigenschaftswert auf `spark` festzulegen.

**Anmerkung**  
Athena hat ein Limit von 100 Partitionen pro `CREATE TABLE AS SELECT` ([CTAS](ctas.md))-Abfrage. Ebenso können Sie einer Zieltabelle mit einer [INSERT INTO](insert-into.md)-Anweisung maximal 100 Partitionen hinzufügen.  
Wenn Sie diese Einschränkung überschreiten, wird möglicherweise die Fehlermeldung HIVE\$1TOO\$1MANY\$1OPEN\$1PARTITIONS: 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 von CTAS und INSERT INTO zum Umgehen des Limits von 100 Partitionen](ctas-insert-into.md).

## Beispiel für CREATE-TABLE-Bucketing
<a name="ctas-partitioning-and-bucketing-bucketing-create-table-example"></a>

Verwenden Sie die `CLUSTERED BY (column)`-Klausel, gefolgt von der `INTO N BUCKETS`-Klausel, um eine Tabelle für einen vorhandenen Bucket-Datensatz zu erstellen. Die `INTO N BUCKETS`-Klausel gibt die Anzahl der Buckets an, in die die Daten aufgeteilt werden.

Im folgenden `CREATE TABLE`-Beispiel wird der `sales`-Datensatz mithilfe des Spark-Algorithmus `customer_id` in 8 Buckets aufgeteilt. Die `CREATE TABLE`-Anweisung verwendet die Klauseln `CLUSTERED BY` und `TBLPROPERTIES`, um die Eigenschaften entsprechend festzulegen.

```
CREATE EXTERNAL TABLE sales (...) 
... 
CLUSTERED BY (`customer_id`) INTO 8 BUCKETS 
... 
TBLPROPERTIES ( 
  'bucketing_format' = 'spark' 
)
```

## Beispiel für CREATE TABLE AS (CTAS)-Bucketing
<a name="ctas-partitioning-and-bucketing-bucketing-create-table-as-example"></a>

Um Bucketing mit `CREATE TABLE AS` zu spezifizieren, verwenden Sie die Parameter `bucket_count` und `bucketed_by`, wie im folgenden Beispiel gezeigt.

```
CREATE TABLE sales 
WITH ( 
  ... 
  bucketed_by = ARRAY['customer_id'], 
  bucket_count = 8 
) 
AS SELECT ...
```

## Beispiel für eine Bucketing-Abfrage
<a name="ctas-partitioning-and-bucketing-bucketing-query-example"></a>

In der folgenden Beispielabfrage wird nach den Namen von Produkten gesucht, die ein bestimmter Kunde im Laufe einer Woche gekauft hat.

```
SELECT DISTINCT product_name 
FROM sales 
WHERE sales_date BETWEEN '2023-02-27' AND '2023-03-05' 
AND customer_id = 'c123'
```

Wenn diese Tabelle von `sales_date` partitioniert ist und von `customer_id` bucketiert ist, kann Athena den Bucket berechnen, in dem sich die Kundendatensätze befinden. Athena liest höchstens eine Datei pro Partition.

# Weitere Ressourcen
<a name="ctas-partitioning-and-bucketing-additional-resources"></a>
+ Für ein `CREATE TABLE AS`-Beispiel, das sowohl bucketierte als auch partitionierte Tabellen erstellt, siehe das [Beispiel: Erstellen von bucketierten Tabellen und partitionierten Tabellen](https://docs.aws.amazon.com/athena/latest/ug/ctas-examples.html#ctas-example-bucketed).
+ Informationen zur Implementierung von Bucketing auf AWS Data Lakes, einschließlich der Verwendung einer Athena CTAS-Anweisung, AWS Glue für Apache Spark und zum Bucketing für Apache Iceberg-Tabellen finden Sie im AWS Big-Data-Blogbeitrag [Optimieren Sie das Datenlayout durch Bucketing mit Amazon Athena](https://aws.amazon.com/blogs/big-data/optimize-data-layout-by-bucketing-with-amazon-athena-and-aws-glue-to-accelerate-downstream-queries/) und zur Beschleunigung nachgelagerter Abfragen. AWS Glue 

# Ihre Daten partitionieren
<a name="partitions"></a>

Durch eine Datenpartitionierung können Sie die pro Abfrage durchsuchte Datenmenge eingrenzen und so die Leistung verbessern sowie Kosten senken. Sie können Ihre Daten nach einem beliebigen Schlüssel partitionieren. In der Regel werden die Daten zeitbasiert partitioniert und das führt häufig zu einem Multi-Level-Partitionierungsschema. Beispielsweise kann ein Kunde, bei dem stündlich Daten eingehen, diese nach Jahr, Monat, Datum und Stunde partitionieren. Ein anderer Kunde, der über Daten aus vielen verschiedenen Quellen verfügt, die jedoch nur einmal pro Tag geladen werden, kann nach einer Datenquellenkennung und einem Datum partitionieren.

Athena kann Partitionen im Apache-Hive-Stil verwenden, deren Datenpfade Schlüsselwertpaare enthalten, die durch Gleichheitszeichen verbunden sind (z. B. `country=us/...` oder `year=2021/month=01/day=26/...`). Daher enthalten die Pfade sowohl die Namen der Partitionsschlüssel als auch die Werte, die jeder Pfad darstellt. Um neue Hive-Partitionen in eine partitionierte Tabelle zu laden, können Sie den [MSCK REPAIR TABLE](msck-repair-table.md)-Befehl verwenden, der nur mit Partitionen im Hive-Stil funktioniert.

Athena kann auch Partitionierungsschemata im Nicht-Hive-Stil verwenden. Beispielsweise verwenden CloudTrail Logs und Firehose-Lieferdatenströme separate Pfadkomponenten für Datenteile wie`data/2021/01/26/us/6fc7845e.json`. Bei solchen Partitionen im Nicht-Hive-Stil können Sie [ALTER TABLE ADD PARTITION](alter-table-add-partition.md) verwenden, um die Partitionen manuell hinzuzufügen.

## Überlegungen und Einschränkungen
<a name="partitions-considerations-limitations"></a>

Beachten Sie bei der Verwendung der Partitionierung die folgenden Punkte:
+ Wenn Sie eine partitionierte Tabelle abfragen und die Partition in der `WHERE`-Klausel angeben, scannt Athena nur die Daten aus dieser Partition.
+ Wenn Sie Abfragen gegen Amazon-S3-Buckets mit einer großen Anzahl von Objekten ausgeben und die Daten nicht partitioniert sind, können sich solche Abfragen auf die Grenzwerte für die `GET`-Anforderungsrate in Amazon S3 auswirken und zu Amazon-S3-Ausnahmen führen. Um Fehler zu vermeiden, partitionieren Sie Ihre Daten. Überlegen Sie zusätzlich, ob Sie Ihre Amazon-S3-Anforderungsraten optimieren möchten. Weitere Informationen finden Sie unter [Bewährte Methoden für Designmuster: Optimieren der Amazon-S3-Leistung ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/request-rate-perf-considerations.html).
+ Partitionsspeicherorte zur Verwendung mit Athena müssen das `s3`-Protokoll verwenden (z. B. `s3://amzn-s3-demo-bucket/folder/`). In Athena führen Speicherorte, die andere Protokolle verwenden (z. B. `s3a://amzn-s3-demo-bucket/folder/`), zu Abfragefehlern, wenn `MSCK REPAIR TABLE`-Abfragen für die enthaltenen Tabellen ausgeführt werden. 
+ Achten Sie darauf, dass der Amazon-S3-Pfad in Kleinbuchstaben und nicht mit der Camel-Case-Schreibweise geschrieben ist (z. B. `userid` statt `userId`). Wenn der S3-Pfad in Camel-Case geschrieben ist, fügt `MSCK REPAIR TABLE` die Partitionen nicht zu AWS Glue Data Catalog hinzu. Weitere Informationen finden Sie unter [MSCK REPAIR TABLE](msck-repair-table.md).
+ Da es sich bei `MSCK REPAIR TABLE` durchsucht sowohl einen Ordner als auch seine Unterordner, um ein übereinstimmendes Partitionsschema zu finden. Achten Sie darauf, dass die Daten für separate Tabellen in separaten Ordnerhierarchien aufbewahrt werden. Angenommen, Sie haben Daten für Tabelle 1 in `s3://amzn-s3-demo-bucket1` und Daten für Tabelle 2 in `s3://amzn-s3-demo-bucket1/table-2-data`. Wenn beide Tabellen nach einer Zeichenfolge partitioniert sind, wird `MSCK REPAIR TABLE` die Partitionen für Tabelle 2 zu Tabelle 1 hinzufügen. Um dies zu vermeiden, verwenden Sie stattdessen separate Ordnerstrukturen wie `s3://amzn-s3-demo-bucket1` und `s3://amzn-s3-demo-bucket2`. Beachten Sie, dass dieses Verhalten mit Amazon EMR und Apache Hive konsistent ist.
+ Wenn Sie das AWS Glue Data Catalog mit Athena verwenden, finden Sie unter [AWS Glue Endpunkte und Kontingente](https://docs.aws.amazon.com/general/latest/gr/glue.html) Informationen zu Dienstkontingenten auf Partitionen pro Konto und pro Tabelle. 
  + Athena unterstützt zwar das Abfragen von AWS Glue Tabellen mit 10 Millionen Partitionen, Athena kann jedoch nicht mehr als 1 Million Partitionen in einem einzigen Scan lesen. In solchen Szenarien kann die Indizierung von Partitionen von Vorteil sein. Weitere Informationen finden Sie im AWS Big-Data-Blogartikel [Verbessern Sie die Abfrageleistung von Amazon Athena mithilfe von AWS Glue Data Catalog Partitionsindizes](https://aws.amazon.com/blogs/big-data/improve-amazon-athena-query-performance-using-aws-glue-data-catalog-partition-indexes/).
+ Um eine Erhöhung des Partitionskontingents zu beantragen, wenn Sie den verwenden AWS Glue Data Catalog, besuchen Sie die [Service Quotas Quota-Konsole für AWS Glue](https://console.aws.amazon.com/servicequotas/home?region=us-east-1#!/services/glue/quotas).

## Erstellen und Laden einer Tabelle mit partitionierten Daten
<a name="partitions-creating-loading"></a>

Um eine Tabelle zu erstellen, verwenden Sie die `PARTITIONED BY`-Klausel in Ihrer [CREATE TABLE](create-table.md)-Anweisung. Die `PARTITIONED BY`-Klausel definiert die Schlüssel, mit denen Daten partitioniert werden sollen, wie im folgenden Beispiel. Die `LOCATION`-Klausel gibt den Stammspeicherort der partitionierten Daten an.

```
CREATE EXTERNAL TABLE users (
first string,
last string,
username string
)
PARTITIONED BY (id string)
STORED AS parquet
LOCATION 's3://amzn-s3-demo-bucket'
```

Nachdem Sie die Tabelle erstellt haben, laden Sie die Daten in den Partitionen für die Abfrage. Bei Partitionen im Hive-Stil führen Sie [MSCK REPAIR TABLE](msck-repair-table.md) aus. Bei Partitionen im Nicht-Hive-Stil verwenden Sie [ALTER TABLE ADD PARTITION](alter-table-add-partition.md), um die Partitionen manuell hinzuzufügen.

## Vorbereiten von Hive-artigen und Nicht-Hive-artigen Daten für die Abfrage
<a name="partitions-preparing-data"></a>

In den folgenden Abschnitten wird gezeigt, wie Sie Hive-Stil- und Nicht-Hive-Stil-Daten für die Abfrage in Athena vorbereiten.

### Szenario 1: Daten, die im Hive-Format auf Amazon S3 gespeichert sind
<a name="scenario-1-data-already-partitioned-and-stored-on-s3-in-hive-format"></a>

Die Partitionen in diesem Szenario werden in Amazon S3 in separaten Ordnern gespeichert. Hier ist beispielsweise die teilweise Auflistung für Beispiel-Anzeigenimpressionen, die vom [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3/ls.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3/ls.html)-Befehl ausgegeben werden, der die S3-Objekte unter einem angegebenen Präfix auflistet:

```
aws s3 ls s3://elasticmapreduce/samples/hive-ads/tables/impressions/

    PRE dt=2009-04-12-13-00/
    PRE dt=2009-04-12-13-05/
    PRE dt=2009-04-12-13-10/
    PRE dt=2009-04-12-13-15/
    PRE dt=2009-04-12-13-20/
    PRE dt=2009-04-12-14-00/
    PRE dt=2009-04-12-14-05/
    PRE dt=2009-04-12-14-10/
    PRE dt=2009-04-12-14-15/
    PRE dt=2009-04-12-14-20/
    PRE dt=2009-04-12-15-00/
    PRE dt=2009-04-12-15-05/
```

Die Protokolle werden hier mit dem Spaltennamen (dt) gespeichert, der auf Datums- und Uhrzeitangaben gesetzt ist. Wenn Sie eine DDL mit dem Speicherort des übergeordneten Ordners, dem Schema und dem Namen der partitionierten Spalte angeben, kann Athena Abfragen für die Daten in diesen Unterordnern ausführen.

#### Erstellen der Tabelle
<a name="creating-a-table"></a>

Um aus diesen Daten eine Tabelle zu erzeugen, erstellen Sie wie in der folgenden Athena-DDL-Anweisung eine Partition für „dt“:

```
CREATE EXTERNAL TABLE impressions (
    requestBeginTime string,
    adId string,
    impressionId string,
    referrer string,
    userAgent string,
    userCookie string,
    ip string,
    number string,
    processId string,
    browserCookie string,
    requestEndTime string,
    timers struct<modelLookup:string, requestTime:string>,
    threadId string,
    hostname string,
    sessionId string)
PARTITIONED BY (dt string)
ROW FORMAT  serde 'org.apache.hive.hcatalog.data.JsonSerDe'
LOCATION 's3://elasticmapreduce/samples/hive-ads/tables/impressions/' ;
```

Diese Tabelle nutzt den Hive-eigenen JSON-SerDe (Serializer/Deserializer) zum Lesen der in Amazon S3 gespeicherten JSON-Daten. Weitere Informationen zu den unterstützten Formaten finden Sie unter [Wählen Sie eine SerDe für Ihre Daten](supported-serdes.md).

#### MSCK REPAIR TABLE ausführen
<a name="run-msck-repair-table"></a>

Führen Sie nach dem Ausführen der `CREATE TABLE`-Abfrage den `MSCK REPAIR TABLE`-Befehl im Athena-Abfrageeditor aus, um die Partitionen zu laden, wie im folgenden Beispiel.

```
MSCK REPAIR TABLE impressions
```

Nachdem Sie diesen Befehl ausführen, sind die Daten für die Abfrage bereit.

#### Abfragen der Daten
<a name="query-the-data"></a>

Führen Sie mithilfe der partitionierten Spalte eine Datenabfrage für die Tabelle „impressions“ aus. Hier ein Beispiel:

```
SELECT dt,impressionid FROM impressions WHERE dt<'2009-04-12-14-00' and dt>='2009-04-12-13-00' ORDER BY dt DESC LIMIT 100
```

Diese Abfrage sollte Ergebnisse ähnlich den folgenden anzeigen:

```
2009-04-12-13-20    ap3HcVKAWfXtgIPu6WpuUfAfL0DQEc
2009-04-12-13-20    17uchtodoS9kdeQP1x0XThKl5IuRsV
2009-04-12-13-20    JOUf1SCtRwviGw8sVcghqE5h0nkgtp
2009-04-12-13-20    NQ2XP0J0dvVbCXJ0pb4XvqJ5A4QxxH
2009-04-12-13-20    fFAItiBMsgqro9kRdIwbeX60SROaxr
2009-04-12-13-20    V4og4R9W6G3QjHHwF7gI1cSqig5D1G
2009-04-12-13-20    hPEPtBwk45msmwWTxPVVo1kVu4v11b
2009-04-12-13-20    v0SkfxegheD90gp31UCr6FplnKpx6i
2009-04-12-13-20    1iD9odVgOIi4QWkwHMcOhmwTkWDKfj
2009-04-12-13-20    b31tJiIA25CK8eDHQrHnbcknfSndUk
```

### Szenario 2: Daten werden nicht im Hive-Format partitioniert
<a name="scenario-2-data-is-not-partitioned"></a>

Im folgenden Beispiel zeigt der `aws s3 ls`-Befehl [ELB](elasticloadbalancer-classic-logs.md)-Protokolle an, die in Amazon S3 gespeichert sind. Beachten Sie, dass das Datenlayout keine `key=value`-Paare verwendet und daher nicht im Hive-Format vorliegt. (Die `--recursive`-Option für den `aws s3 ls`-Befehl gibt an, dass alle Dateien oder Objekte unter dem angegebenen Verzeichnis oder Präfix aufgelistet werden.)

```
aws s3 ls s3://athena-examples-myregion/elb/plaintext/ --recursive

2016-11-23 17:54:46   11789573 elb/plaintext/2015/01/01/part-r-00000-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:46    8776899 elb/plaintext/2015/01/01/part-r-00001-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:46    9309800 elb/plaintext/2015/01/01/part-r-00002-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:47    9412570 elb/plaintext/2015/01/01/part-r-00003-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:47   10725938 elb/plaintext/2015/01/01/part-r-00004-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:46    9439710 elb/plaintext/2015/01/01/part-r-00005-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:47          0 elb/plaintext/2015/01/01_$folder$
2016-11-23 17:54:47    9012723 elb/plaintext/2015/01/02/part-r-00006-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:47    7571816 elb/plaintext/2015/01/02/part-r-00007-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:47    9673393 elb/plaintext/2015/01/02/part-r-00008-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:48   11979218 elb/plaintext/2015/01/02/part-r-00009-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:48    9546833 elb/plaintext/2015/01/02/part-r-00010-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:48   10960865 elb/plaintext/2015/01/02/part-r-00011-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:48          0 elb/plaintext/2015/01/02_$folder$
2016-11-23 17:54:48   11360522 elb/plaintext/2015/01/03/part-r-00012-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:48   11211291 elb/plaintext/2015/01/03/part-r-00013-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:48    8633768 elb/plaintext/2015/01/03/part-r-00014-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:49   11891626 elb/plaintext/2015/01/03/part-r-00015-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:49    9173813 elb/plaintext/2015/01/03/part-r-00016-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:49   11899582 elb/plaintext/2015/01/03/part-r-00017-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:49          0 elb/plaintext/2015/01/03_$folder$
2016-11-23 17:54:50    8612843 elb/plaintext/2015/01/04/part-r-00018-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:50   10731284 elb/plaintext/2015/01/04/part-r-00019-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:50    9984735 elb/plaintext/2015/01/04/part-r-00020-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:50    9290089 elb/plaintext/2015/01/04/part-r-00021-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:50    7896339 elb/plaintext/2015/01/04/part-r-00022-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:51    8321364 elb/plaintext/2015/01/04/part-r-00023-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:51          0 elb/plaintext/2015/01/04_$folder$
2016-11-23 17:54:51    7641062 elb/plaintext/2015/01/05/part-r-00024-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:51   10253377 elb/plaintext/2015/01/05/part-r-00025-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:51    8502765 elb/plaintext/2015/01/05/part-r-00026-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:51   11518464 elb/plaintext/2015/01/05/part-r-00027-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:51    7945189 elb/plaintext/2015/01/05/part-r-00028-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:51    7864475 elb/plaintext/2015/01/05/part-r-00029-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:51          0 elb/plaintext/2015/01/05_$folder$
2016-11-23 17:54:51   11342140 elb/plaintext/2015/01/06/part-r-00030-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:51    8063755 elb/plaintext/2015/01/06/part-r-00031-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:52    9387508 elb/plaintext/2015/01/06/part-r-00032-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:52    9732343 elb/plaintext/2015/01/06/part-r-00033-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:52   11510326 elb/plaintext/2015/01/06/part-r-00034-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:52    9148117 elb/plaintext/2015/01/06/part-r-00035-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:52          0 elb/plaintext/2015/01/06_$folder$
2016-11-23 17:54:52    8402024 elb/plaintext/2015/01/07/part-r-00036-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:52    8282860 elb/plaintext/2015/01/07/part-r-00037-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:52   11575283 elb/plaintext/2015/01/07/part-r-00038-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:53    8149059 elb/plaintext/2015/01/07/part-r-00039-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:53   10037269 elb/plaintext/2015/01/07/part-r-00040-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:53   10019678 elb/plaintext/2015/01/07/part-r-00041-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:53          0 elb/plaintext/2015/01/07_$folder$
2016-11-23 17:54:53          0 elb/plaintext/2015/01_$folder$
2016-11-23 17:54:53          0 elb/plaintext/2015_$folder$
```

#### ALTER TABLE ADD PARTITION ausführen
<a name="run-alter-table-add-partition"></a>

Da die Daten nicht im Hive-Format vorliegen, können Sie den `MSCK REPAIR TABLE`-Befehl nicht verwenden, um der Tabelle die Partitionen hinzuzufügen, nachdem Sie sie erstellt haben. Stattdessen können Sie den [ALTER TABLE ADD PARTITION](alter-table-add-partition.md)-Befehl verwenden, um jede Partition manuell hinzuzufügen. Um beispielsweise die Daten in s3://athena-examples - *myregion* /elb/plaintext/2015/01/01/ zu laden, können Sie die folgende Abfrage ausführen. Beachten Sie, dass nicht für jeden Amazon-S3-Ordner eine separate Partitionsspalte erforderlich ist und dass sich der Partitionsschlüsselwert vom Amazon-S3-Schlüssel unterscheiden kann.

```
ALTER TABLE elb_logs_raw_native_part ADD PARTITION (dt='2015-01-01') location 's3://athena-examples-us-west-1/elb/plaintext/2015/01/01/'
```

Wenn bereits eine Partition vorhanden ist, erhalten Sie die Fehlermeldung Partition bereits vorhanden. Um diesen Fehler zu vermeiden, können Sie die `IF NOT EXISTS`-Klausel verwenden. Weitere Informationen finden Sie unter [ALTER TABLE ADD PARTITION](alter-table-add-partition.md). Um eine Partition zu entfernen, können Sie [ALTER TABLE DROP PARTITION](alter-table-drop-partition.md) verwenden. 

## Partitionsprojektion berücksichtigen
<a name="partitions-partition-projection"></a>

Um zu vermeiden, dass Sie Partitionen selbst verwalten müssen, können Sie die Partitionsprojektion verwenden. Die Partitionsprojektion ist eine Option für hoch partitionierte Tabellen, deren Struktur im Voraus bekannt ist. Bei der Partitionsprojektion werden Partitionswerte und Speicherorte aus Tabelleneigenschaften berechnet, die Sie konfigurieren, anstatt aus einem Metadaten-Repository zu lesen. Da die Berechnungen im Arbeitsspeicher schneller sind als die Remote-Suche, kann die Verwendung der Partitionsprojektion die Abfragelaufzeiten erheblich verkürzen. 

Weitere Informationen finden Sie unter [Partitionsprojektion mit Amazon Athena verwenden](partition-projection.md).

## Weitere Ressourcen
<a name="partitions-additional-resources"></a>
+ Informationen zu Partitionierungsoptionen für Firehose-Daten finden Sie unter [Beispiel für Amazon Data Firehose](partition-projection-kinesis-firehose-example.md).
+ Sie können den [JDBC-Treiber](connect-with-jdbc.md) verwenden, um das Hinzufügen von Partitionen zu automatisieren. 
+ Sie können CTAS und INSERT INTO verwenden, um eine Datenmenge zu partitionieren. Weitere Informationen finden Sie unter [Verwenden von CTAS und INSERT INTO für ETL und Datenanalyse](ctas-insert-into-etl.md).

# Partitionsprojektion mit Amazon Athena verwenden
<a name="partition-projection"></a>

Sie können die Partitionsprojektion in Athena verwenden, um die Abfrageverarbeitung von hochpartitionierten Tabellen zu beschleunigen und die Partitionsverwaltung zu automatisieren.

Bei der Partitionsprojektion berechnet Athena Partitionswerte und Speicherorte aus Tabelleneigenschaften, die Sie direkt in Ihrer Tabelle in AWS Glue konfigurieren. Die Tabelleneigenschaften ermöglichen es Athena, die erforderlichen Partitionsinformationen zu „projizieren“ oder zu ermitteln, anstatt eine zeitaufwändigere Suche nach Metadaten in AWS Glue Data Catalog durchführen zu müssen. Da In-Memory-Operationen oft schneller sind als Remote-Operationen, kann die Partitionsprojektion die Laufzeit von Abfragen für hochpartitionierte Tabellen reduzieren. Je nach den spezifischen Merkmalen der Abfrage und den zugrunde liegenden Daten kann die Partitionsprojektion die Abfragelaufzeit für Abfragen, die auf den Abruf von Partitionsmetadaten beschränkt sind, erheblich verkürzen.

## Grundlegendes über Partitionsbereinigung im Vergleich zu Partitionsprojektion
<a name="partition-projection-pruning-vs-projection"></a>

Die Partitionsbeschneidung erfasst Metadaten und „beschneidet“ sie nur für die Partitionen, die für Ihre Abfrage gelten. Dies beschleunigt häufig Abfragen. Athena verwendet die Partitionsbeschneidung für alle Tabellen mit Partitionsspalten, einschließlich der Tabellen, die für die Partitionsprojektion konfiguriert sind.

Normalerweise `GetPartitions` ruft Athena bei der Verarbeitung von Abfragen den auf, AWS Glue Data Catalog bevor die Partition bereinigt wird. Wenn eine Tabelle über eine große Anzahl von Partitionen verfügt, kann die Verwendung von `GetPartitions` die Leistung negativ beeinflussen. Um dies zu vermeiden, können Sie die Partitionsprojektion verwenden. Die Partitionsprojektion ermöglicht es Athena, Aufrufe von `GetPartitions` zu vermeiden, da die Partitionsprojektionskonfiguration Athena alle notwendigen Informationen gibt, um die Partitionen selbst zu erstellen.

## So verwenden Sie Partitionsprojektion
<a name="partition-projection-using"></a>

Um die Partitionsprojektion zu verwenden, geben Sie die Bereiche der Partitionswerte und Projektionstypen für jede Partitionsspalte in den Tabelleneigenschaften im AWS Glue Data Catalog oder in Ihrem [externen Hive-Metastore](connect-to-data-source-hive.md) an. Diese benutzerdefinierten Eigenschaften in der Tabelle ermöglichen es Athena zu wissen, welche Partitionsmuster zu erwarten sind, wenn eine Abfrage für die Tabelle ausgeführt wird. Während der Abfrageausführung verwendet Athena diese Informationen, um die Partitionswerte zu projizieren, anstatt sie aus dem AWS Glue Data Catalog oder einem externen Hive-Metastore abzurufen. Dies reduziert nicht nur die Ausführungszeit der Abfrage, sondern automatisiert auch das Partitionsmanagement, da dadurch keine manuelle Erstellung von Partitionen in Athena, AWS Glue oder Ihrem externen Hive-Metastore erforderlich ist.

**Wichtig**  
Wenn Sie die Partitionsprojektion für eine Tabelle aktivieren, ignoriert Athena alle Partitionsmetadaten, die für die Tabelle im AWS Glue Data Catalog oder Hive-Metastore registriert sind.

## Einige Anwendungsfälle
<a name="partition-projection-use-cases"></a>

Szenarien, in denen Partitionsprojektion sinnvoll ist, sind die etwa folgenden:
+ Abfragen für eine hochpartitionierte Tabelle werden nicht so schnell abgeschlossen, wie Sie dies wünschen.
+ Sie fügen regelmäßig Partitionen zu Tabellen hinzu, wenn neue Datums- oder Zeitpartitionen in Ihren Daten erstellt werden. Mit der Partitionsprojektion konfigurieren Sie relative Datumsbereiche, die beim Eintreffen neuer Daten verwendet werden können. 
+ Sie haben stark partitionierte Daten in Amazon S3. Es ist nicht praktikabel, die Daten in Ihrem AWS Glue Data Catalog oder Hive-Metastore zu modellieren, und Ihre Abfragen lesen nur kleine Teile davon.

### Projizierbare Partitionsstrukturen
<a name="partition-projection-known-data-structures"></a>

Die Partitionsprojektion kann am einfachsten konfiguriert werden, wenn Ihre Partitionen einem vorhersehbaren Muster folgen, wie z. B.
+ **Ganzzahlen** – Jede fortlaufende Folge von ganzen Zahlen wie `[1, 2, 3, 4, ..., 1000]` oder `[0500, 0550, 0600, ..., 2500]`.
+ **Datumsangaben** – Jede fortlaufende Folge von Datumsangaben oder Datum/Uhrzeitangaben wie `[20200101, 20200102, ..., 20201231]` oder `[1-1-2020 00:00:00, 1-1-2020 01:00:00, ..., 12-31-2020 23:00:00]`.
+ **Aufzählungswerte** — Eine endliche Menge von Aufzählungswerten wie Flughafencodes oder. AWS-Regionen
+ **AWS-Service Logs** — AWS-Service Logs haben in der Regel eine bekannte Struktur, deren Partitionsschema Sie angeben können AWS Glue und die Athena daher für die Partitionsprojektion verwenden kann.

### So passen Sie die Partitionspfadvorlage an
<a name="partition-projection-custom-s3-storage-locations"></a>

Standardmäßig erstellt Athena Partitionsspeicherorte mithilfe des Formulars `s3://amzn-s3-demo-bucket/<table-root>/partition-col-1=<partition-col-1-val>/partition-col-2=<partition-col-2-val>/`, aber wenn Ihre Daten anders organisiert sind, bietet Athena einen Mechanismus zum Anpassen dieser Pfadvorlage. Informationen zu den erforderlichen Schritten finden Sie unter [So geben Sie benutzerdefinierte S3-Speicherorten an](partition-projection-setting-up.md#partition-projection-specifying-custom-s3-storage-locations).

## Überlegungen und Einschränkungen
<a name="partition-projection-considerations-and-limitations"></a>

Beachten Sie die folgenden Überlegungen:
+ Die Partitionsprojektion beseitigt die Notwendigkeit, Partitionen manuell in AWS Glue oder einem externen Hive-Metastore anzugeben.
+ Wenn Sie die Partitionsprojektion für eine Tabelle aktivieren, ignoriert Athena alle Partitionsmetadaten im AWS Glue Data Catalog oder externen Hive-Metastore für diese Tabelle.
+ Wenn eine projizierte Partition in Amazon S3 nicht vorhanden ist, projiziert Athena die Partition weiter aus. Athena löst keinen Fehler aus, aber es werden keine Daten zurückgegeben. Wenn jedoch zu viele Ihrer Partitionen leer sind, kann die Leistung im Vergleich zu herkömmlichen Partitionen langsamer sein. AWS Glue Wenn mehr als die Hälfte der projizierten Partitionen leer ist, wird empfohlen, herkömmliche Partitionen zu verwenden.
+ Abfragen für Werte, die außerhalb der für die Partitionsprojektion definierten Bereichsgrenzen liegen, geben keinen Fehler zurück. Stattdessen wird die Abfrage ausgeführt, gibt aber null Zeilen aus. Wenn Sie beispielsweise zeitbezogene Daten haben, die im Jahr 2020 beginnen und als `'projection.timestamp.range'='2020/01/01,NOW'` definiert sind, wird eine Abfrage wie `SELECT * FROM table-name WHERE timestamp = '2019/02/02'` erfolgreich abgeschlossen, aber Nullzeilen zurückgeben.
+ Die Partitionsprojektion ist nur verwendbar, wenn die Tabelle über Athena abgefragt wird. Wenn dieselbe Tabelle durch einen anderen Service wie Amazon Redshift Spectrum, Athena for Spark oder Amazon EMR gelesen wird, werden die Standard-Partitionsmetadaten verwendet.
+ Da es sich bei der Partitionsprojektion nur um eine DML-Funktion handelt, werden `SHOW PARTITIONS` keine Partitionen aufgeführt, die von Athena projiziert, aber nicht im AWS Glue Katalog oder im externen Hive-Metastore registriert sind. 
+ Athena verwendet die Tabelleneigenschaften von Ansichten nicht als Konfiguration für die Partitionsprojektion. Um diese Einschränkung zu umgehen, konfigurieren und aktivieren Sie die Partitionsprojektion in den Tabelleneigenschaften für die Tabellen, auf die die Ansichten verweisen.

## Video
<a name="partition-projection-video"></a>

Das folgende Video zeigt, wie Sie die Partitionsprojektion verwenden, um die Leistung Ihrer Abfragen in Athena zu verbessern.

[![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/iUD5pPpcyZk/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/iUD5pPpcyZk)


**Topics**
+ [

## Grundlegendes über Partitionsbereinigung im Vergleich zu Partitionsprojektion
](#partition-projection-pruning-vs-projection)
+ [

## So verwenden Sie Partitionsprojektion
](#partition-projection-using)
+ [

## Einige Anwendungsfälle
](#partition-projection-use-cases)
+ [

## Überlegungen und Einschränkungen
](#partition-projection-considerations-and-limitations)
+ [

## Video
](#partition-projection-video)
+ [

# Partitionsprojektions einrichten
](partition-projection-setting-up.md)
+ [

# Unterstützte Typen für die Partitionsprojektion
](partition-projection-supported-types.md)
+ [

# Dynamische ID-Partitionierung verwenden
](partition-projection-dynamic-id-partitioning.md)
+ [

# Beispiel für Amazon Data Firehose
](partition-projection-kinesis-firehose-example.md)

# Partitionsprojektions einrichten
<a name="partition-projection-setting-up"></a>

Das Einrichten der Partitionsprojektion in den Eigenschaften einer Tabelle ist ein zweistufiger Prozess:

1. Geben Sie die Datenbereiche und relevanten Muster für jede Partitionsspalte an oder verwenden Sie eine benutzerdefinierte Vorlage.

1. Aktivieren Sie die Partitionsprojektion für die Tabelle.

**Anmerkung**  
Bevor Sie einer vorhandenen Tabelle Partitionsprojektionseigenschaften hinzufügen, muss die Partitionsspalte, für die Sie Partitionsprojektionseigenschaften einrichten, bereits im Tabellenschema vorhanden sein. Wenn die Partitionsspalte noch nicht existiert, müssen Sie der vorhandenen Tabelle manuell eine Partitionsspalte hinzufügen. AWS Glue führt diesen Schritt nicht automatisch für Sie aus. 

In diesem Abschnitt wird gezeigt, wie Sie die Tabelleneigenschaften für festlegen AWS Glue. Um sie festzulegen, können Sie die AWS Glue Konsole, [CREATE TABLE](create-table.md) Athena-Abfragen oder [AWS Glue API](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api.html)Operationen verwenden. Das folgende Verfahren zeigt, wie die Eigenschaften in der AWS Glue Konsole festgelegt werden.

**So konfigurieren und aktivieren Sie die Partitionsprojektion mit der AWS Glue Konsole**

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS Glue Konsole unter [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).

1. Wählen Sie die Registerkarte **Tables** (Tabellen).

   Auf der Registerkarte **Tables** (Tabellen) können Sie vorhandene Tabellen bearbeiten oder mit **Add tables** (Tabellen hinzufügen) neue Tabellen erstellen. Informationen zum manuellen Hinzufügen von Tabellen oder zur Verwendung eines Crawlers dafür finden Sie unter [Arbeiten mit Tabellen in der AWS Glue -Konsole](https://docs.aws.amazon.com/glue/latest/dg/console-tables.html) im *AWS Glue -Entwicklerhandbuch*.

1. Wählen Sie in der Liste der Tabellen den Link für die Tabelle aus, die Sie bearbeiten möchten.  
![\[Wählen Sie in der AWS Glue Konsole eine Tabelle aus, die Sie bearbeiten möchten.\]](http://docs.aws.amazon.com/de_de/athena/latest/ug/images/partition-projection-1.png)

1. Wählen Sie **Actions** (Aktionen) und **Edit table** (Tabelle bearbeiten) aus.

1. Fügen Sie auf der Seite **Edit table** (Tabelle bearbeiten) im Abschnitt **Table properties** (Tabelleneigenschaften) für jede partitionierte Spalte das folgende Schlüssel-Wert-Paar hinzu:

   1. Fügen Sie für **Key (Schlüssel)** `projection.columnName.type` hinzu.

   1. Fügen Sie für **Value (Wert)** einen der unterstützten Typen hinzu: `enum`, `integer`, `date` oder `injected`. Weitere Informationen finden Sie unter [Unterstützte Typen für die Partitionsprojektion](partition-projection-supported-types.md).

1. Fügen Sie nach den Anweisungen in [Unterstützte Typen für die Partitionsprojektion](partition-projection-supported-types.md) zusätzliche Schlüssel-Wert-Paare gemäß Ihren Konfigurationsanforderungen hinzu.

   In der folgenden Beispieltabellenkonfiguration wird die `year`-Spalte für die Partitionsprojektion konfiguriert, wobei die Werte, die zurückgegeben werden können, auf einen Bereich von 2010 bis 2016 beschränkt werden.  
![\[Konfigurieren der Partitionsprojektion für eine Partitionsspalte in den Eigenschaften der AWS Glue -Konsolentabelle.\]](http://docs.aws.amazon.com/de_de/athena/latest/ug/images/partition-projection-3.png)

1. Fügen Sie ein Schlüssel-Wert-Paar hinzu, um die Partitionsprojektion zu aktivieren. Geben Sie für **Key (Schlüssel)** den Wert `projection.enabled` und für dessen **Value (Wert)** `true` ein.
**Anmerkung**  
Sie können die Partitionsprojektion für diese Tabelle jederzeit deaktivieren, indem Sie `projection.enabled` auf `false` setzen.

1. Klicken Sie auf **Save **, sobald Sie fertig sind.

1. Prüfen Sie im Athena-Abfrage-Editor die Spalten, die Sie für die Tabelle konfiguriert haben.

   Die folgende Beispielabfrage verwendet `SELECT DISTINCT`, um die eindeutigen Werte aus der `year`-Spalte zurückzugeben. Die Datenbank enthält Daten von 1987 bis 2016, aber die `projection.year.range`-Eigenschaft beschränkt die zurückgegebenen Werte auf die Jahre 2010 bis 2016.  
![\[Abfragen einer Spalte, die die Partitionsprojektion verwendet.\]](http://docs.aws.amazon.com/de_de/athena/latest/ug/images/partition-projection-5.png)
**Anmerkung**  
Wenn Sie `projection.enabled` auf `true` festlegen, aber nicht mindestens eine Partitionsspalte konfigurieren, erhalten Sie eine Fehlermeldung wie die folgende:  
`HIVE_METASTORE_ERROR: Table database_name.table_name is configured for partition projection, but the following partition columns are missing projection configuration: [column_name] (table database_name.table_name)`.

## So geben Sie benutzerdefinierte S3-Speicherorten an
<a name="partition-projection-specifying-custom-s3-storage-locations"></a>

Wenn Sie Tabelleneigenschaften in bearbeiten AWS Glue, können Sie auch eine benutzerdefinierte Amazon S3 S3-Pfadvorlage für die projizierten Partitionen angeben. Eine benutzerdefinierte Vorlage ermöglicht Athena die ordnungsgemäße Zuweisung von Partitionswerten zu benutzerdefinierten Amazon-S3-Dateispeicherorten, die keinem typischen `.../column=value/...`-Muster folgen. 

Die Verwendung einer benutzerdefinierten Vorlage ist optional. Wenn Sie jedoch eine benutzerdefinierte Vorlage verwenden, muss die Vorlage einen Platzhalter für jede Partitionsspalte enthalten. Vorlagenspeicherorte müssen mit einem Schrägstrich enden, damit die partitionierten Datendateien pro Partition in einem „Ordner“ gespeichert werden.

**So geben Sie eine benutzerdefinierte Partitionsspeicherortvorlage an:**

1. Folgen Sie den Schritten zur [Konfiguration und Aktivierung der Partitionsprojektion mithilfe der AWS Glue Konsole](#partition-projection-setting-up-procedure) und fügen Sie ein zusätzliches Schlüssel-Wert-Paar hinzu, das eine benutzerdefinierte Vorlage wie folgt spezifiziert:

   1. Geben Sie für **Key (Schlüssel)** `storage.location.template` ein.

   1. Geben Sie für **Value (Wert)** einen Speicherort an, der für jede Partitionsspalte einen Platzhalter enthält. Stellen Sie sicher, dass jeder Platzhalter (und der S3-Pfad selbst) durch einen einzelnen Schrägstrich beendet wird.

      In den folgenden Beispielvorlagenwerten wird von einer Tabelle mit den Partitionsspalten `a`, `b` und `c` ausgegangen.

      ```
      s3://amzn-s3-demo-bucket/table_root/a=${a}/${b}/some_static_subdirectory/${c}/      
      ```

      ```
      s3://amzn-s3-demo-bucket/table_root/c=${c}/${b}/some_static_subdirectory/${a}/${b}/${c}/${c}/      
      ```

      Für dieselbe Tabelle ist der folgende Beispielvorlagenwert ungültig, da er keinen Platzhalter für die Spalte `c` enthält.

      ```
      s3://amzn-s3-demo-bucket/table_root/a=${a}/${b}/some_static_subdirectory/         
      ```

1. Wählen Sie **Anwenden** aus.

# Unterstützte Typen für die Partitionsprojektion
<a name="partition-projection-supported-types"></a>

Eine Tabelle kann eine beliebige Kombination aus den Partitionsspaltentypen `enum`, `integer`, `date,` oder `injected` aufweisen.

## Aufzählungstyp
<a name="partition-projection-enum-type"></a>

Verwenden Sie den `enum` Typ für Partitionsspalten, deren Werte Mitglieder einer Aufzählung sind (z. B. Flughafencodes oder). AWS-Regionen

Definieren Sie die Partitionseigenschaften in der Tabelle wie folgt:


****  

| Name der Eigenschaft | Beispielwerte | Description | 
| --- | --- | --- | 
| projection.columnName.type |  `enum`  | Erforderlich Der Projektionstyp, der für Spalten verwendet werden soll. columnName Der Wert muss enum (ohne Beachtung der Groß- und Kleinschreibung) sein, um die Verwendung des Aufzählungstyps zu signalisieren. Vorangehende und nachfolgende Leerzeichen sind zulässig. | 
| projection.columnName.values |  `A,B,C,D,E,F,G,Unknown`  | Erforderlich Eine durch Kommas getrennte Liste von aufgezählten Partitionswerten für eine Spalte. columnName Jeder Leerraum wird als Teil eines Aufzählungswerts betrachtet. | 

**Anmerkung**  
Als bewährte Methode empfehlen wir, die Verwendung von `enum`-basierten Partitionsprojektionen auf einige Dutzend oder weniger zu beschränken. Es gibt zwar keine spezifische Obergrenze für `enum` Projektionen, aber die Gesamtgröße der Metadaten Ihrer Tabelle darf die AWS Glue Grenze von etwa 1 MB bei der GZIP-Komprimierung nicht überschreiten. Beachten Sie, dass dieses Limit für wichtige Teile Ihrer Tabelle wie Spaltennamen, Speicherort, Speicherformat und andere freigegeben wird. Wenn Sie feststellen, dass Sie IDs in Ihrer `enum` Projektion mehr als ein paar Dutzend eindeutige Werte verwenden, sollten Sie einen alternativen Ansatz in Betracht ziehen, z. B. das Aufteilen in einer kleineren Anzahl von Einzelwerten in einem Ersatzfeld. Durch den Handel mit Kardinalität können Sie die Anzahl der eindeutigen Werte in Ihrem `enum`-Feld steuern. 

## Ganzzahl-Typ
<a name="partition-projection-integer-type"></a>

Verwenden Sie den Ganzzahl-Typ für Partitionsspalten, deren mögliche Werte als Ganzzahlen innerhalb eines definierten Bereichs interpretierbar sind. Projizierte Ganzzahl-Spalten sind derzeit auf den Java Signed Long-Bereich (-263 bis 263-1 inklusive) begrenzt.


****  

| Name der Eigenschaft | Beispielwerte | Description | 
| --- | --- | --- | 
| projection.columnName.type |  `integer`  | Erforderlich Der Projektionstyp, der für die Spalte verwendet werden soll. columnName Der Wert muss integer (ohne Beachtung der Groß- und Kleinschreibung) sein, um die Verwendung des Ganzzahl-Typs zu signalisieren. Vorangehende und nachfolgende Leerzeichen sind zulässig. | 
| projection.columnName.range |  `0,10` `-1,8675309` `0001,9999`  | Erforderlich Eine durch Kommas getrennte Liste mit zwei Elementen, die die minimalen und maximalen Bereichswerte enthält, die von Abfragen in der Spalte zurückgegeben werden sollen. columnName Beachten Sie, dass die Werte durch Kommata voneinander getrennt werden müssen, nicht durch einen Bindestrich. Diese Werte sind einschließlich, können negativ sein und können vorangehende Nullen aufweisen. Vorangehende und nachfolgende Leerzeichen sind zulässig. | 
| projection.columnName.interval |  `1` `5`  | Optional. Eine positive Ganzzahl, die das Intervall zwischen aufeinanderfolgenden Partitionswerten für die Spalte angibt. columnName Beispiel: Ein range-Wert von „1,3“ mit dem interval-Wert „1“ erzeugt die Werte 1, 2 und 3. Derselbe range-Wert mit dem interval-Wert „2" erzeugt die Werte 1 und 3, wobei 2 übersprungen wird. Vorangehende und nachfolgende Leerzeichen sind zulässig. Der Standardwert ist 1. | 
| projection.columnName.digits |  `1` `5`  | Optional. Eine positive Ganzzahl, die die Anzahl der Ziffern angibt, die in der endgültigen Darstellung des Partitionswerts für die Spalte enthalten sein sollencolumnName. Beispiel: Ein range-Wert von „1,3“ mit dem digits-Wert „1“ erzeugt die Werte 1, 2 und 3. Derselbe range-Wert mit dem digits-Wert „2" erzeugt die Werte 01, 02 und 03. Vorangehende und nachfolgende Leerzeichen sind zulässig. Der Standard beinhaltet keine feste Anzahl von Ziffern und keine vorangehenden Nullen. | 

## Datumstyp
<a name="partition-projection-date-type"></a>

Verwenden Sie den Datumstyp für Partitionsspalten, deren Werte innerhalb eines definierten Bereichs als Datumsangaben (mit optionalen Uhrzeiten) interpretierbar sind.

**Wichtig**  
Projizierte Datumsspalten werden in Coordinated Universal Time (UTC) zur Abfrageausführungszeit generiert.


****  

| Name der Eigenschaft | Beispielwerte | Description | 
| --- | --- | --- | 
| projection.columnName.type |  `date`  | Erforderlich Der Projektionstyp, der für die Spalte verwendet werden sollcolumnName. Der Wert muss date (ohne Beachtung der Groß- und Kleinschreibung) sein, um die Verwendung des Datumstyps zu signalisieren. Vorangehende und nachfolgende Leerzeichen sind zulässig. | 
| projection.columnName.range |  `201701,201812` `01-01-2010,12-31-2018` `NOW-3YEARS,NOW` `201801,NOW+1MONTH`  |  Erforderlich Eine aus zwei Elementen bestehende, durch Kommas getrennte Liste, die die Minimal- und `range` Maximalwerte für die Spalte enthält. *columnName* Diese Werte sind einschließlich und können jedes Format verwenden, das mit den Java `java.time.*`-Datentypen kompatibel ist. Sowohl der Minimal- als auch der Maximalwert müssen dasselbe Format verwenden. Das in der `.format`-Eigenschaft angegebene Format muss dem Format entsprechen, das für diese Werte verwendet wird. Diese Spalte kann auch relative Datumszeichenfolgen enthalten, die in diesem Muster für reguläre Ausdrücke formatiert sind: `\s*NOW\s*(([\+\-])\s*([0-9]+)\s*(YEARS?\|MONTHS?\|WEEKS?\|DAYS?\|HOURS?\|MINUTES?\|SECONDS?)\s*)?` Leerzeichen sind erlaubt, aber in Datumsliteralen gelten sie als Teil der Datumszeichenfolgen selbst.  | 
| projection.columnName.format |  `yyyyMM` `dd-MM-yyyy` `dd-MM-yyyy-HH-mm-ss`  | Erforderlich Eine Zeichenfolge im Datumsformat, die auf dem Java-Datumsformat basiert. [DateTimeFormatter](https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html) Kann ein beliebiger unterstützter Java.time.\$1-Typ sein. | 
| projection.columnName.interval |  `1` `5`  |  Eine positive Ganzzahl, die das Intervall zwischen aufeinanderfolgenden Partitionswerten für die Spalte angibt*columnName*. Beispiel: Ein `range`-Wert von `2017-01,2018-12` mit einem `interval`-Wert von `1` und einem `interval.unit`-Wert von `MONTHS` erzeugt die Werte 2017-01, 2017-02, 2017-03 usw. Derselbe `range`-Wert mit einem `interval`-Wert von `2` und einem `interval.unit`-Wert von `MONTHS` erzeugt die Werte 2017-01, 2017-03, 2017-05 usw. Vorangehende und nachfolgende Leerzeichen sind zulässig. Wenn die angegebenen Datumsangaben eine Genauigkeit von einem Tag oder einem Monat aufweisen, ist `interval` optional und standardmäßig 1 Tag bzw. 1 Monat. Andernfalls ist `interval` erforderlich.  | 
| projection.columnName.interval.unit |  `YEARS` `MONTHS` `WEEKS` `DAYS` `HOURS` `MINUTES` `SECONDS` `MILLIS`  |  Ein Wort in einer Zeiteinheit, das die serialisierte Form von a [ChronoUnit](https://docs.oracle.com/javase/8/docs/api/java/time/temporal/ChronoUnit.html)darstellt. Mögliche Werte sind `YEARS`, `MONTHS`, `WEEKS`, `DAYS`, `HOURS`, `MINUTES`, `SECONDS` oder `MILLIS`. Bei den Werten wird die Groß- und Kleinschreibung nicht berücksichtigt. Wenn die angegebenen Datumsangaben eine Genauigkeit von einem Tag oder einem Monat aufweisen, ist `interval.unit` optional und standardmäßig 1 Tag bzw. 1 Monat. Andernfalls ist `interval.unit` erforderlich.  | 

**Example – Partition nach Monat**  
In der folgenden Beispieltabellenkonfiguration werden Daten von 2015 bis heute nach Monaten partitioniert.  

```
'projection.month.type'='date', 
'projection.month.format'='yyyy-MM', 
'projection.month.interval'='1', 
'projection.month.interval.unit'='MONTHS', 
'projection.month.range'='2015-01,NOW', 
...
```

## Injizierter Typ
<a name="partition-projection-injected-type"></a>

Verwenden Sie den injizierten Typ für Partitionsspalten mit möglichen Werten, die nicht prozedural innerhalb eines logischen Bereichs generiert werden können, aber in der `WHERE`-Klausel einer Abfrage als einzelner Wert bereitgestellt werden.

Es ist wichtig, dabei die folgenden Punkte zu beachten:
+ Abfragen zu injizierten Spalten schlagen fehl, wenn nicht für jede injizierte Spalte ein Filterausdruck bereitgestellt wird.
+ Abfragen mit mehreren Werten für einen Filterausdruck in einer injizierten Spalte sind nur erfolgreich, wenn die Werte disjunkt sind.
+ Nur Spalten von `string`-Typen werden unterstützt.
+ Wenn Sie die `WHERE IN`-Klausel mit einer injizierten Partitionsspalte verwenden, gibt es eine Obergrenze von 1.000 Werten, die Sie in der `IN`-Liste angeben können. Um einen Datensatz mit mehr als 1.000 Partitionen für eine injizierte Spalte abzufragen, teilen Sie die Abfrage in mehrere kleinere Abfragen mit jeweils bis zu 1.000 Werten in der `WHERE IN`-Klausel auf und aggregieren Sie dann die Ergebnisse.


****  

| Name der Eigenschaft | Wert | Description | 
| --- | --- | --- | 
| projection.columnName.type |  `injected`  | Erforderlich Der Projektionstyp, der für die Spalte columnName verwendet werden soll. Es wird nur der string-Typ unterstützt. Der angegebene Wert muss injected (ohne Beachtung der Groß- und Kleinschreibung) sein. Vorangehende und nachfolgende Leerzeichen sind zulässig. | 

Weitere Informationen finden Sie unter [Wann sollte der `injected`-Projektionstyp verwendet werden](partition-projection-dynamic-id-partitioning.md#partition-projection-injection).

# Dynamische ID-Partitionierung verwenden
<a name="partition-projection-dynamic-id-partitioning"></a>

Wenn Ihre Daten nach einer Eigenschaft mit hoher Kardinalität partitioniert sind oder die Werte nicht im Voraus bekannt sind, können Sie den `injected`-Projektionstyp verwenden. Beispiele für solche Eigenschaften sind Benutzernamen sowie IDs Geräte oder Produkte. Wenn Sie den `injected`-Projektionstyp zum Konfigurieren eines Partitionsschlüssels verwenden, verwendet Athena Werte aus der Abfrage selbst, um die Menge der zu lesenden Partitionen zu berechnen.

Damit Athena eine Abfrage für eine Tabelle ausführen kann, deren Partitionsschlüssel mit dem `injected`-Projektionstyp konfiguriert ist, muss Folgendes zutreffen:
+ Ihre Abfrage muss mindestens einen Wert für den Partitionsschlüssel enthalten.
+ Bei den Werten muss es sich um Literale oder Ausdrücke handeln, die ohne Lesen von Daten ausgewertet werden können.

Wenn eines dieser Kriterien nicht erfüllt ist, schlägt Ihre Abfrage mit der folgenden Fehlermeldung fehl:

CONSTRAINT\$1VIOLATION: Für die Spalte *column\$1name* mit der injizierten projizierten Partition darf die WHERE-Klausel nur statische Gleichheitsbedingungen enthalten, und mindestens eine solche Bedingung muss erfüllt sein.

## Wann sollte der `injected`-Projektionstyp verwendet werden
<a name="partition-projection-injection"></a>

Stellen Sie sich vor, Sie haben einen Datensatz, der aus Ereignissen von IoT-Geräten besteht, die auf den Geräten IDs partitioniert sind. Dieser Datensatz weist folgende Merkmale auf:
+ Die Geräte IDs werden zufällig generiert.
+ Neue Geräte werden regelmäßig bereitgestellt.
+ Derzeit gibt es Hunderttausende Geräte und in Zukunft werden es Millionen sein.

Dieser Datensatz lässt sich mit herkömmlichen Metastores nur schwer verwalten. Es ist schwierig, die Partitionen zwischen dem Datenspeicher und dem Metastore synchron zu halten. Das Filtern von Partitionen kann während der Abfrageplanung langsam sein. Wenn Sie jedoch eine Tabelle für die Verwendung der Partitionsprojektion konfigurieren und den `injected`-Projektionstyp verwenden, haben Sie zwei Vorteile: Sie müssen keine Partitionen im Metastore verwalten und Ihre Abfragen müssen nicht nach Partitionsmetadaten suchen.

Im folgenden `CREATE TABLE`-Beispiel wird eine Tabelle für den soeben beschriebenen Geräteereignisdatensatz erstellt. Die Tabelle verwendet den Typ der injizierten Projektion.

```
CREATE EXTERNAL TABLE device_events (
  event_time TIMESTAMP,
  data STRING,
  battery_level INT
)
PARTITIONED BY (
  device_id STRING
)
LOCATION "s3://amzn-s3-demo-bucket/prefix/"
TBLPROPERTIES (
  "projection.enabled" = "true",
  "projection.device_id.type" = "injected",
  "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${device_id}"
)
```

Die folgende Beispielabfrage ermittelt die Anzahl der Ereignisse, die innerhalb von 12 Stunden von drei bestimmten Geräten empfangen wurden.

```
SELECT device_id, COUNT(*) AS events
FROM device_events
WHERE device_id IN (
  '4a770164-0392-4a41-8565-40ed8cec737e',
  'f71d12cf-f01f-4877-875d-128c23cbde17',
  '763421d8-b005-47c3-ba32-cc747ab32f9a'
)
AND event_time BETWEEN TIMESTAMP '2023-11-01 20:00' AND TIMESTAMP '2023-11-02 08:00'
GROUP BY device_id
```

Wenn Sie diese Abfrage ausführen, identifiziert Athena die drei Werte für den `device_id`-Partitionsschlüssel und verwendet sie zur Berechnung der Partitionsspeicherorte. Athena verwendet den Wert für die `storage.location.template`-Eigenschaft, um die folgenden Standorte zu generieren:
+ `s3://amzn-s3-demo-bucket/prefix/4a770164-0392-4a41-8565-40ed8cec737e`
+ `s3://amzn-s3-demo-bucket/prefix/f71d12cf-f01f-4877-875d-128c23cbde17`
+ `s3://amzn-s3-demo-bucket/prefix/763421d8-b005-47c3-ba32-cc747ab32f9a`

Wenn Sie die `storage.location.template`-Eigenschaft in der Konfiguration der Partitionsprojektion weglassen, verwendet Athena eine Partitionierung im Hive-Stil, um Partitionspositionen basierend auf dem Wert in `LOCATION` zu projizieren (z. B. `s3://amzn-s3-demo-bucket/prefix/device_id=4a770164-0392-4a41-8565-40ed8cec737e`).

# Beispiel für Amazon Data Firehose
<a name="partition-projection-kinesis-firehose-example"></a>

Wenn Sie Firehose verwenden, um Daten an Amazon S3 zu liefern, schreibt die Standardkonfiguration Objekte mit Schlüsseln, die wie im folgenden Beispiel aussehen:

```
s3://amzn-s3-demo-bucket/prefix/yyyy/MM/dd/HH/file.extension
```

Um eine Athena-Tabelle zu erstellen, die die Partitionen automatisch bei der Abfrage findet, können Sie die Partitionsprojektion verwenden, anstatt sie der AWS Glue Data Catalog hinzufügen zu müssen, wenn neue Daten eintreffen.

Im folgenden `CREATE TABLE`-Beispiel wird die Standardkonfiguration von Firehose verwendet.

```
CREATE EXTERNAL TABLE my_ingested_data (
 ...
)
...
PARTITIONED BY (
 datehour STRING
)
LOCATION "s3://amzn-s3-demo-bucket/prefix/"
TBLPROPERTIES (
 "projection.enabled" = "true",
 "projection.datehour.type" = "date",
 "projection.datehour.format" = "yyyy/MM/dd/HH",
 "projection.datehour.range" = "2021/01/01/00,NOW",
 "projection.datehour.interval" = "1",
 "projection.datehour.interval.unit" = "HOURS",
 "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${datehour}/"
)
```

Die `TBLPROPERTIES`-Klausel in der `CREATE TABLE`-Anweisung sagt Athena Folgendes:
+ Verwenden Sie Partitionsprojektion beim Abfragen der Tabelle
+ Der Partitionsschlüssel `datehour` ist vom Typ `date` (welcher eine optionale Zeit beinhaltet)
+ Wie die Daten formatiert werden
+ Der Bereich der Datumszeiten. Beachten Sie, dass die Werte durch Kommata voneinander getrennt werden müssen, nicht durch einen Bindestrich.
+ Wo Sie die Daten auf Amazon S3 finden.

Wenn Sie die Tabelle abfragen, berechnet Athena die Werte für `datehour` und erstellt mithilfe der Speicherortsvorlage eine Liste von Partitionsspeicherorten.

**Topics**
+ [

# Vorgehensweise zum Verwenden des `date`-Typs
](partition-projection-kinesis-firehose-example-using-the-date-type.md)
+ [

# So wählen Sie Partitionsschlüssel aus
](partition-projection-kinesis-firehose-example-choosing-partition-keys.md)
+ [

# So verwenden Sie benutzerdefinierte Präfixen und dynamische Partitionierung
](partition-projection-kinesis-firehose-example-using-custom-prefixes-and-dynamic-partitioning.md)

# Vorgehensweise zum Verwenden des `date`-Typs
<a name="partition-projection-kinesis-firehose-example-using-the-date-type"></a>

Wenn Sie den `date`-Typ für einen projizierten Partitionsschlüssel verwenden, müssen Sie einen Bereich angeben. Da Sie keine Daten für Datumsangaben haben, bevor der Firehose-Bereitstellungsdatenstrom erstellt wurde, können Sie das Erstellungsdatum als Start verwenden. Und da Sie keine Daten für Datumsangaben in der Zukunft haben, können Sie das spezielle Token `NOW` als Ende verwenden.

Im `CREATE TABLE`-Beispiel wird als Startdatum der 1. Januar 2021 um Mitternacht UTC angegeben.

**Anmerkung**  
Konfigurieren Sie einen Bereich, der Ihren Daten so genau wie möglich entspricht, damit Athena nur nach vorhandenen Partitionen sucht.

Wenn eine Abfrage für die Beispieltabelle ausgeführt wird, verwendet Athena die Bedingungen des `datehour`-Partitionsschlüssels in Kombination mit dem Bereich, um Werte zu generieren. Betrachten Sie folgende Abfrage:

```
SELECT *
FROM my_ingested_data
WHERE datehour >= '2020/12/15/00'
AND datehour < '2021/02/03/15'
```

Die erste Bedingung in der `SELECT`-Abfrage verwendet ein Datum, das vor dem Beginn des durch die `CREATE TABLE`-Anweisung angegebenen Datumsbereichs liegt. Da die Partitionsprojektionskonfiguration keine Partitionen für Daten vor dem 1. Januar 2021 angibt, sucht Athena nur an den folgenden Orten nach Daten und ignoriert die früheren Daten in der Abfrage.

```
s3://amzn-s3-demo-bucket/prefix/2021/01/01/00/
s3://amzn-s3-demo-bucket/prefix/2021/01/01/01/
s3://amzn-s3-demo-bucket/prefix/2021/01/01/02/
...
s3://amzn-s3-demo-bucket/prefix/2021/02/03/12/
s3://amzn-s3-demo-bucket/prefix/2021/02/03/13/
s3://amzn-s3-demo-bucket/prefix/2021/02/03/14/
```

Wenn die Abfrage zu einem Datum und einer Uhrzeit vor dem 3. Februar 2021 um 15:00 Uhr ausgeführt wurde, würde die letzte Partition das aktuelle Datum und die Uhrzeit widerspiegeln, nicht das Datum und die Uhrzeit in der Abfragebedingung.

Wenn Sie die neuesten Daten abfragen möchten, können Sie sich die Tatsache zunutze machen, dass Athena keine zukünftigen Daten generiert und nur ein beginnendes `datehour` angeben, wie im folgenden Beispiel.

```
SELECT *
FROM my_ingested_data
WHERE datehour >= '2021/11/09/00'
```

# So wählen Sie Partitionsschlüssel aus
<a name="partition-projection-kinesis-firehose-example-choosing-partition-keys"></a>

Sie können angeben, wie die Partitionsprojektion die Partitionspositionen Partitionsschlüsseln zuordnet. Im `CREATE TABLE`-Beispiel im vorigen Abschnitt wurden Datum und Uhrzeit zu einem Partitionsschlüssel namens datehour zusammengefasst, es sind jedoch auch andere Schemata möglich. Zum Beispiel könnten Sie auch eine Tabelle mit separaten Partitionsschlüsseln für Jahr, Monat, Tag und Stunde konfigurieren. 

Die Aufteilung von Daten in Jahr, Monat und Tag bedeutet jedoch, dass der Partitionsprojektionstyp `date` nicht verwendet werden kann. Eine Alternative besteht darin, das Datum von der Stunde zu trennen, um weiterhin den Partitionsprojektionstyp `date` zu nutzen, Abfragen, die Stundenbereiche angeben, aber leichter lesbar zu machen.

Vor diesem Hintergrund trennt das folgende `CREATE TABLE`-Beispiel das Datum von der Stunde. Da `date` es sich um ein reserviertes Wort in SQL handelt, wird in diesem `day`-Beispiel der Name für den Partitionsschlüssel verwendet, der das Datum darstellt.

```
CREATE EXTERNAL TABLE my_ingested_data2 (
 ...
)
...
PARTITIONED BY (
 day STRING,
 hour INT
)
LOCATION "s3://amzn-s3-demo-bucket/prefix/"
TBLPROPERTIES (
 "projection.enabled" = "true",
 "projection.day.type" = "date",
 "projection.day.format" = "yyyy/MM/dd",
 "projection.day.range" = "2021/01/01,NOW",
 "projection.day.interval" = "1",
 "projection.day.interval.unit" = "DAYS",
 "projection.hour.type" = "integer",
 "projection.hour.range" = "0,23",
 "projection.hour.digits" = "2",
 "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${day}/${hour}/"
)
```

In der `CREATE TABLE`-Beispielanweisung ist die Stunde ein separater Partitionsschlüssel, der als Ganzzahl konfiguriert ist. Die Konfiguration für den Stundenpartitionsschlüssel gibt den Bereich 0 bis 23 an und dass die Stunde mit zwei Ziffern formatiert werden sollte, wenn Athena die Partitionspositionen generiert.

Eine Abfrage für die `my_ingested_data2`-Tabelle könnte so aussehen:

```
SELECT *
FROM my_ingested_data2
WHERE day = '2021/11/09'
AND hour > 3
```

## Grundlegendes über Partitionsschlüssel- und Partitionsprojektions-Typen
<a name="partition-projection-kinesis-firehose-example-partition-key-types-and-partition-projection-types"></a>

Beachten Sie, dass der `datehour`-Schlüssel im ersten `CREATE TABLE`-Beispiel als `date` in der Partitionsprojektionskonfiguration konfiguriert ist, aber der Typ des Partitionsschlüssels `string` ist. Dies gilt auch für `day` im zweiten Beispiel. Die Typen in der Partitionsprojektionskonfiguration sagen Athena nur, wie die Werte formatiert werden sollen, wenn die Partitionspositionen generiert werden. Die von Ihnen angegebenen Typen ändern den Typ des Partitionsschlüssels nicht – in Abfragen sind `datehour` und `day` vom Typ `string`.

Wenn eine Abfrage eine Bedingung wie `day = '2021/11/09'` enthält, parst Athena die Zeichenfolge auf der rechten Seite des Ausdrucks unter Verwendung des Datumsformats, das in der Partitionsprojektionskonfiguration angegeben ist. Nachdem Athena überprüft hat, dass das Datum innerhalb des konfigurierten Bereichs liegt, wird das Datumsformat erneut als Zeichenfolge in die Speicherortsvorlage eingefügt.

In ähnlicher Weise analysiert Athena für eine Abfragebedingung wie `day > '2021/11/09'` die rechte Seite und generiert eine Liste aller übereinstimmenden Daten innerhalb des konfigurierten Bereichs. Anschließend wird das Datumsformat verwendet, um jedes Datum in die Speicherortvorlage einzufügen, um die Liste der Partitionspositionen zu erstellen.

Das Schreiben der gleichen Bedingung wie `day > '2021-11-09'` oder `day > DATE '2021-11-09'` funktioniert nicht. Im ersten Fall stimmt das Datumsformat nicht überein (beachten Sie die Bindestriche anstelle der Schrägstriche) und im zweiten Fall stimmen die Datentypen nicht überein.

# So verwenden Sie benutzerdefinierte Präfixen und dynamische Partitionierung
<a name="partition-projection-kinesis-firehose-example-using-custom-prefixes-and-dynamic-partitioning"></a>

Firehose kann mit [benutzerdefinierten Präfixen](https://docs.aws.amazon.com/firehose/latest/dev/s3-prefixes.html) und [dynamischer Partitionierung](https://docs.aws.amazon.com/firehose/latest/dev/dynamic-partitioning.html) konfiguriert werden. Mit diesen Features können Sie die Amazon-S3-Schlüssel konfigurieren und Partitionierungsschemata einrichten, die Ihren Anwendungsfall besser unterstützen. Sie können auch die Partitionsprojektion mit diesen Partitionierungsschemas verwenden und entsprechend konfigurieren.

Sie könnten beispielsweise das Feature des benutzerdefinierten Präfixes verwenden, um Amazon-S3-Schlüssel mit ISO-formatierten Daten anstelle des Standard-`yyyy/MM/dd/HH`-Schemas zu erhalten.

Sie können auch benutzerdefinierte Präfixe mit dynamischer Partitionierung kombinieren, um eine Eigenschaft wie `customer_id` aus Firehose-Nachrichten zu extrahieren, wie im folgenden Beispiel.

```
prefix/!{timestamp:yyyy}-!{timestamp:MM}-!{timestamp:dd}/!{partitionKeyFromQuery:customer_id}/
```

Mit diesem Amazon-S3-Präfix würde der Firehose-Bereitstellungsdatenstrom Objekte in Schlüssel wie `s3://amzn-s3-demo-bucket/prefix/2021-11-01/customer-1234/file.extension` schreiben. Für eine Eigenschaft wie `customer_id`, bei der die Werte möglicherweise nicht im Voraus bekannt sind, können Sie den Partitionsprojektionstyp `injected` verwenden und eine `CREATE TABLE`-Anweisung wie die folgende verwenden:

```
CREATE EXTERNAL TABLE my_ingested_data3 (
 ...
)
...
PARTITIONED BY (
 day STRING,
 customer_id STRING
)
LOCATION "s3://amzn-s3-demo-bucket/prefix/"
TBLPROPERTIES (
 "projection.enabled" = "true",
 "projection.day.type" = "date",
 "projection.day.format" = "yyyy-MM-dd",
 "projection.day.range" = "2021-01-01,NOW",
 "projection.day.interval" = "1",
 "projection.day.interval.unit" = "DAYS",
 "projection.customer_id.type" = "injected",
 "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${day}/${customer_id}/"
)
```

Wenn Sie eine Tabelle mit einem Partitionsschlüssel vom Typ `injected` abfragen, muss Ihre Abfrage einen Wert für diesen Partitionsschlüssel enthalten. Eine Abfrage für die `my_ingested_data3`-Tabelle könnte so aussehen:

```
SELECT *
FROM my_ingested_data3
WHERE day BETWEEN '2021-11-01' AND '2021-11-30'
AND customer_id = 'customer-1234'
```

## Verwenden Sie den DATE-Typ für den Tagespartitionsschlüssel
<a name="partition-projection-kinesis-firehose-example-iso-formatted-dates"></a>

Da die Werte für den Partitionsschlüssel `day` ISO-formatiert sind, können Sie anstelle von `STRING` auch den Typ `DATE` für den Partitionsschlüssel Tag verwenden, wie im folgenden Beispiel:

```
PARTITIONED BY (day DATE, customer_id STRING)
```

Wenn Sie eine Abfrage durchführen, können Sie mit dieser Strategie Datumsfunktionen für den Partitionsschlüssel verwenden, ohne sie zu analysieren oder umzuwandeln, wie im folgenden Beispiel:

```
SELECT *
FROM my_ingested_data3
WHERE day > CURRENT_DATE - INTERVAL '7' DAY
AND customer_id = 'customer-1234'
```

**Anmerkung**  
Wenn Sie einen Partitionsschlüssel dieses `DATE`-Typs angeben, wird davon ausgegangen, dass Sie das Feature für das [benutzerdefinierte Präfix](https://docs.aws.amazon.com/firehose/latest/dev/s3-prefixes.html) verwendet haben, um Amazon-S3-Schlüssel mit ISO-formatierten Datumsangaben zu erstellen. Wenn Sie das Standardformat `yyyy/MM/dd/HH` von Firehose verwenden, müssen Sie den Partitionsschlüssel als Typ `string` angeben, obwohl die entsprechende Tabelleneigenschaft vom Typ `date` ist, wie im folgenden Beispiel:  

```
PARTITIONED BY ( 
  `mydate` string)
TBLPROPERTIES (
  'projection.enabled'='true', 
   ...
  'projection.mydate.type'='date',
  'storage.location.template'='s3://amzn-s3-demo-bucket/prefix/${mydate}')
```

# Drosselung durch Amazon S3 verhindern
<a name="performance-tuning-s3-throttling"></a>

Bei der Drosselung wird die Geschwindigkeit begrenzt, mit der Sie einen Service, eine Anwendung oder ein System nutzen. In können Sie die Drosselung verwenden AWS, um eine übermäßige Nutzung des Amazon S3-Service zu verhindern und die Verfügbarkeit und Reaktionsfähigkeit von Amazon S3 für alle Benutzer zu erhöhen. Da die Drosselung jedoch die Geschwindigkeit begrenzt, mit der die Daten zu oder von Amazon S3 übertragen werden können, ist es wichtig, zu verhindern, dass Ihre Interaktionen gedrosselt werden.

Wie im Kapitel zur [Leistungsoptimierung](performance-tuning.md) dargelegt, können Optimierungen von Ihren Service-Level-Entscheidungen davon abhängen, wie Sie Ihre Tabellen und Daten strukturieren und wie Sie Ihre Abfragen schreiben.

**Topics**
+ [

# Drosselung auf Service-Ebene reduzieren
](performance-tuning-s3-throttling-reduce-throttling-at-the-service-level.md)
+ [

# Ihre Tabellen optimieren
](performance-tuning-s3-throttling-optimizing-your-tables.md)
+ [

# Ihre Abfragen optimieren
](performance-tuning-s3-throttling-optimizing-queries.md)

# Drosselung auf Service-Ebene reduzieren
<a name="performance-tuning-s3-throttling-reduce-throttling-at-the-service-level"></a>

Um eine Drosselung von Amazon S3 auf Service-Ebene zu vermeiden, können Sie Ihre Nutzung überwachen und Ihre [Servicekontingente](https://docs.aws.amazon.com/general/latest/gr/s3.html#limits_s3) anpassen oder Sie verwenden bestimmte Techniken wie Partitionierung. Im Folgenden sind einige der Bedingungen aufgeführt, die zu einer Drosselung führen können:
+ **Überschreitung der API-Anforderungslimits Ihres Kontos** – Amazon S3 hat standardmäßige API-Anforderungslimits, die auf Kontotyp und -nutzung basieren. Wenn Sie die maximale Anzahl von Anfragen pro Sekunde für ein einzelnes Präfix überschreiten, werden Ihre Anfragen möglicherweise gedrosselt, um eine Überlastung des Amazon-S3-Service zu verhindern.
+ **Unzureichende Datenpartitionierung** – Wenn Sie Ihre Daten nicht richtig partitionieren und große Datenmengen übertragen, kann Amazon S3 Ihre Anfragen drosseln. Weitere Informationen finden Sie im Abschnitt [Partitionierung verwenden](performance-tuning-s3-throttling-optimizing-your-tables.md#performance-tuning-s3-throttling-use-partitioning) in diesem Dokument.
+ **Große Anzahl kleiner Objekte** – Vermeiden Sie nach Möglichkeit eine große Anzahl kleiner Dateien. Amazon S3 hat ein Limit von [5 500 GET-Anfragen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) pro Sekunde pro partitioniertem Präfix, und Ihre Athena-Abfragen haben dasselbe Limit. Wenn Sie Millionen von kleinen Objekten in einer einzigen Abfrage scannen müssen, wird Ihre Abfrage wahrscheinlich von Amazon S3 gedrosselt werden.

Um übermäßiges Scannen zu vermeiden, können Sie AWS Glue ETL verwenden, um Ihre Dateien regelmäßig zu komprimieren, oder Sie partitionieren die Tabelle und fügen Partitionsschlüsselfilter hinzu. Weitere Informationen finden Sie in den folgenden Ressourcen.
+ [Wie kann ich einen AWS Glue ETL-Job für die Ausgabe größerer Dateien konfigurieren?](https://aws.amazon.com/premiumsupport/knowledge-center/glue-job-output-large-files/) (*AWS Wissenszentrum*)
+ [Lesen von Eingabedateien in größeren Gruppen](https://docs.aws.amazon.com/glue/latest/dg/grouping-input-files.html) (*AWS Glue Entwicklerhandbuch*)

# Ihre Tabellen optimieren
<a name="performance-tuning-s3-throttling-optimizing-your-tables"></a>

Die Strukturierung Ihrer Daten ist wichtig, wenn Sie auf Probleme mit der Drosselung stoßen. Obwohl Amazon S3 große Datenmengen verarbeiten kann, kommt es manchmal aufgrund der Art und Weise, wie die Daten strukturiert sind, zu einer Drosselung.

In den folgenden Abschnitten finden Sie einige Vorschläge zur Strukturierung Ihrer Daten in Amazon S3, um Drosselungsprobleme zu vermeiden.

## Partitionierung verwenden
<a name="performance-tuning-s3-throttling-use-partitioning"></a>

Sie können die Partitionierung verwenden, um die Drosselung zu reduzieren, indem Sie die Datenmenge einschränken, auf die zu einem bestimmten Zeitpunkt zugegriffen werden muss. Durch die Partitionierung von Daten in bestimmten Spalten können Sie Anfragen gleichmäßig auf mehrere Objekte verteilen und die Anzahl der Anfragen für ein einzelnes Objekt reduzieren. Durch die Reduzierung der Datenmenge, die gescannt werden muss, wird die Abfrageleistung verbessert und die Kosten gesenkt.

Sie können beim Erstellen einer Tabelle Partitionen definieren, die als virtuelle Spalten fungieren. Um eine Tabelle mit Partitionen in einer `CREATE TABLE`-Anweisung zu erstellen, verwenden Sie die `PARTITIONED BY (column_name data_type)`-Klausel, um die Schlüssel für die Partitionierung Ihrer Daten zu definieren.

Um die von einer Abfrage gescannten Partitionen einzuschränken, können Sie sie als Prädikate in einer `WHERE`-Klausel der Abfrage angeben. Daher eignen sich Spalten, die häufig als Filter verwendet werden, gut für die Partitionierung. In der Regel werden die Daten zeitbasiert partitioniert und das kann zu einem Multi-Level-Partitionierungsschema führen.

Beachten Sie, dass die Partitionierung auch mit Kosten verbunden ist. Wenn Sie die Anzahl der Partitionen in Ihrer Tabelle erhöhen, erhöht sich auch der Zeitaufwand für das Abrufen und Verarbeiten von Partitionsmetadaten. Durch eine zu starke Partitionierung können also die Vorteile zunichte gemacht werden, die Sie durch eine umsichtigere Partitionierung erzielen. Wenn Ihre Daten stark auf einen Partitionswert ausgerichtet sind und die meisten Abfragen diesen Wert verwenden, kann Ihnen der zusätzliche Mehraufwand entstehen.

Weitere Informationen über Partitionierung in Athena finden Sie unter [Was ist Partitionierung?](ctas-partitioning-and-bucketing-what-is-partitioning.md)

## Ihre Daten in Buckets sammeln
<a name="performance-tuning-s3-throttling-bucket-your-data"></a>

Eine andere Möglichkeit, Ihre Daten zu partitionieren, besteht darin, die Daten in einer einzigen Partition zu sammeln. Beim Bucketing geben Sie eine oder mehrere Spalten an, die Zeilen enthalten, die Sie gruppieren möchten. Anschließend ordnen Sie diese Zeilen mehreren Gruppen zu. Auf diese Weise fragen Sie nur den Bucket ab, der gelesen werden muss, wodurch die Anzahl der Datenzeilen, die gescannt werden müssen, reduziert wird.

Wenn Sie eine Spalte auswählen, die für das Bucketing verwendet werden soll, wählen Sie die Spalte mit hoher Kardinalität (d. h. mit vielen unterschiedlichen Werten), die gleichmäßig verteilt ist und häufig zum Filtern der Daten verwendet wird. Ein Beispiel für eine Spalte, die sich gut für das Bucketing eignet, ist ein Primärschlüssel, z. B. eine ID-Spalte.

Weitere Informationen zu Bucketing in Athena finden Sie unter [Was ist Bucketing?](ctas-partitioning-and-bucketing-what-is-bucketing.md)

## Verwenden Sie AWS Glue Partitionsindizes
<a name="performance-tuning-s3-throttling-use-aws-glue-partition-indexes"></a>

Sie können AWS Glue Partitionsindizes verwenden, um Daten in einer Tabelle auf der Grundlage der Werte einer oder mehrerer Partitionen zu organisieren. AWS Glue Partitionsindizes können die Anzahl der Datenübertragungen, den Umfang der Datenverarbeitung und die Verarbeitungszeit von Abfragen reduzieren.

Ein AWS Glue Partitionsindex ist eine Metadatendatei, die Informationen über die Partitionen in der Tabelle enthält, einschließlich der Partitionsschlüssel und ihrer Werte. Der Partitionsindex wird in einem Amazon S3 S3-Bucket gespeichert und automatisch aktualisiert AWS Glue , wenn der Tabelle neue Partitionen hinzugefügt werden.

Wenn ein AWS Glue Partitionsindex vorhanden ist, versuchen Abfragen, eine Teilmenge der Partitionen abzurufen, anstatt alle Partitionen in der Tabelle zu laden. Abfragen werden nur für die Teilmenge der Daten ausgeführt, die für die Abfrage relevant sind.

Wenn Sie eine Tabelle in erstellen AWS Glue, können Sie einen Partitionsindex für eine beliebige Kombination von Partitionsschlüsseln erstellen, die in der Tabelle definiert sind. Nachdem Sie einen oder mehrere Partitionsindizes für eine Tabelle erstellt haben, müssen Sie der Tabelle eine Eigenschaft hinzufügen, die die Partitionsfilterung ermöglicht. Anschließend können Sie die Tabelle von Athena abfragen.

Informationen zum Erstellen von Partitionsindizes in AWS Glue finden Sie unter [Arbeiten mit Partitionsindizes AWS Glue im AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html) *Entwicklerhandbuch*. Hinweise zum Hinzufügen einer Tabelleneigenschaft zur Aktivierung der Partitionsfilterung finden Sie unter [Optimieren Sie Abfragen mit AWS Glue Partitionsindexierung und Filterung](glue-best-practices-partition-index.md).

## Datenkomprimierung und Dateiaufteilung verwenden
<a name="performance-tuning-s3-throttling-use-data-compression-and-file-splitting"></a>

Datenkomprimierung kann Abfragen erheblich beschleunigen, wenn Dateien ihre optimale Größe haben oder wenn sie in logische Gruppen aufgeteilt werden können. Im Allgemeinen erfordern höhere Komprimierungsraten mehr CPU-Zyklen, um die Daten zu komprimieren und zu dekomprimieren. Für Athena empfehlen wir, entweder Apache Parquet oder Apache ORC zu verwenden, die Daten standardmäßig komprimieren. Weitere Informationen zur Datenkomprimierung in Athena finden Sie unter [Komprimierung in Athena verwenden](compression-formats.md).

Das Aufteilen von Dateien erhöht die Parallelität, da Athena das Lesen einer einzelnen Datei auf mehrere Leser verteilen kann. Wenn eine einzelne Datei nicht aufgeteilt werden kann, kann nur ein einziger Leser die Datei lesen, während andere Leser inaktiv sind. Apache Parquet und Apache ORC unterstützen auch teilbare Dateien.

## Verwenden Sie optimierte spaltenförmige Datenspeicher
<a name="performance-tuning-s3-throttling-use-optimized-columnar-data-stores"></a>

Die Athena-Abfrageleistung verbessert sich erheblich, wenn Sie Ihre Daten in ein Spaltenformat konvertieren. Wenn Sie spaltenförmige Dateien generieren, ist eine Optimierungstechnik, die Sie in Betracht ziehen sollten, darin, die Daten auf der Grundlage des Partitionsschlüssels zu ordnen.

Apache Parquet und Apache ORC sind häufig verwendete spaltenorientierte Open-Source-Datenspeicher. Informationen zur Konvertierung vorhandener Amazon-S3-Datenquellen in eines dieser Formate finden Sie unter [Konvertieren in spaltenbasierte Formate](columnar-storage.md#convert-to-columnar).

### Verwenden Sie eine größere Parquet-Blockgröße oder ORC-Streifengröße
<a name="performance-tuning-s3-throttling-use-a-larger-parquet-block-size-or-orc-stripe-size"></a>

Parquet und ORC verfügen über Datenspeicherparameter, die Sie zur Optimierung anpassen können. In Parquet können Sie die Blockgröße optimieren. In ORC können Sie die Streifengröße optimieren. Je größer der Block oder der Streifen, desto mehr Zeilen können Sie in jedem Block oder Streifen speichern. Standardmäßig beträgt die Parquet-Blockgröße 128 MB und die ORC-Streifen-Größe 64 MB.

Wenn ein ORC-Streifen weniger als 8 MB groß ist (der Standardwert von `hive.orc.max_buffer_size`), liest Athena den gesamten ORC-Streifen. Dies ist der Kompromiss, den Athena zwischen Spaltenselektivität und Eingabe-/Ausgabeoperationen pro Sekunde für kleinere Streifen eingeht.

Wenn Sie Tabellen mit einer sehr großen Anzahl von Spalten haben, kann eine kleine Block- oder Streifen-Größe dazu führen, dass mehr Daten gescannt werden als nötig. In diesen Fällen kann eine größere Blockgröße effizienter sein.

### Verwenden Sie ORC für komplexe Typen
<a name="performance-tuning-s3-throttling-use-orc-for-complex-types"></a>

Wenn Sie derzeit in Parquet gespeicherte Spalten mit komplexen Datentypen (z. B. `array`, `map` oder `struct`) abfragen, liest Athena eine gesamte Datenzeile, anstatt nur die angegebenen Spalten selektiv zu lesen. Dies ist ein bekanntes Problem in Athena. Um dieses Problem zu umgehen, sollten Sie ORC verwenden.

### Wählen Sie einen Komprimierungsalgorithmus
<a name="performance-tuning-s3-throttling-choose-a-compression-algorithm"></a>

Ein weiterer Parameter, den Sie konfigurieren können, ist der Komprimierungsalgorithmus für Datenblöcke. Informationen zu den in Athena für Parquet und ORC unterstützten Komprimierungsalgorithmen finden Sie unter [Athena-Komprimierungsunterstützung](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html).

Weitere Informationen zur Optimierung von spaltenförmigen Speicherformaten in Athena finden Sie im Abschnitt „Optimieren Sie die Generierung von spaltenförmigen Datenspeichern“ im AWS Big-Data-Blogbeitrag Die [10 besten Tipps zur Leistungsoptimierung für](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/) Amazon Athena.

## Verwenden von Iceberg-Tabellen
<a name="performance-tuning-s3-throttling-use-iceberg-tables"></a>

Apache Iceberg ist ein offenes Tabellenformat für sehr große Analysedatensätze, das für eine optimierte Nutzung auf Amazon S3 konzipiert ist. Sie können Iceberg-Tabellen verwenden, um die Drosselung in Amazon S3 zu reduzieren.

Iceberg-Tabellen bieten Ihnen folgende Vorteile:
+ Sie können Iceberg-Tabellen auf eine oder mehrere Spalten partitionieren. Dadurch wird der Datenzugriff optimiert und die Datenmenge reduziert, die durch Abfragen gescannt werden muss.
+ Da der Iceberg-Objektspeichermodus die Iceberg-Tabellen für die Verwendung mit Amazon S3 optimiert, kann er große Datenmengen und umfangreiche Abfrage-Workloads verarbeiten.
+ Iceberg-Tabellen im Objektspeichermodus sind skalierbar, fehlertolerant und robust, was dazu beitragen kann, die Drosselung zu reduzieren.
+ Die ACID-Transaktionsunterstützung bedeutet, dass mehrere Benutzer Amazon-S3-Objekte auf atomare Weise hinzufügen und löschen können.

Weitere Informationen zu Apache Iceberg finden Sie unter [Apache Iceberg](https://iceberg.apache.org/). Weitere Informationen zur Verwendung von Apache-Iceberg-Tabellen in Athena finden Sie unter [Verwendung von Iceberg-Tabellen](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg.html).

# Ihre Abfragen optimieren
<a name="performance-tuning-s3-throttling-optimizing-queries"></a>

Verwenden Sie die Vorschläge in diesem Abschnitt für die Optimierung Ihrer SQL-Abfragen in Athena.

## Verwenden Sie LIMIT mit der ORDER-BY-Klausel
<a name="performance-tuning-s3-throttling-use-limit-with-the-order-by-clause"></a>

Die `ORDER BY`-Klausel gibt Daten in einer sortierten Reihenfolge zurück. Dazu muss Athena alle Datenzeilen an einen einzelnen Worker-Knoten senden und die Zeilen dann sortieren. Diese Art von Abfrage kann lange laufen oder sogar fehlschlagen.

Um Ihre Abfragen effizienter zu gestalten, sollten Sie sich die oberen oder niedrigsten *N* Werte ansehen und dann auch eine Klausel verwenden. `LIMIT` Dadurch werden die Kosten für die Sortierung erheblich reduziert, da sowohl die Sortierung als auch die Beschränkung auf einzelne Worker-Knoten und nicht auf einen einzelnen Worker verlagert werden.

## JOIN-Klauseln optimieren
<a name="performance-tuning-s3-throttling-optimize-join-clauses"></a>

Wenn Sie zwei Tabellen verbinden, verteilt Athena die Tabelle auf der rechten Seite an die Worker-Knoten und streamt dann die Tabelle auf der linken Seite, um den Join durchzuführen.

Geben Sie aus diesem Grund die größere Tabelle auf der linken Seite des Joins und die kleinere Tabelle auf der rechten Seite des Joins an. Auf diese Weise verwendet Athena weniger Speicher und führt die Abfrage mit geringerer Latenz aus.

Beachten Sie auch folgende Punkte:
+ Wenn Sie mehrere `JOIN`-Befehle verwenden, geben Sie die Tabellen vom größten zum kleinsten an.
+ Vermeiden Sie Kreuzverknüpfungen, sofern sie nicht für die Abfrage erforderlich sind.

## Optimieren Sie GROUP-BY-Klauseln
<a name="performance-tuning-s3-throttling-optimize-group-by-clauses"></a>

Der `GROUP BY`-Operator verteilt Zeilen auf der Grundlage der `GROUP BY`-Spalten an die Worker-Knoten. Auf diese Spalten wird im Speicher verwiesen, und die Werte werden verglichen, während die Zeilen aufgenommen werden. Die Werte werden zusammen aggregiert, wenn die `GROUP BY`-Spalte übereinstimmt. Angesichts der Funktionsweise dieses Verfahrens ist es ratsam, die Spalten von der höchsten zur niedrigsten Kardinalität anzuordnen.

## Verwenden Sie Zahlen statt Zeichenketten
<a name="performance-tuning-s3-throttling-use-numbers-instead-of-strings"></a>

Zahlen benötigen weniger Speicher und sind im Vergleich zu Zeichenketten schneller zu verarbeiten. Verwenden Sie nach Möglichkeit Zahlen anstelle von Zeichenketten.

## Die Gesamtanzahl der Spalten reduzieren
<a name="performance-tuning-s3-throttling-limit-the-number-of-columns"></a>

Um den Gesamtspeicherbedarf zum Speichern Ihrer Daten zu reduzieren, begrenzen Sie die Anzahl der in Ihrer `SELECT`-Anweisung angegebenen Spalten.

## Verwenden Sie reguläre Ausdrücke anstelle von LIKE
<a name="performance-tuning-s3-throttling-use-regular-expressions-instead-of-like"></a>

Abfragen, die Klauseln enthalten, z. B. `LIKE '%string%'` bei großen Zeichenketten, können sehr rechenintensiv sein. Wenn Sie in einer Zeichenkettenspalte nach mehreren Werten filtern, verwenden Sie stattdessen die Funktion [regexp\$1like()](https://trino.io/docs/current/functions/regexp.html#regexp_like) und einen regulären Ausdruck. Dies ist besonders nützlich, wenn Sie eine lange Werteliste vergleichen.

## Die LIMIT-Klausel verwenden
<a name="performance-tuning-s3-throttling-use-the-limit-clause"></a>

Anstatt beim Ausführen einer Abfrage alle Spalten auszuwählen, verwenden Sie die `LIMIT`-Klausel, um nur die Spalten zurückzugeben, die Sie benötigen. Dadurch wird die Größe des Datensatzes reduziert, der über die Pipeline zur Abfrageausführung verarbeitet wird. `LIMIT`-Klauseln sind hilfreicher, wenn Sie Tabellen mit einer großen Anzahl von Spalten abfragen, die auf Zeichenfolgen basieren. `LIMIT`-Klauseln sind auch hilfreich, wenn Sie mehrere Verknüpfungen oder Aggregationen für eine Abfrage durchführen.

# Weitere Ressourcen
<a name="performance-tuning-additional-resources"></a>

Weitere Informationen zur Leistungsoptimierung in Athena finden Sie in den folgenden Ressourcen:
+ AWS Big-Data-Blogbeitrag: [Die 10 wichtigsten Tipps zur Leistungsoptimierung für Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/).
+ AWS Big-Data-Blogbeitrag: [Abfragen dreimal schneller ausführen und dabei bis zu 70% Kosten sparen — mit der neuesten Amazon Athena Athena-Engine](https://aws.amazon.com/blogs/big-data/run-queries-3x-faster-with-up-to-70-cost-savings-on-the-latest-amazon-athena-engine/) im *AWS Big Data-Blog*.
+ AWS Big-Data-Blogbeitrag: [Verbessern Sie föderierte Abfragen mit Predicate Pushdown in](https://aws.amazon.com/blogs/big-data/improve-federated-queries-with-predicate-pushdown-in-amazon-athena/) Amazon Athena.
+ Benutzerhandbuch für Amazon Simple Storage Service: [Bewährte Methoden für Designmuster: Leistung von Amazon S3 finden optimieren](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html).
+ Andere [Athena-Beiträge im AWS -Big-Data-Blog](https://aws.amazon.com/blogs/big-data/tag/amazon-athena/). 
+ Stellen Sie ein Frage auf [AWS -re:Post](https://repost.aws/tags/TA78iVOM7gR62_QqDe2-CmiA/amazon-athena) mit Hilfe des **Amazon-Athena**-Tags.
+ Konsultieren Sie die [Athena-Themen im AWS Knowledge Center](https://aws.amazon.com/premiumsupport/knowledge-center/#Amazon_Athena).
+ Kontakt AWS Support (klicken Sie im AWS-Managementkonsole**Support auf Support**, **Support Center**)