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à.

# Ottimizzazione delle prestazioni
<a name="performance-tuning"></a>

Questo argomento fornisce informazioni generali e suggerimenti specifici per migliorare le prestazioni delle tue query Athena e su come rimediare agli errori relativi ai limiti e all'utilizzo delle risorse.

In generale, le ottimizzazioni possono essere raggruppate in categorie di servizi, query e strutture dati. Le decisioni prese a livello di servizio, sul modo in cui si scrivono le query e sulla struttura dei dati e delle tabelle possono influire sulle prestazioni.

**Topics**
+ [Ottimizza l’uso del servizio](performance-tuning-service-level-considerations.md)
+ [Ottimizzazione delle query](performance-tuning-query-optimization-techniques.md)
+ [Ottimizzazione dei dati](performance-tuning-data-optimization-techniques.md)
+ [Usa formati di archiviazione colonnare](columnar-storage.md)
+ [Utilizzare partizionamento e bucketing](ctas-partitioning-and-bucketing.md)
+ [Come partizionare i dati](partitions.md)
+ [Proiezione delle partizioni con Amazon Athena](partition-projection.md)
+ [Prevenire la limitazione (della larghezza di banda della rete) di Amazon S3](performance-tuning-s3-throttling.md)
+ [Risorse aggiuntive](performance-tuning-additional-resources.md)

# Ottimizza l’uso del servizio
<a name="performance-tuning-service-level-considerations"></a>

Le considerazioni sul livello di servizio includono il numero di carichi di lavoro eseguiti per account, le service quotas non solo per Athena, ma per tutti i servizi e la riflessione su come ridurre gli errori di «esaurimento delle risorse».

**Topics**
+ [Gestisci più carichi di lavoro all’interno dello stesso account](#performance-tuning-service-quotas)
+ [Riduci gli errori di «esaurimento delle risorse»](#performance-tuning-resource-limits)

## Gestisci più carichi di lavoro all’interno dello stesso account
<a name="performance-tuning-service-quotas"></a>

Athena utilizza le quote per limitare la concorrenza delle query e i tassi di richiesta API a livello di account. Il superamento di queste quote può causare il fallimento delle query durante l’esecuzione o al momento dell’invio. Per ulteriori informazioni su queste quote, consulta [Service Quotas](service-limits.md). 

Se gestisci più carichi di lavoro all'interno dello stesso AWS account, i tuoi carichi di lavoro competono per la stessa quota a livello di account. Ad esempio, se in un carico di lavoro si verifica un'esplosione imprevista di query, un altro carico di lavoro in esecuzione sullo stesso account potrebbe registrare tempi di coda elevati o, nel peggiore dei casi, errori di invio delle query a causa della limitazione (della larghezza di banda della rete).

Ti consigliamo di CloudWatch utilizzarlo per monitorare l'utilizzo del servizio tramite grafici e dashboard. Puoi anche configurare CloudWatch allarmi che ti avvisino quando l'utilizzo si avvicina alla quota di servizio per le query simultanee, consentendoti di intervenire prima di raggiungere i limiti di quota. Per ulteriori informazioni, consulta [Monitora le metriche di utilizzo di Athena con CloudWatch](monitoring-athena-usage-metrics.md).

Per controllare la concomitanza delle query e isolare i carichi di lavoro all’interno del tuo account, utilizza le prenotazioni di capacità. Le prenotazioni di capacità forniscono una capacità dedicata di elaborazione delle query all’interno di un singolo account. La capacità viene misurata in unità di elaborazione dati (DPUs) e può essere aggiunta o rimossa rispettivamente per aumentare o diminuire la concomitanza delle query. Le prenotazioni di capacità consentono di isolare i carichi di lavoro all’interno dell’account l’uno dall’altro assegnando la capacità a uno o più gruppi di lavoro. Per ulteriori informazioni, consulta [Gestisci la capacità di elaborazione delle query](capacity-management.md).

Sebbene sia necessario isolare i carichi di lavoro non correlati in AWS account diversi (ad esempio isolando lo sviluppo dagli ambienti di produzione), questo approccio non fornisce un modo scalabile per aumentare la concomitanza delle query. Utilizzate invece le prenotazioni di capacità per gestire e scalare le esigenze di elaborazione delle query all’interno di un unico account.

### Considera le quote in altri servizi
<a name="performance-tuning-quotas-in-other-services"></a>

Quando Athena esegue una query, può chiamare altri servizi che applicano le quote. Durante l'esecuzione delle query, Athena può effettuare chiamate API verso Amazon S3 e AWS altri servizi come IAM e. AWS Glue Data Catalog AWS KMS Se si utilizzano [interrogazioni federate](federated-queries.md), viene chiamata anche Athena. AWS Lambda Tutti questi servizi hanno rispettivi limiti e quote che possono essere superati. L'esecuzione di una query, quando rileva errori dovuti a questi servizi, non va a buon fine e include l'errore del servizio di origine. Gli errori rimediabili vengono ritentati, ma le query possono comunque avere esito negativo se il problema non si risolve automaticamente in tempo. Assicurati di leggere attentamente i messaggi degli errori per comprendere se questi provengono da Athena o da un altro servizio. In questa sezione sono trattati alcuni errori rilevanti.

Per ulteriori informazioni su come rimediare agli errori provocati dalle service quotas di Amazon S3, consulta [Come evitare di avere un numero eccessivo di file](performance-tuning-data-optimization-techniques.md#performance-tuning-avoid-having-too-many-files) più avanti in questo documento. Per ulteriori informazioni sull'ottimizzazione delle prestazioni di Amazon S3, consulta [Modelli di concezione delle best practice: ottimizzazione delle prestazioni di Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) nella *Guida per l'utente di Amazon S3*.

## Riduci gli errori di «esaurimento delle risorse»
<a name="performance-tuning-resource-limits"></a>

Athena esegue le query in un motore di query distribuito. Quando invii una query, il pianificatore di query del motore Athena stima la capacità di calcolo richiesta per l’esecuzione della query e prepara di conseguenza un cluster di nodi di calcolo. Alcune query, come le query DDL, sono eseguite su un solo nodo. Le query complesse su set di dati di grandi dimensioni sono eseguite su cluster molto più grandi. I nodi sono uniformi, con le stesse configurazioni di memoria, CPU e disco. Athena si dimensiona orizzontalmente, non verticalmente, per elaborare query più impegnative.

Talvolta le richieste di una query superano le risorse disponibili al cluster che esegue la query. Quando ciò accade, la query non va a buon fine e viene visualizzato l'errore La query ha esaurito le risorse con questo fattore di scala.

La risorsa più comunemente esaurita è la memoria, ma in rari casi anche lo spazio su disco può essere esaurito. In genere si presentano errori di memoria quando il motore esegue una funzione join o finestra, ma possono presentarsi anche durante conteggi e aggregazioni distinti.

Una query, che non sia riuscita e abbia presentato l'errore di "risorse esaurite", potrebbe avere esito positivo quando la esegui nuovamente. L'esecuzione delle query non è deterministica. Fattori quali il tempo necessario al caricamento di dati e il modo di distribuzione sui nodi di set di dati intermedi possono comportare un diverso utilizzo delle risorse. Ad esempio, immagina una query che unisce due tabelle e che presenta una forte asimmetria nella distribuzione dei valori per la condizione di join. Una query di questo tipo può avere esito positivo per la maggior parte del tempo, ma talvolta può non riuscire quando i valori più comuni risultano essere elaborati dallo stesso nodo.

Per evitare che le query superino le risorse disponibili, segui i consigli per ottimizzare le prestazioni cui si è accennato in questo documento. In particolare, relativamente ai consigli sulle modalità di ottimizzazione delle query che esauriscono le risorse disponibili, consulta [Ottimizzazione dei join](performance-tuning-query-optimization-techniques.md#performance-tuning-optimizing-joins), [Riduci l’ambito delle funzioni delle finestre o rimuovile](performance-tuning-query-optimization-techniques.md#performance-tuning-optimizing-window-functions) e [Ottimizzazione delle query mediante approssimazioni](performance-tuning-query-optimization-techniques.md#performance-tuning-optimizing-queries-by-using-approximations). 

# Ottimizzazione delle query
<a name="performance-tuning-query-optimization-techniques"></a>

Attieniti alle tecniche di ottimizzazione delle query descritte in questa sezione per velocizzare l'esecuzione delle query o per rimediare al problema delle query che superano i limiti di risorse in Athena.

## Ottimizzazione dei join
<a name="performance-tuning-optimizing-joins"></a>

Le strategie per eseguire join in un motore di query distribuito sono svariate. Due delle più comuni sono gli hash join distribuiti e le query con condizioni di join complesse.

### In un hash join distribuito, posiziona le tabelle grandi a sinistra e le tabelle piccole a destra
<a name="performance-tuning-distributed-hash-join"></a>

Il tipo più comune di join utilizza come condizione di join un confronto di uguaglianza. Athena esegue questo tipo di join come hash join distribuito.

In un hash join distribuito, il motore crea una tabella di ricerca (tabella hash) da uno dei lati del join. Questo lato è denominato il *lato build*. I record del lato build sono distribuiti tra i nodi. Ogni nodo costruisce una tabella di ricerca per il relativo sottoinsieme. L'altro lato del join, denominato *lato probe*, è quindi trasmesso in streaming attraverso i nodi. I record dal lato probe sono distribuiti sui nodi nello stesso modo del lato build. Ciò consente a ciascun nodo di eseguire il join cercando i record corrispondenti nella relativa tabella di ricerca.

Quando le tabelle di ricerca create dal lato build del join non rientrano nella memoria, le query possono non andare a buon fine. Anche se la dimensione totale del lato di build è inferiore alla memoria disponibile, se la distribuzione dei record presenta un'asimmetria significativa, le query possono comunque avere esito negativo. In un caso estremo, è possibile che tutti i record abbiano per la condizione di join lo stesso valore e che sia richiesto che vengano immessi nella memoria su un singolo nodo. Anche una query con asimmetria minore può avere esito negativo se un set di valori viene inviato allo stesso nodo e la somma dei valori supera la quantità superiore di memoria disponibile. I nodi hanno la capacità di versare i record su disco, tuttavia il versamento rallenta l'esecuzione delle query e può essere insufficiente per evitare che la query abbia esito negativo.

Athena tenta di riordinare i join per utilizzare la relazione più grande come lato probe e la relazione più piccola come lato build. Tuttavia Athena, poiché non gestisce i dati nelle tabelle, dispone di informazioni limitate e spesso deve presumere che la prima tabella sia la più grande e la seconda tabella sia la più piccola.

Quando scrivi join con condizioni di join basate sull'uguaglianza, presumi che la tabella a sinistra della parola chiave `JOIN` sia il lato probe e la tabella a destra sia il lato build. Assicurati che la tabella a destra, il lato build, sia la tabella di dimensioni inferiori. Se non è possibile ridurre le dimensione del lato build del join affinché rientri nella memoria, considera la possibile di eseguire più query che uniscano sottoinsiemi della tabella build.

### Usa EXPLAIN per analizzare le interrogazioni con join complessi
<a name="performance-tuning-other-join-types"></a>

Le query con condizioni di join complesse (ad esempio, query che utilizzano `LIKE` o altri operatori) sono spesso impegnative dal punto di vista computazionale. `>` Nel peggiore dei casi, tutti i record di un lato del join devono essere confrontati con tutti i record sull'altro lato del join. Poiché il tempo di esecuzione aumenta con il quadrato del numero di record, si rischia che tali query superino il tempo di esecuzione massimo.

Per sapere in in anticipo in che modo Athena eseguirà la query, puoi utilizzare la dichiarazione `EXPLAIN`. Per ulteriori informazioni, consultare [Utilizzo di EXPLAIN e EXPLAIN ANALYZE in Athena](athena-explain-statement.md) e [Capire i risultati dell’istruzione EXPLAIN di Athena](athena-explain-statement-understanding.md).

## Riduci l’ambito delle funzioni delle finestre o rimuovile
<a name="performance-tuning-optimizing-window-functions"></a>

Le funzioni delle finestre, poiché richiedono molte risorse, possono rallentare o addirittura far fallire le query con il messaggio La query ha esaurito le risorse con questo fattore di scala. Le funzioni finestra conservano in memoria tutti i record su cui operano per calcolarne il risultato. Quando la finestra è di dimensioni molto grandi, la funzione finestra può esaurire la memoria.

Per assicurarti che le query vengano eseguite entro i limiti di memoria disponibili, riduci le dimensioni delle finestre su cui operano le funzioni finestra. A tale scopo, puoi aggiungere una clausola `PARTITIONED BY` o restringere l'ambito delle clausole di partizionamento esistenti.

### Utilizza invece funzioni diverse dalle finestre
<a name="performance-tuning-optimizing-window-functions-rewrite"></a>

A volte le query con le funzioni finestra possono essere riscritte senza funzioni finestra. Ad esempio, invece di utilizzare `row_number` per trovare i record top `N`, puoi utilizzare `ORDER BY` e `LIMIT`. Anziché utilizzare `row_number` o `rank` per deduplicare i record, puoi utilizzare funzioni aggregate come [max\$1by](https://trino.io/docs/current/functions/aggregate.html#max_by), [min\$1by](https://trino.io/docs/current/functions/aggregate.html#min_by) e [arbitrary](https://trino.io/docs/current/functions/aggregate.html#arbitrary).

Ad esempio, considera di disporre di un set di dati con aggiornamenti da un sensore. Il sensore comunica regolarmente lo stato della batteria e include alcuni metadati quali la posizione. Se vuoi conoscere lo stato più recente della batteria di ogni sensore e la sua posizione, puoi utilizzare questa query:

```
SELECT sensor_id,
       arbitrary(location) AS location,
       max_by(battery_status, updated_at) AS battery_status
FROM sensor_readings
GROUP BY sensor_id
```

Poiché i metadati, ad esempio la posizione, sono gli stessi per ogni record, puoi utilizzare la funzione `arbitrary` per selezionare qualsiasi valore dal gruppo. 

Per conoscere lo stato più recente della batteria, puoi usare la funzione `max_by`. La funzione `max_by` seleziona il valore di una colonna dal record in cui è stato trovato il valore massimo di un'altra colonna. In questo caso, la funzione restituisce lo stato della batteria del record con l'orario dell'ultimo aggiornamento all'interno del gruppo. Questa query viene eseguita più velocemente e utilizza meno memoria rispetto a una query equivalente con una funzione finestra. 

## Ottimizzazione delle aggregazioni
<a name="performance-tuning-optimizing-aggregations"></a>

Athena, quando esegue un'aggregazione, distribuisce i record tra i nodi worker utilizzando le colonne nella clausola `GROUP BY`. Per rendere il più efficiente possibile l'abbinamento dei record ai gruppi, i nodi cercano di conservare i record in memoria ma, se necessario, li trasferiscono su disco.

Inoltre, nelle clausole `GROUP BY` è consigliabile evitare di includere colonne ridondanti. Poiché un numero inferiore di colonne richiede una quantità di memoria inferiore, è più efficiente una query che descrive un gruppo con un numero inferiore di colonne. Le colonne numeriche utilizzano inoltre una quantità di memoria inferiore rispetto alle stringhe. Ad esempio, quando aggreghi un set di dati che ha sia un ID di categoria numerico sia un nome di categoria, nella clausola `GROUP BY` utilizza solo la colonna ID di categoria.

A volte le query includono colonne nella clausola `GROUP BY` per ovviare al fatto che una colonna debba far parte della clausola `GROUP BY` o di un'espressione aggregata. Se questa regola non viene seguita, puoi ricevere un messaggio di errore come il seguente:

 EXPRESSION\$1NOT\$1AGGREGATE: riga 1:8: 'category' deve essere un'espressione aggregata o apparire nella clausola GROUP BY 

Per evitare di dover aggiungere colonne ridondanti alla `GROUP BY` clausola, puoi utilizzare la funzione [arbitraria](https://trino.io/docs/current/functions/aggregate.html#arbitrary), come nell'esempio che segue.

```
SELECT country_id,
       arbitrary(country_name) AS country_name,
       COUNT(*) AS city_count
FROM world_cities
GROUP BY country_id
```

La funzione `ARBITRARY` restituisce un valore arbitrario dal gruppo. La funzione è utile quando sai che tutti i record del gruppo hanno lo stesso valore per una colonna, ma il valore non identifica il gruppo.

## Ottimizzazione delle query top N
<a name="performance-tuning-optimizing-top-n-queries"></a>

La clausola `ORDER BY` restituisce i risultati di una query disponendoli in ordine. Athena utilizza l'ordinamento distribuito per eseguire l'operazione di ordinamento in parallelo su più nodi.

Se non è strettamente necessario ordinare i risultati, evita di aggiungere una clausola `ORDER BY`. Inoltre, se non sono strettamente necessarie, evita di aggiungere informazioni `ORDER BY` alle query interne. In molti casi, il pianificatore di query può rimuovere l'ordinamento ridondante, ma ciò non è garantito. Un'eccezione a questa regola è prevista se una query interna esegue un'operazione top `N`, ad esempio la ricerca dei valori `N` più recenti o dei valori `N` più comuni.

Athena, quando vede `ORDER BY` insieme a `LIMIT`, capisce che stai eseguendo una query top `N` e mette in atto operazioni dedicate di conseguenza.

**Nota**  
Sebbene Athena sia spesso in grado di rilevare anche funzioni finestra come `row_number` che utilizza top `N`, è consigliabile la versione più semplice che utilizza `ORDER BY` e `LIMIT`. Per ulteriori informazioni, consulta [Riduci l’ambito delle funzioni delle finestre o rimuovile](#performance-tuning-optimizing-window-functions).

## Come includere solo le colonne obbligatorie
<a name="performance-tuning-include-only-required-columns"></a>

Se una colonna non è strettamente necessaria, non includerla nella tua query. Minore è la quantità di dati che una query deve elaborare, maggiore sarà la velocità di esecuzione. Ciò riduce sia la quantità di memoria richiesta sia la quantità di dati da inviare tra i nodi. Se utilizzi un formato di file colonnare, la riduzione del numero di colonne fa comporta una diminuzione anche della quantità di dati letti da Amazon S3.

In Athena non sono previsti limiti specifici al numero di colonne in un risultato, tuttavia le modalità di esecuzione delle query limita la possibile dimensione combinata delle colonne. La dimensione combinata delle colonne include i relativi nomi e tipi.

Ad esempio, l'errore seguente è causato da una relazione che supera il limite di dimensione di un descrittore di relazione:

 GENERIC\$1INTERNAL\$1ERROR: io.airlift.bytecode. CompilationException 

Per risolvere il problema, riduci il numero di colonne nella query o crea sottoquery e utilizza `JOIN` che recuperi una quantità inferiore di dati. Se hai query che eseguono `SELECT *` nella query più esterna, dovresti cambiare il `*` a un elenco che presenti solo le colonne di cui hai bisogno.

## Ottimizzazione delle query mediante approssimazioni
<a name="performance-tuning-optimizing-queries-by-using-approximations"></a>

Athena supporta [funzioni di aggregazione di approssimazione](https://trino.io/docs/current/functions/aggregate.html#appro) per il conteggio di valori distinti, dei valori più frequenti, di percentili (comprese le mediane approssimative) e per la creazione di istogrammi. Utilizza queste funzioni ogni volta che non hai bisogno di valori esatti.

A differenza delle operazioni `COUNT(DISTINCT col)`, [approx\$1distinct](https://trino.io/docs/current/functions/aggregate.html#approx_distinct) utilizza molta meno memoria e funziona più velocemente. Allo stesso modo, l'utilizzo di [numeric\$1histogram](https://trino.io/docs/current/functions/aggregate.html#numeric_histogram), anziché di [histogram](https://trino.io/docs/current/functions/aggregate.html#histogram), comporta metodi approssimativi e quindi una quantità di memoria inferiore.

## Ottimizzazione LIKE
<a name="performance-tuning-optimizing-like"></a>

Puoi usare `LIKE` per trovare stringhe corrispondenti, ma per le stringhe lunghe richiede molto calcolo. La funzione [regexp\$1like](https://trino.io/docs/current/functions/regexp.html#regexp_like) è nella maggior parte dei casi un'alternativa più veloce e offre anche maggiore flessibilità.

Spesso puoi ottimizzare una ricerca ancorando la sottostringa che stai cercando. Ad esempio, se stai cercando un prefisso, è molto meglio usare '*substr*%' invece di *substr* '% %'. Oppure, se stai usando`regexp_like`, '^ '. *substr*

## Utilizzo di UNION ALL anziché di UNION
<a name="performance-tuning-use-union-all-instead-of-union"></a>

 `UNION ALL` e `UNION` sono due modi di combinare i risultati di due query in un unico risultato. `UNION ALL` concatena i record della prima query con la seconda e `UNION` fa lo stesso, ma rimuove anche i duplicati. `UNION` deve elaborare tutti i record e trovare i duplicati, il che richiede molta memoria e calcolo, ma `UNION ALL` è un'operazione relativamente rapida. A meno che non sia necessario deduplicare i record, utilizza `UNION ALL` per ottenere prestazioni ottimali.

## Utilizzo di UNLOAD per set di risultati di grandi dimensioni
<a name="performance-tuning-use-unload-for-large-result-sets"></a>

Quando prevedi che i risultati di una query siano di grandi dimensioni (ad esempio, decine di migliaia di righe o più), utilizza UNLOAD per esportare i risultati. Nella maggior parte dei casi, questa operazione è più veloce rispetto all'esecuzione di una normale query e l'utilizzo di `UNLOAD` offre anche maggior controllo sull'output.

Al termine dell'esecuzione di una query, Athena archivia su Amazon S3 il risultato in un unico file CSV non compresso. Questa operazione richiede più tempo di `UNLOAD`, non solo perché il risultato non è compresso, ma anche perché l'operazione non può essere parallelizzata. Al contrario, `UNLOAD` scrive i risultati direttamente dai nodi worker e utilizza appieno il parallelismo del cluster di elaborazione. Inoltre, puoi configurare `UNLOAD` in modo che scriva i risultati in formato compresso e in altri formati di file come JSON e Parquet.

Per ulteriori informazioni, consulta [UNLOAD](unload.md). 

## Utilizzo di CTAS o Glue ETL per materializzare le aggregazioni utilizzate di frequente
<a name="performance-tuning-use-ctas-or-glue-etl-to-materialize-frequently-used-aggregations"></a>

La "materializzazione" di una query è un modo per accelerare le prestazioni delle query archiviando i risultati di query complesse precalcolate (ad esempio aggregazioni e join) per riutilizzarli nelle query successive.

Se molte delle query includono gli stessi join e le stesse aggregazioni, puoi materializzare la sottoquery comune come una nuova tabella e quindi eseguire query su quella tabella. Puoi creare la nuova tabella con [Creare una tabella dai risultati delle query (CTAS)](ctas.md) o con uno strumento ETL dedicato come [Glue ETL](https://aws.amazon.com/glue).

Ad esempio, considera di avere una dashboard con widget che mostrano diversi aspetti di un set di dati di ordini. Ogni widget ha una propria query, ma tutte queste condividono gli stessi join e filtri. Una tabella di ordini viene unita a una tabella di elementi, inoltre è presente un filtro per mostrare solo gli ultimi tre mesi. Se identifichi le funzionalità comuni di queste query, puoi creare una nuova tabella utilizzabile dai widget. Ciò riduce la duplicazione e migliora le prestazioni. Lo svantaggio è che devi mantenere aggiornata la nuova tabella.

## Riutilizzo dei risultati query
<a name="performance-tuning-reuse-query-results"></a>

Accade spesso che la stessa query venga eseguita più volte in un breve periodo. Ad esempio, ciò può succedere quando più persone aprono la stessa dashboard di dati. Quando esegui una query, puoi fare in modo che Athena riutilizzi i risultati calcolati in precedenza. Specifica l'età massima dei risultati da riutilizzare. Se la stessa query è stata eseguita in precedenza entro tale intervallo di tempo, Athena restituisce tali risultati anziché eseguire nuovamente la query. Per ulteriori informazioni, consulta [Riutilizza i risultati delle query in Athena](reusing-query-results.md) nella *Guida per l'utente di Amazon Athena* e il blog [Riduci i costi e migliora le prestazioni delle query con Amazon Athena Query Result Reuse](https://aws.amazon.com/blogs/big-data/reduce-cost-and-improve-query-performance-with-amazon-athena-query-result-reuse/) nel *Blog sui Big Data di AWS *.

# Ottimizzazione dei dati
<a name="performance-tuning-data-optimization-techniques"></a>

Le prestazioni dipendono non solo dalle query, ma anche, in misura significativa, dal modo di organizzazione del set di dati nonché dal formato di file e dalla compressione utilizzati dal set di dati.

## Come partizionare i dati
<a name="performance-tuning-partition-your-data"></a>

Il partizionamento divide la tabella in parti e mantiene insieme i dati correlati in base a proprietà quali data, paese o regione. Le chiavi di partizione fungono da colonne virtuali. Al momento della creazione della tabella, definisci le chiavi di partizione, quindi utilizzale per filtrare le query. Quando filtri in base alle colonne delle chiavi di partizione, vengono letti solo i dati delle partizioni corrispondenti. Ad esempio, se il set di dati è partizionato in base alla data e la query ha un filtro corrispondente solo all'ultima settimana, vengono letti solo i dati dell'ultima settimana. Per ulteriori informazioni sulle partizioni, consulta [Come partizionare i dati](partitions.md).

## Scegli le chiavi di partizione che supporteranno le query
<a name="performance-tuning-pick-partition-keys-that-will-support-your-queries"></a>

Poiché il partizionamento ha un impatto significativo sulle prestazioni delle query, quando pianifichi il set di dati e le tabelle, assicurati di considerare attentamente le modalità di partizionamento. Un numero eccessivo di chiavi di partizione può comportare set di dati frammentati con un numero eccessivo di file e file di dimensioni troppo piccole. Viceversa, se il numero delle chiavi di partizione è troppo basso o il partizionamento è inesistente, le query eseguono la scansione di una quantità di dati superiore a quella necessaria.

### Evita di eseguire l'ottimizzazione delle query rare
<a name="performance-tuning-avoid-optimizing-for-rare-queries"></a>

Una buona strategia consiste nell'eseguire l'ottimizzazione delle query più comuni ed evitare l'ottimizzazione delle query rare. Ad esempio, se le tue query riguardano intervalli di giorni, non partizionarle in base all'ora, anche se alcune query filtrano a quel livello. Se i dati presentano una colonna con timestamp granulare, le query rare che filtrano per ora possono utilizzare la colonna timestamp. Anche se in casi rari viene scansionata una quantità di dati leggermente superiore a quella necessaria, ridurre le prestazioni complessive a vantaggio dei casi rari di solito non è un buon compromesso.

Per ridurre la quantità di dati che le query devono scansionare e quindi migliorare le prestazioni, utilizza un formato di file colonnare e mantieni i record ordinati. Invece di partizionarli per ora, mantieni i record ordinati per timestamp. Per le query su finestre temporali più brevi, l'ordinamento per timestamp è efficiente quasi quanto il partizionamento per ora. Inoltre, l'ordinamento per timestamp in genere non pregiudica le prestazioni delle query su finestre temporali contate in giorni. Per ulteriori informazioni, consulta [Utilizzo di formati di file colonnari](#performance-tuning-use-columnar-file-formats).

Tieni presente che le query su tabelle con decine di migliaia di partizioni offrono prestazioni migliori se sono presenti predicati su tutte le chiavi di partizione. Questo è un motivo in più per pianificare lo schema di partizionamento per le query più comuni. Per ulteriori informazioni, consulta [Partizioni di query per uguaglianza](#performance-tuning-query-partitions-by-equality).

## Utilizzo della proiezione di partizioni
<a name="performance-tuning-use-partition-projection"></a>

La proiezione delle partizioni è una funzionalità di Athena che memorizza le informazioni sulle partizioni non in AWS Glue Data Catalog, ma come regole nelle proprietà della tabella in. AWS Glue Athena, quando pianifica una query su una tabella configurata con la proiezione delle partizioni, legge le regole di proiezione delle partizioni della tabella. Athena calcola le partizioni da leggere in memoria in base alla query e alle regole invece di cercare le partizioni in AWS Glue Data Catalog.

Oltre a semplificare la gestione delle partizioni, la proiezione delle partizioni può migliorare le prestazioni dei set di dati che presentano un numero elevato di partizioni. Quando una query include intervalli anziché valori specifici per le chiavi di partizione, la ricerca delle partizioni corrispondenti nel catalogo richiede tanto più tempo quanto maggiori sono le partizioni. Con la proiezione delle partizioni, il filtro può essere calcolato nella memoria senza andare al catalogo e può essere molto più veloce.

In determinate circostanze, la proiezione delle partizioni può comportare prestazioni peggiori. Un esempio in tal senso è la situazione che si presenta quando una tabella è "sparsa". Una tabella sparsa non contiene dati per tutte le permutazioni dei valori delle chiavi di partizione descritti dalla configurazione di proiezione delle partizioni. Con una tabella sparsa, il set di partizioni calcolato dalla query e la configurazione di proiezione delle partizioni sono tutti elencati su Amazon S3, anche quando non contengono dati.

Quando usi la proiezione delle partizioni, assicurati di includere i predicati su tutte le chiavi delle partizioni. Restringi l'ambito dei valori possibili per evitare elenchi Amazon S3 non necessari. Immagina una chiave di partizione con un intervallo di un milione di valori e una query che non abbia filtri su quella chiave di partizione. Per eseguire la query, Athena deve eseguire almeno un milione di operazioni sugli elenchi Amazon S3. Le query più veloci quelle eseguite su valori specifici, indipendentemente dal fatto che utilizzi la proiezione delle partizioni o memorizzi le informazioni delle partizioni nel catalogo. Per ulteriori informazioni, consulta [Partizioni di query per uguaglianza](#performance-tuning-query-partitions-by-equality).

Quando configuri una tabella per la proiezione delle partizioni, assicurati che gli intervalli specificati siano ragionevoli. Se una query non include un predicato su una chiave di partizione, tutti i valori nell'intervallo vengono utilizzati per tale chiave. Se il set di dati è stato creato in una data specifica, per qualsiasi intervallo di date utilizza quella data come punto di inizio. Utilizza `NOW` come fine degli intervalli di data. Evita gli intervalli numerici con un numero elevato di valori e considera invece l'utilizzo del tipo [injected](partition-projection-dynamic-id-partitioning.md#partition-projection-injection).

Per maggiori informazioni sulla proiezione delle partizioni, consulta [Proiezione delle partizioni con Amazon Athena](partition-projection.md).

## Utilizzo degli indici di partizioni
<a name="performance-tuning-use-partition-indexes"></a>

Gli indici di partizione sono una funzionalità AWS Glue Data Catalog che migliora le prestazioni di ricerca delle partizioni per le tabelle con un numero elevato di partizioni.

L'elenco delle partizioni nel catalogo è simile a una tabella in un database relazionale. La tabella contiene colonne per le chiavi delle partizioni e una colonna aggiuntiva per la posizione delle partizioni. Quando si esegue una query su una tabella partizionata, i percorsi delle partizioni vengono ricercati mediante la scansione di questa tabella.

Proprio come con i database relazionali, puoi aumentare le prestazioni delle query aggiungendo indici. Puoi aggiungere più indici per supportare diversi modelli di query. L'indice di AWS Glue Data Catalog partizione supporta sia gli operatori di uguaglianza che quelli di confronto`>`, come, `>=` e combinati con l'operatore. `<` `AND` *Per ulteriori informazioni, consulta [Lavorare con gli indici delle partizioni AWS Glue nella](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html) *Guida per gli AWS Glue sviluppatori* e Migliorare le [prestazioni delle query di Amazon Athena utilizzando gli indici delle AWS Glue Data Catalog partizioni](https://aws.amazon.com/blogs/big-data/improve-amazon-athena-query-performance-using-aws-glue-data-catalog-partition-indexes/) nel Big Data Blog.AWS *

## Utilizzo costante di STRING come tipo per le chiavi di partizione
<a name="performance-tuning-always-use-string-as-the-type-for-partition-keys"></a>

Quando esegui una query sulle chiavi delle partizioni, ricorda che in Athena le chiavi delle partizioni devono essere di tipo `STRING` affinché in AWS Glue sia eseguito il pushdown del filtraggio delle partizioni. Se il numero di partizioni non è basso, l'utilizzo di altri tipi può comportare prestazioni peggiori. Se i valori delle chiavi di partizione sono simili a date o numeri, convertili nel tipo appropriato della query.

## Rimozione delle partizioni vecchie e vuote
<a name="performance-tuning-remove-old-and-empty-partitions"></a>

Se rimuovi dati da una partizione su Amazon S3 (ad esempio, utilizzando il [ciclo di vita](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) di Amazon S3), devi rimuovere anche la voce della partizione da AWS Glue Data Catalog. Durante la pianificazione delle query, su Amazon S3 viene elencata qualsiasi partizione corrispondente alla query. Se hai molte partizioni vuote, il sovraccarico di elencare queste partizioni può essere dannoso.

Inoltre, se disponi di molte migliaia di partizioni, valuta la possibilità di rimuovere i metadati delle partizioni dei dati vecchi che non sono più rilevanti. Ad esempio, se le query non scansionano mai dati più vecchi di un anno, puoi rimuovere periodicamente i metadati delle partizioni più vecchie. Se il numero di partizioni aumenta fino a decine di migliaia, la rimozione delle partizioni inutilizzate può velocizzare le query che non includono predicati su tutte le chiavi delle partizioni. Per informazioni sull'inclusione dei predicati su tutte le chiavi delle partizioni nelle query, consulta [Partizioni di query per uguaglianza](#performance-tuning-query-partitions-by-equality).

## Partizioni di query per uguaglianza
<a name="performance-tuning-query-partitions-by-equality"></a>

Le query che includono i predicati di uguaglianza su tutte le chiavi delle partizioni sono eseguite più velocemente perché possono essere caricati direttamente i metadati delle partizioni. Evita le query in cui una o più chiavi di partizione sono prive di predicato o in cui il predicato seleziona un intervallo di valori. Per tali query, è necessario filtrare l'elenco di tutte le partizioni per trovare i valori corrispondenti. Per la maggior parte delle tabelle, il sovraccarico è minimo, ma per le tabelle con decine di migliaia o più di partizioni, il sovraccarico può diventare significativo.

Se non è possibile riscrivere le query per filtrare le partizioni in base all'uguaglianza, puoi provare la proiezione delle partizioni. Per ulteriori informazioni, consulta [Utilizzo della proiezione di partizioni](#performance-tuning-use-partition-projection).

## Come evitare di usare MSCK REPAIR TABLE per la manutenzione delle partizioni
<a name="performance-tuning-avoid-using-msck-repair-table-for-partition-maintenance"></a>

Poiché può richiedere molto tempo, aggiunge solo nuove partizioni e non rimuove le vecchie partizioni, l'esecuzione `MSCK REPAIR TABLE` non è un modo efficiente per gestire le partizioni (consulta [Considerazioni e limitazioni](msck-repair-table.md#msck-repair-table-considerations)).

[È meglio gestire le partizioni manualmente utilizzando, o i crawler. [AWS Glue Data Catalog APIs](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-catalog.html)[ALTER TABLE ADD PARTITION](alter-table-add-partition.md)AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/crawler-running.html) In alternativa, puoi utilizzare la proiezione delle partizioni, che rimuove del tutto il bisogno di gestire le partizioni. Per ulteriori informazioni, consulta [Proiezione delle partizioni con Amazon Athena](partition-projection.md).

## Come verificare che le query siano compatibili con lo schema di partizionamento
<a name="performance-tuning-validate-that-your-queries-are-compatible-with-the-partitioning-scheme"></a>

Puoi verificare in anticipo quali partizioni saranno scansionate da una query utilizzando la dichiarazione [`EXPLAIN`](athena-explain-statement.md). Utilizza la parola chiave `EXPLAIN` come prefisso della query, quindi cerca il frammento di origine (ad esempio `Fragment 2 [SOURCE]`) per ogni tabella nella parte inferiore dell'output `EXPLAIN`. Cerca le assegnazioni in cui il lato destro è definito come chiave di partizione. La riga sottostante include un elenco di tutti i valori per la chiave di partizione da scansionare durante l'esecuzione della query.

Ad esempio, supponi di avere una query su una tabella con una chiave di partizione `dt` e di anteporre alla query il prefisso `EXPLAIN`. Se i valori della query sono date e un filtro seleziona un intervallo di tre giorni, l'output `EXPLAIN` potrebbe essere simile a quanto segue:

```
dt := dt:string:PARTITION_KEY
    :: [[2023-06-11], [2023-06-12], [2023-06-13]]
```

L'output `EXPLAIN` mostra che il pianificatore ha trovato tre valori per questa chiave di partizione corrispondenti alla query. Ti mostra anche quali sono questi valori. Per ulteriori informazioni sull'utilizzo di `EXPLAIN` consulta [Utilizzo di EXPLAIN e EXPLAIN ANALYZE in Athena](athena-explain-statement.md) e [Capire i risultati dell’istruzione EXPLAIN di Athena](athena-explain-statement-understanding.md).

## Utilizzo di formati di file colonnari
<a name="performance-tuning-use-columnar-file-formats"></a>

I formati di file colonnari come Parquet e ORC sono concepiti per carichi di lavoro di analisi distribuiti. Tali formati organizzano i dati per colonna anziché per riga. L'organizzazione dei dati in formato colonnare presenta i seguenti vantaggi:
+ Vengono caricate solo le colonne necessarie alla query
+ La quantità complessiva di dati da caricare è ridotta
+ I valori delle colonne sono memorizzati insieme, così i dati possono essere compressi in modo efficiente 
+ I file possono contenere metadati che consentono al motore di evitare il caricamento di dati non necessari

Un esempio del possibile utilizzo dei metadati dei file è il fatto che questi possano contenere informazioni sui valori minimi e massimi in una pagina di dati. Se i valori richiesti non rientrano nell'intervallo indicato nei metadati, la pagina può essere saltata.

Un modo per utilizzare questi metadati per migliorare le prestazioni consiste nell'assicurare che i dati all'interno dei file vengano ordinati. Ad esempio, supponi di avere delle query che cercano i record la cui voce `created_at` rientra in un breve intervallo di tempo. Se i dati sono ordinati per colonna `created_at`, Athena può utilizzare i valori minimi e massimi nei metadati del file per ignorare le parti non necessarie dei file di dati.

Quando utilizzi formati di file colonnari, assicurati che i file non siano di dimensioni troppo piccole. Come indicato in [Come evitare di avere un numero eccessivo di file](#performance-tuning-avoid-having-too-many-files), i set di dati con molti file di piccole dimensioni comportano problemi di prestazioni. Ciò è particolarmente vero con i formati di file colonnari. Per i file di piccole dimensioni, è più importante il sovraccarico del formato di file colonnari rispetto ai vantaggi.

Nota che Parquet e ORC sono organizzati internamente per gruppi di file (Parquet) e stripe (ORC). La dimensione predefinita per i gruppi di righe è pari a 128 MB e per le stripe è pari a 64 MB. Se hai molte colonne, puoi aumentare il gruppo di righe e le dimensioni delle stripe per migliorare le prestazioni. Non è consigliabile ridurre la dimensione del gruppo di righe o di stripe a un valore inferiore a quelli predefiniti.

Per convertire altri formati di dati in Parquet o ORC, puoi usare AWS Glue ETL o Athena. Per ulteriori informazioni, consulta [Converti in formati colonnari](columnar-storage.md#convert-to-columnar).

## Compressione di dati
<a name="performance-tuning-compress-data"></a>

Athena supporta un'ampia serie di formati di compressione. L'esecuzione di query su dati compressi è più veloce e anche più economica perché i costi sono commisurati al numero di byte scansionati prima della decompressione.

Il formato [gzip](https://www.gnu.org/software/gzip/) offre buoni rapporti di compressione e supporta molti altri strumenti e servizi. Il formato [zstd](https://facebook.github.io/zstd/) (Zstandard) è un formato di compressione più recente con un buon equilibrio tra prestazioni e rapporto di compressione.

Quando comprimi file di testo come dati JSON e CSV, cerca di mantenere un equilibrio tra il numero di file e la dimensione di questi. Per la maggior parte dei formati di compressione è necessario che il lettore legga i file dall'inizio. In generale, ciò significa che i file di testo compressi non possono essere elaborati in parallelo. I file non compressi di grandi dimensioni sono spesso suddivisi tra i worker per avere maggiore parallelismo durante l'elaborazione delle query, ma ciò non è possibile con la maggior parte dei formati di compressione.

Come detto in [Come evitare di avere un numero eccessivo di file](#performance-tuning-avoid-having-too-many-files), è preferibile non avere né un numero di file troppo alto né troppo basso. Poiché il numero di file rappresenta il limite del numero di lavoratori che possono elaborare la query, questa regola è particolarmente vera per i file compressi.

Per ulteriori informazioni sull'utilizzo della compressione in Athena, consulta [Usa la compressione in Athena](compression-formats.md).

## Come utilizzare il raggruppamento in bucket delle ricerche su chiavi con cardinalità elevata
<a name="performance-tuning-use-bucketing-for-lookups-on-keys-with-high-cardinality"></a>

Il raggruppamento in bucket è una tecnica per distribuire i record in file separati in base al valore di una delle colonne. Questo modo garantisce che tutti i record con lo stesso valore si trovino nello stesso file. Il raggruppamento in bucket è utile quando hai una chiave con cardinalità elevata e quando molte delle query cercano valori specifici della chiave.

Ad esempio, supponi di eseguire una query su un set di record per un utente specifico. Se i dati sono raggruppati in bucket in base all'ID utente, Athena per un ID specifico conosce in anticipo quali file contengono record e quali file no. Ciò consente ad Athena di leggere solo i file che possono contenere l'ID, riducendo notevolmente la quantità di dati letta. Inoltre, ciò riduce il tempo di elaborazione che altrimenti sarebbe necessario per cercare l'ID specifico tra i dati.

### Evita il raggruppamento in bucket quando le query cercano spesso diversi valori in una colonna
<a name="performance-tuning-disadvantages-of-bucketing"></a>

Il raggruppamento in bucket è meno utile quando le query cercano spesso diversi valori nella colonna del bucket in cui sono raggruppati i dati. Maggiore è il numero di valori richiesti, maggiore è la probabilità che tutti o la maggior parte dei file debbano essere letti. Ad esempio, se hai tre bucket e una query cerca tre valori diversi, potrebbe essere necessario leggere tutti i file. Il raggruppamento in bucket funziona meglio quando le query cercano valori singoli.

Per ulteriori informazioni, consulta [Utilizzare partizionamento e bucketing](ctas-partitioning-and-bucketing.md).

## Come evitare di avere un numero eccessivo di file
<a name="performance-tuning-avoid-having-too-many-files"></a>

I set di dati composti da molti file di piccole dimensioni comportano prestazioni complessive delle query scadenti. Athena, quando pianifica una query, elenca tutte i percorsi delle partizioni, operazione che richiede tempo. La gestione e la richiesta di ogni file comportano anche un sovraccarico computazionale. Pertanto, il caricamento di un singolo file di dimensioni maggiori da Amazon S3 è più veloce rispetto al caricamento degli stessi record da molti file di dimensioni minori.

In casi estremi, potresti incontrare dei limiti al servizio Amazon S3. Amazon S3 supporta fino a 5.500 richieste al secondo su una singola partizione di indice. Inizialmente, un bucket viene trattato come una singola partizione di indice, ma all'aumentare del carico delle richieste, può essere suddiviso in più partizioni di indice.

Amazon S3 esamina i modelli di richiesta e le suddivisioni in base ai prefissi delle chiavi. Se il set di dati è composto da molte migliaia di file, le richieste provenienti da Athena possono superare la quota delle richieste. Anche con un numero inferiore di file, la quota può essere superata se vengono eseguite più query simultanee sullo stesso set di dati. Altre applicazioni che accedono agli stessi file possono contribuire al numero totale di richieste.

Quando la frequenza di richiesta `limit` viene superata, Amazon S3 restituisce il seguente errore. Questo errore è incluso in Athena nelle informazioni sullo stato della query.

 SlowDown: Riduci il tasso di richiesta 

Per risolvere il problema, stabilisci innanzitutto se l'errore è provocato da una singola query o da più query che leggono gli stessi file. In quest'ultimo caso, coordina l'esecuzione delle query in modo che queste non vengano eseguite contemporaneamente. A tale scopo, aggiungi un meccanismo di accodamento o ritenta l'applicazione.

Se l'esecuzione di una singola query provoca l'errore, prova a combinare file di dati o a modificare la query per leggere un numero inferiore di file. Il momento migliore per combinare file di piccole dimensioni è prima che questi vengano scritti. A tal fine, tieni conto delle seguenti tecniche:
+ Modifica il processo di scrittura dei file per scrivere file di maggiori dimensioni. Ad esempio, puoi memorizzare i record nel buffer per un periodo più lungo prima che siano scritti. 
+ Memorizza i file in un percorso su Amazon S3 e utilizza uno strumento come Glue ETL per combinarli in file più grandi. Quindi, sposta i file più grandi nel percorso a cui punta la tabella. Per ulteriori informazioni, consulta [Leggere i file di input in gruppi più grandi](https://docs.aws.amazon.com/glue/latest/dg/grouping-input-files.html) nella *Guida per gli AWS Glue sviluppatori* e [Come posso configurare un processo AWS Glue ETL per generare file più grandi](https://repost.aws/knowledge-center/glue-job-output-large-files)? nel Knowledge Center *AWS di re:POST*.
+ Riduzione del numero di chiavi di partizione. Quando hai troppe chiavi di partizione, ogni partizione potrebbe avere solo pochi record, il che comporta un numero eccessivo di file di piccole dimensioni. Per informazioni su come stabilire quali partizioni creare, consulta [Scegli le chiavi di partizione che supporteranno le query](#performance-tuning-pick-partition-keys-that-will-support-your-queries).

## Come evitare gerarchie di archiviazione aggiuntive oltre alla partizione
<a name="performance-tuning-avoid-additional-storage-hierarchies-beyond-the-partition"></a>

Per evitare un sovraccarico determinato dalla pianificazione delle query, archivia i file in una struttura piatta in ogni percorso della partizione. Non utilizzare gerarchie di directory aggiuntive.

Athena, quando pianifica una query, elenca tutti i file in tutte le partizioni corrispondenti alla query. Sebbene Amazon S3 non disponga di directory di per sé, la convenzione prevede di interpretare la barra `/` come un separatore di directory. Athena, quando elenca le posizioni delle partizioni, elenca in modo ricorsivo tutte le directory individuate. Quando i file all'interno di una partizione sono organizzati in una gerarchia, si verificano più cicli di elenchi.

Quando tutti i file si trovano direttamente nel percorso della partizione, nella maggior parte dei casi è sufficiente eseguire una sola operazione sull'elenco. Tuttavia, se hai più di 1000 file in una partizione, sono necessarie più operazioni di elenco sequenziali perché Amazon S3 restituisce solo 1000 oggetti per operazione di elenco. La presenza di più di 1000 file in una partizione può creare anche altri problemi di prestazioni, più gravi. Per ulteriori informazioni, consulta [Come evitare di avere un numero eccessivo di file](#performance-tuning-avoid-having-too-many-files). 

## Utilizzo di SymlinkTextInputFormat solo quando necessario
<a name="performance-tuning-use-symlinktextinputformat-only-when-necessary"></a>

L'utilizzo della tecnica [https://athena.guide/articles/stitching-tables-with-symlinktextinputformat](https://athena.guide/articles/stitching-tables-with-symlinktextinputformat) può essere un modo per aggirare le situazioni in cui i file di una tabella non sono organizzati in modo ordinato in partizioni. Ad esempio, i symlink possono essere utili quando tutti i file hanno lo stesso prefisso o quando i file con schemi diversi si trovano nella stessa posizione.

Tuttavia, l'utilizzo dei symlink aggiunge livelli di riferimenti indiretti all'esecuzione della query. Questi livelli di rifirimenti indiretti influiscono sulle prestazioni complessive. I file symlink devono essere letti e le posizioni che definiscono devono essere elencate. Ciò aggiunge diversi round trip ad Amazon S3 che le normali tabelle Hive non richiedono. In conclusione, dovresti utilizzare `SymlinkTextInputFormat` solo quando non sono disponibili opzioni migliori come la riorganizzazione dei file.

# Usa formati di archiviazione colonnare
<a name="columnar-storage"></a>

[Apache Parquet](https://parquet.apache.org) e [ORC](https://orc.apache.org/) sono formati di archiviazione colonnari ottimizzati per il recupero rapido dei dati e utilizzati nelle applicazioni analitiche. AWS 

I formati di archiviazione colonnare presentano le seguenti caratteristiche, che li rendono ideali per l'utilizzo con Athena: 
+ *Compressione per colonna, con algoritmo di compressione selezionato per il tipo di dati della colonna* per risparmiare spazio di archiviazione in Amazon S3 e ridurre lo spazio su disco e I/O durante l'elaborazione delle query.
+ *Pushdown dei predicati* in Parquet e ORC, che consente alle query Athena di recuperare solo i blocchi necessari migliorandone così le prestazioni. Quando una query Athena ottiene valori di colonna specifici dai dati, utilizza le statistiche dei predicati dei blocchi di dati, come i max/min valori, per determinare se leggere o ignorare il blocco. 
+ *Frazionamento dei dati* in Parquet e ORC, che consente ad Athena di frazionare la lettura dei dati su più lettori e aumentare il parallelismo durante l'elaborazione delle query. 

Per convertire i dati grezzi esistenti da altri formati di archiviazione in Parquet o ORC, puoi eseguire le query [CREATE TABLE AS SELECT (CTAS)](ctas.md) in Athena e specificare un formato di archiviazione dei dati come Parquet o ORC, oppure utilizzare il Crawler. AWS Glue 

## Scegli tra Parquet e ORC
<a name="columnar-storage-choosing"></a>

La scelta tra ORC (Optimized Row Columnar) e Parquet dipende dai requisiti di uso specifico.

Apache Parquet offre efficienti schemi di compressione e codifica dei dati ed è ideale per eseguire query complesse ed elaborare grandi quantità di dati. Parquet è ottimizzato per l'uso con [Apache Arrow](https://arrow.apache.org/), il che può essere vantaggioso se utilizzi strumenti correlati ad Arrow.

ORC offre un modo efficiente per archiviare i dati Hive. I file ORC sono spesso di dimensioni inferiori rispetto ai file Parquet e gli indici ORC possono velocizzare l'esecuzione di query. Inoltre, ORC supporta tipi complessi come strutture, mappe ed elenchi.

Quando scegli tra Parquet e ORC, valuta quanto segue:

**Prestazioni delle query**: poiché Parquet supporta una serie più ampia di tipi di query, Parquet potrebbe essere la scelta migliore se intendi eseguire query complesse. 

**Tipi di dati complessi**: se utilizzi tipi di dati complessi, ORC potrebbe essere la scelta migliore in quanto supporta una serie più ampia di tipi di dati complessi.

**Dimensioni dei file**: se lo spazio su disco è un problema, ORC di solito produce file di dimensioni inferiori, il che può ridurre i costi di archiviazione.

**Compressione**: sia Parquet sia ORC offrono una buona compressione, ma il formato migliore per te può dipendere dal caso d'uso specifico.

**Evoluzione**: sia Parquet che ORC supportano l'evoluzione di schema, il che significa che puoi aggiungere, rimuovere o modificare colonne nel tempo.

Sia Parquet che ORC sono buone scelte per le applicazioni di big data, ma valuta i requisiti del tuo scenario prima di prendere una decisione. Puoi eseguire benchmark sui tuoi dati e sulle tue query per stabilire quale formato offre prestazioni migliori per il tuo caso d'uso.

## Converti in formati colonnari
<a name="convert-to-columnar"></a>

Le opzioni per convertire facilmente i dati di origine come JSON o CSV in un formato colonnare includono l'utilizzo di query [CREATE TABLE AS](ctas.md) o l'esecuzione di processi in AWS Glue.
+ È possibile utilizzare query `CREATE TABLE AS` (CTAS) per convertire i dati in Parquet o ORC in un unico passaggio. Per un esempio, consulta [Esempio: scrittura di risultati della query in un formato diverso](https://docs.aws.amazon.com/athena/latest/ug/ctas-examples.html#ctas-example-format) nella pagina [Esempi di query CTAS](ctas-examples.md).
+ Per informazioni sull’utilizzo di Athena per ETL per trasformare i dati da CSV a Parquet, consultare [Utilizzare CTAS e INSERT INTO per ETL e analisi dei dati](ctas-insert-into-etl.md). 
+ Per informazioni sull'esecuzione di un AWS Glue processo per trasformare i dati CSV in Parquet, consulta la sezione «Trasformare i dati dal formato CSV al formato Parquet» nel post del blog AWS Big Data [Build a data lake foundation with AWS Glue and Amazon S3](https://aws.amazon.com/blogs/big-data/build-a-data-lake-foundation-with-aws-glue-and-amazon-s3/). AWS Glue supporta l'utilizzo della stessa tecnica per convertire i dati CSV in ORC o i dati JSON in Parquet o ORC.

# Utilizzare partizionamento e bucketing
<a name="ctas-partitioning-and-bucketing"></a>

Il partizionamento e il raggruppamento in bucket sono due modi per ridurre la quantità di dati che Athena deve scansionare quando si esegue una query. Il partizionamento e il raggruppamento in bucket sono complementari e possono essere utilizzati insieme. La riduzione della quantità di dati scansionati comporta un miglioramento delle prestazioni e una riduzione dei costi. Per le linee guida generali sulle prestazioni delle query Athena, consulta [Suggerimenti di ottimizzazione delle prestazioni in Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/).

**Topics**
+ [Cos'è il partizionamento?](ctas-partitioning-and-bucketing-what-is-partitioning.md)
+ [Cos'è il raggruppamento in bucket?](ctas-partitioning-and-bucketing-what-is-bucketing.md)
+ [Risorse aggiuntive](ctas-partitioning-and-bucketing-additional-resources.md)

# Cos'è il partizionamento?
<a name="ctas-partitioning-and-bucketing-what-is-partitioning"></a>

Il partizionamento significa organizzare i dati in directory (o «prefissi») su Amazon S3 in base a una particolare proprietà dei dati. Tali proprietà sono chiamate chiavi di partizione. Una chiave di partizione comune è la data o un'altra unità di tempo come l'anno o il mese. Tuttavia, un set di dati può essere partizionato in base a più di una chiave. Ad esempio, i dati sulle vendite di prodotti potrebbero essere suddivisi per data, categoria di prodotto e mercato.

## Decidere come partizionare
<a name="ctas-partitioning-and-bucketing-deciding-how-to-partition"></a>

Elementi adatti a essere utilizzati come chiavi di partizione sono le proprietà che vengono utilizzate sempre o frequentemente nelle query e hanno una cardinalità bassa. Esiste un compromesso tra l'avere troppe partizioni e l'averne troppo poche. Con troppe partizioni, l'aumento del numero di file crea un sovraccarico. Inoltre, il filtraggio delle partizioni stesse comporta un certo sovraccarico. Con un numero insufficiente di partizioni, le query spesso devono scansionare più dati.

## Creare una tabella partizionata
<a name="ctas-partitioning-and-bucketing-creating-a-partitioned-table"></a>

Quando un set di dati viene partizionato, puoi creare una tabella partizionata in Athena. Una tabella partizionata è una tabella con chiavi di partizione. Quando utilizzi `CREATE TABLE`, aggiungi delle partizioni alla tabella. Quando utilizzi `CREATE TABLE AS`, le partizioni create su Amazon S3 vengono aggiunte automaticamente alla tabella.

In una dichiarazione `CREATE TABLE`, specifica le chiavi di partizione nella clausola `PARTITIONED BY (column_name data_type)`. In un'istruzione `CREATE TABLE AS`, si specificano le chiavi di partizione in una clausola `WITH (partitioned_by = ARRAY['partition_key'])` o `WITH (partitioning = ARRAY['partition_key'])` per le tabelle Iceberg. Per motivi di prestazioni, le chiavi di partizione devono essere sempre di tipo `STRING`. Per ulteriori informazioni, consulta [Usa string come tipo di dati per le chiavi di partizione](data-types-timestamps.md#data-types-timestamps-partition-key-types).

Per ulteriori dettagli sulla sintassi di `CREATE TABLE` e `CREATE TABLE AS`, consulta [CREATE TABLE](create-table.md) e [Proprietà tabella CTAS](create-table-as.md#ctas-table-properties).

## Eseguire query su tabelle partizionate
<a name="ctas-partitioning-and-bucketing-querying-partitioned-tables"></a>

Quando esegui una query su una tabella partizionata, Athena utilizza i predicati della query per filtrare l'elenco delle partizioni. Quindi utilizza le posizioni delle partizioni corrispondenti per elaborare i file trovati. Athena può ridurre in modo efficiente la quantità di dati analizzati semplicemente non leggendo i dati nelle partizioni che non corrispondono ai predicati delle query.

### Esempi
<a name="ctas-partitioning-and-bucketing-partitioned-table-example-queries"></a>

Supponi di avere una tabella partizionata per `sales_date` e `product_category` e di voler conoscere le entrate totali nell'arco di una settimana in una categoria specifica. Includi i predicati nelle colonne `product_category` e `sales_date` per assicurarti che Athena analizzi solo la quantità minima di dati, come nell'esempio seguente.

```
SELECT SUM(amount) AS total_revenue 
FROM sales 
WHERE sales_date BETWEEN '2023-02-27' AND '2023-03-05' 
AND product_category = 'Toys'
```

Supponi di avere un set di dati partizionato per data ma che abbia anche un timestamp dettagliato.

Con le tabelle Iceberg, puoi dichiarare che una chiave di partizione ha una relazione con una colonna, ma con le tabelle Hive il motore di query non conosce le relazioni tra colonne e chiavi di partizione. Per questo motivo, è necessario includere un predicato sia sulla colonna che sulla chiave di partizione nella query per assicurarsi che la query non analizzi più dati del necessario.

Ad esempio, supponi che la tabella `sales` dell'esempio precedente contenga anche una colonna `sold_at` del tipo di dati `TIMESTAMP`. Se desideri le entrate solo per un intervallo di tempo specifico, devi scrivere la query in questo modo:

```
SELECT SUM(amount) AS total_revenue 
FROM sales 
WHERE sales_date = '2023-02-28' 
AND sold_at BETWEEN TIMESTAMP '2023-02-28 10:00:00' AND TIMESTAMP '2023-02-28 12:00:00' 
AND product_category = 'Toys'
```

Per ulteriori informazioni su questa differenza tra le query delle tabelle Hive e Iceberg, consulta [Come scrivere query per campi timestamp che sono anche partizionati in base all'ora](data-types-timestamps.md#data-types-timestamps-how-to-write-queries-for-timestamp-fields-that-are-also-time-partitioned).

# Cos'è il raggruppamento in bucket?
<a name="ctas-partitioning-and-bucketing-what-is-bucketing"></a>

Il raggruppamento in bucket è un modo per organizzare i record di un set di dati in categorie chiamate bucket.

Questo significato di bucket and raggruppamento in bucket è diverso e non deve essere confuso con i bucket Amazon S3. Nel bucket di dati, i record che hanno lo stesso valore per una proprietà vengono inseriti nello stesso bucket. I record vengono distribuiti nel modo più uniforme possibile tra i bucket in modo che ogni bucket contenga all'incirca la stessa quantità di dati.

In pratica, i bucket sono file e una funzione hash determina il bucket in cui va inserito un record. Un set di dati con bucket avrà uno o più file per bucket per partizione. Il bucket a cui appartiene un file è codificato nel nome del file.

## Vantaggi del raggruppamento in bucket
<a name="ctas-partitioning-and-bucketing-bucketing-benefits"></a>

Il raggruppamento in bucket è utile quando un set di dati è inserito in un bucket in base a una determinata proprietà e si desidera recuperare i record in cui tale proprietà ha un determinato valore. Poiché i dati sono raggruppati in un bucket, Athena può utilizzare il valore per determinare quali file guardare. Ad esempio, supponi che un set di dati sia suddiviso in bucket in base a `customer_id` e che tu voglia trovare tutti i record di un cliente specifico. Athena determina il bucket che contiene tali record e legge solo i file in quel bucket.

I buoni candidati per il raggruppamento in bucket si presentano quando si hanno colonne con cardinalità elevata (ovvero molti valori distinti), sono distribuite uniformemente e vengono spesso eseguite interrogazioni per valori specifici.

**Nota**  
Athena non supporta l'utilizzo di `INSERT INTO` per aggiungere nuovi record alle tabelle bloccate.

## Tipi di dati supportati per il filtro su colonne con bucket
<a name="ctas-partitioning-and-bucketing-data-types-supported-for-filtering-on-bucketed-columns"></a>

Puoi aggiungere filtri su colonne separate con determinati tipi di dati. Athena supporta il filtraggio solo su colonne raggruppate per bucket con i seguenti tipi di dati:
+ BOOLEAN
+ BYTE
+ DATE
+ DOUBLE
+ FLOAT
+ INT
+ LONG
+ SHORT
+ STRING
+ VARCHAR

## Supporto per Hive e Spark
<a name="ctas-partitioning-and-bucketing-hive-and-spark-support"></a>

La versione 2 del motore Athena supporta i set di dati raggruppati utilizzando l'algoritmo bucket Hive e la versione 3 del motore Athena supporta anche l'algoritmo di raggruppamento in bucket Apache Spark. L'impostazione predefinita è il raggruppamento in bucket Hive. Se il tuo set di dati è raggruppato in bucket tramite l'algoritmo Spark, utilizza la clausola `TBLPROPERTIES` per impostare il valore della proprietà `bucketing_format` su `spark`.

**Nota**  
Athena ha un limite di 100 partizioni per query `CREATE TABLE AS SELECT` ([CTAS](ctas.md)). Allo stesso modo, puoi aggiungere un massimo di 100 partizioni a una tabella di destinazione con una dichiarazione [INSERT INTO](insert-into.md).  
Se superi questa limitazione potresti ricevere il messaggio di errore HIVE\$1TOO\$1MANY\$1OPEN\$1PARTITIONS: Exceeded limit of 100 open writers for partitions/buckets (HIVE\$1TOO\$1MANY\$1OPEN\$1PARTITIONS: limite di 100 scrittori aperti per partizioni/bucket superato). Per ovviare questa limitazione, puoi utilizzare un'istruzione CTAS e una serie di istruzioni `INSERT INTO` che creano o inseriscono fino a 100 partizioni ciascuna. Per ulteriori informazioni, consulta [Utilizzare CTAS e INSERT INTO per aggirare il limite di 100 partizioni](ctas-insert-into.md).

## Esempio di raggruppamento in bucket di CREATE TABLE
<a name="ctas-partitioning-and-bucketing-bucketing-create-table-example"></a>

Per creare una tabella per un set di dati raggruppato in bucket esistenti, utilizza la clausola `CLUSTERED BY (column)` seguita dalla clausola `INTO N BUCKETS`. La clausola `INTO N BUCKETS` specifica il numero di bucket in cui sono inseriti i dati.

Nell'esempio `CREATE TABLE` seguente, il set di dati `sales` viene suddiviso in 8 bucket in base a `customer_id` attraverso l'algoritmo Spark. L'istruzione `CREATE TABLE` utilizza le clausole `CLUSTERED BY` e `TBLPROPERTIES` per impostare le proprietà di conseguenza.

```
CREATE EXTERNAL TABLE sales (...) 
... 
CLUSTERED BY (`customer_id`) INTO 8 BUCKETS 
... 
TBLPROPERTIES ( 
  'bucketing_format' = 'spark' 
)
```

## Esempio di raggruppamento in bucket di CREATE TABLE AS (CTAS)
<a name="ctas-partitioning-and-bucketing-bucketing-create-table-as-example"></a>

Per specificare il raggruppamento in bucket with`CREATE TABLE AS`, utilizzate i `bucket_count` parametri `bucketed_by` and, come nell'esempio seguente.

```
CREATE TABLE sales 
WITH ( 
  ... 
  bucketed_by = ARRAY['customer_id'], 
  bucket_count = 8 
) 
AS SELECT ...
```

## Esempio di query bucketing
<a name="ctas-partitioning-and-bucketing-bucketing-query-example"></a>

La seguente query di esempio cerca i nomi dei prodotti che un cliente specifico ha acquistato nel corso di una settimana.

```
SELECT DISTINCT product_name 
FROM sales 
WHERE sales_date BETWEEN '2023-02-27' AND '2023-03-05' 
AND customer_id = 'c123'
```

Se questa tabella è partizionata in base a `sales_date` e raggruppata in bucket in base a `customer_id`, Athena può calcolare il bucket in cui si trovano i record dei clienti. Al massimo, Athena legge un file per partizione.

# Risorse aggiuntive
<a name="ctas-partitioning-and-bucketing-additional-resources"></a>
+ Per un esempio di `CREATE TABLE AS` che crea tabelle sia partizionate sia raggruppate nei bucket, consulta [Esempio: creazione di tabelle raggruppate in bucket e partizionate](https://docs.aws.amazon.com/athena/latest/ug/ctas-examples.html#ctas-example-bucketed).
+ Per informazioni sull'implementazione del bucketing sui AWS data lake, incluso l'utilizzo di un'istruzione Athena CTAS AWS Glue , per Apache Spark e del bucketing per le tabelle Apache Iceberg, consulta AWS il post sul blog Big Data Optimize data [layout by bucketing with](https://aws.amazon.com/blogs/big-data/optimize-data-layout-by-bucketing-with-amazon-athena-and-aws-glue-to-accelerate-downstream-queries/) Amazon Athena and to accelerate downstream. AWS Glue 

# Come partizionare i dati
<a name="partitions"></a>

Effettuando il partizionamento dei dati, è possibile limitare la quantità di dati scansionati da ogni query, migliorando così le prestazioni e riducendo i costi. in base a qualsiasi chiave di partizione. In genere è consigliabile partizionare i dati in base al tempo, spesso determinando uno schema di partizionamento multilivello. Ad esempio, un cliente che ha dati in entrata ogni ora potrebbe decidere di partizione per anno, mese, data e ora. Un altro cliente che ha dati provenienti da diverse origini ma che vengono caricati una volta al giorno, potrebbe eseguire la partizione in base all'identificatore dell'origine dati e alla data.

Athena può utilizzare partizioni in stile Apache Hive, i cui percorsi di dati contengono coppie chiave-valore collegate da simboli di uguale (ad esempio, `country=us/...` o `year=2021/month=01/day=26/...`). Pertanto, i percorsi includono sia i nomi delle chiavi di partizione che i valori rappresentati da ciascun percorso. Per caricare nuove partizioni Hive in una tabella partizionata, è possibile utilizzare il comando [MSCK REPAIR TABLE](msck-repair-table.md), che funziona solo con partizioni in stile Hive.

Athena può utilizzare anche schemi di partizionamento in stile non Hive. Ad esempio, CloudTrail i log e i flussi di consegna Firehose utilizzano componenti di percorso separati per parti di data come. `data/2021/01/26/us/6fc7845e.json` Per le partizioni non in stile Hive, è possibile usare [ALTER TABLE ADD PARTITION](alter-table-add-partition.md) per aggiungere manualmente le partizioni.

## Considerazioni e limitazioni
<a name="partitions-considerations-limitations"></a>

Quando si utilizza il partizionamento, tenere presente i seguenti punti:
+ Se esegui una query su una tabella partizionata e specifichi la partizione nella clausola `WHERE`, Athena analizza i dati solo da quella partizione.
+ Se si esegue le query sui bucket Amazon S3 con un numero elevato di oggetti e i dati non sono partizionati, queste query possono influenzare i limiti del tasso di richieste `GET` in Amazon S3 e comportare eccezioni Amazon S3. Per evitare errori, partiziona i dati. Inoltre, considera di ottimizzare i tassi di richiesta Amazon S3. Per maggiori informazioni, consulta le [Best practice per la creazione di modelli: ottimizzazione delle prestazioni di Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/request-rate-perf-considerations.html).
+ Le posizioni delle partizioni da utilizzare con Athena devono utilizzare il protocollo `s3` (ad esempio, `s3://amzn-s3-demo-bucket/folder/`). In Athena, i percorsi che utilizzano altri protocolli (ad esempio, `s3a://amzn-s3-demo-bucket/folder/`) determineranno errori quando le query `MSCK REPAIR TABLE` vengono eseguite sulle tabelle contenenti. 
+ Assicurarsi che il percorso Amazon S3 sia in minuscolo invece che in camel case (ad esempio, `userid` invece di `userId`) Se il percorso S3 è in camel case, `MSCK REPAIR TABLE` non aggiunge le partizioni a AWS Glue Data Catalog. Per ulteriori informazioni, consulta [MSCK REPAIR TABLE](msck-repair-table.md).
+ Poiché `MSCK REPAIR TABLE` analizza sia una cartella che le relative sottocartelle per trovare uno schema di partizioni corrispondente, assicurarsi di conservare i dati per tabelle separate in gerarchie di cartelle separate. Supponiamo ad esempio che tu abbia dati per la tabella 1 in `s3://amzn-s3-demo-bucket1` e dati per la tabella 2 in `s3://amzn-s3-demo-bucket1/table-2-data`. Se entrambe le tabelle sono partizionate per stringa, `MSCK REPAIR TABLE` aggiungerà le partizioni per la tabella 2 alla tabella 1. Per evitare ciò, si consiglia di utilizzare invece strutture di cartelle separate come `s3://amzn-s3-demo-bucket1` e `s3://amzn-s3-demo-bucket2`. Questo comportamento è coerente con Amazon EMR e Apache Hive.
+ Se utilizzi il AWS Glue Data Catalog con Athena, consulta [AWS Glue endpoint e quote per le quote](https://docs.aws.amazon.com/general/latest/gr/glue.html) di servizio sulle partizioni per account e per tabella. 
  + Sebbene Athena supporti l'interrogazione di AWS Glue tabelle con 10 milioni di partizioni, Athena non è in grado di leggere più di 1 milione di partizioni in una singola scansione. In tali scenari, l'indicizzazione delle partizioni può essere utile. Per ulteriori informazioni, consulta l'articolo del blog AWS Big Data [Migliora le prestazioni delle query di Amazon Athena utilizzando gli indici di AWS Glue Data Catalog partizione](https://aws.amazon.com/blogs/big-data/improve-amazon-athena-query-performance-using-aws-glue-data-catalog-partition-indexes/).
+ Per richiedere un aumento della quota delle partizioni se utilizzi il AWS Glue Data Catalog, visita la console [Service Quotas](https://console.aws.amazon.com/servicequotas/home?region=us-east-1#!/services/glue/quotas) per. AWS Glue

## Creazione e caricamento di una tabella con dati partizionati
<a name="partitions-creating-loading"></a>

Per creare una tabella con partizioni, utilizzare la clausola `PARTITIONED BY` nell'istruzione [CREATE TABLE](create-table.md). La clausola `PARTITIONED BY` definisce le chiavi su cui partizionare i dati, come nell'esempio seguente. La clausola `LOCATION` specifica la posizione principale dei dati partizionati.

```
CREATE EXTERNAL TABLE users (
first string,
last string,
username string
)
PARTITIONED BY (id string)
STORED AS parquet
LOCATION 's3://amzn-s3-demo-bucket'
```

Dopo aver creato la tabella, è possibile caricare i dati nelle partizioni per l'interrogazione. Per le partizioni stile Hive, esegui [MSCK REPAIR TABLE](msck-repair-table.md). Per le partizioni in stile non Hive, utilizza [ALTER TABLE ADD PARTITION](alter-table-add-partition.md) per aggiungere manualmente le partizioni.

## Preparazione di dati in stile Hive e in stile non Hive per le query
<a name="partitions-preparing-data"></a>

Nelle sezioni seguenti viene illustrato come preparare i dati in stile Hive e non Hive per le query in Athena.

### Scenario 1: dati archiviati su Amazon S3 in formato Hive
<a name="scenario-1-data-already-partitioned-and-stored-on-s3-in-hive-format"></a>

In questo scenario, le partizioni vengono archiviate in cartelle separate in Amazon S3. Ad esempio, ecco l'elenco parziale di campioni e impressioni prodotti dal comando [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3/ls.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3/ls.html), che elenca gli oggetti S3 con un prefisso specificato:

```
aws s3 ls s3://elasticmapreduce/samples/hive-ads/tables/impressions/

    PRE dt=2009-04-12-13-00/
    PRE dt=2009-04-12-13-05/
    PRE dt=2009-04-12-13-10/
    PRE dt=2009-04-12-13-15/
    PRE dt=2009-04-12-13-20/
    PRE dt=2009-04-12-14-00/
    PRE dt=2009-04-12-14-05/
    PRE dt=2009-04-12-14-10/
    PRE dt=2009-04-12-14-15/
    PRE dt=2009-04-12-14-20/
    PRE dt=2009-04-12-15-00/
    PRE dt=2009-04-12-15-05/
```

Qui, i log vengono archiviati con il nome di colonna (dt) impostato in modo corrispondente a incrementi di giorno, ora e minuto. Quando si assegna un DDL con il percorso della cartella padre, lo schema e il nome della colonna partizionata, Athena è in grado di eseguire query sui dati in quelle sottocartelle.

#### Creazione della tabella
<a name="creating-a-table"></a>

Per creare una tabella da questi dati, creare una partizione insieme a 'dt' come nella seguente istruzione DDL di Athena:

```
CREATE EXTERNAL TABLE impressions (
    requestBeginTime string,
    adId string,
    impressionId string,
    referrer string,
    userAgent string,
    userCookie string,
    ip string,
    number string,
    processId string,
    browserCookie string,
    requestEndTime string,
    timers struct<modelLookup:string, requestTime:string>,
    threadId string,
    hostname string,
    sessionId string)
PARTITIONED BY (dt string)
ROW FORMAT  serde 'org.apache.hive.hcatalog.data.JsonSerDe'
LOCATION 's3://elasticmapreduce/samples/hive-ads/tables/impressions/' ;
```

Questa tabella utilizza il serializzatore/deserializzatore JSON nativo di Hive per leggere i dati JSON archiviati in Amazon S3. Per ulteriori informazioni sui formati supportati, consulta [Scegli un file SerDe per i tuoi dati](supported-serdes.md).

#### Esecuzione di MSCK REPAIR TABLE
<a name="run-msck-repair-table"></a>

Dopo aver eseguito la query `CREATE TABLE`, eseguire il comando `MSCK REPAIR TABLE` nell'editor di query Athena per caricare le partizioni, come nell'esempio seguente.

```
MSCK REPAIR TABLE impressions
```

Una volta eseguito il comando, i dati sono pronti per l'esecuzione della query.

#### Esecuzione di query sui dati
<a name="query-the-data"></a>

Eseguire la query sui dati dalla tabella di impressioni utilizzando la colonna di partizione. Ecco un esempio:

```
SELECT dt,impressionid FROM impressions WHERE dt<'2009-04-12-14-00' and dt>='2009-04-12-13-00' ORDER BY dt DESC LIMIT 100
```

Questa query dovrebbe restituire risultati simili ai seguenti:

```
2009-04-12-13-20    ap3HcVKAWfXtgIPu6WpuUfAfL0DQEc
2009-04-12-13-20    17uchtodoS9kdeQP1x0XThKl5IuRsV
2009-04-12-13-20    JOUf1SCtRwviGw8sVcghqE5h0nkgtp
2009-04-12-13-20    NQ2XP0J0dvVbCXJ0pb4XvqJ5A4QxxH
2009-04-12-13-20    fFAItiBMsgqro9kRdIwbeX60SROaxr
2009-04-12-13-20    V4og4R9W6G3QjHHwF7gI1cSqig5D1G
2009-04-12-13-20    hPEPtBwk45msmwWTxPVVo1kVu4v11b
2009-04-12-13-20    v0SkfxegheD90gp31UCr6FplnKpx6i
2009-04-12-13-20    1iD9odVgOIi4QWkwHMcOhmwTkWDKfj
2009-04-12-13-20    b31tJiIA25CK8eDHQrHnbcknfSndUk
```

### Scenario 2: i dati non sono partizionati in formato Hive
<a name="scenario-2-data-is-not-partitioned"></a>

Nell'esempio seguente, il comando `aws s3 ls` mostra i registri [ELB](elasticloadbalancer-classic-logs.md) archiviati in Amazon S3. Notare come il layout dei dati non utilizza coppie `key=value` e quindi non è in formato Hive. (L'opzione `--recursive` per il comando `aws s3 ls` specifica che siano elencati tutti i file o gli oggetti nella directory o nel prefisso specificati).

```
aws s3 ls s3://athena-examples-myregion/elb/plaintext/ --recursive

2016-11-23 17:54:46   11789573 elb/plaintext/2015/01/01/part-r-00000-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:46    8776899 elb/plaintext/2015/01/01/part-r-00001-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:46    9309800 elb/plaintext/2015/01/01/part-r-00002-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:47    9412570 elb/plaintext/2015/01/01/part-r-00003-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:47   10725938 elb/plaintext/2015/01/01/part-r-00004-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:46    9439710 elb/plaintext/2015/01/01/part-r-00005-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:47          0 elb/plaintext/2015/01/01_$folder$
2016-11-23 17:54:47    9012723 elb/plaintext/2015/01/02/part-r-00006-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:47    7571816 elb/plaintext/2015/01/02/part-r-00007-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:47    9673393 elb/plaintext/2015/01/02/part-r-00008-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:48   11979218 elb/plaintext/2015/01/02/part-r-00009-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:48    9546833 elb/plaintext/2015/01/02/part-r-00010-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:48   10960865 elb/plaintext/2015/01/02/part-r-00011-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:48          0 elb/plaintext/2015/01/02_$folder$
2016-11-23 17:54:48   11360522 elb/plaintext/2015/01/03/part-r-00012-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:48   11211291 elb/plaintext/2015/01/03/part-r-00013-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:48    8633768 elb/plaintext/2015/01/03/part-r-00014-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:49   11891626 elb/plaintext/2015/01/03/part-r-00015-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:49    9173813 elb/plaintext/2015/01/03/part-r-00016-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:49   11899582 elb/plaintext/2015/01/03/part-r-00017-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:49          0 elb/plaintext/2015/01/03_$folder$
2016-11-23 17:54:50    8612843 elb/plaintext/2015/01/04/part-r-00018-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:50   10731284 elb/plaintext/2015/01/04/part-r-00019-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:50    9984735 elb/plaintext/2015/01/04/part-r-00020-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:50    9290089 elb/plaintext/2015/01/04/part-r-00021-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:50    7896339 elb/plaintext/2015/01/04/part-r-00022-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:51    8321364 elb/plaintext/2015/01/04/part-r-00023-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:51          0 elb/plaintext/2015/01/04_$folder$
2016-11-23 17:54:51    7641062 elb/plaintext/2015/01/05/part-r-00024-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:51   10253377 elb/plaintext/2015/01/05/part-r-00025-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:51    8502765 elb/plaintext/2015/01/05/part-r-00026-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:51   11518464 elb/plaintext/2015/01/05/part-r-00027-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:51    7945189 elb/plaintext/2015/01/05/part-r-00028-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:51    7864475 elb/plaintext/2015/01/05/part-r-00029-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:51          0 elb/plaintext/2015/01/05_$folder$
2016-11-23 17:54:51   11342140 elb/plaintext/2015/01/06/part-r-00030-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:51    8063755 elb/plaintext/2015/01/06/part-r-00031-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:52    9387508 elb/plaintext/2015/01/06/part-r-00032-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:52    9732343 elb/plaintext/2015/01/06/part-r-00033-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:52   11510326 elb/plaintext/2015/01/06/part-r-00034-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:52    9148117 elb/plaintext/2015/01/06/part-r-00035-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:52          0 elb/plaintext/2015/01/06_$folder$
2016-11-23 17:54:52    8402024 elb/plaintext/2015/01/07/part-r-00036-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:52    8282860 elb/plaintext/2015/01/07/part-r-00037-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:52   11575283 elb/plaintext/2015/01/07/part-r-00038-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:53    8149059 elb/plaintext/2015/01/07/part-r-00039-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:53   10037269 elb/plaintext/2015/01/07/part-r-00040-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:53   10019678 elb/plaintext/2015/01/07/part-r-00041-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt
2016-11-23 17:54:53          0 elb/plaintext/2015/01/07_$folder$
2016-11-23 17:54:53          0 elb/plaintext/2015/01_$folder$
2016-11-23 17:54:53          0 elb/plaintext/2015_$folder$
```

#### Esecuzione di ALTER TABLE ADD PARTITION
<a name="run-alter-table-add-partition"></a>

Poiché i dati non sono in formato Hive, non è possibile utilizzare il comando `MSCK REPAIR TABLE` per aggiungere le partizioni alla tabella dopo averla creata. Invece, è possibile utilizzare il comando [ALTER TABLE ADD PARTITION](alter-table-add-partition.md) per aggiungere manualmente ogni partizione. Ad esempio, per caricare i dati in s3://athena-examples - *myregion* /elb/plaintext/2015/01/01/, puoi eseguire la seguente query. Si noti che non è richiesta una colonna di partizione separata per ogni cartella Amazon S3 e che il valore della chiave di partizione può essere diverso dalla chiave Amazon S3.

```
ALTER TABLE elb_logs_raw_native_part ADD PARTITION (dt='2015-01-01') location 's3://athena-examples-us-west-1/elb/plaintext/2015/01/01/'
```

Se esiste già una partizione, viene visualizzato l'errore Partizione già esistente. Per evitare questo errore, è possibile utilizzare la clausola `IF NOT EXISTS`. Per ulteriori informazioni, consulta [ALTER TABLE ADD PARTITION](alter-table-add-partition.md). Per rimuovere una partizione, è possibile utilizzare [ALTER TABLE DROP PARTITION](alter-table-drop-partition.md). 

## Considera la proiezione delle partizioni
<a name="partitions-partition-projection"></a>

Per evitare di dover gestire le partizioni, è possibile utilizzare la proiezione delle partizioni. La proiezione delle partizioni è un'opzione per tabelle altamente partizionate la cui struttura è nota in anticipo. Nella proiezione delle partizioni, i valori e le posizioni delle partizioni vengono calcolati dalle proprietà della tabella configurate piuttosto che dalla lettura da un repository di metadati. Poiché i calcoli in memoria sono più veloci della ricerca remota, l'uso della proiezione delle partizioni può ridurre significativamente i tempi di esecuzione delle query. 

Per ulteriori informazioni, consulta [Proiezione delle partizioni con Amazon Athena](partition-projection.md).

## Altre risorse
<a name="partitions-additional-resources"></a>
+ Per informazioni sulle opzioni di partizionamento per i dati Kinesis Data Firehose, consultare [Esempio di Amazon Data Firehose](partition-projection-kinesis-firehose-example.md).
+ È inoltre possibile automatizzare l'aggiunta di partizioni utilizzando il [driver JDBC](connect-with-jdbc.md). 
+ È possibile utilizzare CTAS e INSERT INTO per partizionare un set di dati. Per ulteriori informazioni, consulta [Utilizzare CTAS e INSERT INTO per ETL e analisi dei dati](ctas-insert-into-etl.md).

# Proiezione delle partizioni con Amazon Athena
<a name="partition-projection"></a>

È possibile utilizzare la proiezione delle partizioni in Athena per velocizzare l'elaborazione delle query di tabelle altamente partizionate e automatizzare la gestione delle partizioni.

Durante la proiezione delle partizioni, Athena calcola i valori e le posizioni delle partizioni utilizzando le proprietà della tabella configurate direttamente sulla tabella in AWS Glue. Le proprietà della tabella consentono ad Athena di "proiettare", o determinare, le informazioni sulla partizione necessarie anziché eseguire in AWS Glue Data Catalog una ricerca di metadati più dispendiosa in termini di tempo. Poiché le operazioni in memoria sono spesso più veloci delle operazioni remote, la proiezione delle partizioni può ridurre il runtime delle query su tabelle altamente partizionate. A seconda delle caratteristiche specifiche della query e dei dati sottostanti, la proiezione delle partizioni può ridurre significativamente il runtime delle query vincolate al recupero dei metadati delle partizioni.

## Comprendi l’eliminazione delle partizioni rispetto alla proiezione delle partizioni
<a name="partition-projection-pruning-vs-projection"></a>

Il pruning delle partizioni raccoglie i metadati e li assegna solo alle partizioni che si applicano alla query. Questo spesso accelera le query. Athena utilizza il pruning delle partizioni per tutte le tabelle con colonne di partizione, incluse quelle configurate per la proiezione delle partizioni.

Normalmente, durante l'elaborazione delle interrogazioni, Athena effettua `GetPartitions` una chiamata a prima di eseguire AWS Glue Data Catalog l'eliminazione delle partizioni. Se una tabella ha un numero elevato di partizioni, l'utilizzo di `GetPartitions` può influire negativamente sulle prestazioni. Per evitare ciò, è possibile utilizzare la proiezione delle partizioni. La proiezione delle partizioni permette ad Athena di evitare di chiamare `GetPartitions` perché la configurazione della proiezione delle partizioni fornisce ad Athena tutte le informazioni necessarie per costruire le partizioni stesse.

## Utilizzo della proiezione di partizioni
<a name="partition-projection-using"></a>

[Per utilizzare la proiezione delle partizioni, specificate gli intervalli di valori di partizione e i tipi di proiezione per ogni colonna di partizione nelle proprietà della tabella nel metastore Hive o nel metastore Hive esterno. AWS Glue Data Catalog](connect-to-data-source-hive.md) Queste proprietà personalizzate nella tabella permettono ad Athena di sapere quali modelli di partizione aspettarsi quando viene eseguita una query sulla tabella. Durante l'esecuzione delle query, Athena utilizza queste informazioni per proiettare i valori delle partizioni invece di recuperarli dal metastore Hive o esterno. AWS Glue Data Catalog Questo non solo riduce i tempi di esecuzione delle query, ma automatizza anche la gestione delle partizioni perché elimina la necessità di creare manualmente partizioni in Athena, AWS Glue o nel metastore Hive esterno.

**Importante**  
L'abilitazione della proiezione delle partizioni su una tabella fa sì che Athena ignori tutti i metadati di partizione registrati nella tabella nel metastore o Hive. AWS Glue Data Catalog 

## Alcuni casi d'uso
<a name="partition-projection-use-cases"></a>

Gli scenari in cui la proiezione delle partizioni è utile sono i seguenti:
+ Le query su una tabella altamente partizionata non vengono completate rapidamente come si desidera.
+ È possibile aggiungere regolarmente partizioni alle tabelle quando vengono create nuove partizioni di data o ora nei dati. Con la proiezione delle partizioni, è possibile configurare intervalli di date relativi che possono essere utilizzati all'arrivo di nuovi dati. 
+ Si dispone di dati altamente partizionati in Amazon S3. Non è pratico modellare i dati nel tuo AWS Glue Data Catalog metastore o in Hive e le tue query ne leggono solo piccole parti.

### Strutture di partizioni proiettabili
<a name="partition-projection-known-data-structures"></a>

La proiezione delle partizioni è configurata più facilmente quando le partizioni seguono un modello prevedibile come, a titolo esemplificativo, il seguente:
+ **Interi**: qualsiasi sequenza continua di numeri interi come `[1, 2, 3, 4, ..., 1000]` o `[0500, 0550, 0600, ..., 2500]`.
+ **Date**: qualsiasi sequenza continua di date o date e orari, ad esempio `[20200101, 20200102, ..., 20201231]` o `[1-1-2020 00:00:00, 1-1-2020 01:00:00, ..., 12-31-2020 23:00:00]`.
+ Valori **enumerati: un insieme finito di valori** enumerati come codici aeroportuali o. Regioni AWS
+ **Servizio AWS logs: i** Servizio AWS log hanno in genere una struttura nota il cui schema di partizione è possibile specificare e AWS Glue che Athena può quindi utilizzare per la proiezione delle partizioni.

### Come personalizzare il modello di percorso della partizione
<a name="partition-projection-custom-s3-storage-locations"></a>

Per impostazione predefinita, Athena crea le posizioni delle partizioni utilizzando il modulo `s3://amzn-s3-demo-bucket/<table-root>/partition-col-1=<partition-col-1-val>/partition-col-2=<partition-col-2-val>/`, ma se i dati sono organizzati in modo diverso, Athena offre un meccanismo per personalizzare questo modello di percorso. Per le fasi, consulta [Specifica dei percorsi di storage S3 personalizzati](partition-projection-setting-up.md#partition-projection-specifying-custom-s3-storage-locations).

## Considerazioni e limitazioni
<a name="partition-projection-considerations-and-limitations"></a>

Tieni presente le seguenti considerazioni:
+ La proiezione delle partizioni elimina la necessità di specificare manualmente le partizioni AWS Glue o un metastore Hive esterno.
+ Quando abilitate la proiezione delle partizioni su una tabella, Athena ignora tutti i metadati di partizione nel metastore Hive esterno AWS Glue Data Catalog o nel metastore Hive per quella tabella.
+ Se una partizione proiettata non esiste in Amazon S3, Athena continuerà a proiettare la partizione. Athena non genera un errore, ma non viene restituito alcun dato. Tuttavia, se troppe partizioni sono vuote, le prestazioni possono essere inferiori rispetto alle partizioni tradizionali. AWS Glue Se più della metà delle partizioni proiettate sono vuote, si consiglia di utilizzare partizioni tradizionali.
+ Le query per valori che superano i limiti di intervallo definiti per la proiezione della partizione non restituiscono un errore. La query invece viene eseguita, ma restituisce zero righe. Ad esempio, se si dispone di dati relativi al tempo che iniziano nel 2020 e sono definiti come `'projection.timestamp.range'='2020/01/01,NOW'`, una query come `SELECT * FROM table-name WHERE timestamp = '2019/02/02'` verrà completata correttamente, ma restituirà zero righe.
+ La proiezione delle partizioni è utilizzabile solo quando la tabella viene interrogata tramite Athena. Se la stessa tabella viene letta attraverso un altro servizio, ad esempio Amazon Redshift Spectrum, Athena per Spark o Amazon EMR, vengono utilizzati i metadati della partizione standard.
+ Poiché la proiezione delle partizioni è una funzionalità solo DML, `SHOW PARTITIONS` non elenca le partizioni proiettate da Athena ma non registrate nel catalogo o nel metastore Hive esterno. AWS Glue 
+ Athena non utilizza le proprietà della tabella delle viste come configurazione per la proiezione delle partizioni. Per aggirare questa limitazione, configurare e abilitare la proiezione della partizione nelle proprietà della tabella per le tabelle a cui fanno riferimento le viste.

## Video
<a name="partition-projection-video"></a>

Il video seguente mostra come utilizzare la proiezione delle partizioni per migliorare le prestazioni delle vostre query in Athena.

[![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/iUD5pPpcyZk/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/iUD5pPpcyZk)


**Topics**
+ [Comprendi l’eliminazione delle partizioni rispetto alla proiezione delle partizioni](#partition-projection-pruning-vs-projection)
+ [Utilizzo della proiezione di partizioni](#partition-projection-using)
+ [Alcuni casi d'uso](#partition-projection-use-cases)
+ [Considerazioni e limitazioni](#partition-projection-considerations-and-limitations)
+ [Video](#partition-projection-video)
+ [proiezione delle partizioni configurata](partition-projection-setting-up.md)
+ [Tipi supportati per la proiezione delle partizioni](partition-projection-supported-types.md)
+ [Partizionamento ID dinamico](partition-projection-dynamic-id-partitioning.md)
+ [Esempio di Amazon Data Firehose](partition-projection-kinesis-firehose-example.md)

# proiezione delle partizioni configurata
<a name="partition-projection-setting-up"></a>

L'impostazione della proiezione delle partizioni nelle proprietà di una tabella è un processo in due fasi:

1. Specificare gli intervalli di dati e i modelli pertinenti per ogni colonna di partizione oppure utilizzare un modello personalizzato.

1. Attivare la proiezione delle partizioni per la tabella.

**Nota**  
Prima di aggiungere le proprietà di proiezione delle partizioni a una tabella esistente, la colonna di partizione per la quale stai impostando tali proprietà deve già esistere nello schema della tabella. Se la colonna di partizione non esiste ancora, è necessario aggiungere manualmente una colonna di partizione alla tabella esistente. AWS Glue non esegue questo passaggio automaticamente. 

Questa sezione mostra come impostare le proprietà della tabella per AWS Glue. Per impostarli, puoi utilizzare la AWS Glue console, le [CREATE TABLE](create-table.md) query Athena o le operazioni. [AWS Glue API](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api.html) La procedura seguente mostra come impostare le proprietà nella AWS Glue console.

**Per configurare e abilitare la proiezione delle partizioni utilizzando la console AWS Glue**

1. Accedi a Console di gestione AWS e apri la AWS Glue console all'indirizzo. [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)

1. Scegliere la scheda **Tabelle**.

   Nella scheda **Tabelle** è possibile modificare le tabelle esistenti oppure scegliere **Aggiungi tabelle** per crearne di nuove. Per informazioni sull'aggiunta manuale di tabelle o con un crawler, consulta [Utilizzo delle tabelle nella console AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/console-tables.html) nella *Guida per gli sviluppatori di AWS Glue *.

1. Nell'elenco delle tabelle scegliere il collegamento per la tabella che si desidera modificare.  
![\[Nella AWS Glue console, scegli una tabella da modificare.\]](http://docs.aws.amazon.com/it_it/athena/latest/ug/images/partition-projection-1.png)

1. Scegli **Actions** (Operazioni), **Edit** (Modifica).

1. Nella pagina **Edit table** (Modifica tabella), nella sezione **Table properties** (Proprietà della tabella), per ogni colonna partizionata, aggiungi la seguente coppia chiave-valore:

   1. Per **Chiave**, aggiungere `projection.columnName.type`.

   1. Per **Valore**, aggiungere uno dei tipi supportati: `enum`, `integer`, `date` o `injected`. Per ulteriori informazioni, consulta [Tipi supportati per la proiezione delle partizioni](partition-projection-supported-types.md).

1. Seguendo le indicazioni fornite in [Tipi supportati per la proiezione delle partizioni](partition-projection-supported-types.md), aggiungere ulteriori coppie chiave-valore in base ai requisiti di configurazione.

   La configurazione della tabella di esempio seguente configura la colonna `year` per la proiezione delle partizioni, limitando i valori che possono essere restituiti a un intervallo compreso tra il 2010 e il 2016.  
![\[Configurazione della proiezione delle partizioni per una colonna di partizione nelle proprietà della tabella della console AWS Glue .\]](http://docs.aws.amazon.com/it_it/athena/latest/ug/images/partition-projection-3.png)

1. Aggiungere una coppia chiave-valore per abilitare la proiezione delle partizioni. Per **Chiave**, immettere `projection.enabled`, e per il relativo **valore**, immettere `true`.
**Nota**  
È possibile disattivare la proiezione delle partizioni su questa tabella in qualsiasi momento impostando `projection.enabled` su `false`.

1. Quando hai terminato, seleziona **Save** (Salva).

1. Nell'editor di query Athena, eseguire una query sulle colonne configurate per la tabella.

   La query di esempio seguente utilizza `SELECT DISTINCT` per restituire i valori univoci della colonna `year`. Il database contiene dati dal 1987 al 2016, ma la proprietà `projection.year.range` limita i valori restituiti agli anni dal 2010 al 2016.  
![\[Esecuzione di query su una colonna che utilizza la proiezione delle partizioni.\]](http://docs.aws.amazon.com/it_it/athena/latest/ug/images/partition-projection-5.png)
**Nota**  
Se si imposta su `projection.enabled` su `true` ma non si riesce a configurare una o più colonne di partizione, viene visualizzato un messaggio di errore analogo al seguente:  
`HIVE_METASTORE_ERROR: Table database_name.table_name is configured for partition projection, but the following partition columns are missing projection configuration: [column_name] (table database_name.table_name)`.

## Specifica dei percorsi di storage S3 personalizzati
<a name="partition-projection-specifying-custom-s3-storage-locations"></a>

Quando modifichi le proprietà della tabella in AWS Glue, puoi anche specificare un modello di percorso Amazon S3 personalizzato per le partizioni proiettate. Un modello personalizzato consente ad Athena di mappare correttamente i valori delle partizioni alle posizioni dei file Amazon S3 personalizzate che non seguono un modello `.../column=value/...` tipico. 

L'utilizzo di un modello personalizzato è facoltativo. Tuttavia, se si utilizza un modello personalizzato, il modello deve contenere un segnaposto per ogni colonna di partizione. Le posizioni basate su modelli devono terminare con una barra in avanti in modo che i file di dati partizionati risiedano in una "cartella" per partizione.

**Per specificare un modello di posizione della partizione personalizzato**

1. Seguendo i passaggi per [configurare e abilitare la proiezione delle partizioni utilizzando la AWS Glue console](#partition-projection-setting-up-procedure), aggiungi un'ulteriore coppia chiave-valore che specifica un modello personalizzato come segue:

   1. In **Chiave**, inserire `storage.location.template`.

   1. In **Valore**, specificare una posizione che includa un segnaposto per ogni colonna di partizione. Assicurarsi che ogni segnaposto (e il percorso S3 stesso) sia terminato da una singola barra in avanti.

      I valori del modello di esempio seguenti presuppongono una tabella con colonne di partizione `a`, `b` e `c`.

      ```
      s3://amzn-s3-demo-bucket/table_root/a=${a}/${b}/some_static_subdirectory/${c}/      
      ```

      ```
      s3://amzn-s3-demo-bucket/table_root/c=${c}/${b}/some_static_subdirectory/${a}/${b}/${c}/${c}/      
      ```

      Per la stessa tabella, il valore del modello di esempio seguente non è valido perché non contiene segnaposto per la colonna `c`.

      ```
      s3://amzn-s3-demo-bucket/table_root/a=${a}/${b}/some_static_subdirectory/         
      ```

1. Scegli **Applica**.

# Tipi supportati per la proiezione delle partizioni
<a name="partition-projection-supported-types"></a>

Una tabella può avere qualsiasi combinazione di `enum`, `integer`, `date,` o tipi di colonna di partizione `injected`.

## Tipi di enumerazione
<a name="partition-projection-enum-type"></a>

Utilizzate il `enum` tipo per le colonne di partizione i cui valori sono membri di un set enumerato (ad esempio, codici aeroportuali o). Regioni AWS

Definire le proprietà della partizione nella tabella come segue:


****  

| Nome proprietà | Valori di esempio | Description | 
| --- | --- | --- | 
| projection.columnName.type |  `enum`  | Obbligatorio. Il tipo di proiezione da usare per la colonna. columnName Il valore deve essere enum (senza distinzione tra maiuscole e minuscole) per segnalare l'uso del tipo enum. È consentito lo spazio bianco iniziale e finale. | 
| projection.columnName.values |  `A,B,C,D,E,F,G,Unknown`  | Obbligatorio. Un elenco separato da virgole di valori di partizione enumerati per colonna. columnName Qualsiasi spazio bianco è considerato parte di un valore enum. | 

**Nota**  
Come best practice si consiglia di limitare l'uso delle proiezioni delle partizioni basate su `enum` a poche dozzine o meno. Sebbene non esista un limite specifico per `enum` le proiezioni, la dimensione totale dei metadati della tabella non può superare il limite di circa 1 MB quando viene compressa con gzip. AWS Glue Si noti che questo limite è condiviso tra le parti chiave della tabella, come i nomi delle colonne, la posizione, il formato di archiviazione e altri. Se ti ritrovi a utilizzare più di qualche dozzina di valori unici IDs nella tua `enum` proiezione, prendi in considerazione un approccio alternativo, come l'inserimento di un numero inferiore di valori univoci in un campo sostitutivo. Negoziando la cardinalità, puoi controllare il numero di valori univoci nel campo `enum`. 

## Tipo intero
<a name="partition-projection-integer-type"></a>

Utilizzare il tipo intero per le colonne di partizione i cui valori possibili sono interpretabili come numeri interi all'interno di un intervallo definito. Le colonne intere proiettate sono attualmente limitate all'intervallo firmato Java (da -263 a 263-1 incluso).


****  

| Nome proprietà | Valori di esempio | Description | 
| --- | --- | --- | 
| projection.columnName.type |  `integer`  | Obbligatorio. Il tipo di proiezione da usare per la colonna. columnName Il valore deve essere integer (senza distinzione tra maiuscole e minuscole) per segnalare l'uso del tipo intero. È consentito lo spazio bianco iniziale e finale. | 
| projection.columnName.range |  `0,10` `-1,8675309` `0001,9999`  | Obbligatorio. Un elenco di due elementi separati da virgole che fornisce i valori dell'intervallo minimo e massimo che devono essere restituiti dalle interrogazioni sulla colonna. columnName Tieni presente che i valori devono essere separati da virgole, non da trattini. Questi valori sono inclusivi, possono essere negativi e possono avere zeri iniziali. È consentito lo spazio bianco iniziale e finale. | 
| projection.columnName.interval |  `1` `5`  | Opzionale. Un numero intero positivo che specifica l'intervallo tra i valori di partizione successivi per la colonna. columnName Ad esempio, un valore range di "1,3" con un valore interval di "1" produce i valori 1, 2 e 3. Lo stesso valore range con un valore interval di "2" produce i valori 1 e 3, saltando 2. È consentito lo spazio bianco iniziale e finale. Il valore di default è 1. | 
| projection.columnName.digits |  `1` `5`  | Opzionale. Un numero intero positivo che specifica il numero di cifre da includere nella rappresentazione finale del valore di partizione per colonna. columnName Ad esempio, un valore range di "1,3" che ha un valore digits di "1" produce i valori 1, 2 e 3. Lo stesso valore range con un valore digits di "2" produce i valori 01, 02 e 03. È consentito lo spazio bianco iniziale e finale. Il valore predefinito non è un numero statico di cifre e nessuno zero iniziale. | 

## Tipo di data
<a name="partition-projection-date-type"></a>

Utilizzare il tipo di data per le colonne di partizione i cui valori sono interpretabili come date (con orari facoltativi) all'interno di un intervallo definito.

**Importante**  
Le colonne della data prevista vengono generate in ora UTC (Coordinated Universal Time) al momento dell'esecuzione della query.


****  

| Nome proprietà | Valori di esempio | Description | 
| --- | --- | --- | 
| projection.columnName.type |  `date`  | Obbligatorio. Il tipo di proiezione da usare per la colonna. columnName Il valore deve essere date (senza distinzione tra maiuscole e minuscole) per segnalare l'utilizzo del tipo di data. È consentito lo spazio bianco iniziale e finale. | 
| projection.columnName.range |  `201701,201812` `01-01-2010,12-31-2018` `NOW-3YEARS,NOW` `201801,NOW+1MONTH`  |  Obbligatorio. Un elenco di due elementi, separato da virgole, che fornisce i valori minimo e massimo `range` per la colonna. *columnName* Questi valori sono inclusivi e possono utilizzare qualsiasi formato compatibile con i tipi di data `java.time.*` Java. Entrambi i valori minimo e massimo devono utilizzare lo stesso formato. Il formato specificato nella proprietà `.format` deve corrispondere al formato utilizzato per questi valori. Questa colonna può anche contenere stringhe di data relative, formattate in questo modello di espressione regolare: `\s*NOW\s*(([\+\-])\s*([0-9]+)\s*(YEARS?\|MONTHS?\|WEEKS?\|DAYS?\|HOURS?\|MINUTES?\|SECONDS?)\s*)?` Gli spazi bianchi sono consentiti, ma nei valori letterali della data sono considerati parte delle stringhe di data stesse.  | 
| projection.columnName.format |  `yyyyMM` `dd-MM-yyyy` `dd-MM-yyyy-HH-mm-ss`  | Obbligatorio. Una stringa di formato data basata sul formato di data Java. [DateTimeFormatter](https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html) Può essere qualsiasi tipo Java.time.\$1 supportato. | 
| projection.columnName.interval |  `1` `5`  |  Un numero intero positivo che specifica l'intervallo tra i valori di partizione successivi per la colonna. *columnName* Ad esempio, un valore `range` di `2017-01,2018-12` con un valore `interval` di `1` e un valore `interval.unit` di `MONTHS` produce i valori 2017-01, 2017-02, 2017-03 e così via. Lo stesso valore `range` con un valore `interval` di `2` e un valore `interval.unit` di `MONTHS` produce i valori 2017-01, 2017-03, 2017-05 e così via. È consentito lo spazio bianco iniziale e finale. Quando le date sono fornite con la precisione di un singolo giorno o di un mese, `interval` è facoltativo e il valore predefinito è 1 giorno o 1 mese, rispettivamente. In caso contrario, `interval` è richiesto.  | 
| projection.columnName.interval.unit |  `YEARS` `MONTHS` `WEEKS` `DAYS` `HOURS` `MINUTES` `SECONDS` `MILLIS`  |  Una parola unitaria di tempo che rappresenta la forma serializzata di a. [ChronoUnit](https://docs.oracle.com/javase/8/docs/api/java/time/temporal/ChronoUnit.html) I valori possibili sono `YEARS`, `MONTHS`, `WEEKS`, `DAYS`, `HOURS`, `MINUTES`, `SECONDS` o `MILLIS`. I valori non rispettano la distinzione tra maiuscole e minuscole. Quando le date sono fornite con la precisione di un singolo giorno o di un mese, `interval.unit` è facoltativo e il valore predefinito è 1 giorno o 1 mese, rispettivamente. In caso contrario, `interval.unit` è richiesto.  | 

**Example Partizione per mese**  
La seguente tabella di configurazione di esempio partiziona i dati per mese dal 2015 ad oggi.  

```
'projection.month.type'='date', 
'projection.month.format'='yyyy-MM', 
'projection.month.interval'='1', 
'projection.month.interval.unit'='MONTHS', 
'projection.month.range'='2015-01,NOW', 
...
```

## Tipo iniettato
<a name="partition-projection-injected-type"></a>

Utilizzare il tipo iniettato per le colonne di partizione con valori possibili che non possono essere generati proceduralmente all'interno di un intervallo logico, ma che sono forniti nella clausola `WHERE` di una query come valore singolo.

È importante tenere a mente i seguenti punti:
+ Le query sulle colonne iniettate hanno esito negativo se non viene fornita un'espressione di filtro per ogni colonna iniettata.
+ Le query con più valori per un'espressione filtro su una colonna iniettata hanno esito positivo solo se i valori sono disgiunti.
+ Solo le colonne di tipo `string` sono supportate.
+ Quando si utilizza la frase `WHERE IN` con una colonna di partizione iniettata, esiste un limite di 1.000 valori che è possibile specificare nell’elenco. `IN` Per interrogare un set di dati con più di 1.000 partizioni per una colonna iniettata, suddividi la query in più query più piccole, ognuna con un massimo di 1.000 valori nella `WHERE IN` clausola, quindi aggrega i risultati.


****  

| Nome proprietà | Valore | Description | 
| --- | --- | --- | 
| projection.columnName.type |  `injected`  | Obbligatorio. Il tipo di proiezione da utilizzare per la colonna. columnName È supportato solo il tipo string. Il valore specificato deve essere injected (senza distinzione tra maiuscole e minuscole). È consentito lo spazio bianco iniziale e finale. | 

Per ulteriori informazioni, consulta [Quando `injected` utilizzare il tipo di proiezione](partition-projection-dynamic-id-partitioning.md#partition-projection-injection).

# Partizionamento ID dinamico
<a name="partition-projection-dynamic-id-partitioning"></a>

Quando i dati sono partizionati in base a una proprietà con cardinalità elevata o quando i valori non possono essere conosciuti in anticipo, è possibile utilizzare il tipo di proiezione `injected`. Esempi di tali proprietà sono i nomi utente e IDs i dispositivi o i prodotti. Quando si utilizza il tipo di proiezione `injected` per configurare una chiave di partizione, Athena utilizza i valori della query stessa per calcolare l'insieme di partizioni che verranno lette.

Affinché Athena sia in grado di eseguire una query su una tabella con una chiave di partizione configurata con il tipo di proiezione `injected`, deve essere vero quanto segue:
+ La query deve includere almeno un valore per la chiave di partizione.
+ I valori devono essere letterali o espressioni che possono essere valutate senza leggere alcun dato.

Se uno di questi criteri non viene soddisfatto, la query ha esito negativo e viene visualizzato il seguente errore:

CONSTRAINT\$1VIOLATION: per la colonna di partizione proiettata iniettata*column\$1name*, la clausola WHERE deve contenere solo condizioni di uguaglianza statiche e deve essere presente almeno una di queste condizioni.

## Quando `injected` utilizzare il tipo di proiezione
<a name="partition-projection-injection"></a>

Immagina di avere un set di dati composto da eventi provenienti da dispositivi IoT, partizionati sui dispositivi». IDs Questo esempio presenta le caratteristiche seguenti:
+ I dispositivi vengono generati in modo casuale. IDs 
+ Nuovi dispositivi vengono forniti frequentemente.
+ Attualmente i dispositivi ammontano a centinaia di migliaia e in futuro saranno milioni.

Questo set di dati è difficile da gestire utilizzando i metastore tradizionali. È difficile mantenere sincronizzate le partizioni tra l'archiviazione di dati e il metastore e il filtraggio delle partizioni può essere lento durante la pianificazione delle query. Tuttavia, se si configura una tabella per utilizzare la proiezione delle partizioni e si utilizza il tipo di proiezione `injected`, si ottengono due vantaggi: non è necessario gestire le partizioni nel metastore e le query non devono cercare i metadati delle partizioni.

L'esempio di `CREATE TABLE` seguente crea una tabella per il set di dati degli eventi del dispositivo appena descritto. La tabella utilizza il tipo di proiezione iniettata.

```
CREATE EXTERNAL TABLE device_events (
  event_time TIMESTAMP,
  data STRING,
  battery_level INT
)
PARTITIONED BY (
  device_id STRING
)
LOCATION "s3://amzn-s3-demo-bucket/prefix/"
TBLPROPERTIES (
  "projection.enabled" = "true",
  "projection.device_id.type" = "injected",
  "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${device_id}"
)
```

La seguente query di esempio cerca il numero di eventi ricevuti da tre dispositivi specifici nell'arco di 12 ore.

```
SELECT device_id, COUNT(*) AS events
FROM device_events
WHERE device_id IN (
  '4a770164-0392-4a41-8565-40ed8cec737e',
  'f71d12cf-f01f-4877-875d-128c23cbde17',
  '763421d8-b005-47c3-ba32-cc747ab32f9a'
)
AND event_time BETWEEN TIMESTAMP '2023-11-01 20:00' AND TIMESTAMP '2023-11-02 08:00'
GROUP BY device_id
```

Quando si esegue questa query, Athena vede i tre valori per la chiave di partizione `device_id` e li usa per calcolare le posizioni delle partizioni. Athena utilizza il valore della proprietà `storage.location.template` per generare le seguenti posizioni:
+ `s3://amzn-s3-demo-bucket/prefix/4a770164-0392-4a41-8565-40ed8cec737e`
+ `s3://amzn-s3-demo-bucket/prefix/f71d12cf-f01f-4877-875d-128c23cbde17`
+ `s3://amzn-s3-demo-bucket/prefix/763421d8-b005-47c3-ba32-cc747ab32f9a`

Se si omette la proprietà `storage.location.template` dalla configurazione di proiezione della partizione, Athena utilizza il partizionamento in stile Hive per proiettare le posizioni delle partizioni in base al valore in `LOCATION` (ad esempio, `s3://amzn-s3-demo-bucket/prefix/device_id=4a770164-0392-4a41-8565-40ed8cec737e`).

# Esempio di Amazon Data Firehose
<a name="partition-projection-kinesis-firehose-example"></a>

Quando si utilizza Firehose per consegnare dati ad Amazon S3, la configurazione di default scrive oggetti con chiavi simili al seguente esempio:

```
s3://amzn-s3-demo-bucket/prefix/yyyy/MM/dd/HH/file.extension
```

Per creare una tabella Athena che trovi automaticamente le partizioni al momento della query, invece di doverle aggiungere all'arrivo di nuovi dati, puoi utilizzare la AWS Glue Data Catalog proiezione delle partizioni.

Il seguente esempio di `CREATE TABLE` utilizza la configurazione di default di Firehose.

```
CREATE EXTERNAL TABLE my_ingested_data (
 ...
)
...
PARTITIONED BY (
 datehour STRING
)
LOCATION "s3://amzn-s3-demo-bucket/prefix/"
TBLPROPERTIES (
 "projection.enabled" = "true",
 "projection.datehour.type" = "date",
 "projection.datehour.format" = "yyyy/MM/dd/HH",
 "projection.datehour.range" = "2021/01/01/00,NOW",
 "projection.datehour.interval" = "1",
 "projection.datehour.interval.unit" = "HOURS",
 "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${datehour}/"
)
```

La clausola `TBLPROPERTIES` nell'istruzione `CREATE TABLE` indica ad Athena quanto segue:
+ Usa la proiezione delle partizioni durante la query sulla tabella
+ La chiave di partizione `datehour` è di tipo `date` (che include un orario facoltativo)
+ Come vengono formattate le date
+ L'intervallo di date e orari Tieni presente che i valori devono essere separati da virgole, non da trattini.
+ Dove trovare i dati su Amazon S3.

Quando si esegue una query sulla tabella, Athena calcola i valori per `datehour` e utilizza il modello di posizione di archiviazione per generare un elenco di posizioni di partizione.

**Topics**
+ [Come utilizzare il tipo `date`](partition-projection-kinesis-firehose-example-using-the-date-type.md)
+ [Come scegliere le chiavi di partizione](partition-projection-kinesis-firehose-example-choosing-partition-keys.md)
+ [Come utilizzare prefissi personalizzati e partizionamento dinamico](partition-projection-kinesis-firehose-example-using-custom-prefixes-and-dynamic-partitioning.md)

# Come utilizzare il tipo `date`
<a name="partition-projection-kinesis-firehose-example-using-the-date-type"></a>

Quando si utilizza il tipo `date` per una chiave di partizione proiettata, è necessario specificare un intervallo. Poiché non si dispone di dati per le date precedenti alla creazione del flusso di consegna di Firehose, è possibile utilizzare la data di creazione come inizio. E poiché non si dispone di dati per le date in futuro, è possibile utilizzare il token speciale `NOW` come la fine.

Nell'esempio `CREATE TABLE`, la data di inizio è specificata come 1 gennaio 2021 a mezzanotte UTC.

**Nota**  
Configurare un intervallo che corrisponda il più possibile ai propri dati in modo che Athena cerchi solo le partizioni esistenti.

Quando viene eseguita una query sulla tabella di esempio, Athena utilizza le condizioni sulla chiave di partizione `datehour` insieme all'intervallo per generare i valori. Considera la query seguente:

```
SELECT *
FROM my_ingested_data
WHERE datehour >= '2020/12/15/00'
AND datehour < '2021/02/03/15'
```

La prima condizione nella query `SELECT` utilizza una data precedente all'inizio dell'intervallo di date specificato dall'istruzione `CREATE TABLE`. Poiché la configurazione di proiezione delle partizioni non specifica partizioni per le date precedenti al 1° gennaio 2021, Athena cerca i dati solo nelle posizioni seguenti e ignora le date precedenti nella query.

```
s3://amzn-s3-demo-bucket/prefix/2021/01/01/00/
s3://amzn-s3-demo-bucket/prefix/2021/01/01/01/
s3://amzn-s3-demo-bucket/prefix/2021/01/01/02/
...
s3://amzn-s3-demo-bucket/prefix/2021/02/03/12/
s3://amzn-s3-demo-bucket/prefix/2021/02/03/13/
s3://amzn-s3-demo-bucket/prefix/2021/02/03/14/
```

Analogamente, se la query viene eseguita in una data e ora precedenti al 3 febbraio 2021 alle 15:00, l'ultima partizione rifletterebbe la data e l'ora correnti, non la data e l'ora nella condizione della query.

Se si desidera eseguire una query per i dati più recenti, è possibile sfruttare il fatto che Athena non genera date future e specificare solo un inizio `datehour`, come nel seguente esempio.

```
SELECT *
FROM my_ingested_data
WHERE datehour >= '2021/11/09/00'
```

# Come scegliere le chiavi di partizione
<a name="partition-projection-kinesis-firehose-example-choosing-partition-keys"></a>

È possibile specificare in che modo la proiezione delle partizioni mappa le posizioni delle partizioni alle chiavi di partizione. Nell'esempio `CREATE TABLE` nella sezione precedente, la data e l'ora sono state combinate in una chiave di partizione chiamata datehour, ma sono possibili altri schemi. Ad esempio, è possibile configurare una tabella con chiavi di partizione separate per l'anno, il mese, il giorno e l'ora. 

Tuttavia, la suddivisione delle date in anno, mese e giorno significa che il tipo di proiezione della partizione `date` non può essere utilizzato. Un'alternativa consiste nel separare la data dall'ora per sfruttare comunque il tipo di proiezione della partizione `date`, ma rendere più facili da leggere le query che specificano gli intervalli di ore.

Ricordando questo, nell'esempio `CREATE TABLE` seguente la data viene separata dall'ora. Poiché `date` è una parola riservata in SQL, nell'esempio viene utilizzata `day` come nome la chiave di partizione che rappresenta la data.

```
CREATE EXTERNAL TABLE my_ingested_data2 (
 ...
)
...
PARTITIONED BY (
 day STRING,
 hour INT
)
LOCATION "s3://amzn-s3-demo-bucket/prefix/"
TBLPROPERTIES (
 "projection.enabled" = "true",
 "projection.day.type" = "date",
 "projection.day.format" = "yyyy/MM/dd",
 "projection.day.range" = "2021/01/01,NOW",
 "projection.day.interval" = "1",
 "projection.day.interval.unit" = "DAYS",
 "projection.hour.type" = "integer",
 "projection.hour.range" = "0,23",
 "projection.hour.digits" = "2",
 "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${day}/${hour}/"
)
```

Nell'istruzione `CREATE TABLE` di esempio, l'ora è una chiave di partizione separata configurata come numero intero. La configurazione per la chiave di partizione dell'ora specifica l'intervallo da 0 a 23 e che l'ora deve essere formattata con due cifre quando Athena genera le posizioni della partizione.

Una query per la tabella `my_ingested_data2` potrebbe essere simile alla seguente:

```
SELECT *
FROM my_ingested_data2
WHERE day = '2021/11/09'
AND hour > 3
```

## Comprendere tipi di chiavi di partizione e tipi di proiezione delle partizioni
<a name="partition-projection-kinesis-firehose-example-partition-key-types-and-partition-projection-types"></a>

Tieni presente che la chiave `datehour` nel primo esempio `CREATE TABLE` è configurata come `date` nella configurazione di proiezione della partizione, ma il tipo di chiave di partizione è `string`. Lo stesso vale per `day` nel secondo esempio. I tipi nella configurazione di proiezione delle partizioni indicano ad Athena soltanto come formattare i valori quando vengono generate le posizioni della partizione. I tipi specificati non modificano il tipo di chiave di partizione, nelle query, `datehour` e `day` sono di tipo `string`.

Quando una query include una condizione come `day = '2021/11/09'`, Athena analizza la stringa sul lato destro dell'espressione utilizzando il formato data specificato nella configurazione di proiezione della partizione. Una volta che Athena ha verificato che la data rientra nell'intervallo configurato, utilizza nuovamente il formato della data per inserire la data come stringa nel modello di posizione di archiviazione.

Allo stesso modo, per una condizione di query come `day > '2021/11/09'`, Athena analizza il lato destro e genera un elenco di tutte le date corrispondenti all'interno dell'intervallo configurato. Viene quindi utilizzato il formato della data per inserire ogni data nel modello di posizione di archiviazione per creare l'elenco delle posizioni delle partizioni.

Scrivi la stessa condizione come `day > '2021-11-09'` altrimenti `day > DATE '2021-11-09'` non funzionerà. Nel primo caso, il formato della data non corrisponde (notare i trattini anziché le barre) mentre nel secondo caso i tipi di dati non corrispondono.

# Come utilizzare prefissi personalizzati e partizionamento dinamico
<a name="partition-projection-kinesis-firehose-example-using-custom-prefixes-and-dynamic-partitioning"></a>

Firehose può essere configurato con [prefissi personalizzati](https://docs.aws.amazon.com/firehose/latest/dev/s3-prefixes.html) e [partizionamento dinamico](https://docs.aws.amazon.com/firehose/latest/dev/dynamic-partitioning.html). Grazie a queste funzionalità, è possibile configurare le chiavi Amazon S3 e impostare schemi di partizionamento che supportano meglio il proprio caso d'uso. È inoltre possibile utilizzare la proiezione delle partizioni con questi schemi di partizionamento e configurarli di conseguenza.

Ad esempio, è possibile utilizzare la funzione di prefisso personalizzato per ottenere chiavi Amazon S3 con date formattate in ISO anziché lo schema `yyyy/MM/dd/HH` di default.

È inoltre possibile combinare i prefissi personalizzati con il partizionamento dinamico per estrarre una proprietà come `customer_id` dai messaggi Firehose, come nell’esempio seguente.

```
prefix/!{timestamp:yyyy}-!{timestamp:MM}-!{timestamp:dd}/!{partitionKeyFromQuery:customer_id}/
```

Con quel prefisso Amazon S3, il flusso di consegna di Firehose scriverebbe oggetti su chiavi come `s3://amzn-s3-demo-bucket/prefix/2021-11-01/customer-1234/file.extension`. Per una proprietà come `customer_id` dove i valori potrebbero non essere noti in anticipo, è possibile utilizzare il tipo di proiezione della partizione `injected` e usare un'istruzione `CREATE TABLE` come la seguente:

```
CREATE EXTERNAL TABLE my_ingested_data3 (
 ...
)
...
PARTITIONED BY (
 day STRING,
 customer_id STRING
)
LOCATION "s3://amzn-s3-demo-bucket/prefix/"
TBLPROPERTIES (
 "projection.enabled" = "true",
 "projection.day.type" = "date",
 "projection.day.format" = "yyyy-MM-dd",
 "projection.day.range" = "2021-01-01,NOW",
 "projection.day.interval" = "1",
 "projection.day.interval.unit" = "DAYS",
 "projection.customer_id.type" = "injected",
 "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${day}/${customer_id}/"
)
```

Quando si esegue una query su una tabella con una chiave di partizione di tipo `injected`, la query deve includere un valore per quella chiave di partizione. Una query per la tabella `my_ingested_data3` potrebbe essere simile alla seguente:

```
SELECT *
FROM my_ingested_data3
WHERE day BETWEEN '2021-11-01' AND '2021-11-30'
AND customer_id = 'customer-1234'
```

## Utilizzare il tipo DATE per la chiave di partizione del giorno
<a name="partition-projection-kinesis-firehose-example-iso-formatted-dates"></a>

Perché i valori per la chiave di partizione `day` sono formattati in ISO, è anche possibile utilizzare il tipo `DATE` per la chiave di partizione del giorno invece di `STRING`, come nel seguente esempio:

```
PARTITIONED BY (day DATE, customer_id STRING)
```

Quando si esegue una query, questa strategia consente di utilizzare le funzioni data sulla chiave di partizione senza analizzare o eseguire il casting, come nell'esempio seguente:

```
SELECT *
FROM my_ingested_data3
WHERE day > CURRENT_DATE - INTERVAL '7' DAY
AND customer_id = 'customer-1234'
```

**Nota**  
La specificazione di una chiave di partizione di tipo `DATE` presuppone che per creare chiavi Amazon S3 con date in formato ISO sia stata utilizzata la funzionalità di [prefisso personalizzato](https://docs.aws.amazon.com/firehose/latest/dev/s3-prefixes.html). Se utilizzi il formato predefinito di Firehose `yyyy/MM/dd/HH`, è necessario specificare la chiave di partizione di tipo `string` anche se la proprietà della tabella corrispondente è di tipo `date`, come mostra il seguente esempio:  

```
PARTITIONED BY ( 
  `mydate` string)
TBLPROPERTIES (
  'projection.enabled'='true', 
   ...
  'projection.mydate.type'='date',
  'storage.location.template'='s3://amzn-s3-demo-bucket/prefix/${mydate}')
```

# Prevenire la limitazione (della larghezza di banda della rete) di Amazon S3
<a name="performance-tuning-s3-throttling"></a>

La limitazione (della larghezza di banda della rete) è il processo di limitazione della velocità con cui utilizzi un servizio, un'applicazione o un sistema. Inoltre AWS, puoi utilizzare la limitazione per evitare un uso eccessivo del servizio Amazon S3 e aumentare la disponibilità e la reattività di Amazon S3 per tutti gli utenti. Tuttavia, poiché la limitazione limitazione (della larghezza di banda della rete) riduce la velocità con cui i dati possono essere trasferiti da o verso Amazon S3, è importante tenere a mente di evitare che le interazioni siano limitate.

Come indicato nel capitolo sull’[ottimizzazione delle prestazioni](performance-tuning.md), le ottimizzazioni possono dipendere dalle decisioni prese a livello di servizio, dalla struttura delle tabelle e dei dati e dalla modalità di scrittura delle query.

**Topics**
+ [Riduzione della limitazione (della larghezza di banda della rete) a livello di servizio](performance-tuning-s3-throttling-reduce-throttling-at-the-service-level.md)
+ [Ottimizzare le tabelle](performance-tuning-s3-throttling-optimizing-your-tables.md)
+ [Ottimizzare le query](performance-tuning-s3-throttling-optimizing-queries.md)

# Riduzione della limitazione (della larghezza di banda della rete) a livello di servizio
<a name="performance-tuning-s3-throttling-reduce-throttling-at-the-service-level"></a>

Per evitare la limitazione (della larghezza di banda della rete) di Amazon S3 a livello di servizio, puoi monitorare l'utilizzo e modificare le [service quotas](https://docs.aws.amazon.com/general/latest/gr/s3.html#limits_s3) oppure puoi utilizzare determinate tecniche, come il partizionamento. Di seguito sono riportate alcune delle condizioni che possono portare alla limitazione (della larghezza di banda della rete):
+ **Superamento dei limiti di richiesta API da parte del tuo account**: Amazon S3 ha limiti di richiesta API predefiniti basati sul tipo di account e sull'utilizzo. Se per un singolo prefisso viene superato il numero massimo di richieste al secondo, le tue richieste potrebbero essere sottoposte alle limitazione (della larghezza di banda della rete) per evitare il sovraccarico del servizio Amazon S3.
+ **Partizionamento insufficiente dei dati**: se non partizioni correttamente i dati e trasferisci una grande quantità di dati, Amazon S3 può limitare le richieste. Per ulteriori informazioni sul partizionamento, consulta la sezione [Utilizzo del partizionamento](performance-tuning-s3-throttling-optimizing-your-tables.md#performance-tuning-s3-throttling-use-partitioning) in questo documento.
+ **Numero elevato di oggetti di piccole dimensioni**: se possibile, evita molti file di piccole dimensioni. Amazon S3 ha un limite di [5500 richieste GET](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) al secondo per prefisso partizionato e le tue query Athena hanno lo stesso limite. Se in una singola query analizzi milioni di oggetti di piccole dimensioni, è probabile che la tua query venga limitata da Amazon S3.

Per evitare un eccesso di scansione, puoi utilizzare AWS Glue ETL per compattare periodicamente i file oppure partizionare la tabella e aggiungere filtri per le chiavi di partizione. Per ulteriori informazioni, consulta le risorse seguenti.
+ [Come posso configurare un processo AWS Glue ETL per generare file più grandi?](https://aws.amazon.com/premiumsupport/knowledge-center/glue-job-output-large-files/) (*Centro di AWS conoscenza*)
+ [Leggere i file di input in gruppi più grandi](https://docs.aws.amazon.com/glue/latest/dg/grouping-input-files.html) (*Guida per AWS Glue gli sviluppatori*)

# Ottimizzare le tabelle
<a name="performance-tuning-s3-throttling-optimizing-your-tables"></a>

La strutturazione dei dati è importante in caso di problemi di limitazione (della larghezza di banda della rete). Sebbene Amazon S3 sia in grado di gestire grandi quantità di dati, talvolta sopraggiunge una limitazione (della larghezza di banda della rete) a causa del modo in cui i dati sono strutturati.

Le sezioni seguenti mostrano alcuni suggerimenti su come strutturare i dati in Amazon S3 per evitare problemi di limitazione (della larghezza di banda della rete).

## Utilizzo del partizionamento
<a name="performance-tuning-s3-throttling-use-partitioning"></a>

Puoi utilizzare il partizionamento per ridurre le limitazioni (della larghezza di banda della rete) contenendo la quantità di dati a cui accedere in un dato momento. Partizionando i dati su colonne specifiche, puoi distribuire le richieste in modo uniforme su più oggetti e ridurre il numero di richieste per un singolo oggetto. La riduzione della quantità di dati da analizzare migliora le prestazioni delle query e riduce i costi.

Quando crei una tabella, puoi definire le partizioni che fungono da colonne virtuali. Per creare una tabella con partizioni in una dichiarazione `CREATE TABLE`, utilizza la clausola `PARTITIONED BY (column_name data_type)` in modo da definire le chiavi per partizionare i dati.

Per limitare le partizioni analizzate da una query, puoi specificarle come predicati in una clausola `WHERE` della query. Pertanto, le colonne utilizzate frequentemente come filtri sono adatte al partizionamento. In genere è consigliabile partizionare i dati in base agli intervalli di tempo, il che spesso determina uno schema di partizionamento a più livelli.

Nota che anche per il partizionamento sono previsti dei costi. Quando aumenti il numero di partizioni nella tabella, viene aumentato anche il tempo necessario a recuperare ed elaborare i metadati delle partizioni. Pertanto, un partizionamento eccessivo può eliminare i vantaggi derivanti da un partizionamento più oculato. Se i dati sono fortemente disallineati rispetto a un valore di partizione e la maggior parte delle query utilizza tale valore, potresti andare incontro a un sovraccarico aggiuntivo.

Per ulteriori informazioni sul partizionamento in Athena, consulta [Cos'è il partizionamento?](ctas-partitioning-and-bucketing-what-is-partitioning.md).

## Come raggruppare i dati nel bucket
<a name="performance-tuning-s3-throttling-bucket-your-data"></a>

Un altro modo per partizionare i dati consiste nel raggrupparli in bucket all'interno di una singola partizione. Per raggruppare dati nel bucket specifica una o più colonne che contengono le righe che vuoi raggruppare insieme. Quindi sistema quelle righe in più bucket. In questo modo puoi eseguire una query solo sul bucket da leggere, il che riduce il numero di righe di dati da analizzare.

Quando selezioni una colonna da utilizzare per il raggruppamento in bucket, seleziona la colonna con cardinalità elevata (ovvero con molti valori distinti), che è distribuita uniformemente e che viene spesso utilizzata per filtrare i dati. Un esempio di colonna valida da utilizzare per il raggruppamento in bucket è una chiave primaria, ad esempio una colonna di ID.

Per ulteriori informazioni sul raggruppamento in bucket su Athena, consulta [Cos'è il raggruppamento in bucket?](ctas-partitioning-and-bucketing-what-is-bucketing.md).

## Usa gli AWS Glue indici di partizione
<a name="performance-tuning-s3-throttling-use-aws-glue-partition-indexes"></a>

È possibile utilizzare gli indici di AWS Glue partizione per organizzare i dati in una tabella in base ai valori di una o più partizioni. AWS Glue gli indici di partizione possono ridurre il numero di trasferimenti di dati, la quantità di elaborazione dei dati e il tempo di elaborazione delle query.

Un indice di AWS Glue partizione è un file di metadati che contiene informazioni sulle partizioni della tabella, incluse le chiavi di partizione e i relativi valori. L'indice delle partizioni viene archiviato in un bucket Amazon S3 e viene aggiornato automaticamente non appena vengono AWS Glue aggiunte nuove partizioni alla tabella.

Quando è presente un indice di AWS Glue partizione, le query tentano di recuperare un sottoinsieme delle partizioni invece di caricare tutte le partizioni della tabella. Le query sono eseguite solo sul sottoinsieme di dati rilevante per la query.

Quando si crea una tabella in AWS Glue, è possibile creare un indice di partizione su qualsiasi combinazione di chiavi di partizione definite nella tabella. Dopo aver creato uno o più indici di partizione su una tabella, è necessario aggiungere una proprietà alla tabella che abiliti il filtraggio delle partizioni. Quindi, puoi eseguire query sulla tabella da Athena.

*Per informazioni sulla creazione di indici di partizione in AWS Glue, consulta [Working with partition indexes](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html) nella Developer Guide. AWS GlueAWS Glue * Per informazioni su come aggiungere una proprietà di tabella per abilitare il filtraggio delle partizioni, consulta [Ottimizza le query con l'indicizzazione e il AWS Glue filtraggio delle partizioni](glue-best-practices-partition-index.md).

## Come utilizzare la compressione di dati e la suddivisione dei file
<a name="performance-tuning-s3-throttling-use-data-compression-and-file-splitting"></a>

La compressione dei dati può velocizzare le query in maniera significativa se i file hanno dimensioni ottimali o se possono essere suddivisi in gruppi logici. In genere, i rapporti di compressione più elevati richiedono più cicli di CPU per comprimere e decomprimere i dati. Per Athena, è consigliabile utilizzare Apache Parquet o Apache ORC, che comprimono i dati per impostazione predefinita. Per ulteriori informazioni sulla compressione dei dati in Athena, consulta [Usa la compressione in Athena](compression-formats.md).

La suddivisione dei file aumenta il parallelismo consentendo ad Athena di distribuire il processo di lettura di un singolo file tra più lettori. Se un singolo file non è suddivisibile, può leggerlo solo un lettore mentre gli altri lettori sono inattivi. Apache Parquet e Apache ORC supportano anche i file suddivisibili.

## Utilizzo di archivi dati colonnari ottimizzati
<a name="performance-tuning-s3-throttling-use-optimized-columnar-data-stores"></a>

Le prestazioni delle query Athena migliorano in modo significativo se converti i dati in un formato colonnare. Quando generi file colonnari, una tecnica di ottimizzazione da considerare consiste nell'ordinare i dati in base alla chiave di partizione.

Apache Parquet e Apache ORC sono gli archivi dati colonnari e open source comunemente utilizzati. Per informazioni sulla conversione dell'origine dati esistente di Amazon S3 in uno di questi formati, consulta [Converti in formati colonnari](columnar-storage.md#convert-to-columnar).

### Utilizzo di una dimensione di blocco Parquet o di una dimensione di stripe ORC maggiore
<a name="performance-tuning-s3-throttling-use-a-larger-parquet-block-size-or-orc-stripe-size"></a>

Parquet e ORC dispongono di parametri di archiviazione di dati che puoi regolare per l'ottimizzazione. In Parquet, puoi ottimizzare la dimensione dei blocchi. In ORC, puoi ottimizzare la dimensione delle stripe. Più grande è il blocco o la stripe, maggiore è il numero di righe che puoi memorizzare in ciascuno di essi. Per impostazione predefinita, la dimensione del blocco Parquet è di 128 MB e la dimensione della stripe ORC è di 64 MB.

Se una stripe ORC è inferiore a 8 MB (il valore predefinito di `hive.orc.max_buffer_size`), Athena legge l'intera stripe ORC. Questo è il compromesso a cui Athena scende tra la selettività delle colonne e le operazioni di input/output al secondo per stripe di dimensioni inferiori.

Se hai tabelle con un numero molto elevato di colonne, dimensioni ridotte di blocchi o stripe possono comportare una scansione di più dati di quanto sia necessario. In questi casi, le dimensioni maggiori di un blocco possono essere più efficienti.

### Utilizzo di ORC per tipi complessi
<a name="performance-tuning-s3-throttling-use-orc-for-complex-types"></a>

Al momento, quando esegui una query su colonne archiviate in Parquet con tipi di dati complessi (`array`, `map` o `struct`), Athena legge un'intera riga di dati anziché leggere selettivamente solo le colonne specificate. Si tratta di un problema noto di Athena. Per ovviare al problema, prendi in considerazione la possibilità di utilizzare ORC.

### Scelta di un algoritmo di compressione
<a name="performance-tuning-s3-throttling-choose-a-compression-algorithm"></a>

Un altro parametro che puoi configurare è l'algoritmo di compressione sui blocchi di dati. Per informazioni sugli algoritmi di compressione supportati per Parquet e ORC in Athena, consulta [Supporto della compressione Athena](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html).

Per ulteriori informazioni sull'ottimizzazione dei formati di storage a colonne in Athena, consulta la sezione «Ottimizzazione della generazione di archivi dati a colonne» nel post del blog AWS Big Data I [10 migliori](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/) consigli per l'ottimizzazione delle prestazioni per Amazon Athena.

## Utilizzo delle tabelle Iceberg
<a name="performance-tuning-s3-throttling-use-iceberg-tables"></a>

Apache Iceberg è un formato a tabella aperta per set di dati analitici di dimensioni molto grandi concepito per un utilizzo ottimizzato su Amazon S3. Puoi usare le tabelle Iceberg per ridurre la limitazione (della larghezza di banda della rete) in Amazon S3.

Le tabelle Iceberg ti offrono i seguenti vantaggi:
+ Puoi partizionare le tabelle Iceberg su una o più colonne. Ciò ottimizza l'accesso ai dati e riduce la quantità di dati che le query devono scansionare.
+ La modalità di archiviazione di oggetti Iceberg, poiché ottimizza l'utilizzo delle tabelle Iceberg in Amazon S3, può elaborare grandi volumi di dati e carichi di lavoro di query pesanti.
+ Le tabelle Iceberg in modalità di archiviazione di oggetti sono scalabili, resistenti agli errori e durevoli, il che può aiutare a ridurre la limitazione (della larghezza di banda della rete).
+ Con il supporto delle transazioni ACID più utenti possono aggiungere ed eliminare oggetti Amazon S3 in modo atomico.

Per ulteriori informazioni su Apache Iceberg, consulta [Apache Iceberg](https://iceberg.apache.org/). Per informazioni sull'utilizzo delle tabelle Apache Iceberg in Athena, consulta la sezione [Utilizzo delle tabelle Iceberg](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg.html).

# Ottimizzare le query
<a name="performance-tuning-s3-throttling-optimizing-queries"></a>

Utilizza i suggerimenti di questa sezione per ottimizzare le query SQL in Athena.

## Utilizza LIMIT con la clausola ORDER BY
<a name="performance-tuning-s3-throttling-use-limit-with-the-order-by-clause"></a>

La clausola `ORDER BY` restituisce i dati disponendoli in ordine. Ciò richiede che Athena invii tutte le righe di dati a un singolo nodo worker e che quindi ordini le righe. Questo tipo di query può essere eseguito a lungo o addirittura non andare a buon fine.

Per una maggiore efficienza delle query, esamina i *N* valori iniziali o inferiori, quindi utilizza anche una clausola. `LIMIT` Ciò riduce in modo significativo il costo dell'ordinamento, inviando sia l'ordinamento sia le restrizioni ai singoli nodi worker anziché a un singolo worker.

## Ottimizzazione delle clausole JOIN
<a name="performance-tuning-s3-throttling-optimize-join-clauses"></a>

Quando effettui il join di due tabelle, Athena distribuisce la tabella a destra ai nodi worker, quindi trasmette la tabella a sinistra per eseguire il join.

Per questo motivo, specifica la tabella di maggiori dimensioni sul lato sinistro del join e la tabella di dimensioni inferiori sul lato destro del join. In questo modo, Athena utilizza meno memoria ed esegue la query con una latenza inferiore.

Inoltre, nota quanto segue:
+ Quando utilizzi più comandi `JOIN`, specifica le tabelle dalla più grande alla più piccola.
+ Evita i cross join a meno che non siano richiesti dalla query.

## Ottimizzazione delle clausole GROUP BY
<a name="performance-tuning-s3-throttling-optimize-group-by-clauses"></a>

L'operatore `GROUP BY` distribuisce le righe ai nodi worker in base alle colonne `GROUP BY`. Queste colonne hanno un riferimento in memoria e i valori sono confrontati man mano che le righe sono acquisite. I valori sono aggregati insieme quando si trova una corrispondenza con la colonna `GROUP BY`. Considerando il modo di funzionamento di questo processo, è consigliabile ordinare le colonne dalla cardinalità più alta a quella più bassa.

## Utilizzo di numeri anziché di stringhe
<a name="performance-tuning-s3-throttling-use-numbers-instead-of-strings"></a>

Poiché i numeri richiedono meno memoria e sono più veloci da elaborare rispetto alle stringhe, se possibile utilizza numeri anziché stringhe.

## Limitazione del numero di colonne
<a name="performance-tuning-s3-throttling-limit-the-number-of-columns"></a>

Per ridurre la quantità totale di memoria necessaria per archiviare i dati, limita il numero di colonne specificato nella dichiarazione `SELECT`.

## Utilizzo di espressioni regolari anziché di LIKE
<a name="performance-tuning-s3-throttling-use-regular-expressions-instead-of-like"></a>

Le query che includono clausole quali `LIKE '%string%'` su stringhe di grandi dimensioni possono essere molto intense dal punto di vista computazionale. Quando filtri in base a più valori su una colonna di stringhe, utilizza la funzione [regexp\$1like()](https://trino.io/docs/current/functions/regexp.html#regexp_like) e un'espressione regolare. Ciò è particolarmente utile quando confronti un lungo elenco di valori.

## Utilizzo della clausola LIMIT
<a name="performance-tuning-s3-throttling-use-the-limit-clause"></a>

Quando esegui una query, anziché selezionare tutte le colonne, puoi utilizzare la clausola `LIMIT` per restituire solo le colonne necessarie. In questo modo si riducono le dimensioni del set di dati elaborato tramite la pipeline di esecuzione delle query. Le clausole `LIMIT` sono più utili quando esegui query su tabelle con un gran numero di colonne basate su stringhe. Le clausole `LIMIT` sono utili anche quando esegui più join o aggregazioni sulle query.

# Risorse aggiuntive
<a name="performance-tuning-additional-resources"></a>

Per ulteriori informazioni sull'ottimizzazione delle prestazioni in Athena, prendi in considerazione le seguenti risorse:
+ AWS Post sul blog Big Data: [I 10 migliori consigli di ottimizzazione delle prestazioni per Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/).
+ AWS *Post sul blog Big Data: [esegui le query 3 volte più velocemente con un risparmio sui costi fino al 70% sull'ultimo motore Amazon Athena](https://aws.amazon.com/blogs/big-data/run-queries-3x-faster-with-up-to-70-cost-savings-on-the-latest-amazon-athena-engine/) nel AWS Big Data Blog.*
+ AWS Post del blog sui Big Data: [Migliora le query federate con il pushdown dei predicati in Amazon Athena](https://aws.amazon.com/blogs/big-data/improve-federated-queries-with-predicate-pushdown-in-amazon-athena/).
+ Guida per l’utente di Amazon Simple Storage Service: [Modelli di concezione di best practice: ottimizzazione delle prestazioni di Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html).
+ Altri [post su Athena nel blog Big Data AWS](https://aws.amazon.com/blogs/big-data/tag/amazon-athena/). 
+ Fare domanda su [AWS re:Post](https://repost.aws/tags/TA78iVOM7gR62_QqDe2-CmiA/amazon-athena) utilizzando il tag **Amazon Athena**.
+ Consulta gli [argomenti di Athena nel AWS Knowledge Center](https://aws.amazon.com/premiumsupport/knowledge-center/#Amazon_Athena).
+ Contatti Supporto AWS (in Console di gestione AWS, fai clic su **Support**, **Support Center**)