

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.

# Trino
<a name="emr-trino"></a>

Trino ist eine Open-Source-Abfrage-Engine, die für interaktive Abfragen in einer Vielzahl von Datenquellen entwickelt wurde. Dazu können relationale Datenbanken, dateibasierte Daten, HDFS-Daten und andere gehören. Der häufigste Zweck von Trino mit Amazon EMR besteht darin, komplexe SQL-Abfragen für große Datensätze auszuführen, die in Amazon S3 gespeichert sind. Es ist auch mit ANSI SQL kompatibel, wodurch es Datenbankingenieuren, Datenanalysten und Datenwissenschaftlern, die mit SQL vertraut sind, vertraut ist.



**Anmerkung**  
PrestoSQL wurde im Dezember 2020 in Trino umbenannt. Amazon EMR-Versionen 6.4.0 und höher beziehen sich im Allgemeinen auf [Trino](https://trino.io/), während sich frühere Versionen auf PrestoSQL beziehen. 

**Wichtig**  
PrestoSQL, die vorherige Version von Trino, ist weiterhin für die Verwendung mit Amazon EMR verfügbar. Wir empfehlen jedoch dringend, Trino künftig mit Amazon EMR zu verwenden. Beachten Sie auch, dass Trino und PrestoSQL nicht gleichzeitig auf demselben Cluster ausgeführt werden können.

In der folgenden Tabelle sind die Version von Trino aufgeführt, die in der neuesten Version von Amazon EMR 7.x enthalten ist, sowie die Komponenten, die Amazon EMR zusammen mit Trino installiert. [Die Version der Komponenten, die in dieser Version mit Trino installiert wurden, finden Sie unter Version 7.12.0 der Komponentenversionen.](emr-7120-release.md)


**Trino (PrestoSQL) -Versionsinformationen für emr-7.12.0**  

| Amazon-EMR-Versionsbezeichnung | Trino (PrestoSQL)-Version | Mit Trino (PrestoSQL) installierte Komponenten | 
| --- | --- | --- | 
| emr-7.12.0 | trino-prestosql 476-amzn-1 | emrfs, emr-goodies, hadoop-client, hadoop-hdfs-datanode, hadoop-hdfs-library, hadoop-hdfs-namenode, hadoop-hdfs-zkfc, hadoop-kms-server, hadoop-yarn-nodemanager, hadoop-yarn-resourcemanager, hadoop-yarn-timeline-server, hive-client, hudi, hudi-trino, hcatalog-server, mariadb-server, trino-coordinator, trino-worker | 

**Topics**
+ [Geschichte und Design von Trino](emr-trino-intro-history.md)
+ [Erste Schritte mit Trino](emr-trino-getting-started.md)
+ [Konfiguration von Trino auf Amazon EMR](emr-trino-config.md)
+ [Bewährte Methoden für Trino auf Amazon EMR](emr-trino-advanced.md)
+ [Überlegungen zu Trino](Trino-considerations.md)
+ [Versionsverlauf von Trino](Trino-release-history.md)

# Geschichte und Design von Trino
<a name="emr-trino-intro-history"></a>

Trino ist auf die Abfrage großer Datensätze aus vielen verschiedenen Quellen spezialisiert. Trino kann in einem herkömmlichen Big-Data-Anwendungsfall auf HDFS zugreifen und es abfragen, aber es kann auch zusätzliche Quellen wie relationale Datenbanken und NoSQL-Datenbanken abfragen. Trino begann ursprünglich als Fork der Presto-Abfrage-Engine im Jahr 2019. Seitdem wurde es unabhängig von der Presto-Codebasis entwickelt. 

Weitere Informationen zur Trino Query Engine und zu ihrer Verwendung finden Sie auf der [Trino-Website](https://trino.io/). [Die Quelldokumentation zu Trino finden Sie unter Trino Overview.](https://trino.io/docs/current/overview.html)

## Architektonische Konzepte
<a name="emr-trino-intro-architecture"></a>

Trino kann schnelle und effiziente Abfragen ausführen, da es Daten in einem Cluster parallel verarbeitet. Es wurde speziell für die Abfrage eines Data Lakes entwickelt, da es auf Abfragen großer Datenmengen spezialisiert ist, typischerweise in Anwendungsfällen mit Hadoop und HDFS. Es kann aber auch herkömmliche relationale Datenbanken abfragen. Weitere Informationen finden Sie unter [Architektur](https://trino.io/docs/current/overview/concepts.html#architecture) in der *Trino-Dokumentation*.

### Komponenten von Trino
<a name="emr-trino-key-components"></a>

Trino verfügt über einige wichtige Architekturkomponenten, die zusammenarbeiten, damit Abfragen schnell ausgeführt werden können. Es ist hilfreich, wenn Sie bei der Feinabstimmung Ihres Clusters für eine bessere Leistung über praktische Kenntnisse verfügen:
+ Der **Koordinator** ist für die Abfrageorchestrierung verantwortlich. Er analysiert und optimiert eingehende SQL-Abfragen, generiert Ausführungspläne, weist Worker-Knoten Aufgaben zu und sammelt und stellt Abfrageergebnisse zusammen. Darüber hinaus überwacht es die Ressourcennutzung und verfolgt den Status der Worker-Knoten. Weitere Informationen finden Sie unter [Coordinator](https://trino.io/docs/current/overview/concepts.html#coordinator) in der *Trino-Dokumentation*.
+ **Worker-Knoten** übernehmen die Datenverarbeitung für Abfragen. Nachdem der Koordinator Aufgaben zugewiesen hat, rufen die Mitarbeiter Daten ab, führen die erforderlichen Operationen wie Verknüpfungen und Aggregationen durch und tauschen Zwischendaten mit anderen Mitarbeitern aus. Weitere Informationen finden Sie unter [Worker](https://trino.io/docs/current/overview/concepts.html#worker) in der *Trino-Dokumentation*.
+ **Konnektoren** sind Plugins, mit denen Trino eine Verbindung zu verschiedenen Datenquellen herstellen und diese abfragen kann. Jeder Connector weiß, wie er auf Daten aus seiner Quelle wie Amazon S3, Apache Hive oder relationalen Datenbanken zugreift und diese abruft. Diese Konnektoren ordnen Quelldaten der Schemastruktur von Trino zu.
+ Ein **Katalog** ist eine logische Sammlung von Schemas und Tabellen, die einem bestimmten Konnektor zugeordnet sind. Kataloge, die im Koordinator definiert sind, ermöglichen es Trino, verschiedene Datenquellen als einen einzigen Namespace zu behandeln. Dadurch können Benutzer mehrere Quellen zusammen abfragen, wie Hive und MySQL, auf einheitliche Weise in derselben Abfrage.
+ **Clients** wie die Trino CLI stellen über JDBC- und ODBC-Treiber eine Verbindung zum Trino-Koordinator her, um SQL-Abfragen zu senden. Der Koordinator verwaltet den Abfragelebenszyklus und stellt dem Kunden Ergebnisse zur weiteren Analyse oder Berichterstattung zur Verfügung.

### Ausführen von Abfragen
<a name="emr-trino-queries"></a>

Informationen darüber, wie Trino SQL-Anweisungen verwendet und sie als Abfragen ausführt, finden Sie in der [Trino-Dokumentation unter *Trino-Konzepte*](https://trino.io/docs/current/overview/concepts.html#query-execution-model).

# Erste Schritte mit Trino
<a name="emr-trino-getting-started"></a>

Die Verfahren in diesem Abschnitt zeigen Ihnen, wie Sie einen Amazon EMR-Cluster einrichten, um Metastore-Datenquellen mit Trino abzufragen. Diese Metastores, zu denen auch der AWS Glue-Datenkatalog gehört, speichern Metadaten und Datenbankobjekte und verwalten Zugriffsberechtigungen. Die Verfahren behandeln die Voraussetzungen, empfohlene Konfigurationseinstellungen, das Erstellen von Konnektoren und das Ausführen von Abfragen für Metastore-Tabellen.

**Topics**
+ [Führen Sie die erforderlichen Schritte für die Verwendung von Amazon EMR mit aus Trino](emr-trino-getting-started-pre.md)
+ [Starten Sie einen Amazon EMR-Cluster mit Trino](emr-trino-getting-started-launch.md)
+ [Connect zum primären Knoten für den Amazon EMR-Cluster her und führen Sie Abfragen aus](emr-trino-getting-started-connect.md)

# Führen Sie die erforderlichen Schritte für die Verwendung von Amazon EMR mit aus Trino
<a name="emr-trino-getting-started-pre"></a>

Wenn Sie keinen Amazon EMR-Cluster verwendet oder noch keinen erstellt haben AWS, führen Sie diese erforderlichen Schritte durch, bevor Sie einen Amazon EMR-Cluster mit Trino erstellen.

## AWS Umgebung eingerichtet
<a name="emr-trino-getting-started-account"></a>

Gehen Sie wie folgt vor, um Ihr AWS Konto zu konfigurieren, falls Sie dies noch nicht getan haben:

1. Eröffnen Sie ein AWS Konto, falls Sie noch keines haben. Weitere Informationen finden Sie im *Referenzhandbuch zur AWS Kontoverwaltung unter Konto* [erstellen](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-creating.html). AWS 

1. Melden Sie sich als Administratorbenutzer bei Ihrem Konto an.

1. Erstellen Sie eine Gruppe und weisen Sie ihr Benutzer zu.

1. Erstellen Sie ein Amazon EC2 EC2-Schlüsselpaar, das Sie später verwenden können, um die Kommunikation zwischen Ressourcen mit SSH zu sichern. Dieser Schritt ist erforderlich, wenn Sie eine Verbindung zum primären Knoten herstellen möchten, um Aufgaben auszuführen. Weitere Informationen finden Sie unter [Connect zum primären Knoten des Amazon EMR-Clusters mithilfe von SSH](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-connect-master-node-ssh.html).

# Starten Sie einen Amazon EMR-Cluster mit Trino
<a name="emr-trino-getting-started-launch"></a>

Im Folgenden werden die richtigen Konfigurationsoptionen beschrieben, wenn Sie einen Cluster mit Trino erstellen.

## Verwenden eines Hive-Connectors, um Daten für Abfragen verfügbar zu machen
<a name="emr-trino-getting-started-connect-hive"></a>

Sie können einen Trino-Konnektor für einen Hive-Metastore konfigurieren, um Metastore-Daten aus Ihrem Cluster abzufragen. Ein Metastore ist eine Abstraktionsebene, die dateibasierte Inhalte oder Daten als Tabellen zur Verfügung stellt, sodass sie einfach abzufragen sind. Sie müssen einen Connector in Amazon EMR konfigurieren, um die Hive-Metastore-Tabellen für den Cluster verfügbar zu machen. Das folgende Verfahren zeigt Ihnen, wie das geht:

1. Wählen Sie in der Konsole AWS Glue und erstellen Sie eine Tabelle, die auf Ihren Quelldaten in Amazon S3 basiert. Eine Tabelle im AWS Glue-Datenkatalog ist die Metadatendefinition für die Daten. In diesem Zusammenhang ist es sinnvoll, die Tabelle manuell zu erstellen und Spalten nach Ihren Wünschen aus Ihren Quelldaten zu erstellen. Weitere Informationen zum Erstellen von Tabellen in AWS Glue aus halbstrukturierten Daten in Amazon S3 finden Sie unter [Erstellen von Tabellen mit der Konsole](https://docs.aws.amazon.com/glue/latest/dg/tables-described.html#console-tables) im *AWS Glue-Benutzerhandbuch*.

1. Legen Sie Ihre Konfiguration als Teil der Cluster-Erstellung fest. Wählen Sie die Registerkarte **Konfigurationen** aus. Konfigurationen sind optionale Spezifikationen für Ihren Cluster. Wenn Sie eine Konfiguration eingeben, fügen Sie JSON wie im folgenden Beispiel hinzu, das Trino anweist, den AWS Glue-Datenkatalog als externen Hive-Metastore für Tabellenmetadaten zu verwenden:

   ```
   {
       "classification": "trino-connector-hive",
       "properties": {
           "hive.metastore": "glue"
       }
   }
   ```

   Alternativ können Sie Konfigurationen im Abschnitt **Softwareeinstellungen** anwenden, wenn Sie einen Cluster erstellen.

   Darüber hinaus können Sie andere Konnektortypen einrichten, z. B. für die Verbindung mit Apache Iceberg. Weitere Informationen finden Sie unter [Verwenden eines Iceberg-Clusters mit Trino](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-iceberg-use-trino-cluster.html) im *Amazon EMR-Versionshandbuch*. Die Konfiguration zusätzlicher Einstellungen ist optional.

Informationen zur Fortsetzung der ersten Schritte finden Sie unter. [Connect zum primären Knoten für den Amazon EMR-Cluster her und führen Sie Abfragen aus](emr-trino-getting-started-connect.md)

## Erstellen Sie einen Cluster mit Trino
<a name="emr-trino-getting-started-launch-cluster-settings"></a>

Im Folgenden werden die richtigen Konfigurationsoptionen beschrieben, wenn Sie einen Cluster erstellen, den Sie mit Trino verwenden möchten.

**Wichtig**  
Bevor Sie Ihren Cluster erstellen, schließen Sie die AWS Glue Data Catalog-Konfiguration als Ihren Hive-Metastore ab, was wir für den Einstieg empfehlen. Weitere Informationen finden Sie unter [Verwenden eines Hive-Connectors, um Daten für Abfragen verfügbar zu machen](#emr-trino-getting-started-connect-hive).

1. Wählen Sie in der AWS Konsole Amazon EMR aus den Diensten aus. Wenn Sie Amazon EMR wählen und über bestehende Cluster verfügen, werden Ihre **EMR auf EC2-Clustern aufgeführt**.

1. Wählen Sie **Cluster erstellen**. Von hier aus starten Sie den Prozess zum Aufbau eines Clusters.

1. Geben Sie Ihrem Cluster einen Namen und wählen Sie eine **Amazon EMR-Version** aus. Sie können die aktuellste Version für das Tutorial auswählen.

1. Wählen Sie das **Trino-Paket**, für das die Trino-Anwendung vorausgewählt ist. Pakete werden aus Gründen der Benutzerfreundlichkeit eingerichtet, wenn Sie den Zweck des Clusters im Voraus kennen. Andernfalls können Sie einfach das Kontrollkästchen für Trino aktivieren.

1. Wählen Sie für die **Cluster-Konfiguration** **Uniform Instance Groups** aus. Fahren Sie fort und entfernen Sie weitere Instanzgruppen.

1. Wählen Sie einen **Instanztyp**. Generell empfehlen wir Ihnen, einen Instance-Typ mit mindestens 16 GiB Arbeitsspeicher zu wählen. Wählen Sie außerdem für **Cluster-Skalierung und -Bereitstellung** die Option **Clustergröße manuell festlegen**.

1. Stellen Sie an dieser Stelle Ihre Hive-Metastore-Konfiguration so ein, dass sie auf Glue verweist AWS . Dies wird im Abschnitt detailliert beschrieben. [Verwenden eines Hive-Connectors, um Daten für Abfragen verfügbar zu machen](#emr-trino-getting-started-connect-hive) Schließen Sie dies ab, bevor Sie den Cluster erstellen.

1. Wählen Sie **Cluster erstellen**. Es kann einige Minuten dauern, bis der Vorgang abgeschlossen ist.

   Die Schritte hier behandeln nicht alle Konfigurationsschritte im Detail. Weitere Informationen zur Einrichtung eines Clusters finden Sie unter [Amazon EMR-Cluster planen, konfigurieren und starten](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan.html).

**Anmerkung**  
Wählen Sie nicht sowohl Presto als auch Trino für die Verwendung auf demselben Cluster aus. Sie zusammen auszuführen, wird nicht unterstützt. Es wird außerdem empfohlen, dass Sie, wenn Sie Trino ausführen, keine anderen Anwendungen auf dem Cluster ausführen, z. B. Spark.

# Connect zum primären Knoten für den Amazon EMR-Cluster her und führen Sie Abfragen aus
<a name="emr-trino-getting-started-connect"></a>

## Stellen Sie Testdaten bereit und konfigurieren Sie Berechtigungen
<a name="emr-trino-getting-started-pre-data"></a>

Sie können Amazon EMR mit Trino testen, indem Sie AWS Glue Data Catalog und seinen Hive-Metastore verwenden. In diesen erforderlichen Schritten wird beschrieben, wie Sie Testdaten einrichten, falls Sie dies noch nicht getan haben:

1. Erstellen Sie einen SSH-Schlüssel, der für die Kommunikationsverschlüsselung verwendet werden soll, falls Sie dies noch nicht getan haben.

1. Sie können aus mehreren Dateisystemen wählen, um Daten und Protokolldateien zu speichern. Erstellen Sie zunächst einen Amazon S3 S3-Bucket. Geben Sie dem Bucket einen eindeutigen Namen. Geben Sie bei der Erstellung den Verschlüsselungsschlüssel an, den Sie erstellt haben.
**Anmerkung**  
Wählen Sie dieselbe Region, um sowohl Ihren Storage-Bucket als auch den Amazon EMR-Cluster zu erstellen.

1. Wählen Sie den Bucket aus, den Sie erstellt haben. Wählen Sie **Ordner erstellen** und geben Sie dem Ordner einen einprägsamen Namen. Wählen Sie beim Erstellen des Ordners eine Sicherheitskonfiguration aus. Sie können die Sicherheitseinstellungen für den übergeordneten Ordner auswählen oder die Sicherheitseinstellungen spezialisieren.

1. Fügen Sie Ihrem Ordner Testdaten hinzu. Für die Zwecke dieses Tutorials eignet sich die Verwendung einer CSV-Datei mit kommagetrennten Datensätzen gut, um diesen Anwendungsfall abzuschließen.

1. Nachdem Sie Daten zu einem Amazon S3 S3-Bucket hinzugefügt haben, konfigurieren Sie eine Tabelle in AWS Glue, um eine Abstraktionsebene für die Abfrage der Daten bereitzustellen.

## Abfragen Connect und ausführen
<a name="emr-trino-getting-started-run"></a>

Im Folgenden wird beschrieben, wie Sie eine Verbindung zu einem Cluster herstellen und Abfragen auf einem Cluster ausführen, auf dem Trino ausgeführt wird. Bevor Sie dies tun, stellen Sie sicher, dass Sie den Hive-Metastore-Konnektor, der im vorherigen Verfahren beschrieben wurde, so eingerichtet haben, dass die Metastore-Tabellen sichtbar sind.

1. Wir empfehlen, EC2 Instance Connect zu verwenden, um eine Verbindung zu Ihrem Cluster herzustellen, da dies eine sichere Verbindung bietet. Wählen Sie **Connect to the Primary Node using SSH** aus der Cluster-Zusammenfassung aus. Die Verbindung erfordert, dass die Sicherheitsgruppe über eine Regel für eingehenden Datenverkehr verfügt, die Verbindungen über Port 22 zu Clients im Subnetz zulässt. Sie müssen außerdem den Benutzer **Hadoop** verwenden, wenn Sie eine Verbindung herstellen.

1. Starten Sie die Trino CLI, indem Sie sie ausführen`trino-cli`. Auf diese Weise können Sie Befehle ausführen und Daten mit Trino abfragen.

1. Führen Sie `show catalogs;`. Vergewissern Sie sich, dass der **Hive-Katalog** aufgeführt ist. Dies enthält eine Liste der verfügbaren Kataloge, die Datenspeicher oder Systemeinstellungen enthalten.

1. Führen Sie den Befehl aus, um die verfügbaren Schemas anzuzeigen. `show schemas in hive;` Von hier aus können Sie Ihr Schema ausführen `use schema-name;` und den Namen angeben. Dann können Sie loslegen, `show tables;` um Tabellen aufzulisten.

1. Fragen Sie eine Tabelle ab, indem Sie einen Befehl ausführen`SELECT * FROM table-name`, z. B. indem Sie den Namen einer Tabelle in Ihrem Schema verwenden. Wenn Sie die `USE` Anweisung bereits ausgeführt haben, um eine Verbindung zu einem bestimmten Schema herzustellen, müssen Sie keine zweiteilige Notation wie *schema* verwenden. *table*.

# Konfiguration von Trino auf Amazon EMR
<a name="emr-trino-config"></a>

**Topics**
+ [Konnektoren für Trino konfigurieren](#emr-trino-config-connector)
+ [Überwachen](#emr-trino-monitoring)

## Konnektoren für Trino konfigurieren
<a name="emr-trino-config-connector"></a>

### Verbindung zu AWS Glue als Hive-Metastore herstellen
<a name="emr-trino-config-connector-hive"></a>

Es ist wichtig und nützlich zu verstehen, dass Sie AWS Glue Data Catalog als Ihren Hive-Metastore konfigurieren können, wenn Sie Abfragen mit Trino ausführen. Weitere Informationen, einschließlich der Schritte zum Einrichten eines Clusters mit einem Hive-Metastore, finden Sie unter [Verwenden des AWS Glue-Datenkatalogs als Metastore](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-metastore-glue.html) für Hive.



Informationen zur Integration von EMR auf EKS mit AWS Glue finden Sie in den folgenden bewährten Methoden: [EMR-Container-Integration mit AWS](https://aws.github.io/aws-emr-containers-best-practices/metastore-integrations/docs/aws-glue/) Glue.

### Verbindung zu Iceberg-Tabellen herstellen, wenn Trino mit Amazon EMR verwendet wird
<a name="emr-trino-config-connector-iceberg"></a>

Iceberg ist ein offenes Tabellenformat für Analysetabellen. Es wurde für Engines wie Spark und Trino entwickelt, um mithilfe von SQL-Abfragen große Datenmengen aus denselben Tabellen abzufragen. Es enthält Funktionen wie das Isolieren von Lese- und Schreibvorgängen, sodass ein Leser beispielsweise vermeiden kann, Daten abzufragen, die teilweise aktualisiert wurden. Es unterstützt auch Statusfunktionen wie Schnappschüsse. Es bietet eine Abstraktionsebene durch die Verwendung von Metadaten und Manifestdateien. Diese beschreiben das Tabellenschema und erleichtern das Abfragen von Daten, ohne dass viele Details darüber bekannt sein müssen, wie sie formatiert oder organisiert sind. Wenn Sie verbunden sind, können Sie sowohl Daten aus den Tabellen lesen, Daten aktualisieren als auch neue Daten in die zugrunde liegenden Dateien schreiben.

Es gibt einen Workshop, der Ihnen zeigt, wie Sie Iceberg-Tabellen mit Amazon EMR und AWS Glue konfigurieren. Weitere Informationen finden Sie unter [Analytics-Workshop — Apache Iceberg-Tabellen auf Ihrem Data Lake einrichten und verwenden](https://youtu.be/SZDYmWIStUo?si=sW35AjSWIcHu5x_p).

### Verbindung zu Kunden herstellen
<a name="emr-trino-config-connector-jdbc"></a>

Sie können sich mit einem verfügbaren JDBC-Treiber mit Trino verbinden. *Weitere Informationen finden Sie unter [JDBC-Treiber](https://trino.io/docs/current/client/jdbc.html) in der Trino-Dokumentation.*

## Überwachen
<a name="emr-trino-monitoring"></a>

Sie können Amazon EMR-Cluster über den AWS-Managementkonsoleüberwachen. Weitere Informationen finden Sie unter [Einen Amazon EMR-Cluster bei der Ausführung seiner Arbeit anzeigen und überwachen](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-view.html). Amazon EMR sendet seine Überwachungsmetriken auch an Amazon CloudWatch. Weitere Informationen zur Überwachung eines Amazon EMR-Clusters finden Sie unter [Amazon CloudWatch Ereignisse und Metriken von Amazon EMR]().

# Bewährte Methoden für Trino auf Amazon EMR
<a name="emr-trino-advanced"></a>

Die Architektur von Trino ist für schnelle, verteilte SQL-Abfragen für große Datenmengen über mehrere Datenquellen hinweg konzipiert. Dabei wird ein Koordinator-Worker-Modell verwendet, bei dem jede Komponente eine spezielle Rolle bei der Abfrageausführung spielt. Es gibt einige Bereiche oder Kategorien, auf die Sie sich konzentrieren können, um Ihren Amazon EMR-Cluster zu konfigurieren, auf dem Trino ausgeführt wird, um die beste Leistung zu erzielen. Diese umfassen u. a. folgende:
+ Anpassung der Cluster-Konfigurationseinstellungen zur Speicheroptimierung.
+ Optimierung der Einstellungen für die Datenpartitionierung und Datenverteilung.
+ Verwendung dynamischer Filterung zur Reduzierung der Anzahl der Abfrageergebnisse.

Einige dieser Einstellungen werden automatisch angepasst, wenn Sie Trino mit Amazon EMR verwenden. Andere können manuell über die Konsole oder über CLI-Befehle eingestellt werden. Die Themen in diesem Abschnitt helfen Ihnen dabei, Ihre Daten und Ihren Cluster optimal zu konfigurieren.

**Topics**
+ [Wichtige Schwerpunktbereiche für die Leistungsverbesserung](emr-trino-performance-areas.md)
+ [Erfassen und nutzen Sie Tabellenstatistiken](emr-trino-performance-areas-collect-stats.md)
+ [Häufige Herausforderungen bei der Skalierung von Trino-Workloads](emr-trino-common-issues.md)

# Wichtige Schwerpunktbereiche für die Leistungsverbesserung
<a name="emr-trino-performance-areas"></a>

Trino maximiert Abfrageparallelität und Speicheroptimierung. Diese Architektur bietet Flexibilität, da sie es ihr ermöglicht, mehrere unterschiedliche Datenquellen abzufragen und gleichzeitig effizient zu skalieren. Zu den wichtigsten Bereichen der Leistungsverbesserung in Trino gehören die unten aufgeführten.

## Optimierung des Speichers
<a name="emr-trino-performance-areas-optimization"></a>

Die Speicherverwaltung in Trino ist entscheidend für eine hohe Leistung und Stabilität, insbesondere wenn Sie große, komplexe Abfragen ausführen. Trino verwendet ein verteiltes Speichermodell. In diesem Modell wird den Worker-Knoten Speicher für die Verarbeitung von Aufgaben, Aggregationen, Verknüpfungen und anderen Vorgängen zugewiesen. In der folgenden Liste wird eine Sammlung dieser Einstellungen vorgestellt:
+ **query.max-memory** — Legt den maximalen Speicher fest, der für eine einzelne Abfrage im gesamten Cluster verfügbar ist. Dies ist ein fester Grenzwert. Wenn eine Abfrage diesen Speicher überschreitet, schlägt sie fehl.
+ **abfragen. max-memory-per-node** — Definiert den maximalen Speicher, den eine Abfrage auf jedem Worker-Knoten verbrauchen kann. Durch diese Einstellung wird sichergestellt, dass keine einzelne Abfrage Ressourcen für einen Worker monopolisiert.
+ **JVM-Heap-Größe** — Auf JVM-Ebene konfiguriert, legt sie die maximale Heap-Größe für den Trino-Serverprozess auf jedem Knoten fest. **Dieser Wert sollte im Allgemeinen größer sein als die speicherbezogenen Konfigurationen (dies ist die Summe der Abfragen). **max-memory-per-node**und Speicher. heap-headroom-per-node**) in Trino, um zu verhindern, dass dem System auf JVM-Ebene der Speicher ausgeht.
+ **Speicher. heap-headroom-per-node** — Gibt eine Pufferspeichermenge an, die von der JVM-Heap-Größe für Operationen, die keine Abfragen sind, weggelassen werden soll. Dies ist entscheidend, um sicherzustellen, dass genügend Overhead für interne Abläufe und die Müllabfuhr zur Verfügung steht.

## Dynamisches Filtern
<a name="emr-trino-performance-areas-dynamic"></a>

Dynamisches Filtern in Trino ist eine Optimierungstechnik, die die Abfrageleistung verbessert, indem sie die Menge der verarbeiteten Daten reduziert, insbesondere bei Verknüpfungen. Es wendet dynamisch Filterbedingungen an, um die von einer Seite einer Verknüpfung gescannten Daten auf der Grundlage der Daten auf der anderen Seite einzuschränken. Dies ist besonders nützlich bei Abfragen, bei denen eine Seite der Verknüpfung sehr selektiv ist (d. h., dass sie eine kleine Teilmenge von Daten enthält). Es ist standardmäßig auf Amazon EMR aktiviert. Im Folgenden finden Sie eine Beispielabfrage:

```
SELECT orders.order_id, orders.total_amount
FROM orders
JOIN customers ON orders.customer_id = customers.customer_id
WHERE customers.country = 'France';
```

Ohne dynamische Filterung scannt Trino die gesamte Bestelltabelle in einem Join, obwohl nur ein kleiner Teil der Kunden (Kunden aus Frankreich) relevant ist. Bei diesem Ansatz werden alle Zeilen in der **Bestelltabelle** gelesen, was zu hohen I/O Bearbeitungskosten führt. Bei der dynamischen Filterung scannt Trino zunächst die Tabelle mit den kleineren **Kunden**, ruft customer\$1id-Werte nur für Kunden aus Frankreich ab und wendet diese Teilmenge dann als Filter auf Bestellungen an. Das bedeutet, dass nur relevante Zeilen aus **Bestellungen gescannt werden** — also solche mit einer Kunden-ID, die der gefilterten Teilmenge entspricht —, wodurch die Anzahl der verarbeiteten Datensätze erheblich reduziert wird.

## Auf Festplatte speichern
<a name="emr-trino-performance-areas-spill"></a>

 In Trino ermöglicht das Verschütten von Festplatten, dass Zwischenabfrageergebnisse auf die Festplatte ausgelagert werden, sodass speicherintensive Abfragen abgeschlossen werden können, auch wenn sie die durch oder festgelegten Speicherlimits überschreiten. `query_max_memory` `query_max_memory_per_node` Standardmäßig setzt Trino diese Grenzwerte durch, um eine faire Speicherzuweisung zu gewährleisten und einen Cluster-Deadlock zu verhindern. Wenn eine umfangreiche Abfrage diese Grenzwerte überschreitet, besteht jedoch die Gefahr, dass sie beendet wird. Disk Spilling behebt dieses Problem durch Verwendung`revocable memory`, sodass eine Abfrage zusätzlichen Speicher ausleihen kann, der gesperrt werden kann, wenn Ressourcen an anderer Stelle benötigt werden. Wenn Speicher gesperrt wird, werden Zwischendaten auf die Festplatte übertragen, sodass Abfragen weiter verarbeitet werden können, ohne die Speichergrenzen zu überschreiten. Bitte beachten Sie, dass eine Abfrage, die gezwungen wird, auf die Festplatte zu übertragen, eine längere Ausführungszeit haben kann und daher standardmäßig deaktiviert ist. Verwenden Sie die folgende Konfiguration, um Spill auf Amazon EMR zu aktivieren:
+ `spill-enabled=true`— Aktiviert das Verschütten von Festplatten, wenn die Speichernutzung die verfügbaren Schwellenwerte überschreitet.
+ `spill-paths`— Definiert die Verzeichnisse, in denen verschüttete Daten gespeichert werden,. `spill-paths=/mnt/spill`

# Erfassen und nutzen Sie Tabellenstatistiken
<a name="emr-trino-performance-areas-collect-stats"></a>

 Durch das Sammeln von Tabellenstatistiken kann der kostenbasierte Optimierer von Trino fundierte Entscheidungen über Join-Bestellungen, Filter-Pushdown und Partitionsbereinigung treffen, was zu einer besseren Leistung führt.

Sie können den `ANALYZE` Befehl verwenden, um Statistiken für Hive- oder Iceberg-Tabellen zu sammeln:

```
ANALYZE sales;
```

Das Sammeln von Statistiken in großen Tabellen kann Ressourcen beanspruchen. Es wird empfohlen, eine Teilmenge von Spalten anzugeben, die in Verknüpfungen, Filtern oder Gruppierungsvorgängen verwendet werden.

Dies ist ein weiterer hilfreicher Befehl. Es zeigt aktuelle Statistiken für eine Tabelle an, um zu überprüfen, ob die Statistiken aktuell sind.

```
show stats for table_name;
```

# Häufige Herausforderungen bei der Skalierung von Trino-Workloads
<a name="emr-trino-common-issues"></a>

Die Hauptvorteile der Verwendung von Amazon S3 mit Trino sind die Skalierbarkeit von S3 für große Datenmengen und die Wirtschaftlichkeit von S3. Wenn Sie jedoch große Datenmengen abfragen, kann es gelegentlich zu einer Reihe damit verbundener Leistungsprobleme kommen. Diese können sich aus der Art und Weise ergeben, wie Daten gespeichert werden, oder durch Konfigurationseinstellungen, die eine gute Leistung einschränken, oder aus anderen Gründen. Wenn diese Probleme auftreten, können Sie wirksame Maßnahmen ergreifen, um sie zu vermeiden oder zu mindern.

Dieser Abschnitt beginnt mit einer Liste allgemeiner Optimierungen, die Sie implementieren können, um die Abfrageleistung bei großen Datenmengen zu erhöhen. Anschließend werden häufig auftretende Probleme detailliert beschrieben und es werden Lösungsmöglichkeiten für jedes Problem bereitgestellt.

Dieses Thema stammt aus der folgenden Konferenzpräsentation: [Accelerate performance at scale: Best practices for Trino with Amazon S3](https://www.youtube.com/watch?v=cjUUcHlUKxQ).

## Optimierung des Datenlayouts für große Datenmengen
<a name="emr-trino-common-issues-practices"></a>

Leistungsengpässe treten nicht selten auf, wenn Sie große Datensätze abfragen. Es gibt jedoch bewährte Methoden, die Sie implementieren können, um sich einen Vorsprung zu verschaffen, wenn Sie Trino verwenden, um Daten in Amazon S3 abzufragen. Diese umfassen u. a. folgende:
+ **Partitionierung** — Partitionierung bedeutet, Daten in einer Hierarchie zu organisieren und verwandte Daten zusammen auf der Grundlage verwandter Attribute zu speichern. Durch die Partitionierung müssen Abfragen nicht so viele irrelevante Daten scannen, was zu einer besseren Abfrageleistung führt. Sie können verschiedene Partitionierungsstrategien verwenden, z. B. das Anordnen von Quelldaten mit Präfixen, insbesondere nach Datumsbereichen, Regionen oder anderen Attributen. Ausführlichere Informationen zur Partitionierung von Daten in Amazon S3 zur Leistungssteigerung finden Sie im Blogbeitrag [Erste Schritte mit der Verwaltung von Partitionen für Amazon S3 S3-Tabellen, die vom AWS Glue-Datenkatalog unterstützt](https://aws.amazon.com/blogs/big-data/get-started-managing-partitions-for-amazon-s3-tables-backed-by-the-aws-glue-data-catalog/) werden, oder im Beitrag Die [10 besten Tipps zur Leistungsoptimierung für Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/).
+ **Bucketing** — Beim Bucketing werden verwandte Daten in gemeinsamen Dateien zusammengefasst. Wenn Sie Daten beispielsweise nach einer geografischen Region, z. B. einem Bundesstaat, abfragen, können Sie die Abfrageleistung steigern, indem Sie alle Daten für einen bestimmten Bundesstaat in derselben Datei oder Gruppe von Dateien gruppieren. Damit dies am besten funktioniert, sollten Sie Ihr Bucketing auf einem Datenattribut mit hoher Kardinalität aufbauen, z. B. einem Bundesstaat oder einer Provinz. Sie können auch Ihre Abfragemuster berücksichtigen. Ein Beispiel hierfür könnte das Gruppieren von Daten für Kalifornien und Oregon bedeuten, wenn Ihre Abfragen in der Regel Daten aus diesen Bundesstaaten zusammen lesen.
+ **Verwaltung von S3-Präfixen** — Sie können Amazon S3 S3-Präfixe verwenden, um eine Partitionierungsstrategie zu implementieren. Wenn Sie nur ein einziges Präfix für einen Amazon S3 S3-Bucket verwenden, z. B. ein bestimmtes Datum, kann dies zu einer hohen Anzahl von Anfragen und zu einem HTTP 503-Fehler führen. Wir empfehlen die Verwendung von Präfixen, um zusätzliche Bedingungen hinzuzufügen und Ihre Quelldaten effektiver zu organisieren. Weitere Informationen finden Sie unter [Organisieren von Objekten mithilfe von Präfixen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-prefixes.html) in der Amazon S3 S3-Dokumentation. Das folgende kurze Beispiel zeigt ein Präfix, das zu einem besseren Anforderungsdurchsatz führt:`s3://bucket/country=US/dt=2024-06-13`. In diesem Beispiel sind sowohl das Land als auch das Datum im Präfix enthalten, was zu weniger Lesevorgängen führt als in einem Fall, in dem das Präfix nur das Datum enthält.

  Die Minimierung von HTTP 503-Fehlern wird im nachfolgenden Abschnitt zur *HTTP-Verlangsamung* in diesem Thema ausführlicher behandelt.
+ **Optimieren der Datengröße** — Sie können den Befehl OPTIMIZE ausführen, um die Konfiguration so einzustellen, dass Abfragen mit besserer Leistung unterstützt werden. Gehen Sie wie folgt vor, um ihn für externe Hive-Tabellen auszuführen:
  + Verwenden Sie es `OPTIMIZE` mit dem folgenden Parameter:`hive.non-managed-table-writes-enabled=true`. Weitere Informationen zu dieser Eigenschaft finden Sie unter [Allgemeine Konfigurationseigenschaften von Hive](https://trino.io/docs/current/connector/hive.html#hive-general-configuration-properties).
  + Stellen Sie den folgenden Sitzungsparameter ein: `SET SESSION` `catalog.non_transactional_optimize_enabled=true`
  + Führen Sie den `OPTIMIZE` Befehl aus:`ALTER TABLE catalog.schema.table EXECUTE optimize(file_size_threshold => '128MB')`. In diesem Fall `file_size_threshold` sind es standardmäßig 100 MB. Eine Erhöhung dieses Schwellenwerts, wie im Beispiel gezeigt, führt dazu, dass Dateien unter 128 MB zusammengeführt werden.
+ **Wiederholungen konfigurieren** — Sie können das Wiederholungslimit erhöhen, wodurch die Wahrscheinlichkeit von HTTP 503-Fehlern verringert werden kann, indem Sie Folgendes festlegen:. `s3.max-error-retries` Dies gilt, wenn Sie die TrinoFileSystem API und die Trino 449-Version oder höher verwenden. Wenn Sie dagegen Amazon EMR mit Trino verwenden, verwenden Sie EMRFS, um auf Amazon S3 zuzugreifen. Mit EMRFS können Sie die Anzahl der Retires erhöhen, indem Sie den Parameter ändern. `fs.s3.maxRetries`
+ **Wählen Sie eine Amazon S3 S3-Speicherklasse** — Die Auswahl der geeigneten Speicherklasse für Daten zu verschiedenen Zeitpunkten im Lebenszyklus kann sowohl bei der Leistung als auch bei den Kosten helfen, basierend auf Ihren Anforderungen für bestimmte Datenerfassungen. Weitere Informationen finden Sie in der [Amazon S3 S3-Dokumentation unter Grundlegendes und Verwalten von Amazon S3 S3-Speicherklassen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.htm).
+ **Zu Iceberg migrieren** — Eine weitere Lösung zur Minderung von Leistungsproblemen, insbesondere beim Ausführen von Abfragen für kleine Dateien, ist die Migration zu Iceberg-Tabellen. Iceberg verfügt über Funktionen, die kleine Dateien gut verarbeiten können.
+ **Automatische Datenkomprimierung verwenden — Wenn** Sie Iceberg-Tabellen verwenden, kann die automatische Datenkomprimierung mit dem AWS Glue-Datenkatalog die Datengröße optimieren und zu einer besseren Abfrageleistung führen.

## Häufige Herausforderungen bei der Abfrage großer Datenmengen
<a name="emr-trino-common-issues-challenges"></a>

In diesem Abschnitt werden häufig auftretende Probleme aufgeführt, die auftreten können, wenn Sie einen großen Datensatz in Amazon S3 sammeln und mit Trino abfragen. Jeder Abschnitt zeigt Ihnen, wie Sie das Problem lösen oder seine Auswirkungen auf Abfragen reduzieren können. Jedes der in den folgenden Abschnitten beschriebenen Probleme wurde mithilfe eines Hive-Connectors reproduziert und getestet.

### Scans großer Datenmengen
<a name="emr-trino-common-issues-large-scan"></a>

Wenn Ihre Abfrage große Datensätze scannen muss, kann dies zu Problemen wie einer langsamen Abfrageleistung und höheren Speicherkosten führen. Große Datenmengen können das Ergebnis eines schnellen Datenwachstums oder einer Planung sein, die nicht dazu führt, dass ältere Daten innerhalb eines angemessenen Zeitrahmens verschoben werden. Dies kann zu langsameren Abfragen führen.

Um Leistungseinbußen beim Scannen großer Datensätze zu minimieren, empfehlen wir die Verwendung von Partitionierung und Bucketing:
+ Bei der Partitionierung werden verwandte Daten auf der Grundlage ihrer Attribute gruppiert. Durch eine effektive Partitionierung kann die Abfrageleistung erheblich verbessert werden.
+ Unter Bucketing versteht man das Gruppieren von Daten in Dateien oder Buckets nach bestimmten, zusammengehörenden Datenspalten. Bucketing bedeutet in der Regel, verwandte Quelldatendateien physisch zusammenzuhalten.

Gehen Sie zur Veranschaulichung der Schadensbegrenzung bei umfangreichen Datenscans vor, indem Sie Daten speichern und abfragen, die Datensätze mit einem Bundesstaatsattribut enthalten, das Kalifornien oder Alaska zugewiesen werden kann, und dieses Bundesstaatsattribut ist eine Ihrer Abfragebedingungen. Sie können die Abfrageleistung verbessern, indem Sie Daten für jeden Bundesstaat in einem separaten S3-Bucket speichern oder Ihre Daten anhand des Bundesstaates partitionieren, indem Sie ein S3-Präfix verwenden. Diese Partitionierung und Bündelung kann auch zu einer Leistungsverbesserung führen, wenn Sie sie auf einer zusätzlichen Spalte aufbauen, z. B. einem Datumsattribut.

**Anmerkung**  
Wenn eine Spalte eine hohe Kardinalität aufweist und Sie sie zum Gruppieren von Daten verwenden möchten, empfehlen wir in diesem Fall die Verwendung von Buckets. Andererseits sollten Partitionsschlüssel im Allgemeinen eine geringere Kardinalität haben.

**Verwendung verschiedener S3-Speichertypen**

Im Allgemeinen wählen Sie Speichertypen auf der Grundlage der Leistungs-, Datenzugriffs-, Ausfallsicherheits- und Kostenanforderungen für Ihre Workloads aus. Es kann Kompromisse zwischen Kosten und Leistung geben. Es ist wichtig, die passende Amazon S3 S3-Speicherklasse auszuwählen, die Ihren Datenzugriffsmustern entspricht. Es gibt zwei Hauptzugriffsmuster:
+ Daten, auf die auf bekannte oder vorhersehbare Weise zugegriffen wird. Wenn Sie Daten haben, auf die selten zugegriffen wird, kann S3 Standard IA generell eine gute Wahl sein, da es zur Kostensenkung beiträgt. Wenn Sie häufig auf Daten zugegriffen haben, eignet sich S3 Standard am besten für den Zugriff mit Amazon EMR und Trino.
+ Daten, auf die auf unbekannte oder unvorhersehbare Weise zugegriffen wird. Dies kann die Verwendung anderer Amazon S3 S3-Speicherklassen erfordern. Es gibt Kompromisse zwischen S3-Speicherklassen. Dazu gehören Latenz, Speicherkosten und Verfügbarkeit. Sie können einen geeigneten S3-Speichertyp auswählen, der auf Ihren Workloads und Zugriffsmustern basiert. Eine Beschreibung der Vorteile der einzelnen Klassen finden Sie unter [Amazon S3 S3-Speicherklassen]().

**Verdichtung verwenden**

Sie können auch die automatische Iceberg-Komprimierung verwenden, wenn Sie Iceberg-Tabellen verwenden, was zu optimaleren Dateigrößen führt, um die Abfrageeffizienz zu erhöhen. Weitere Informationen finden Sie unter [AWS Glue Data Catalog unterstützt jetzt die automatische Komprimierung von Apache Iceberg-Tabellen](https://aws.amazon.com/blogs/aws/aws-glue-data-catalog-now-supports-automatic-compaction-of-apache-iceberg-tables/).

### Fehler bei der HTTP-Verlangsamung
<a name="emr-trino-common-issues-slow-network"></a>

Dies tritt auf, wenn die Anforderungsrate einen vorkonfigurierten Schwellenwert für ein Amazon S3 S3-Präfix überschreitet. Der HTTP-Fehler, der am häufigsten auftritt, wenn dieser Status erreicht ist, ist folgender: **Fehler 503: Bitte reduzieren Sie Ihre Anforderungsrate**. Die Ursache für dieses Problem kann darin liegen, dass eine große Anzahl kleiner Dateien vorhanden ist, da zum Lesen der Daten viele *Splits* erstellt werden müssen. Es gibt mehrere Möglichkeiten, das Problem zu beheben:
+ Erhöhen Sie das Wiederholungslimit für Amazon S3 S3-Anfragen in Trino. Dies ist für die Verwendung `fs.s3.maxretries` von EMRFS in Trino 449 festgelegt.
+ Optimieren Sie die Dateigrößen, was auch zu einer niedrigeren Anforderungsrate führen kann.

Weitere Informationen darüber, wie Trino die Anzahl der Splits in einem abzufragenden Datensatz bestimmt, finden Sie unter [Konfigurationseigenschaften zur Leistungsoptimierung](https://trino.io/docs/current/connector/hive.html#performance-tuning-configuration-properties) in der Hive-Connector-Dokumentation.

### Schwierigkeiten beim Abfragen kleiner Dateien
<a name="emr-trino-common-issues-small-files"></a>

Das Abfragen vieler kleiner Dateien kann aufgrund der hohen Anzahl von GET- und LIST-Anfragen zu hohem I/O Mehraufwand führen und sich in der Folge negativ auf die Abfrageleistung auswirken. Durch die Optimierung der Dateigröße kann die Abfrageleistung verbessert werden. Es gibt mehrere Möglichkeiten, dies zu tun:
+ Konsolidieren Sie Daten in weniger größeren Dateien. (Im Allgemeinen empfehlen wir, die Dateigröße bei etwa 128 MB zu halten.) Sie können dies mit Tools tun, wenn Sie Daten aufnehmen, z. B. in einer ETL-Pipeline, oder Sie können Daten manuell konsolidieren. Wenn Ihnen diese Lösungen nicht zur Verfügung stehen, sind die übrigen Optionen möglicherweise besser für Sie geeignet.
+ Führen Sie den Befehl `OPTIMIZE` aus.
+ Legen Sie den Parameter `SESSION` fest.

Beachten Sie, dass Iceberg über eine Funktion zum Zusammenführen kleiner Dateien zu größeren Dateien verfügt, nämlich die automatische Komprimierung. Es funktioniert mit Dateien, die mit dem AWS Glue Data Catalog verwaltet werden. Weitere Informationen finden Sie unter [AWS Glue Data Catalog unterstützt jetzt die automatische Komprimierung von Apache Iceberg-Tabellen](https://aws.amazon.com/blogs/aws/aws-glue-data-catalog-now-supports-automatic-compaction-of-apache-iceberg-tables/).

### Abfragen, die Daten enthalten, die nicht benötigt werden
<a name="emr-trino-common-issues-uneeded-data"></a>

Es ist üblich, dass Daten wachsen. Daher ist es unerlässlich, Ihre Datenzugriffsmuster zu verfolgen und Daten entsprechend zu verschieben, wenn sie altern oder irrelevant werden. Dies liegt daran, dass sich die Abfrageleistung mit der Zeit verschlechtern kann, wenn die Datenmenge wächst. Dies ist hauptsächlich auf die schiere Datenmenge zurückzuführen, die bei der Ausführung einer Abfrage gescannt werden muss. Amazon S3 und andere Services bieten Anleitungen für die Migration des Datenlebenszyklus, in denen Strategien für das Verschieben von Daten an verschiedene Speicherorte aufgezeigt werden, wenn sie kalt werden. Dies hat auch einen Vorteil bei den Speicherkosten.

Neben der Datenmigration können Sie auch andere Strategien verwenden, z. B. das Entfernen von Quelldaten, die für die von Ihnen ausgeführten Abfragen nicht relevant sind. Dies kann einige Arbeit erfordern, da es eine Änderung Ihres Quelldatenschemas bedeuten kann. Das positive Ergebnis besteht jedoch darin, das Datenvolumen zu reduzieren und Abfragen zu beschleunigen. Weitere Informationen finden Sie unter [Verwaltung des Lebenszyklus von Objekten](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html).

# Überlegungen zu Trino
<a name="Trino-considerations"></a>

Beachten Sie Folgendes, wenn Sie Trino auf Amazon EMR ausführen.

## Nicht konfigurierbare Trino-Bereitstellungseigenschaften
<a name="emr-trino-deployment-config"></a>

Die folgende Tabelle zeigt die verschiedenen Konfigurationsoptionen für `properties` Trino-Dateien.


| Datei | Konfigurierbar | 
| --- | --- | 
|  `log.properties`  |  Trino: Konfigurierbar in Amazon EMR-Versionen 6.1.0 und höher. Verwenden Sie die `prestosql-log`- oder `trino-log`-Konfigurationsklassifizierung.  | 
|  `config.properties`  |  Trino: Konfigurierbar in Amazon EMR-Versionen 6.1.0 und höher. Verwenden Sie die `prestosql-config`- oder `trino-config`-Konfigurationsklassifizierung.  | 
|  `hive.properties`  |  Trino: Konfigurierbar in Amazon EMR-Versionen 6.1.0 und höher. Verwenden Sie die `prestosql-connector-hive`- oder `trino-connector-hive`-Konfigurationsklassifizierung.  | 
|  `node.properties`  |  Trino: Konfigurierbar in Amazon EMR-Versionen 6.1.0 und höher. Verwenden Sie die `prestosql-node`- oder `trino-node`-Konfigurationsklassifizierung.  | 
|  `jvm.config`  |  Nicht konfigurierbar.  | 

## Weitere Überlegungen
<a name="emr-trino-deployment-config-additional"></a>
+ Für Trino auf EMR-Version 6.1.0 und höher konfiguriert Amazon EMR automatisch einen gemeinsamen geheimen Schlüssel für die sichere interne Kommunikation zwischen Clusterknoten. Sie müssen keine zusätzliche Konfiguration vornehmen, um dieses Sicherheitsfeature zu aktivieren, und Sie können die Konfiguration mit Ihrem eigenen geheimen Schlüssel überschreiben. Informationen zur internen Authentifizierung von Trino finden Sie in der [Trino-353-Dokumentation: Sichere interne Kommunikation](https://trino.io/docs/current/security/internal-communication.html).

# Versionsverlauf von Trino
<a name="Trino-release-history"></a>

In den Abschnitten mit den Versionshinweisen werden die Änderungen und Updates für eine bestimmte Version von Trino auf Amazon EMR detailliert beschrieben.

## Versionshinweise zu Trino nach Version
<a name="Trino-release-history-versions"></a>
+ [Amazon EMR 7.6.0 — Versionshinweise zu Trino](Trino-release-history-760.md)
+ [Amazon EMR 7.3.0 — Versionshinweise zu Trino](Trino-release-history-730.md)
+ [Amazon EMR 6.9.0 — Versionshinweise zu Trino](Trino-release-history-690.md)

# Amazon EMR 7.6.0 — Versionshinweise zu Trino
<a name="Trino-release-history-760"></a>

## Amazon EMR 7.6.0 — Neue Funktionen von Trino
<a name="Trino-release-history-features-760"></a>
+ Um Abfragen mit langer Laufzeit zu unterstützen, verfügt Trino jetzt über einen fehlertoleranten Ausführungsmechanismus. Die fehlertolerante Ausführung minimiert Abfragefehler, indem fehlgeschlagene Abfragen oder deren Komponentenaufgaben wiederholt werden.

## Amazon EMR 7.6.0 — Änderungen bei Trino
<a name="Trino-release-history-changes-760"></a>


**Amazon EMR 7.6.0 — Änderungen bei Trino**  

| Typ | Description | 
| --- | --- | 
| Upgrade |  Trino auf 4.5.7 aktualisieren  | 

# Amazon EMR 7.3.0 — Versionshinweise zu Trino
<a name="Trino-release-history-730"></a>

## Amazon EMR 7.3.0 — Änderungen bei Trino
<a name="Trino-release-history-changes-730"></a>
+ In dieser Version wird Trino von Version 436 auf 442 aktualisiert.
+ Diese Version leitet Hudi-Abfragen an den neuen Hudi-Korrektor weiter. Der alte Hive-Connector kann keine Hudi-Tabellen mehr lesen. Hinweis 
+ In dieser Version wird das Rubix-Modul aus Amazon EMR entfernt, da es jetzt als Open-Source-Modul veraltet ist.
+ Diese Version [entfernt](https://github.com/trinodb/trino/pull/21013) den Legacy-Modus in der Eigenschaft. `hive.security` Die Standardeinstellung ist jetzt`allow-all`.

# Amazon EMR 6.9.0 — Versionshinweise zu Trino
<a name="Trino-release-history-690"></a>

## Amazon EMR 6.9.0 — Neue Funktionen von Trino
<a name="Trino-release-history-features-690"></a>
+ Um Abfragen mit langer Laufzeit zu unterstützen, verfügt Trino jetzt über einen fehlertoleranten Ausführungsmechanismus. Die fehlertolerante Ausführung minimiert Abfragefehler, indem fehlgeschlagene Abfragen oder deren Komponentenaufgaben wiederholt werden.

## Amazon EMR 6.9.0 – Trino-Änderungen
<a name="Trino-release-history-changes-690"></a>


**Amazon EMR 6.9.0 – Trino-Änderungen**  

| Typ | Description | 
| --- | --- | 
| Upgrade |  Trino-Upgrade auf 398   | 
| Upgrade |  Unterstützung von Hadoop 3.3.3   | 
| Feature |  Tardigrade-Unterstützung: Unterstützung für Exchange-Spooling auf HDFS und Amazon S3 hinzugefügt.   | 
| Fehlerbehebung |  Wenn Trino Iceberg verwendet wird und der Glue-Katalog aktiviert ist, vermeiden Sie das Hinzufügen von Metastore-URI in `iceberg.properties.`  | 

## Amazon EMR 6.9.0 — Bekannte Probleme bei Trino
<a name="Trino-release-history-known-690"></a>
+ Für Amazon-EMR-Version 6.9.0 funktioniert Trino nicht auf Clustern, die für Apache Ranger aktiviert sind. Wenn Sie Trino mit Ranger verwenden müssen, wenden Sie sich an [Support](https://console.aws.amazon.com/support/home#/).