Utilisation d'Apache Trino
Apache Trino permet d'exécuter des requêtes ETL et ad hoc sur plusieurs systèmes de fichiers Big Data. Par défaut, des connecteurs system, tpch et hive sont installés sur le premier noeud maître du cluster.
Pour exécuter l'opération CRUD dans le metastore Hive, vous devez ajouter la stratégie HDFS avec le chemin de ressource /tmp,/warehouse et le droit d'accès R/W/E pour l'utilisateur Trino.
Réglage des performances
Trino est un moteur de requête SQL distribué conçu pour gérer d'importants volumes de données dans de nombreuses sources de données, y compris le stockage d'objets dans des environnements cloud. Cependant, les performances de Trino peuvent être affectées par divers facteurs, tels que la taille et la complexité des données, la bande passante réseau disponible, la configuration du cluster et les modèles de requête. Par conséquent, il est important d'effectuer un réglage des performances afin d'optimiser les performances et l'évolutivité de Trino pour des cas d'utilisation spécifiques aux clients.
fs.oci.io.read.ahead.blocksize = 6291456: ce paramètre définit la taille de bloc (en octets) utilisée pour la mise en mémoire tampon en lecture anticipée dans les lectures de stockage d'objet. Par défaut, la taille de bloc est définie sur 262144 (256 Ko), mais la définir sur une valeur supérieure telle que 6291456 (6 Mo) peut aider à améliorer les performances de lecture pour les fichiers volumineux, en particulier pour les lectures séquentielles.fs.oci.io.read.ahead = true: ce paramètre contrôle le mécanisme de mise en mémoire tampon en lecture anticipée pour les lectures de stockage d'objets dans Trino. Lorsque la mise en mémoire tampon en lecture anticipée est activée, Trino lit de manière proactive des données supplémentaires au-delà de la demande de lecture actuelle, en prévision des demandes de lecture futures. Cela peut aider à réduire l'impact de la latence du réseau et à améliorer les performances des charges de travail lourdes en lecture.fs.oci.caching.object.parquet = true: ce paramètre active la mise en mémoire cache des objets Parquet dans le système de fichiers local afin d'améliorer les performances des requêtes lors de l'utilisation des fichiers Parquet. Lorsque la valeur est True, le client de stockage OCI met en mémoire cache les objets Parquet dans le système de fichiers local pour les lectures ultérieures.fs.oci.caching.filesystem.enabled=true: ce paramètre active la mise en cache des données à partir du stockage d'objet OCI dans le cache HDFS. Cela peut améliorer les performances en réduisant la quantité de données à extraire du stockage d'objets et en mettant en cache les données fréquemment consultées.
Définissez les configurations suivantes dans l'interface utilisateur Ambari.
- Accédez à Apache Ambari.
- Dans la barre d'outils latérale, sous Services, sélectionnez Trino.
- Sélectionnez Configurations, puis mettez à jour/ajoutez les propriétés de configuration.
| Paramètre | Description | Où s]Définir | Valeur recommandée |
|---|---|---|---|
Heap (-Xmx) |
Ce paramètre indique la quantité maximale de portion de mémoire que le processus Trino peut utiliser. Nous vous recommandons de définir ce paramètre sur 80 % de la mémoire physique disponible sur l'ordinateur. | jvm.config |
Nous vous recommandons de définir ce paramètre sur 75 à 80 % de la mémoire physique disponible sur la machine. Remarque : Si d'autres processus sont en cours d'exécution sur le même noeud que le processus actif Trino, conservez une certaine quantité de mémoire physique pour ces processus. Dans ce cas, définissez la valeur du paramètre Par exemple, si d'autres processus sur le même noeud nécessitent 4 Go de mémoire et que la mémoire physique totale disponible sur le noeud est de 16 Go, définissez le paramètre |
query.max-memory-per-node |
Mémoire d'un noeud de processus actif unique. | config.properties |
Définissez ce paramètre sur une valeur inférieure ou égale à la différence entre la mémoire JVM et la valeur de Mémoire effective = portion de mémoire JVM totale - Salle d'en-tête de la portion de mémoire Par exemple, s'il existe un scénario d'utilisateur simultané, définissez le paramètre sur Mémoire effective / Requêtes simultanées. |
query.max-memory |
Mémoire de tous les noeuds d'un cluster. | config.properties |
Définissez ce paramètre sur une valeur calculée en fonction de la formule suivante : valeur de query.max-memory-per-node × nombre de noeuds de processus actif. |
query.max-total-memory |
Quantité totale de mémoire consommée par un cluster, qui ne doit pas être inférieure à la valeur de query.max-memory. |
config.properties |
Si la simultanéité n'est pas élevée, définissez ce paramètre sur la même valeur que le paramètre query.max-memory. Si la simultanéité est élevée, la valeur du paramètre query.max-total-memory ne peut pas dépasser la capacité de mémoire maximale du cluster, qui est égale à 70 % de la mémoire JVM multipliée par le nombre de noeuds de processus actif. Réduisez proportionnellement les valeurs de query.max-memory et query.max-memory-per-node en fonction de vos exigences. Vous pouvez réduire la valeur de query.max-memory à la moitié de query.max-total-memory. Dans ce cas, vous devez définir le paramètre query.max-memory-per-node sur la valeur query.max-memory divisée par le nombre de noeuds de processus actif. |
memory.heap-headroom-per-node |
Portion de mémoire JVM réservée. | config.properties |
La mémoire effective doit être égale à 15 % de la mémoire de la JVM |
task.concurrency
|
Accès simultané local par défaut pour les opérateurs parallèles, tels que les jointures et les agrégations. Ajustez cette valeur à la hausse ou à la baisse en fonction de la simultanéité d'accès aux requêtes et de l'utilisation des ressources du salarié. Les valeurs inférieures sont meilleures pour les clusters qui exécutent de nombreuses requêtes simultanément, car le cluster est déjà utilisé par toutes les requêtes en cours d'exécution. Par conséquent, l'ajout de simultanéité d'accès aux données entraîne des ralentissements en raison du changement de contexte et d'autres surcharges. Les valeurs supérieures sont préférables pour les clusters qui n'exécutent qu'une ou plusieurs requêtes à la fois. | config.properties |
80 % de la CPU disponible dans un noeud/une machine virtuelle |