Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Trino
Trino est un moteur de requêtes open source conçu pour les requêtes interactives sur un large éventail de sources de données. Il peut s'agir de bases de données relationnelles, de données basées sur des fichiers, de données HDFS, etc. L'objectif le plus courant de Trino avec Amazon EMR est d'exécuter des requêtes SQL complexes sur de grands ensembles de données stockés dans Amazon S3. Il est également conforme à la norme ANSI SQL, ce qui le rend familier aux ingénieurs de bases de données, aux analystes de données et aux scientifiques des données familiarisés avec le SQL.
**Note**
PrestoSQL a été renommé Trino en décembre 2020. Les versions 6.4.0 et ultérieures d'Amazon EMR font généralement référence à [Trino](https://trino.io/), tandis que les versions antérieures font référence à PrestoSQL.
**Important**
PrestoSQL, la version précédente de Trino, est toujours disponible pour une utilisation avec Amazon EMR. Cependant, nous recommandons vivement d'utiliser Trino à l'avenir avec Amazon EMR. Notez également que Trino et PrestoSQL ne peuvent pas fonctionner simultanément sur le même cluster.
Le tableau suivant répertorie la version de Trino incluse dans la dernière version d'Amazon EMR 7.x, ainsi que les composants qu'Amazon EMR installe avec Trino. Pour la version des composants installés avec Trino dans cette version, voir la [version 7.12.0](emr-7120-release.md) Versions des composants.
**Informations de version de Trino (PrestoSQL) pour emr-7.12.0**
| Étiquette de version Amazon EMR | Version Trino (PrestoSQL) | Composants installés avec Trino (PrestoSQL) |
| --- | --- | --- |
| 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**
+ [Histoire et design de Trino](emr-trino-intro-history.md)
+ [Commencer à utiliser Trino](emr-trino-getting-started.md)
+ [Configuration de Trino sur Amazon EMR](emr-trino-config.md)
+ [Bonnes pratiques pour Trino sur Amazon EMR](emr-trino-advanced.md)
+ [Considérations relatives à Trino](Trino-considerations.md)
+ [Historique des sorties de Trino](Trino-release-history.md)
# Histoire et design de Trino
Trino est spécialisé dans l'interrogation de grands ensembles de données provenant de nombreuses sources différentes. Trino peut accéder à HDFS et l'interroger dans un cas d'utilisation traditionnel des mégadonnées, mais il peut également interroger des sources supplémentaires telles que des bases de données relationnelles et des bases de données NoSQL. Trino a débuté en tant que fork du moteur de requêtes Presto, en 2019. Depuis, il a été développé indépendamment de la base de code Presto.
Pour plus d'informations sur le moteur de requêtes Trino et son utilisation, consultez le site Web de [Trino](https://trino.io/). Pour lire la documentation source de Trino, voir Présentation de [Trino](https://trino.io/docs/current/overview.html).
## Concepts architecturaux
Trino peut exécuter des requêtes rapides et efficaces car il traite les données en parallèle au sein d'un cluster. Il a été conçu pour interroger un lac de données, car il est spécialisé pour les requêtes portant sur de gros volumes de données, généralement dans les cas d'utilisation impliquant Hadoop et HDFS. Mais il peut également interroger les bases de données relationnelles traditionnelles. Pour plus d'informations, consultez la section [Architecture](https://trino.io/docs/current/overview/concepts.html#architecture) dans la *documentation de Trino*.
### Composants de Trino
Trino possède quelques composants d'architecture clés qui fonctionnent ensemble pour accélérer l'exécution des requêtes. Il est utile d'avoir une connaissance pratique de ces éléments lorsque vous peaufinez votre cluster pour améliorer ses performances :
+ Le **coordinateur** est responsable de l'orchestration des requêtes. Il analyse et optimise les requêtes SQL entrantes, génère des plans d'exécution, assigne des tâches aux nœuds de travail, collecte et assemble les résultats des requêtes. En outre, il surveille l'utilisation des ressources et suit l'état des nœuds de travail. Pour plus d'informations, consultez [Coordinator](https://trino.io/docs/current/overview/concepts.html#coordinator) dans la *documentation de Trino*.
+ **Les nœuds** de travail gèrent le traitement des données pour les requêtes. Une fois que le coordinateur a attribué les tâches, les travailleurs récupèrent les données, effectuent les opérations nécessaires, telles que les jointures et les agrégations, et échangent des données intermédiaires avec d'autres travailleurs. Pour plus d'informations, consultez [Worker](https://trino.io/docs/current/overview/concepts.html#worker) dans la *documentation de Trino*.
+ Les **connecteurs** sont des plug-ins qui permettent à Trino de se connecter à diverses sources de données et de les interroger. Chaque connecteur sait comment accéder aux données et les récupérer à partir de sa source, telle qu'Amazon S3, Apache Hive ou des bases de données relationnelles. Ces connecteurs mappent les données source à la structure du schéma de Trino.
+ Un **catalogue** est un ensemble logique de schémas et de tables associés à un connecteur spécifique. Définis dans le coordinateur, les catalogues permettent à Trino de traiter différentes sources de données comme un seul espace de noms. Cela permet aux utilisateurs d'interroger plusieurs sources ensemble, telles que Hive et MySQL, de manière unifiée dans la même requête.
+ **Les clients** tels que la CLI Trino se connectent au coordinateur Trino au moyen de pilotes JDBC et ODBC pour soumettre des requêtes SQL. Le coordinateur gère le cycle de vie des requêtes et fournit les résultats au client pour une analyse ou un reporting plus approfondis.
### Exécution de requêtes
Pour comprendre comment Trino prend les instructions SQL et les exécute sous forme de requêtes, consultez les [concepts de Trino](https://trino.io/docs/current/overview/concepts.html#query-execution-model) dans la documentation de *Trino*.
# Commencer à utiliser Trino
Les procédures décrites dans cette section vous montrent comment configurer un cluster Amazon EMR afin d'interroger des sources de données de métastore avec Trino. Ces métastores, qui incluent le catalogue de données AWS Glue, stockent les métadonnées et les objets de base de données et gèrent les autorisations d'accès. Les procédures couvrent les prérequis, les paramètres de configuration recommandés, la création de connecteurs et l'exécution de requêtes sur des tables de métastore.
**Topics**
+ [Suivez les étapes préalables à l'utilisation d'Amazon EMR avec Trino](emr-trino-getting-started-pre.md)
+ [Lancez un cluster Amazon EMR avec Trino](emr-trino-getting-started-launch.md)
+ [Connectez-vous au nœud principal du cluster Amazon EMR et exécutez des requêtes](emr-trino-getting-started-connect.md)
# Suivez les étapes préalables à l'utilisation d'Amazon EMR avec Trino
Si vous n'avez pas utilisé AWS, ou si vous n'avez pas créé de cluster Amazon EMR, suivez ces étapes préalables avant de créer un cluster Amazon EMR avec Trino.
## AWS configuration de l'environnement
Si ce n'est pas déjà fait, procédez comme suit pour configurer votre AWS compte :
1. Ouvrez un AWS compte, si vous n'en avez pas déjà un. Pour plus d'informations, consultez la section [Création d'un AWS compte](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-creating.html) dans le *Guide de référence AWS sur la gestion des comptes*.
1. Connectez-vous à votre compte en tant qu'utilisateur administratif.
1. Créez un groupe et attribuez-lui des utilisateurs.
1. Créez une paire de clés Amazon EC2, que vous pourrez utiliser ultérieurement pour sécuriser les communications entre les ressources avec SSH. Cette étape est obligatoire si vous prévoyez de vous connecter au nœud principal pour effectuer des tâches. Pour plus d'informations, consultez [Se connecter au nœud principal du cluster Amazon EMR à l'aide](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-connect-master-node-ssh.html) de SSH.
# Lancez un cluster Amazon EMR avec Trino
Ce qui suit décrit les choix de configuration corrects lorsque vous créez un cluster avec Trino.
## Utilisation d'un connecteur Hive pour rendre les données disponibles pour les requêtes
Vous pouvez configurer un connecteur Trino pour un métastore Hive afin d'interroger les données du métastore provenant de votre cluster. Un métastore est une couche d'abstraction qui rend le contenu ou les données basés sur des fichiers disponibles sous forme de tables, ce qui facilite les requêtes. Vous devez configurer un connecteur dans Amazon EMR pour mettre les tables de métastore Hive à la disposition du cluster. La procédure suivante vous indique comment procéder :
1. Choisissez AWS Glue dans la console et créez un tableau en fonction de vos données sources dans Amazon S3. Un tableau du catalogue de données AWS Glue est la définition des métadonnées des données. Dans ce contexte, il est judicieux de créer le tableau manuellement, en créant des colonnes comme vous le souhaitez, à partir de vos données sources. Pour plus d'informations sur la création de tables dans AWS Glue à partir de données semi-structurées dans Amazon S3, consultez la section [Création de tables à l'aide de la console](https://docs.aws.amazon.com/glue/latest/dg/tables-described.html#console-tables) dans le *guide de l'utilisateur de AWS Glue*.
1. Définissez votre configuration dans le cadre de la création du cluster. Sélectionnez l'onglet **Configurations**. Les configurations sont des spécifications facultatives pour votre cluster. Lorsque vous entrez une configuration, ajoutez du JSON comme dans l'exemple suivant, qui indique à Trino d'utiliser le catalogue de données AWS Glue comme métastore Hive externe pour les métadonnées des tables :
```
{
"classification": "trino-connector-hive",
"properties": {
"hive.metastore": "glue"
}
}
```
Vous pouvez également appliquer des configurations dans la section **Paramètres du logiciel** lorsque vous créez un cluster.
En outre, vous pouvez configurer d'autres types de connecteurs, par exemple pour vous connecter à Apache Iceberg. Pour plus d'informations, consultez la section [Utiliser un cluster Iceberg avec Trino](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-iceberg-use-trino-cluster.html) dans le guide de mise à jour d'Amazon *EMR.* La configuration de paramètres supplémentaires est facultative.
Pour poursuivre les étapes de démarrage, voir. [Connectez-vous au nœud principal du cluster Amazon EMR et exécutez des requêtes](emr-trino-getting-started-connect.md)
## Création d'un cluster avec Trino
Ce qui suit décrit les choix de configuration corrects lorsque vous créez un cluster que vous souhaitez utiliser avec Trino.
**Important**
Avant de créer votre cluster, complétez AWS la configuration de Glue Data Catalog en tant que métastore Hive, ce que nous recommandons pour démarrer. Pour de plus amples informations, veuillez consulter [Utilisation d'un connecteur Hive pour rendre les données disponibles pour les requêtes](#emr-trino-getting-started-connect-hive).
1. Dans la AWS console, sélectionnez Amazon EMR dans les services. Lorsque vous choisissez Amazon EMR, si vous avez des clusters existants, vos **EMR sur les clusters EC2** sont répertoriés.
1. Choisissez **Créer un cluster**. À partir de là, vous lancez le processus de création d'un cluster.
1. Donnez un nom à votre cluster et choisissez une version d'**Amazon EMR.** Vous pouvez choisir la version la plus récente du didacticiel.
1. Choisissez le pack **Trino** dans lequel l'application Trino est présélectionnée. Les offres groupées sont configurées pour des raisons de commodité lorsque vous connaissez à l'avance l'objectif du cluster. Sinon, vous pouvez simplement sélectionner la case à cocher pour Trino.
1. Pour la **configuration du cluster**, choisissez **Uniform instance groups**. Allez-y et supprimez des groupes d'instances supplémentaires.
1. Choisissez un **type d'instance**. En général, nous vous recommandons de choisir un type d'instance avec au moins 16 GiB de mémoire. De plus, pour le **dimensionnement et le provisionnement du cluster**, choisissez **Définir la taille du cluster manuellement**.
1. À ce stade, définissez la configuration de votre métastore Hive pour qu'elle pointe vers Glue. AWS Ceci est détaillé dans la section[Utilisation d'un connecteur Hive pour rendre les données disponibles pour les requêtes](#emr-trino-getting-started-connect-hive). Effectuez cette opération avant de créer le cluster.
1. Choisissez **Créer un cluster**. Cela peut prendre quelques minutes pour terminer.
Les étapes décrites ici ne couvrent pas toutes les étapes de configuration en détail. Plus d'informations sur la configuration d'un cluster sont disponibles sur [Planifier, configurer et lancer des clusters Amazon EMR.](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan.html)
**Note**
Ne sélectionnez pas Presto et Trino pour une utilisation sur le même cluster. Il n'est pas possible de les exécuter ensemble. Il est également recommandé que si vous exécutez Trino, vous n'exécutiez aucune autre application sur le cluster, telle que Spark.
# Connectez-vous au nœud principal du cluster Amazon EMR et exécutez des requêtes
## Fournir des données de test et configurer les autorisations
Vous pouvez tester Amazon EMR avec Trino en utilisant AWS Glue Data Catalog et son métastore Hive. Ces étapes préalables décrivent comment configurer les données de test, si vous ne l'avez pas encore fait :
1. Créez une clé SSH à utiliser pour le chiffrement des communications, si ce n'est déjà fait.
1. Vous pouvez choisir parmi plusieurs systèmes de fichiers pour stocker les données et les fichiers journaux. Pour commencer, créez un compartiment Amazon S3. Donnez un nom unique au compartiment. Lorsque vous le créez, spécifiez la clé de chiffrement que vous avez créée.
**Note**
Choisissez la même région pour créer à la fois votre compartiment de stockage et le cluster Amazon EMR.
1. Choisissez le bucket que vous avez créé. Choisissez **Créer un dossier** et attribuez au dossier un nom mémorable. Lorsque vous créez le dossier, choisissez une configuration de sécurité. Vous pouvez choisir les paramètres de sécurité pour le parent ou les personnaliser davantage.
1. Ajoutez des données de test à votre dossier. Pour les besoins de ce didacticiel, l'utilisation d'un fichier .csv composé d'enregistrements séparés par des virgules fonctionne bien pour compléter ce cas d'utilisation.
1. Après avoir ajouté des données dans un compartiment Amazon S3, configurez une table dans AWS Glue pour fournir une couche d'abstraction permettant d'interroger les données.
## Connect et exécution de requêtes
Ce qui suit décrit comment vous vous connectez à un cluster exécutant Trino et comment exécuter des requêtes sur celui-ci. Avant cela, assurez-vous de configurer le connecteur de métastore Hive, décrit dans la procédure précédente, afin que les tables de métastore soient visibles.
1. Nous vous recommandons d'utiliser EC2 Instance Connect pour vous connecter à votre cluster, car il fournit une connexion sécurisée. Choisissez **Connect to the primary node using SSH** dans le résumé du cluster. La connexion nécessite que le groupe de sécurité dispose d'une règle entrante pour autoriser les connexions via le port 22 aux clients du sous-réseau. Vous devez également utiliser l'utilisateur **hadoop** lors de la connexion.
1. Démarrez la CLI Trino en exécutant. `trino-cli` Cela vous permet d'exécuter des commandes et d'interroger des données avec Trino.
1. Exécutez `show catalogs;`. Vérifiez que le catalogue des **ruches** est répertorié. Cela fournit une liste des catalogues disponibles, qui contiennent des magasins de données ou des paramètres système.
1. Pour voir les schémas disponibles, exécutez`show schemas in hive;`. À partir de là, vous pouvez exécuter `use schema-name;` et inclure le nom de votre schéma. Ensuite, vous pouvez courir `show tables;` pour répertorier les tables.
1. Interrogez une table en exécutant une commande telle que`SELECT * FROM table-name`, en utilisant le nom d'une table dans votre schéma. Si vous avez déjà exécuté l'`USE`instruction pour vous connecter à un schéma spécifique, il n'est pas nécessaire d'utiliser une notation en deux parties telle que*schema*. *table*.
# Configuration de Trino sur Amazon EMR
**Topics**
+ [Configuration des connecteurs pour Trino](#emr-trino-config-connector)
+ [Contrôle](#emr-trino-monitoring)
## Configuration des connecteurs pour Trino
### Connexion à AWS Glue en tant que métastore Hive
Il est important et utile de comprendre que vous pouvez configurer AWS Glue Data Catalog comme métastore Hive lorsque vous exécutez des requêtes avec Trino. Pour plus d'informations, y compris les étapes de configuration d'un cluster avec un métastore Hive, voir Utilisation [du catalogue de données AWS Glue comme métastore](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-metastore-glue.html) pour Hive.
Pour plus d'informations sur l'intégration d'EMR sur EKS avec AWS Glue, consultez les meilleures pratiques suivantes, [Intégration des conteneurs EMR](https://aws.github.io/aws-emr-containers-best-practices/metastore-integrations/docs/aws-glue/) à Glue. AWS
### Connexion aux tables Iceberg lors de l'utilisation de Trino avec Amazon EMR
Iceberg est un format de table ouvert pour les tables analytiques. Il a été créé pour des moteurs tels que Spark et Trino afin d'interroger des données volumineuses à partir des mêmes tables, à l'aide de requêtes SQL. Il inclut des fonctionnalités telles que l'isolation des lectures et des écritures de données, afin qu'un lecteur puisse éviter d'interroger des données partiellement mises à jour, par exemple. Il prend également en charge les fonctionnalités d'état, telles que les instantanés. Il fournit une couche d'abstraction grâce à l'utilisation de métadonnées et de fichiers manifestes. Ils décrivent le schéma des tables et facilitent les requêtes de données sans avoir à connaître beaucoup de détails sur leur mise en forme ou leur organisation. Lorsque vous êtes connecté, vous pouvez à la fois lire les données des tables, les mettre à jour ou écrire de nouvelles données dans les fichiers sous-jacents.
Un atelier vous montre comment configurer les tables Iceberg avec Amazon EMR et AWS Glue. Pour plus d'informations, consultez [Analytics Workshop - Configurer et utiliser les tables Apache Iceberg sur votre lac de données](https://youtu.be/SZDYmWIStUo?si=sW35AjSWIcHu5x_p).
### Établir des liens avec les clients
Vous pouvez vous connecter à Trino à l'aide d'un pilote JDBC disponible. Pour plus d'informations, consultez le [pilote JDBC](https://trino.io/docs/current/client/jdbc.html) dans la documentation de *Trino*.
## Contrôle
Vous pouvez surveiller les clusters Amazon EMR via le. AWS Management Console Pour plus d'informations, consultez [Afficher et surveiller un cluster Amazon EMR pendant qu'il exécute](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-view.html) des tâches. Amazon EMR envoie également ses mesures de surveillance à. Amazon CloudWatch Pour plus d'informations sur la surveillance d'un cluster Amazon EMR, consultez les [Amazon CloudWatch événements et les métriques d'Amazon EMR]().
# Bonnes pratiques pour Trino sur Amazon EMR
L'architecture de Trino est conçue pour des requêtes SQL rapides et distribuées sur de grands ensembles de données provenant de plusieurs sources de données, selon un modèle coordinateur-travailleur, dans lequel chaque composant joue un rôle spécialisé dans l'exécution des requêtes. Il existe quelques domaines ou catégories sur lesquels vous pouvez vous concentrer afin de configurer votre cluster Amazon EMR exécutant Trino pour obtenir les meilleures performances. Cela inclut les éléments suivants :
+ Ajustement des paramètres de configuration du cluster pour optimiser la mémoire.
+ Optimisation des paramètres de partitionnement et de distribution des données.
+ Utilisation du filtrage dynamique pour réduire le nombre de résultats des requêtes.
Certains de ces paramètres sont réglés automatiquement lorsque vous utilisez Trino avec Amazon EMR. D'autres peuvent être définis manuellement via la console ou via les commandes de la CLI. Les rubriques de cette section vous aident à configurer vos données et votre cluster de manière optimale.
**Topics**
+ [Principaux domaines d'intérêt pour l'amélioration des performances](emr-trino-performance-areas.md)
+ [Collecter et utiliser les statistiques des tables](emr-trino-performance-areas-collect-stats.md)
+ [Défis courants liés au dimensionnement des charges de travail de Trino](emr-trino-common-issues.md)
# Principaux domaines d'intérêt pour l'amélioration des performances
Trino maximise le parallélisme des requêtes et l'optimisation de la mémoire. Cette architecture apporte de la flexibilité en lui permettant d'interroger des sources de données multiples et variées tout en assurant une mise à l'échelle efficace. Les principaux domaines d'amélioration des performances de Trino sont ceux énumérés ci-dessous.
## Optimisation de la mémoire
La gestion de la mémoire dans Trino est essentielle pour atteindre des performances et une stabilité élevées, en particulier lorsque vous exécutez des requêtes complexes et volumineuses. Trino utilise un modèle de mémoire distribuée. Dans ce modèle, la mémoire est allouée entre les nœuds de travail pour le traitement des tâches, des agrégations, des jointures et d'autres opérations. La liste suivante présente un ensemble de ces paramètres :
+ **query.max-memory** — Définit la mémoire maximale disponible pour une seule requête sur l'ensemble du cluster. Il s'agit d'une limite stricte ; si une requête dépasse cette mémoire, elle échouera.
+ **requête. max-memory-per-node** — Définit la mémoire maximale qu'une requête peut consommer sur chaque nœud de travail. Cette configuration garantit qu'aucune requête ne monopolise les ressources d'un travailleur.
+ **Taille du tas de mémoire de machine virtuelle Java** : configuré au niveau de la machine virtuelle Java, il définit la taille de segment de mémoire maximale pour le processus du serveur Trino sur chaque nœud. **Cette valeur doit généralement être supérieure aux configurations liées à la mémoire (il s'agit de la somme des requêtes). max-memory-per-node**et de **la mémoire. heap-headroom-per-node**) dans Trino pour éviter que le système ne manque de mémoire au niveau de la JVM.
+ **mémoire. heap-headroom-per-node** — Spécifie la quantité de mémoire tampon à exclure de la taille du segment de mémoire JVM pour les opérations autres que les requêtes. Cela est crucial pour garantir des frais généraux suffisants pour les opérations internes et la collecte des déchets.
## Filtrage dynamique
Le filtrage dynamique dans Trino est une technique d'optimisation qui améliore les performances des requêtes en réduisant la quantité de données traitées, en particulier lors des jointures. Il applique dynamiquement des conditions de filtre pour limiter les données scannées d'un côté d'une jointure, en fonction des données visibles de l'autre côté, ce qui est particulièrement utile dans les requêtes où un côté de la jointure est très sélectif (c'est-à-dire qu'il contient un petit sous-ensemble de données). Il est activé par défaut sur Amazon EMR. Voici un exemple de requête :
```
SELECT orders.order_id, orders.total_amount
FROM orders
JOIN customers ON orders.customer_id = customers.customer_id
WHERE customers.country = 'France';
```
Sans filtrage dynamique, Trino analyse l'intégralité du tableau des commandes dans une jointure, même si seul un petit sous-ensemble de clients (ceux de France) est pertinent. Cette approche permet de lire toutes les lignes du tableau **des commandes**, ce qui entraîne I/O des coûts de traitement élevés. Avec le filtrage dynamique, Trino analyse d'abord la petite table des **clients**, récupère les valeurs customer\$1id uniquement pour les clients de France, puis applique ce sous-ensemble en tant que filtre sur les commandes. Cela signifie que seules les lignes pertinentes des **commandes** (celles dont le customer\$1id correspond au sous-ensemble filtré) sont scannées, ce qui réduit considérablement le nombre d'enregistrements traités.
## Spill to Disk
Dans Trino, le débordement de disque permet de transférer les résultats des requêtes intermédiaires sur le disque, ce qui permet de terminer les requêtes gourmandes en mémoire, même si elles dépassent les limites de mémoire définies par ou. `query_max_memory` `query_max_memory_per_node` Par défaut, Trino applique ces limites pour garantir une allocation de mémoire équitable et empêcher le blocage du cluster. Toutefois, lorsqu'une requête volumineuse dépasse ces limites, elle risque d'être interrompue. Le déversement de disque résout ce problème en utilisant`revocable memory`, permettant à une requête d'emprunter de la mémoire supplémentaire qui peut être révoquée si des ressources sont nécessaires ailleurs. Lorsque la mémoire est révoquée, les données intermédiaires se répandent sur le disque, ce qui permet aux requêtes de poursuivre le traitement sans dépasser les limites de mémoire. Veuillez noter qu'une requête qui est forcée de se propager sur le disque peut avoir un temps d'exécution plus long, c'est pourquoi elle est désactivée par défaut. Pour activer Spill sur Amazon EMR, utilisez la configuration suivante :
+ `spill-enabled=true`— Permet de renverser le disque lorsque l'utilisation de la mémoire dépasse les seuils disponibles.
+ `spill-paths`— Définit les répertoires dans lesquels les données déversées sont stockées, `spill-paths=/mnt/spill`
# Collecter et utiliser les statistiques des tables
La collecte des statistiques des tables permet à l'optimiseur basé sur les coûts de Trino de prendre des décisions éclairées concernant les ordres de jointure, le filtrage et l'élagage des partitions, ce qui se traduit par de meilleures performances.
Vous pouvez utiliser la `ANALYZE` commande pour collecter des statistiques pour les tables Hive ou Iceberg :
```
ANALYZE sales;
```
La collecte de statistiques sur de larges tableaux peut être une lourde charge pour les ressources. Nous vous recommandons de spécifier un sous-ensemble de colonnes utilisées dans les jointures, les filtres ou les opérations de regroupement.
Il s'agit d'une autre commande utile. Il affiche les statistiques actuelles d'un tableau afin de vérifier si les statistiques sont à jour.
```
show stats for table_name;
```
# Défis courants liés au dimensionnement des charges de travail de Trino
Les principaux avantages de l'utilisation d'Amazon S3 avec Trino sont sa capacité à s'adapter à de grands volumes de données et sa rentabilité. Mais lorsque vous interrogez de gros volumes de données, une série de problèmes de performances connexes peuvent parfois survenir. Cela peut être dû à la manière dont les données sont stockées, à des paramètres de configuration qui limitent les bonnes performances ou à d'autres raisons. Lorsque ces problèmes surviennent, vous pouvez prendre des mesures efficaces pour les éviter ou les atténuer.
Cette section commence par une liste d'optimisations générales que vous pouvez mettre en œuvre pour améliorer les performances des requêtes sur de grands volumes de données. Ensuite, les problèmes courants sont détaillés et des mesures d'atténuation sont proposées pour chacun d'entre eux.
Ce sujet est tiré de la présentation de conférence suivante : [Accélérer les performances à grande échelle : meilleures pratiques pour Trino avec Amazon S3](https://www.youtube.com/watch?v=cjUUcHlUKxQ).
## Optimisation de la mise en page des données pour les grands ensembles de données
Les problèmes de performances ne sont pas rares lorsque vous interrogez de grands ensembles de données. Mais il existe des bonnes pratiques que vous pouvez mettre en œuvre pour avoir une longueur d'avance lorsque vous utilisez Trino pour interroger des données dans Amazon S3. Cela inclut les éléments suivants :
+ **Partitionnement** — Le partitionnement consiste à organiser les données dans une hiérarchie et à stocker les données associées ensemble, en fonction d'attributs connexes. Le partitionnement permet aux requêtes de ne pas avoir à analyser autant de données non pertinentes et d'améliorer les performances des requêtes. Vous pouvez utiliser différentes stratégies de partitionnement, telles que l'organisation des données sources à l'aide de préfixes, notamment par plages de dates, régions ou autres attributs. Pour plus d'informations sur le partitionnement des données dans Amazon S3 afin d'améliorer les performances, consultez le [billet de blog Get started managing partitions for Amazon S3 tables backed by the AWS Glue Data Catalog](https://aws.amazon.com/blogs/big-data/get-started-managing-partitions-for-amazon-s3-tables-backed-by-the-aws-glue-data-catalog/) ou le billet [Top 10 des conseils d'optimisation des performances pour Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/).
+ **Compartitionnement** — Le découpage regroupe des données connexes dans des fichiers communs. Par exemple, si vous interrogez des données en fonction d'une région géographique, comme un état, vous pouvez améliorer les performances des requêtes en regroupant toutes les données relatives à un état donné dans le même fichier ou groupe de fichiers. Pour que cela fonctionne au mieux, basez votre bucket sur un attribut de données à forte cardinalité, tel qu'un État ou une province, par exemple. Vous pouvez également prendre en compte vos modèles de requêtes. Par exemple, il peut s'agir de regrouper les données de la Californie et de l'Oregon, si vos requêtes lisent généralement les données de ces États ensemble.
+ **Gestion des préfixes S3** — Vous pouvez utiliser les préfixes Amazon S3 pour implémenter une stratégie de partitionnement. Si vous n'utilisez qu'un seul préfixe pour un compartiment Amazon S3, comme une date précise, par exemple, cela peut entraîner un nombre élevé de demandes et une erreur HTTP 503. Nous vous recommandons d'utiliser des préfixes pour ajouter des conditions supplémentaires et organiser vos données sources de manière plus efficace. Pour plus d'informations, consultez la section [Organisation des objets à l'aide de préfixes](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-prefixes.html) dans la documentation Amazon S3. Le bref exemple suivant montre un préfixe qui améliore le débit des demandes :. `s3://bucket/country=US/dt=2024-06-13` Dans cet exemple, le pays et la date sont inclus dans le préfixe, ce qui entraîne moins de lectures que dans le cas où le préfixe inclut uniquement la date.
La réduction des erreurs HTTP 503 est abordée plus en détail dans la section sur le *ralentissement du protocole HTTP* qui suit dans cette rubrique.
+ **Optimisation de la taille des données** : vous pouvez exécuter la commande OPTIMIZE pour définir une configuration favorable aux requêtes les plus performantes. Pour l'exécuter sur des tables externes Hive, procédez comme suit :
+ À utiliser `OPTIMIZE` avec le paramètre suivant :`hive.non-managed-table-writes-enabled=true`. Pour plus d'informations sur cette propriété, consultez la section [Propriétés de configuration générales de Hive](https://trino.io/docs/current/connector/hive.html#hive-general-configuration-properties).
+ Définissez le paramètre de session suivant : `SET SESSION` `catalog.non_transactional_optimize_enabled=true`
+ Exécutez la `OPTIMIZE` commande :`ALTER TABLE catalog.schema.table EXECUTE optimize(file_size_threshold => '128MB')`. Dans ce cas, `file_size_threshold` c'est 100 Mo par défaut. L'augmentation de ce seuil, comme indiqué dans l'exemple, entraînera la fusion des fichiers inférieurs à 128 Mo.
+ **Configurer les tentatives** — Vous pouvez augmenter la limite de tentatives, ce qui peut atténuer le risque d'erreurs HTTP 503, en définissant les paramètres suivants :. `s3.max-error-retries` Cela s'applique lorsque vous utilisez l' TrinoFileSystem API et la version Trino 449 ou ultérieure. D'autre part, dans le cas où vous utilisez Amazon EMR avec Trino, vous utilisez EMRFS pour accéder à Amazon S3. Avec EMRFS, vous pouvez augmenter le nombre de départs en retraite en modifiant le paramètre. `fs.s3.maxRetries`
+ **Choisissez une classe de stockage Amazon S3** : le choix de la classe de stockage appropriée pour les données à différents stades de leur cycle de vie peut améliorer les performances et les coûts, en fonction de vos besoins en matière de collecte de données spécifiques. Pour plus d'informations, consultez [Comprendre et gérer les classes de stockage Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.htm) dans la documentation Amazon S3.
+ **Migrer vers Iceberg** — Une autre solution pour atténuer les problèmes de performances, notamment en ce qui concerne l'exécution de requêtes sur de petits fichiers, consiste à migrer vers les tables Iceberg. Iceberg possède des fonctionnalités qui gèrent bien les petits fichiers.
+ **Utiliser le compactage automatique des données** : si vous utilisez des tables Iceberg, le compactage automatique des données avec le catalogue de données AWS Glue peut optimiser la taille des données et améliorer les performances des requêtes.
## Défis courants lorsque vous interrogez de grands ensembles de données
Cette section répertorie un ensemble de problèmes courants qui peuvent survenir lorsque vous accumulez un ensemble de données volumineux dans Amazon S3 et que vous l'interrogez avec Trino. Chaque section indique les moyens de résoudre le problème ou de réduire son impact sur les requêtes. Chacun des problèmes décrits dans les sections suivantes a été reproduit et testé à l'aide d'un connecteur Hive.
### Analyses de données volumineuses
Lorsque votre requête doit analyser de grands ensembles de données, cela peut entraîner des problèmes tels que des performances de requête lentes et des coûts de stockage plus élevés. D'importants volumes de données peuvent résulter d'une croissance rapide des données ou d'une planification qui n'entraîne pas le déplacement des données existantes dans un délai approprié. Cela peut entraîner des requêtes plus lentes.
Pour limiter les pertes de performances liées à l'analyse de grands ensembles de données, nous vous recommandons d'utiliser le partitionnement et le partitionnement :
+ Le partitionnement regroupe les données associées en fonction de leurs attributs. L'utilisation efficace du partitionnement peut améliorer considérablement les performances des requêtes.
+ Le découpage consiste à regrouper des données dans des fichiers ou des compartiments en fonction de colonnes de données spécifiques et connexes. Le cloisonnement consiste généralement à conserver physiquement ensemble les fichiers de données sources connexes.
Pour illustrer comment l'atténuation peut fonctionner pour les analyses de données volumineuses, supposons que vous stockez et interrogez des données contenant des enregistrements dotés d'un attribut d'état, qui peut être attribué à la Californie ou à l'Alaska, et que cet attribut d'état est l'une des conditions de votre requête. Vous pouvez améliorer les performances des requêtes en stockant les données pour chaque état dans un compartiment S3 distinct ou en partitionnant vos données en fonction de l'état à l'aide d'un préfixe S3. Ce partitionnement et ce découpage peuvent également améliorer les performances si vous les basez sur une colonne supplémentaire, comme un attribut de date, par exemple.
**Note**
Si une colonne présente une cardinalité élevée et que vous souhaitez l'utiliser pour regrouper des données, nous vous recommandons d'utiliser le découpage dans ce cas. D'un autre côté, les clés de partition devraient généralement avoir une cardinalité inférieure.
**Utilisation de différents types de stockage S3**
En général, vous choisissez les types de stockage en fonction des performances, de l'accès aux données, de la résilience et des exigences de coût pour vos charges de travail. Il peut y avoir des compromis entre le coût et les performances. Il est important de choisir la classe de stockage Amazon S3 appropriée qui correspond à vos modèles d'accès aux données. Il existe deux principaux modèles d'accès :
+ Données accessibles de manière connue ou prévisible. En général, si vos données sont rarement consultées, S3 Standard IA peut être un bon choix, car il permet de réduire les coûts. Si vous avez fréquemment accédé à des données, S3 Standard est idéal pour l'accès avec Amazon EMR et Trino.
+ Données accessibles de manière inconnue ou imprévisible. Cela peut nécessiter l'utilisation d'autres classes de stockage Amazon S3. Il existe des compromis entre les classes de stockage S3. Il s'agit notamment de la latence, du coût du stockage et de la disponibilité. Vous pouvez choisir un type de stockage S3 approprié, en fonction de vos charges de travail et de vos modèles d'accès. Pour une description des avantages de chaque classe, consultez [Classes de stockage Amazon S3]().
**Utilisation du compactage**
Vous pouvez également utiliser le compactage automatique d'Iceberg, si vous utilisez des tables Iceberg, ce qui permet d'optimiser la taille des fichiers, afin d'améliorer l'efficacité des requêtes. Pour plus d'informations, consultez [AWS Glue Data Catalog qui prend désormais en charge le compactage automatique des tables Apache Iceberg](https://aws.amazon.com/blogs/aws/aws-glue-data-catalog-now-supports-automatic-compaction-of-apache-iceberg-tables/).
### Erreurs de ralentissement du protocole HTTP
Cela se produit lorsque le taux de demandes dépasse un seuil préconfiguré sur un préfixe Amazon S3. L'erreur HTTP qui se produit le plus souvent lorsque cet état est atteint est la suivante : **Erreur 503 : veuillez réduire votre taux de requêtes**. La source de ce problème peut être liée à la présence d'un grand nombre de petits fichiers, en raison du nombre de *divisions* qui doivent être créées pour pouvoir lire les données. Il existe deux moyens d'atténuer le problème :
+ Augmentez la limite de nouvelles tentatives pour les requêtes Amazon S3 dans Trino. Ceci est défini pour l'utilisation d'EMRFS `fs.s3.maxretries` dans Trino 449.
+ Optimisez la taille des fichiers, ce qui peut également entraîner une baisse du taux de demandes.
Pour plus d'informations sur la façon dont Trino détermine le nombre de divisions dans un ensemble de données à interroger, consultez la section [Propriétés de configuration du réglage des performances](https://trino.io/docs/current/connector/hive.html#performance-tuning-configuration-properties) dans la documentation du connecteur Hive.
### Difficulté à interroger de petits fichiers
L'interrogation de nombreux petits fichiers peut entraîner une I/O surcharge importante, en raison du nombre élevé de requêtes GET et LIST, et par conséquent affecter négativement les performances des requêtes. L'optimisation de la taille des fichiers peut améliorer les performances des requêtes. Pour ce faire, vous pouvez procéder de différentes manières :
+ Consolidez les données dans des fichiers moins volumineux. (En général, nous recommandons de limiter la taille des fichiers à environ 128 Mo.) Vous pouvez le faire à l'aide d'outils lorsque vous ingérez des données, par exemple dans un pipeline ETL, ou vous pouvez consolider les données manuellement. Si vous ne disposez pas de ces solutions, les autres options vous conviennent peut-être mieux.
+ Exécutez la commande `OPTIMIZE`.
+ Définissez le paramètre `SESSION`.
Notez qu'Iceberg dispose d'une fonctionnalité permettant de fusionner de petits fichiers en fichiers plus volumineux, à savoir le compactage automatique. Il fonctionne avec les fichiers gérés avec le AWS Glue Data Catalog. Pour plus d'informations, consultez [AWS Glue Data Catalog qui prend désormais en charge le compactage automatique des tables Apache Iceberg](https://aws.amazon.com/blogs/aws/aws-glue-data-catalog-now-supports-automatic-compaction-of-apache-iceberg-tables/).
### Requêtes contenant des données inutiles
Comme les données augmentent régulièrement, il est impératif de suivre vos habitudes d'accès aux données et de déplacer les données de manière appropriée au fur et à mesure qu'elles vieillissent ou deviennent inutiles. En effet, à mesure que les données augmentent, les performances des requêtes peuvent se dégrader au fil du temps, principalement en raison du volume considérable de données à analyser lors de l'exécution d'une requête. Amazon S3 et d'autres services proposent des conseils pour la migration du cycle de vie des données, qui présentent des stratégies pour déplacer les données vers différents sites de stockage lorsqu'il fait froid. Cela présente également un avantage en termes de coûts de stockage.
Outre la migration des données, vous pouvez utiliser d'autres stratégies, telles que la suppression des données sources qui ne sont pas pertinentes pour les requêtes que vous exécutez. Cela peut demander du travail, car cela peut impliquer de modifier votre schéma de données sources. Mais son résultat positif est de réduire le volume de données et d'accélérer les requêtes. Pour plus d'informations, consultez la section [Gestion du cycle de vie des objets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html).
# Considérations relatives à Trino
Tenez compte des points suivants lorsque vous exécutez Trino sur Amazon EMR.
## Propriétés de déploiement de Trino non configurables
Le tableau suivant présente les différentes options de configuration pour les `properties` fichiers Trino.
| Fichier | Configurable |
| --- | --- |
| `log.properties` | Trino : configurable dans les versions 6.1.0 et ultérieures d'Amazon EMR. Utilisez la classification de configuration `prestosql-log` ou `trino-log`. |
| `config.properties` | Trino : configurable dans les versions 6.1.0 et ultérieures d'Amazon EMR. Utilisez la classification de configuration `prestosql-config` ou `trino-config`. |
| `hive.properties` | Trino : configurable dans les versions 6.1.0 et ultérieures d'Amazon EMR. Utilisez la classification de configuration `prestosql-connector-hive` ou `trino-connector-hive`. |
| `node.properties` | Trino : configurable dans les versions 6.1.0 et ultérieures d'Amazon EMR. Utilisez la classification de configuration `prestosql-node` ou `trino-node`. |
| `jvm.config` | Non configurable. |
## Considérations supplémentaires
+ Pour Trino on EMR version 6.1.0 et versions ultérieures, Amazon EMR configure automatiquement une clé secrète partagée pour une communication interne sécurisée entre les nœuds du cluster. Vous n'avez pas besoin d'effectuer de configuration supplémentaire pour activer cette fonctionnalité de sécurité, et vous pouvez remplacer la configuration par votre propre clé secrète. Pour plus d'informations sur l'authentification interne de Trino, consultez la [documentation Trino 353 : Communication interne sécurisée](https://trino.io/docs/current/security/internal-communication.html).
# Historique des sorties de Trino
Les sections des notes de publication détaillent les modifications et les mises à jour pour une version spécifique de Trino sur Amazon EMR.
## Notes de mise à jour de Trino par version
+ [Amazon EMR 7.6.0 - Notes de mise à jour de Trino](Trino-release-history-760.md)
+ [Amazon EMR 7.3.0 - Notes de mise à jour de Trino](Trino-release-history-730.md)
+ [Amazon EMR 6.9.0 - Notes de mise à jour de Trino](Trino-release-history-690.md)
# Amazon EMR 7.6.0 - Notes de mise à jour de Trino
## Amazon EMR 7.6.0 - Nouvelles fonctionnalités de Trino
+ Pour prendre en charge les requêtes de longue durée, Trino inclut désormais un mécanisme d'exécution tolérant aux pannes. L'exécution tolérante aux pannes atténue les échecs des requêtes en réessayant les requêtes qui ont échoué ou les tâches correspondantes.
## Amazon EMR 7.6.0 - Modifications apportées à Trino
**Amazon EMR 7.6.0 - Modifications apportées à Trino**
| Type | Description |
| --- | --- |
| Upgrade | Mise à niveau de Trino vers 457 |
# Amazon EMR 7.3.0 - Notes de mise à jour de Trino
## Amazon EMR 7.3.0 - Modifications apportées à Trino
+ Cette version met à niveau Trino de la version 436 à la version 442.
+ Cette version redirige les requêtes Hudi vers le nouveau correcteur Hudi. L'ancien connecteur Hive ne peut plus lire les tables Hudi. Remarque
+ Cette version supprime le module Rubix d'Amazon EMR car il est désormais obsolète en tant que logiciel libre.
+ Cette version [supprime le mode ancien](https://github.com/trinodb/trino/pull/21013) dans la `hive.security` propriété. La valeur par défaut est maintenant`allow-all`.
# Amazon EMR 6.9.0 - Notes de mise à jour de Trino
## Amazon EMR 6.9.0 - Nouvelles fonctionnalités de Trino
+ Pour prendre en charge les requêtes de longue durée, Trino inclut désormais un mécanisme d'exécution tolérant aux pannes. L'exécution tolérante aux pannes atténue les échecs des requêtes en réessayant les requêtes qui ont échoué ou les tâches correspondantes.
## Amazon EMR 6.9.0 - Modifications apportées à Trino
**Amazon EMR 6.9.0 - Modifications apportées à Trino**
| Type | Description |
| --- | --- |
| Upgrade | Mise à niveau de Trino vers la version 398 |
| Upgrade | Prise en charge pour Hadoop 3.3.3. |
| Fonctionnalité | Support tardigrade : ajout de la prise en charge du spoulage des échanges sur HDFS et Amazon S3. |
| Correctif de bogue | Lorsque Trino Iceberg est utilisé et que le catalogue Glue est activé, évitez d'ajouter un URI de métastore dans `iceberg.properties.` |
## Amazon EMR 6.9.0 - Problèmes connus liés à Trino
+ Pour Amazon EMR version 6.9.0, Trino ne fonctionne pas sur les clusters activés pour Apache Ranger. Si vous devez utiliser Trino avec Ranger, contactez [Support](https://console.aws.amazon.com/support/home#/).