Questions fréquemment posées sur l'utilisation de Trino sur EMR.
Ordre incorrect des colonnes pour les requêtes Hudi et Delta Lake
Échec du redémarrage de Trino après des modifications de configuration
Trino par rapport à Presto
Trino, anciennement connu sous le nom de PrestoSQL, est un projet open source développé par Starburst, une société fondée par les créateurs originaux de Presto après leur départ de Facebook. Le projet a été officiellement renommé Trino en 2021. Facebook continue de maintenir sa propre version dérivée, appelée PrestoDB. Bien que les deux projets aient divergé, ils partagent une syntaxe et une utilisation similaires.
Dans les versions EMR 3.44.0 et EMR 5.10.0 et ultérieures, le service porte officiellement le nom de Trino. Dans les versions antérieures, la console affiche Presto, mais le moteur sous-jacent est bien Trino.
Versions de Trino
Pour connaître les modifications apportées à chaque version de Trino, consultez les notes de version de Trino officielles. Les versions plus récentes incluent des optimisations de performances ; nous vous recommandons donc de sélectionner la dernière version disponible.
Déploiement et haute disponibilité de Trino
Trino utilise une architecture standard coordonnateur-travailleur. Le coordonnateur est déployé sur le nœud master-1-1, tandis que les travailleurs sont déployés sur tous les nœuds Core ou Task.
Trino ne prend pas actuellement en charge la haute disponibilité. Sur un cluster à haute disponibilité, le coordonnateur Trino est déployé uniquement sur le nœud master-1-1. Si vous n'avez pas besoin de déployer conjointement des composants Hadoop, sélectionnez uniquement le service Trino lors de la création du cluster.
Si vous n'avez pas besoin de déployer Hadoop conjointement, n'activez pas la haute disponibilité afin d'éviter des coûts inutiles.
Trino, DLF et connecteurs personnalisés
Pour les clusters de lac de données dans les versions EMR antérieures à 3.45.0 et 5.11.0, si vous sélectionnez le service Hive et choisissez DLF Unified Metadata lors de la création du cluster, les connecteurs tels que Hive, Iceberg, Hudi et Delta Lake se connectent directement à Data Lake Formation (DLF). Si le cluster n'inclut pas le service Hive, reportez-vous à la rubrique Configuration d'un centre de stockage de métadonnées pour les données dans les lacs de données afin de configurer manuellement la connexion. Pour les clusters de lac de données dans les versions EMR 3.45.0 et ultérieures ainsi que 5.11.0 et ultérieures, vous pouvez sélectionner DLF Unified Metadata lors de la création d'un cluster Trino.
Une fois DLF activé, les connecteurs par défaut, tels que le connecteur Hive, ne peuvent plus accéder au metastore. Si vous devez configurer plusieurs instances Hive metastore ou MySQL, ou utiliser des services non disponibles dans les connecteurs par défaut, utilisez les cinq connecteurs d'espace réservé (connector1 à connector5) fournis par EMR Trino. Définissez la propriété connector.name pour l'un de ces espaces réservés comme étant hive ou tout autre type de connecteur requis. Ajoutez ensuite les autres propriétés de configuration en fonction de la documentation du connecteur spécifique, en indiquant l'adresse du service cible.
Accès de Trino à OSS et OSS-HDFS
EMR intègre JindoSDK par défaut avec un accès sans mot de passe. Vous pouvez accéder directement à OSS ou interroger des tables Hive stockées dans OSS.
EMR Trino prend en charge OSS-HDFS.
Accès à l'interface web de Trino
Si votre cluster dispose de Knox installé, utilisez l'URL Knox pour accéder à l'interface web de Trino. Pour plus d'informations, reportez-vous à la rubrique Knox.
Si votre cluster n'inclut pas Knox, accédez à l'interface via une URL publique : {adresse IP publique:port HTTP}. Le port HTTP est indiqué dans la configuration http-server.http.port, dont la valeur par défaut est 9090. Si vous ne parvenez pas à accéder à l'interface, assurez-vous que le port 9090 est ouvert dans votre groupe de sécurité.
Si votre cluster s'exécute en mode de sécurité élevée, le port HTTP par défaut n'est pas disponible. Si vous disposez des autorisations réseau nécessaires, accédez à l'interface web en ajoutant la configuration suivante au fichier config.properties du groupe de nœuds maître. Accédez ensuite à l'interface en utilisant la méthode standard.
web-ui.authentication.type=fixed
web-ui.user=trinoL'interface web de Trino affiche les requêtes récemment exécutées, y compris les instructions SQL et les plans d'exécution. Par défaut, Trino conserve jusqu'à 100 requêtes récentes. Les requêtes terminées sont rapidement remplacées par de nouvelles entrées, tandis que les requêtes ayant échoué sont conservées plus longtemps. Ajustez la configuration query.max-history (par défaut : 100) pour augmenter le nombre de requêtes stockées.
Ajout de Trino à un cluster existant
Pour un cluster de lac de données, ajoutez directement le service Trino si le cluster dispose de ressources suffisantes.
-
Pour un cluster Hadoop, vérifiez si des services ont été mis à niveau manuellement. Le cas échéant, Trino risque de ne pas démarrer après l'installation. Suivez alors les étapes suivantes :
Si JindoSDK a fait l'objet d'une mise à niveau distincte, notamment après une mise à jour majeure de version, réexécutez le script de mise à niveau Presto ou Trino pertinent et copiez manuellement la version mise à niveau de JindoSDK dans le répertoire du connecteur correspondant du chemin d'installation de Trino.
Pour EMR-3.39.1, examinez le journal du service. Il signale généralement qu'une classe liée à Delta est introuvable. Dans ce cas, sur chaque nœud, copiez manuellement le fichier
/opt/apps/ecm/service/deltalake/0.6.1-3.3/package/deltalake-0.6.1-3.3/presto-delta/delta-standalone-assembly-0.2.0.jarvers le chemin/usr/lib/presto-current/plugin/delta.
Modifications de configuration non prises en compte
Les fichiers de configuration de Trino se trouvent dans /etc/emr/trino-conf. Vérifiez si les fichiers de configuration sur les nœuds reflètent correctement les modifications effectuées dans la console et contiennent vos ajouts ou modifications précédents :
-
Si le fichier de configuration ne contient pas le nouveau contenu ou le contenu modifié : assurez-vous d'avoir enregistré la configuration, déployé les modifications et défini correctement la portée de la modification.
ImportantSi vous modifiez une propriété de configuration pour un groupe de nœuds spécifique ou un seul nœud, la configuration par défaut du cluster pour cette propriété ne s'applique plus.
Si le fichier de configuration contient le nouveau contenu ou le contenu modifié : assurez-vous que tous les nœuds Trino ont été redémarrés. Trino applique la nouvelle configuration uniquement après un redémarrage.
Requêtes bloquées ou défaillances des nœuds de travail
Si vous voyez un message d'erreur tel que Could not communicate with the remote task. The node may have crashed or be under too much load. This is probably a transient issue, so please retry your query in a few minutes. ou No handle resolver for connector: hive ... Unrecognized token 'io': was expecting (JSON String, Number, Array, Object or token 'null', 'true' or 'false'), cela indique qu'un nœud de travail est surchargé ou a redémarré automatiquement. Le système a peut-être arrêté un processus sur le nœud de travail. Ajustez la configuration en fonction de la charge de travail, en particulier les paramètres liés à la mémoire, ou limitez le nombre de requêtes simultanées.
Consultation des journaux Trino
Les fichiers journaux de Trino sont stockés par défaut dans /mnt/disk1/log/trino/var/log/. La sortie et les traces de pile des exceptions se trouvent dans le fichier server.log.
Pour afficher les détails des erreurs pour une requête spécifique, ajoutez l'indicateur --debug lors du démarrage du client. Cela permet d'imprimer la trace de pile de l'exception.
Le coordonnateur et les travailleurs Trino communiquent via HTTP. Si une exception HTTP se produit sur le nœud coordonnateur, l'erreur peut provenir d'un nœud de travail. En l'absence d'autres informations d'erreur évidentes, vérifiez chaque nœud de travail individuellement.
Échecs de requête ou résultats vides
Résolvez le problème en suivant ces étapes :
Accédez aux données ou interrogez-les à l'aide d'autres moteurs, tels que Hive ou Spark. S'ils échouent également, vérifiez si la source de données est accessible et si les données sont intactes.
Si seul Trino ne parvient pas à accéder aux données ou à exécuter la requête, vérifiez si les métadonnées configurées sont correctes.
-
Si les métadonnées sont valides, mais qu'une requête sur une table contenant des données renvoie un résultat vide, vérifiez si vous disposez des autorisations d'accès aux données nécessaires.
Si l'utilisateur proxy est activé pour le HDFS où les données sont stockées, vous devez également activer la propriété hive.hdfs.impersonation.enabled dans Trino.
Si Ranger est activé, assurez-vous que les autorisations Ranger sont correctement configurées.
Si le cluster a été étendu, vérifiez si le nouveau groupe de nœuds ou le nouveau nœud dispose des autorisations nécessaires pour accéder aux fichiers correspondants.
Ordre incorrect des colonnes pour les requêtes Hudi et Delta Lake
Vérifiez si la propriété hive.parquet.use-columns-names est définie sur true dans le fichier hive.properties pour Trino.
Échec du redémarrage de Trino après des modifications de configuration
Si le fichier Server.log contient l'erreur Error: Configuration property 'xxxxx' was not used, cela signifie que la configuration se trouve au mauvais emplacement ou qu'une configuration préalable est manquante. Trino valide strictement ses propriétés de configuration. Si une propriété n'existe pas, est mal orthographiée ou placée dans le mauvais fichier, le service ne démarre pas. Vérifiez que la nouvelle configuration est correcte ou annulez la modification.
Erreur « Cannot query xxx table » avec le connecteur Hive
Trino propose des connecteurs dédiés pour Iceberg, Hudi et Delta Lake. Utilisez le connecteur dédié pour chaque format de table. Si vous devez utiliser le connecteur Hive, utilisez la fonctionnalité Table Redirection pour transférer la requête vers le connecteur dédié correspondant.
Par exemple, pour configurer le connecteur Hive afin de rediriger les requêtes vers les tables Iceberg, Delta Lake et Hudi, définissez les paramètres suivants :
hive.iceberg-catalog-name=iceberg
hive.delta-lake-catalog-name=delta-lake
hive.hudi-catalog-name=hudi