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

Ottimizza i dati

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

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.

Scegli le chiavi di partizione che supporteranno le query

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

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.

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.

Utilizzo della proiezione di partizioni

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.

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.

Per maggiori informazioni sulla proiezione delle partizioni, consulta Usa la proiezione delle partizioni con Amazon Athena.

Utilizzo degli indici di partizioni

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 Guida per gli AWS Glue sviluppatori e Migliorare le prestazioni delle query di Amazon Athena utilizzando gli indici delle AWS Glue Data Catalog partizioni nel Big Data Blog.AWS

Usalo sempre come tipo per le chiavi di partizione STRING

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

Se rimuovi dati da una partizione su Amazon S3 (ad esempio, utilizzando il ciclo di vita 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.

Partizioni di query per uguaglianza

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.

Evitare l'uso MSCK REPAIR TABLE per la manutenzione delle partizioni

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

È meglio gestire le partizioni manualmente utilizzando i AWS Glue Data Catalog APIscrawlerALTER TABLE ADD PARTITION, o AWS Glue . In alternativa, puoi utilizzare la proiezione delle partizioni, che rimuove del tutto il bisogno di gestire le partizioni. Per ulteriori informazioni, consulta Usa la proiezione delle partizioni con Amazon Athena.

Come verificare che le query siano compatibili con lo schema di partizionamento

Puoi verificare in anticipo quali partizioni saranno scansionate da una query utilizzando la dichiarazione EXPLAIN. 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 Usare EXPLAIN e EXPLAIN ANALYZE in Athena e Comprendi i risultati della dichiarazione di Athena EXPLAIN.

Utilizzo di formati di file colonnari

I formati di file a colonne, come Parquet, ORC sono progettati 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:

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, 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 C ORC sono organizzati internamente per gruppi di file (Parquet) e strisce (). 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 orORC, puoi usare AWS Glue ETL o Athena. Per ulteriori informazioni, consulta Converti in formati colonnari.

Compressione di dati

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 offre buoni rapporti di compressione e supporta molti altri strumenti e servizi. Il formato zstd (Zstandard) è un formato di compressione più recente con un buon equilibrio tra prestazioni e rapporto di compressione.

Quando comprimi file di testo, ad JSON esempio CSV dati, cerca di raggiungere un equilibrio tra il numero di file e la dimensione dei file. 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, è 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.

Come utilizzare il raggruppamento in bucket delle ricerche su chiavi con cardinalità elevata

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 di raggruppare i blocchi quando le query cercano spesso più valori in una colonna

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 Usa il partizionamento e il bucketing.

Come evitare di avere un numero eccessivo di file

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:

Come evitare gerarchie di archiviazione aggiuntive oltre alla partizione

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.

Utilizzo di SymlinkTextInputFormat solo quando necessario

L'utilizzo della tecnica 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.