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.
Difficultés courantes liées à la mise à l'échelle des charges de travail Trino
Les principaux avantages de l'utilisation d'Amazon S3 avec Trino sont la capacité de S3 à s'adapter à de grands volumes de données et la rentabilité de S3. Mais lorsque vous interrogez de grands 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 fournies pour chacun d'entre eux.
Ce sujet est tiré de la présentation de la conférence suivante : Accélérer les performances à grande échelle : meilleures pratiques pour Trino avec Amazon S3
Optimisation de la mise en page des données pour les grands ensembles de données
Les goulots d'étranglement liés aux performances ne sont pas rares lorsque vous interrogez de grands ensembles de données. Il existe toutefois des bonnes pratiques que vous pouvez mettre en œuvre pour prendre 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 selon une hiérarchie et à stocker les données associées ensemble, en fonction d'attributs connexes. Grâce au partitionnement, les requêtes n'ont pas à analyser autant de données non pertinentes, ce qui améliore les performances des requêtes. Vous pouvez utiliser différentes stratégies de partitionnement, telles que l'organisation des données source à l'aide de préfixes, en particulier 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 l'article de blog Commencer à gérer les partitions pour les tables Amazon S3 soutenues par le catalogue de données AWS Glue
ou l'article Les 10 meilleurs conseils d'optimisation des performances pour Amazon Athena . Compartiment — Le compartimentage consiste à regrouper les 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 d'un état particulier dans le même fichier ou groupe de fichiers. Pour que cela fonctionne au mieux, basez votre segmentation sur un attribut de données présentant une cardinalité élevée, comme 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 mettre en œuvre une stratégie de partitionnement. Si vous n'utilisez qu'un seul préfixe pour un compartiment Amazon S3, comme une date particulière, par exemple, cela peut entraîner un nombre élevé de demandes et entraîner 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 dans la documentation Amazon S3. Le bref exemple suivant montre un préfixe qui améliore le débit des requêtes :
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 qu'un cas où le préfixe inclut uniquement la date.L'atténuation des erreurs HTTP 503 est abordée plus en détail dans la section sur le ralentissement 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 qui favorise de meilleures performances des requêtes. Pour l'exécuter sur des tables externes Hive, procédez comme suit :
À utiliser
OPTIMIZEavec 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érale de Hive. Définissez le paramètre de session suivant :
SET SESSIONcatalog.non_transactional_optimize_enabled=trueExécutez la
OPTIMIZEcommande :ALTER TABLE. Dans ce cas,catalog.schema.tableEXECUTE optimize(file_size_threshold => '128MB')file_size_thresholdil est de 100 Mo par défaut. L'augmentation de ce seuil, comme indiqué dans l'exemple, entraînera la fusion de fichiers inférieurs à 128 Mo.
Configurer les nouvelles tentatives — Vous pouvez augmenter la limite de nouvelles tentatives, ce qui peut réduire les risques d'erreurs HTTP 503, en définissant les paramètres suivants :.
s3.max-error-retriesCela s'applique lorsque vous utilisez l' TrinoFileSystem API et Trino 449 version ou ultérieure. En revanche, si 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.maxRetriesChoisissez une classe de stockage Amazon S3 : le choix de la classe de stockage appropriée pour les données à différents moments de leur cycle de vie peut améliorer à la fois les performances et les coûts, en fonction de vos besoins en matière de collectes de données spécifiques. Pour plus d'informations, consultez Comprendre et gérer les classes de stockage Amazon S3 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.
Difficultés courantes lorsque vous interrogez de grands ensembles de données
Cette section répertorie les problèmes courants qui peuvent survenir lorsque vous accumulez un ensemble de données volumineux dans Amazon S3 et que vous l'interrogez auprès de Trino. Chaque section vous montre comment résoudre le problème ou 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 transfert des données existantes dans les délais appropriés. 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 bucket :
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 regroupement consiste à regrouper les données dans des fichiers ou des compartiments en fonction de colonnes de données spécifiques et connexes. Le cloisonnement signifie généralement la conservation physique des fichiers de données sources connexes ensemble.
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 de vos conditions de 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 compartimentage 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 a une cardinalité élevée et que vous souhaitez l'utiliser pour regrouper des données, nous vous recommandons d'utiliser le bucket dans ce cas. D'autre part, en général, les clés de partition doivent avoir une cardinalité inférieure.
Utilisation de différents types de stockage S3
En règle générale, vous choisissez les types de stockage en fonction des exigences en matière de performances, d'accès aux données, de résilience et de coûts pour vos charges de travail. Il peut y avoir des compromis entre les coûts 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 règle générale, 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 la solution idéale pour y accéder avec Amazon EMR et Trino.
Données auxquelles l'accès est effectué 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 le 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.
Utiliser le compactage
Vous pouvez également utiliser le compactage automatique 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, voir AWS Glue Data Catalog prend désormais en charge le compactage automatique des tables Apache Iceberg.
Erreurs de ralentissement 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 enracinée en présence d'un grand nombre de petits fichiers, en raison du nombre de divisions qui doivent être créées pour 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 EMRFS à l'aide de Trino
fs.s3.maxretries449.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
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 plusieurs manières :
Consolidez les données dans un nombre réduit de fichiers volumineux. (En règle générale, nous recommandons de maintenir 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 ces solutions ne vous sont pas proposées, les autres options sont peut-être mieux adaptées à vos besoins.
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 catalogue de données AWS Glue. Pour plus d'informations, voir AWS Glue Data Catalog prend désormais en charge le compactage automatique des tables Apache Iceberg.
Requêtes contenant des données inutiles
Il est courant que les données augmentent. Il est donc impératif de suivre vos habitudes d'accès aux données et de déplacer les données de manière appropriée à 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 emplacements 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 source. 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.
