Utilisation d'Apache Trino

Apache Trino vous permet d'exécuter des interrogations ad hoc et ETL sur plusieurs systèmes de fichiers de mégadonnées. Par défaut, Trino est installé dans le premier noeud principal de la grappe et dispose des connecteurs system, tpch et hive installés.

Pour exécuter l'opération de CRUD dans le magasin de métadonnées Hive, vous devez ajouter la politique HDFS avec le chemin de ressource /tmp,/warehouse et l'autorisation R/W/E pour l'utilisateur Trino.

Réglage de la performance

Trino est un moteur d'interrogation SQL distribué conçu pour gérer de grands volumes de données dans de nombreuses sources de données, y compris le stockage d'objets dans des environnements en nuage. Cependant, la performance de Trino peut être affectée par divers facteurs, tels que la taille et la complexité des données, la bande passante de réseau disponible, la configuration du cluster et les modèles d'interrogation. 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 au client.

Recommandations lors de la lecture des jeux de données à partir du stockage d'objets
  • 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 du stockage d'objets. Par défaut, la taille du bloc est réglée à 262144 (256 Ko), mais le réglage à 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 du 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 courante, en prévision des demandes de lecture futures. Cela peut aider à réduire l'impact de la latence réseau et à améliorer les performances des charges de travail lues.
  • fs.oci.caching.object.parquet = true : Ce paramètre permet la mise en mémoire cache des objets Parquet dans le système de fichiers local pour améliorer la performance des interrogations lors de l'utilisation de fichiers Parquet. Lorsque cette option est réglée à Vrai, le client de stockage OCI met en mémoire cache les objets Parquet dans le système de fichiers local pour les lectures suivantes.
  • fs.oci.caching.filesystem.enabled=true : Ce paramètre permet la mise en mémoire cache des données à partir du stockage d'objets OCI dans la mémoire cache HDFS. Cela permet d'améliorer le rendement en réduisant la quantité de données à extraire du stockage d'objets et en mettant en mémoire cache les données fréquemment consultées.
Recommandations générales
Note

Définissez les configurations suivantes dans l'interface utilisateur d'Ambari.
  1. Apache Ambari Accédez.
  2. Dans la barre d'outils latérale, sous Services, sélectionnez Trino.
  3. Sélectionnez Configs, puis mettez à jour/ajoutez les propriétés des configurations.
Paramètre Description Où s]Set Valeur recommandée
Heap (-Xmx) Ce paramètre spécifie la quantité maximale de mémoire de tas que le travailleur Trino peut utiliser. Nous vous recommandons de régler ce paramètre à 80 % de la mémoire physique disponible sur la machine. jvm.config

Nous vous recommandons de régler ce paramètre à 75-80 % de la mémoire physique disponible sur la machine.

Note :

Si d'autres processus s'exécutent sur le même noeud que le travailleur Trino, conservez une certaine quantité de mémoire physique pour ces processus. Dans ce cas, réglez la valeur du paramètre -Xmx à une valeur inférieure à 80 % de la mémoire physique disponible. Nous vous recommandons de laisser au moins 10 à 20 % de la mémoire physique pour d'autres processus, en fonction de la quantité de mémoire dont ils ont besoin.

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, réglez le paramètre -Xmx à 75 à 80 % de 12 Go (par exemple, 7,2 ti 8,4 Go).

query.max-memory-per-node Mémoire d'un seul noeud de travail. config.properties

Réglez ce paramètre à une valeur inférieure ou égale à la différence entre la mémoire JVM et la valeur de memory.heap-headroom-per-node.

Mémoire effective = Tas total de la JVM - Tas

Par exemple, s'il existe un scénario d'utilisateur concurrent, définissez le paramètre en tant que mémoire en vigueur/interrogations concurrentes.

query.max-memory Mémoire de tous les noeuds d'un cluster. config.properties Réglez ce paramètre à une valeur calculée en fonction de la formule suivante : Valeur de query.max-memory-per-node × Nombre de noeuds de travail.
query.max-total-memory Quantité totale de mémoire consommée par une grappe, qui ne doit pas être inférieure à la valeur de query.max-memory. config.properties Si l'accès simultané n'est pas élevé, réglez ce paramètre à la même valeur que le paramètre query.max-memory. Si l'accès simultané est élevé, la valeur du paramètre query.max-total-memory ne peut pas dépasser la capacité de mémoire maximale de la grappe, qui est égale à 70 % de la mémoire JVM multipliée par le nombre de noeuds de travail. Réduisez proportionnellement les valeurs de query.max-memory et query.max-memory-per-node en fonction de vos besoins. Vous pouvez réduire la valeur de query.max-memory à la moitié de query.max-total-memory. Dans ce cas, vous devez régler le paramètre query.max-memory-per-node à la valeur query.max-memory divisée par le nombre de noeuds de travail.
memory.heap-headroom-per-node Mémoire de tas JVM réservée. config.properties La mémoire efficace doit être égale à 15 % de la mémoire 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 vers le haut ou vers le bas en fonction de la simultanéité d'interrogation et de l'utilisation des ressources du travailleur. Les valeurs inférieures sont meilleures pour les clusters qui exécutent de nombreuses interrogations simultanément, car le cluster est déjà utilisé par toutes les interrogations en cours d'exécution, de sorte que l'ajout d'accès simultané entraîne des ralentissements en raison de la commutation de contexte et d'autres surcharges. Les valeurs plus élevées conviennent mieux aux clusters qui n'exécutent qu'une ou quelques interrogations à la fois. config.properties 80 % de l'UC disponible dans un noeud ou une machine virtuelle