Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Le migliori pratiche per Trino su Amazon EMR
L'architettura di Trino è progettata per query SQL veloci e distribuite su set di dati di grandi dimensioni su più fonti di dati, seguendo un modello coordinatore-lavoratore, in cui ogni componente ha un ruolo specializzato nell'esecuzione delle query. Ci sono alcune aree o categorie su cui puoi concentrarti per configurare il tuo cluster Amazon EMR su cui è in esecuzione Trino per ottenere le migliori prestazioni. Questi sono i seguenti:
+ Regolazione delle impostazioni di configurazione del cluster per l'ottimizzazione della memoria.
+ Ottimizzazione delle impostazioni per il partizionamento e la distribuzione dei dati.
+ Utilizzo del filtraggio dinamico per ridurre il numero di risultati delle query.
Alcune di queste impostazioni vengono ottimizzate automaticamente quando usi Trino con Amazon EMR. Altri possono essere impostati manualmente tramite la console o tramite i comandi CLI. Gli argomenti di questa sezione consentono di configurare i dati e il cluster in modo ottimale.
**Topics**
+ [Principali aree di interesse per il miglioramento delle prestazioni](emr-trino-performance-areas.md)
+ [Raccogli e utilizza le statistiche delle tabelle](emr-trino-performance-areas-collect-stats.md)
+ [Sfide comuni relative alla scalabilità dei carichi di lavoro Trino](emr-trino-common-issues.md)
# Principali aree di interesse per il miglioramento delle prestazioni
Trino massimizza il parallelismo delle query e l'ottimizzazione della memoria. Questa architettura offre flessibilità consentendole di interrogare più e varie fonti di dati con una scalabilità efficiente. Le aree chiave di miglioramento delle prestazioni in Trino includono quelle elencate di seguito.
## Ottimizzazione della memoria
La gestione della memoria in Trino è fondamentale per ottenere prestazioni e stabilità elevate, specialmente quando si eseguono query complesse e di grandi dimensioni. Trino utilizza un modello di memoria distribuito. In questo modello, la memoria viene allocata tra i nodi di lavoro per l'elaborazione di attività, aggregazioni, join e altre operazioni. L'elenco seguente presenta una raccolta di queste impostazioni:
+ **query.max-memory**: imposta la memoria massima disponibile per una singola query nell'intero cluster. Si tratta di un limite rigido; se una query supera questa memoria, avrà esito negativo.
+ **interrogazione. max-memory-per-node** — Definisce la memoria massima che una query può consumare su ogni nodo di lavoro. Questa impostazione garantisce che nessuna singola query monopolizzi le risorse di nessun lavoratore.
+ **Dimensione dell'heap JVM**: configurata a livello di JVM, imposta la dimensione massima dell'heap per il processo del server Trino su ciascun nodo. **Questo valore dovrebbe generalmente essere maggiore delle configurazioni relative alla memoria (questa è la somma delle query). **max-memory-per-node**e memoria. heap-headroom-per-node**) in Trino per evitare che il sistema esaurisca la memoria a livello di JVM.
+ **memoria. heap-headroom-per-node** — specifica una quantità di memoria buffer da escludere dalla dimensione dell'heap JVM per le operazioni non di query. Questo è fondamentale per garantire un sovraccarico sufficiente per le operazioni interne e la raccolta dei rifiuti.
## Filtraggio dinamico
Il filtraggio dinamico in Trino è una tecnica di ottimizzazione che migliora le prestazioni delle query riducendo la quantità di dati elaborati, in particolare durante i join. Applica dinamicamente le condizioni di filtro per limitare i dati scansionati da un lato di un join, in base ai dati visualizzati sull'altro lato, il che è particolarmente utile nelle query in cui un lato del join è altamente selettivo (ovvero contiene un piccolo sottoinsieme di dati). È abilitato per impostazione predefinita su Amazon EMR. Di seguito è riportato un esempio di query:
```
SELECT orders.order_id, orders.total_amount
FROM orders
JOIN customers ON orders.customer_id = customers.customer_id
WHERE customers.country = 'France';
```
Senza filtri dinamici, Trino scansiona l'intera tabella degli ordini in un join, anche se solo un piccolo sottoinsieme di clienti (quelli provenienti dalla Francia) è rilevante. Questo approccio legge tutte le righe della tabella **degli ordini**, con conseguenti costi elevati e di elaborazione. I/O Con il filtraggio dinamico, Trino esegue inizialmente la scansione della tabella **dei clienti** più piccoli, recupera i valori customer\$1id solo per i clienti provenienti dalla Francia e quindi applica questo sottoinsieme come filtro agli ordini. Ciò significa che vengono scansionate solo le righe pertinenti degli **ordini**, quelle con un customer\$1id corrispondente al sottoinsieme filtrato, riducendo significativamente i record elaborati.
## Versate su disco
In Trino, la fuoriuscita del disco consente di scaricare su disco i risultati delle query intermedie, permettendo il completamento di query che richiedono molta memoria, anche se superano i limiti di memoria impostati da o. `query_max_memory` `query_max_memory_per_node` Per impostazione predefinita, Trino applica questi limiti per garantire un'allocazione equa della memoria e prevenire il deadlock del cluster. Tuttavia, quando una query di grandi dimensioni supera questi limiti, rischia di essere interrotta. La fuoriuscita del disco risolve questo problema utilizzando `revocable memory` una query che consente di prendere in prestito memoria aggiuntiva che può essere revocata se sono necessarie risorse altrove. Quando la memoria viene revocata, i dati intermedi vengono trasferiti sul disco, permettendo alle query di continuare l'elaborazione senza superare i limiti di memoria. Tieni presente che una query forzata a riversarsi su disco può avere tempi di esecuzione più lunghi, pertanto è disattivata per impostazione predefinita. Per abilitare lo spill su Amazon EMR, utilizza la seguente configurazione:
+ `spill-enabled=true`— Consente la fuoriuscita del disco quando l'utilizzo della memoria supera le soglie disponibili.
+ `spill-paths`— Definisce le directory in cui vengono archiviati i dati fuoriusciti,. `spill-paths=/mnt/spill`
# Raccogli e utilizza le statistiche delle tabelle
La raccolta delle statistiche delle tabelle consente all'ottimizzatore basato sui costi di Trino di prendere decisioni informate sugli ordini di unione, la riduzione dei filtri e la rimozione delle partizioni, con conseguente miglioramento delle prestazioni.
Puoi usare il `ANALYZE` comando per raccogliere statistiche per le tabelle Hive o Iceberg:
```
ANALYZE sales;
```
La raccolta di statistiche su tabelle ampie può comportare un notevole dispendio di risorse. È consigliabile specificare un sottoinsieme di colonne da utilizzare nei join, nei filtri o nelle operazioni di raggruppamento.
Questo è un altro comando utile. Visualizza le statistiche correnti di una tabella per verificare se le statistiche sono aggiornate.
```
show stats for table_name;
```
# Sfide comuni relative alla scalabilità dei carichi di lavoro Trino
I vantaggi principali dell'utilizzo di Amazon S3 con Trino sono la capacità di S3 di scalare grandi volumi di dati e l'economicità di S3. Tuttavia, quando si eseguono query su grandi volumi di dati, di tanto in tanto possono verificarsi una serie di problemi di prestazioni correlati. Questi possono derivare dal modo in cui i dati vengono archiviati, da impostazioni di configurazione che limitano le buone prestazioni o da altri motivi. Quando si verificano questi problemi, è possibile adottare misure efficaci per evitarli o mitigarli.
Questa sezione inizia con un elenco di ottimizzazioni generali che è possibile implementare per aumentare le prestazioni delle query su grandi volumi di dati. Successivamente, vengono descritti in dettaglio i problemi più comuni e vengono fornite le mitigazioni per ciascuno di essi.
Questo argomento è tratto dalla seguente presentazione alla conferenza: [Accelerare le prestazioni su larga scala: best practice per Trino con Amazon S3](https://www.youtube.com/watch?v=cjUUcHlUKxQ).
## Ottimizzazione del layout dei dati per set di dati di grandi dimensioni
I colli di bottiglia in termini di prestazioni non sono infrequenti quando si eseguono query su set di dati di grandi dimensioni. Tuttavia, ci sono delle best practice che puoi implementare per avere un vantaggio iniziale quando usi Trino per interrogare i dati in Amazon S3. Questi sono i seguenti:
+ **Partizionamento**: il partizionamento significa organizzare i dati in una gerarchia e archiviare insieme i dati correlati, sulla base di attributi correlati. Il partizionamento consente di evitare che le query debbano scansionare troppi dati irrilevanti e si traduce in migliori prestazioni delle query. È possibile utilizzare varie strategie di partizionamento, ad esempio disporre i dati di origine con prefissi, in particolare per intervalli di date, regioni o altri attributi. Per informazioni più dettagliate sul partizionamento dei dati in Amazon S3 per aumentare le prestazioni, consulta il [post del blog Inizia a gestire le partizioni per le tabelle Amazon S3 supportate AWS dal Glue Data Catalog o il](https://aws.amazon.com/blogs/big-data/get-started-managing-partitions-for-amazon-s3-tables-backed-by-the-aws-glue-data-catalog/) [post](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/) Top 10 Performance Tuning Tips for. Amazon Athena
+ Bucketing: **il bucketing** raggruppa i dati correlati in file comuni. Ad esempio, se si interrogano i dati in base a un'area geografica, ad esempio uno stato, è possibile migliorare le prestazioni delle query raggruppando tutti i dati relativi a uno stato particolare nello stesso file o gruppo di file. Affinché ciò funzioni al meglio, è consigliabile basare la propria strategia su un attributo di dati con elevata cardinalità, ad esempio uno stato o una provincia. Inoltre, puoi tenere conto dei tuoi modelli di query. Un esempio di ciò potrebbe consistere nel raggruppamento dei dati per California e Oregon, se le query in genere leggono insieme i dati di tali stati.
+ **Gestione dei prefissi S3: puoi utilizzare i** prefissi Amazon S3 per implementare una strategia di partizionamento. Se utilizzi un solo prefisso per un bucket Amazon S3, ad esempio una data particolare, ciò può portare a un numero elevato di richieste e generare un errore HTTP 503. Ti consigliamo di utilizzare i prefissi per aggiungere condizioni aggiuntive e organizzare i dati di origine in modo più efficace. Per ulteriori informazioni, consulta [Organizzazione degli oggetti utilizzando i prefissi nella documentazione](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-prefixes.html) di Amazon S3. Il breve esempio seguente mostra un prefisso che consente di migliorare il throughput delle richieste:. `s3://bucket/country=US/dt=2024-06-13` In questo esempio, sia il paese che la data sono inclusi nel prefisso, il che si traduce in un minor numero di letture rispetto a un caso in cui il prefisso include solo la data.
La mitigazione degli errori HTTP 503 viene discussa più dettagliatamente nella sezione relativa al *rallentamento dell'HTTP* che segue in questo argomento.
+ **Ottimizzazione delle dimensioni dei dati**: è possibile eseguire il comando OPTIMIZE per impostare una configurazione che favorisca il miglioramento delle prestazioni delle query. Per eseguirlo su tabelle esterne Hive, segui questi passaggi:
+ Utilizzare `OPTIMIZE` con il seguente parametro:`hive.non-managed-table-writes-enabled=true`. Per ulteriori informazioni su questa proprietà, vedere [Proprietà di configurazione generali di Hive](https://trino.io/docs/current/connector/hive.html#hive-general-configuration-properties).
+ Imposta il seguente parametro di sessione: `SET SESSION` `catalog.non_transactional_optimize_enabled=true`
+ Esegui il `OPTIMIZE` comando:`ALTER TABLE catalog.schema.table EXECUTE optimize(file_size_threshold => '128MB')`. In questo caso, l'impostazione predefinita `file_size_threshold` è di 100 MB. L'innalzamento di questa soglia, come mostrato nell'esempio, comporterà l'unione dei file di dimensioni inferiori a 128 MB.
+ **Configura nuovi tentativi**: puoi aumentare il limite di nuovi tentativi, che può ridurre la possibilità di errori HTTP 503, impostando quanto segue:. `s3.max-error-retries` Questo vale quando si utilizzano l' TrinoFileSystem API e la versione Trino 449 o successiva. D'altra parte, nel caso in cui utilizzi Amazon EMR con Trino, utilizzi EMRFS per accedere ad Amazon S3. Con EMRFS, puoi aumentare il numero di ritiri modificando il parametro. `fs.s3.maxRetries`
+ **Scegli una classe di storage Amazon S3: la scelta della classe** di storage appropriata per i dati in diversi momenti del loro ciclo di vita può favorire sia le prestazioni che i costi, in base ai requisiti per raccolte di dati specifiche. Per ulteriori informazioni, consulta [Comprendere e gestire le classi di storage Amazon S3 nella documentazione](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.htm) di Amazon S3.
+ **Migrazione a Iceberg**: un'altra soluzione per mitigare i problemi di prestazioni, in particolare per quanto riguarda l'esecuzione di query su file di piccole dimensioni, è la migrazione alle tabelle Iceberg. Iceberg dispone di funzionalità che gestiscono bene i file di piccole dimensioni.
+ **Usa la compattazione automatica dei dati**: se utilizzi le tabelle Iceberg, la compattazione automatica dei dati con AWS Glue Data Catalog può ottimizzare le dimensioni dei dati e migliorare le prestazioni delle query.
## Sfide comuni quando si interrogano set di dati di grandi dimensioni
Questa sezione elenca una raccolta di problemi comuni che possono verificarsi quando si accumula un set di dati di grandi dimensioni in Amazon S3 e lo si interroga con Trino. Ogni sezione mostra come risolvere il problema o ridurne l'impatto sulle query. Ciascuno dei problemi descritti nelle seguenti sezioni è stato riprodotto e testato utilizzando un connettore Hive.
### Scansioni di dati di grandi dimensioni
Quando la query deve scansionare set di dati di grandi dimensioni, può causare problemi come rallentamenti delle prestazioni delle query e costi di archiviazione più elevati. Grandi volumi di dati possono derivare da una rapida crescita dei dati o da una pianificazione che non comporti lo spostamento dei dati legacy entro un periodo di tempo appropriato. Ciò può portare a query più lente.
Per mitigare gli effetti negativi sulle prestazioni dovuti alla scansione di set di dati di grandi dimensioni, consigliamo di utilizzare il partizionamento e il bucketing:
+ Il partizionamento raggruppa i dati correlati, in base ai relativi attributi. L'uso efficace del partizionamento può migliorare notevolmente le prestazioni delle query.
+ Il bucketing si riferisce al raggruppamento dei dati in file o bucket in base a colonne di dati specifiche e correlate. Il bucketing in genere significa tenere insieme fisicamente i file di dati di origine correlati.
Per illustrare come la mitigazione può funzionare per scansioni di dati di grandi dimensioni, si supponga di archiviare e interrogare dati contenenti record con un attributo di stato, che può essere assegnato alla California o all'Alaska, e che questo attributo di stato sia una delle condizioni di interrogazione. Puoi migliorare le prestazioni delle query archiviando i dati per ogni stato in un bucket S3 separato o partizionando i dati in base allo stato, utilizzando un prefisso S3. Questo partizionamento e suddivisione in categorie possono anche migliorare le prestazioni se le si basa su una colonna aggiuntiva, ad esempio un attributo di data.
**Nota**
Se una colonna ha una cardinalità elevata e desideri utilizzarla per raggruppare i dati, in questo caso ti consigliamo di utilizzare il bucketing. D'altra parte, in genere, le chiavi di partizione dovrebbero avere una cardinalità inferiore.
**Utilizzo di vari tipi di archiviazione S3**
In genere, si scelgono i tipi di storage in base a prestazioni, accesso ai dati, resilienza e requisiti di costo per i carichi di lavoro. È possibile trovare un compromesso tra costi e prestazioni. È importante scegliere la classe di storage Amazon S3 appropriata che corrisponda ai tuoi modelli di accesso ai dati. Esistono due modelli di accesso principali:
+ Dati a cui si accede in modo noto o prevedibile. In genere, se si dispone di dati a cui si accede raramente, S3 Standard IA può essere una buona scelta, perché aiuta a ridurre i costi. Se accedi spesso ai dati, S3 Standard è la soluzione migliore per l'accesso con Amazon EMR e Trino.
+ Dati a cui si accede in modo sconosciuto o imprevedibile. Ciò può richiedere l'utilizzo di altre classi di storage Amazon S3. Esistono dei compromessi tra le classi di storage S3. Questi includono latenza, costi di storage e disponibilità. Puoi scegliere un tipo di storage S3 appropriato, in base ai carichi di lavoro e ai modelli di accesso. Per le descrizioni dei vantaggi di ciascuna classe, consulta [Amazon S3 Storage]() Classes.
**Utilizzo della compattazione**
È inoltre possibile utilizzare la compattazione automatica Iceberg, se si utilizzano le tabelle Iceberg, che consentono di ottenere dimensioni dei file più ottimali, per aumentare l'efficienza delle query. Per ulteriori informazioni, vedi [AWS Glue Data Catalog ora supporta la compattazione automatica delle tabelle Apache Iceberg](https://aws.amazon.com/blogs/aws/aws-glue-data-catalog-now-supports-automatic-compaction-of-apache-iceberg-tables/).
### Errori di rallentamento HTTP
Ciò si verifica quando la frequenza delle richieste supera una soglia preconfigurata su un prefisso Amazon S3. L'errore HTTP che si verifica più comunemente quando viene raggiunto questo stato è il seguente: **Errore 503:** riduci la frequenza delle richieste. L'origine di questo problema può essere radicata in presenza di un gran numero di file di piccole dimensioni, a causa del numero di *suddivisioni* che devono essere create per leggere i dati. Esistono due modi per mitigare il problema:
+ Aumenta il limite di tentativi per le richieste Amazon S3 in Trino. È impostato per l'utilizzo di EMRFS in Trino 449. `fs.s3.maxretries`
+ Ottimizza le dimensioni dei file, il che può anche comportare una riduzione del tasso di richieste.
Per ulteriori informazioni su come Trino determina il numero di suddivisioni in un set di dati da interrogare, consultate [Performance Tuning configuration properties](https://trino.io/docs/current/connector/hive.html#performance-tuning-configuration-properties) nella documentazione del connettore Hive.
### Difficoltà a interrogare file di piccole dimensioni
L'esecuzione di query su molti file di piccole dimensioni può comportare un notevole I/O sovraccarico, a causa dell'elevato numero di richieste GET e LIST, e di conseguenza influire negativamente sulle prestazioni delle query. L'ottimizzazione delle dimensioni dei file può migliorare le prestazioni delle query. Esistono alcuni modi per eseguire questa operazione:
+ Consolida i dati in un numero inferiore di file di dimensioni maggiori. (In genere, consigliamo di mantenere le dimensioni dei file a circa 128 MB.) È possibile farlo con strumenti quando si inseriscono dati, ad esempio in una pipeline ETL, oppure è possibile consolidare i dati manualmente. Se queste soluzioni non sono disponibili, le opzioni rimanenti potrebbero essere più adatte a te.
+ Esegui il comando `OPTIMIZE`.
+ Impostare il parametro `SESSION`.
Tieni presente che Iceberg ha a disposizione una funzionalità per unire file di piccole dimensioni in file più grandi, ovvero la compattazione automatica. Funziona con i file gestiti con il AWS Glue Data Catalog. Per ulteriori informazioni, vedi [AWS Glue Data Catalog ora supporta la compattazione automatica delle tabelle Apache Iceberg](https://aws.amazon.com/blogs/aws/aws-glue-data-catalog-now-supports-automatic-compaction-of-apache-iceberg-tables/).
### Query che includono dati non necessari
È normale che i dati crescano, il che rende imperativo tenere traccia dei modelli di accesso ai dati e spostare i dati in modo appropriato man mano che invecchiano o diventano irrilevanti. Questo perché con l'aumento dei dati, le prestazioni delle query possono peggiorare nel tempo, principalmente a causa dell'enorme volume di dati da analizzare durante l'esecuzione di una query. Amazon S3 e altri servizi offrono linee guida per la migrazione del ciclo di vita dei dati, che mostrano le strategie per spostare i dati in diverse posizioni di storage quando diventano freddi. Ciò comporta anche un vantaggio in termini di costi di storage.
Oltre alla migrazione dei dati, puoi utilizzare altre strategie come la rimozione dei dati di origine che non sono pertinenti alle query che stai eseguendo. Questa operazione può richiedere del tempo, poiché potrebbe comportare la modifica dello schema dei dati di origine. Tuttavia, il risultato positivo è la riduzione del volume dei dati e la velocità delle interrogazioni. Per ulteriori informazioni, vedere [Gestione del ciclo di vita degli](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) oggetti.