Apache Trino verwenden
Mit Apache Trino können Sie Ad-hoc- und ETL-Abfragen über mehrere Big-Data-Dateisysteme ausführen. In Trino ist standardmäßig der erste Masterknoten des Clusters installiert, und die Connectors system, tpch und hive sind installiert.
Um den CRUD-Vorgang im Hive-Metastore auszuführen, müssen Sie die HDFS-Policy mit dem Ressourcenpfad /tmp,/warehouse und der Berechtigung R/W/E für den Trino-Benutzer hinzufügen.
Performanceoptimierung
Trino ist eine verteilte SQL-Abfrage-Engine, die für die Verarbeitung großer Datenmengen in vielen Datenquellen entwickelt wurde, einschließlich Objektspeicher in Cloud-Umgebungen. Die Performance von Trino kann jedoch durch verschiedene Faktoren beeinflusst werden, wie Größe und Komplexität der Daten, die verfügbare Netzwerkbandbreite, die Clusterkonfiguration und die Abfragemuster. Daher ist es wichtig, eine Leistungsoptimierung durchzuführen, um die Performance und Skalierbarkeit von Trino für kundenspezifische Anwendungsfälle zu optimieren.
-
fs.oci.io.read.ahead.blocksize = 6291456: Dieser Parameter legt die Blockgröße (in Byte) fest, die für den Read-Ahead-Puffer in Objektspeicherlesevorgängen verwendet wird. Standardmäßig ist die Blockgröße auf 262144 (256 KB) gesetzt. Wenn Sie sie jedoch auf einen größeren Wert wie 6291456 (6 MB) setzen, kann dies die Leseperformance für große Dateien verbessern, insbesondere für sequenzielle Lesevorgänge. -
fs.oci.io.read.ahead = true: Dieser Parameter steuert den Read-Ahead-Puffermechanismus für Objektspeicherlesevorgänge im Trino. Wenn Read-Ahead-Pufferung aktiviert ist, liest Trino proaktiv zusätzliche Daten über die aktuelle Leseanforderung hinaus, in Erwartung zukünftiger Leseanforderungen. Dies kann dazu beitragen, die Auswirkungen der Netzwerklatenz zu reduzieren und die Performance von leseintensiven Workloads zu verbessern. -
fs.oci.caching.object.parquet = true: Dieser Parameter ermöglicht das Caching von Parquet-Objekten im lokalen Dateisystem, um die Abfrageperformance bei der Arbeit mit Parquet-Dateien zu verbessern. Bei 'Wahr' cacht der OCI-Speicherclient Parquet-Objekte im lokalen Dateisystem für nachfolgende Lesevorgänge. -
fs.oci.caching.filesystem.enabled=true: Dieser Parameter aktiviert das Caching von Daten aus dem OCI-Objektspeicher im HDFS-Cache. Dies kann die Performance verbessern, indem die Datenmenge reduziert wird, die aus dem Objektspeicher abgerufen werden muss, und Daten, auf die häufig zugegriffen wird, im Cache gespeichert werden.
Legen Sie die folgenden Konfigurationen in der Ambari-UI fest.
- Öffnen Sie Apache Ambari.
- Wählen Sie in der seitlichen Symbolleiste unter Services die Option Trino aus.
- Wählen Sie Konfigurationen, und aktualisieren/hinzufügen Sie die Konfigurationseigenschaften.
| Parameter | Beschreibung | Wo s]Einstellen | Empfohlener Wert |
|---|---|---|---|
Heap (-Xmx)
|
Dieser Parameter gibt den maximalen Heap-Speicher an, den der Trino-Worker verwenden kann. Es wird empfohlen, diesen Parameter auf 80% des physischen Speichers zu setzen, der auf dem Rechner verfügbar ist. |
jvm.config
|
Wir empfehlen, diesen Parameter auf 75-80% des auf dem Rechner verfügbaren physischen Speichers einzustellen. Hinweis: Wenn andere Prozesse auf demselben Knoten ausgeführt werden, auf dem der Trino-Worker ausgeführt wird, belassen Sie für diese Prozesse eine gewisse Menge an physischem Speicher. Setzen Sie in diesen Fällen den Wert des Parameters Beispiel: Wenn andere Prozesse auf demselben Knoten 4 GB Arbeitsspeicher benötigen und der gesamte auf dem Knoten verfügbare physische Arbeitsspeicher 16 GB beträgt, setzen Sie den Parameter |
query.max-memory-per-node
|
Der Speicher eines einzelnen Worker-Knotens. |
config.properties
|
Setzen Sie diesen Parameter auf einen Wert, der kleiner/gleich der Differenz zwischen dem JVM-Speicher und dem Wert von Effektiver Speicher = Gesamter JVM-Heap - Heap Headroom Beispiel: Wenn ein Szenario für einen gleichzeitigen Benutzer vorhanden ist, setzen Sie den Parameter auf "Gültiger Speicher/Hintergrundabfragen". |
query.max-memory
|
Der Speicher aller Knoten in einem Cluster. |
config.properties
|
Setzen Sie diesen Parameter auf einen Wert, der basierend auf der folgenden Formel berechnet wird: Wert von query.max-memory-per-node × Anzahl der Worker-Knoten. |
query.max-total-memory
|
Der gesamte von einem Cluster belegte Speicher, der nicht kleiner als der Wert von query.max-memory sein darf. |
config.properties
|
Wenn der Nebenläufigkeitswert nicht hoch ist, setzen Sie diesen Parameter auf denselben Wert wie den Parameter query.max-memory. Wenn der gleichzeitige Zugriff hoch ist, darf der Wert des Parameters query.max-total-memory die maximale Speicherkapazität des Clusters nicht überschreiten. Dieser Wert entspricht 70% des JVM-Speichers multipliziert mit der Anzahl der Worker-Knoten. Verringern Sie die Werte von query.max-memory und query.max-memory-per-node je nach Ihren Anforderungen proportional. Sie können den Wert von query.max-memory auf die Hälfte von query.max-total-memory verringern. In diesem Fall müssen Sie den Parameter query.max-memory-per-node auf den Wert query.max-memory dividiert durch die Anzahl der Worker-Knoten setzen. |
memory.heap-headroom-per-node
|
Der reservierte JVM-Heap-Speicher. |
config.properties
|
Effektiver Speicher muss 15% des JVM-Speichers sein |
task.concurrency
|
Standardmäßige lokale Nebenläufigkeit für parallele Operatoren, wie Joins und Aggregationen. Passen Sie diesen Wert basierend auf dem gleichzeitigen Abfragezugriff und der Ressourcenauslastung des Mitarbeiters nach oben oder unten an. Niedrigere Werte sind besser für Cluster, die viele Abfragen gleichzeitig ausführen, da das Cluster bereits von allen ausgeführten Abfragen verwendet wird. Das Hinzufügen weiterer Nebenläufigkeit führt daher zu einer Verlangsamung aufgrund von Kontextwechsel und anderem Overhead. Höhere Werte sind besser für Cluster, die nur eine oder mehrere Abfragen gleichzeitig ausführen. |
config.properties
|
80% der verfügbaren CPU in einem Knoten/einer VM |