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 prestazioni
Quando si crea una tabella esterna Hive mappata a una tabella DynamoDB, non si utilizza alcuna capacità di lettura o scrittura da DynamoDB. Tuttavia, un'attività di lettura e scrittura nella tabella Hive (ad esempio `INSERT` o `SELECT`) si traduce direttamente in operazioni di lettura e scrittura nella tabella DynamoDB sottostante.
Apache Hive su Amazon EMR implementa la propria logica per bilanciare il carico I/O sulla tabella DynamoDB e cerca di ridurre al minimo la possibilità di superare il throughput assegnato dalla tabella. Al termine di ogni query Hive, Amazon EMR restituisce parametri di runtime, incluso il numero di volte in cui il throughput assegnato è stato superato. È possibile utilizzare queste informazioni, insieme alle CloudWatch metriche sulla tabella DynamoDB, per migliorare le prestazioni nelle richieste successive.
La console di Amazon EMR fornisce strumenti di monitoraggio di base per il tuo cluster. Per maggiori informazioni, consulta [Visualizzazione e monitoraggio di un cluster](https://docs.aws.amazon.com/ElasticMapReduce/latest/ManagementGuide/emr-manage-view.html) nella *Guida alla gestione di Amazon EMR*.
È inoltre possibile monitorare i processi cluster e Hadoop utilizzando strumenti basati sul Web, come Hue, Ganglia e l'interfaccia Web Hadoop. Per ulteriori informazioni, consulta [Visualizzazione delle interfacce Web ospitate nei cluster Amazon EMR](https://docs.aws.amazon.com/ElasticMapReduce/latest/ManagementGuide/emr-web-interfaces.html) nella *Guida alla gestione di Amazon EMR*.
In questa sezione vengono descritti i passaggi che è possibile eseguire per ottimizzare le operazioni Hive nelle tabelle esterne di DynamoDB.
**Topics**
+ [Velocità di trasmissione effettiva assegnata a DynamoDB](EMRforDynamoDB.PerformanceTuning.Throughput.md)
+ [Regolazione dei mappatori](EMRforDynamoDB.PerformanceTuning.Mappers.md)
+ [Argomenti aggiuntivi](EMRforDynamoDB.PerformanceTuning.Misc.md)
# Velocità di trasmissione effettiva assegnata a DynamoDB
Quando si emettono istruzioni HiveQL sulla tabella DynamoDB esterna, la proprietà `DynamoDBStorageHandler` crea le richieste API DynamoDB di basso livello appropriate, che utilizzano la velocità effettiva di provisioning. Se nella tabella DynamoDB non vi è sufficiente capacità di lettura o scrittura, la richiesta verrà limitata, con conseguente rallentamento delle prestazioni HiveQL. Per questo motivo, è consigliabile assicurarsi che la tabella disponga di capacità di throughput sufficiente.
Ad esempio, si supponga di avere 100 unità di capacità di lettura assegnate per la tabella DynamoDB. Questo ti permetterà di leggere 409.600 byte al secondo (dimensioni dell'unità di capacità di lettura 100 × 4 KB). Supponiamo ora che la tabella contenga 20 GB di dati (21.474.836.480 byte) e che si desideri utilizzare la funzione `SELECT` per selezionare tutti i dati utilizzando HiveQL. È possibile stimare quanto tempo impiegherà la query per l'esecuzione in questo modo:
* 21.474.836.480 / 409.600 = 52.429 secondi = 14,56 ore *
In questo scenario, la tabella DynamoDB è un collo di bottiglia. Non aiuterà ad aggiungere altri nodi Amazon EMR perché il throughput Hive è limitato a soli 409.600 byte al secondo. L'unico modo per ridurre il tempo necessario per l'istruzione `SELECT` è di aumentare la capacità di lettura assegnata della tabella DynamoDB.
È possibile eseguire un calcolo simile per stimare il tempo necessario per caricare dati in massa in una tabella esterna Hive mappata a una tabella DynamoDB. Determina il numero totale di unità di capacità di scrittura necessarie per elemento (meno di 1 KB = 1, 1-2 KB = 2, ecc.) e moltiplicalo per il numero di elementi da caricare. Il risultato sarà il numero di unità di capacità di scrittura. Dividi questo risultato per il numero di unità di capacità di scrittura allocate al secondo. Ciò produrrà il numero di secondi necessari per caricare la tabella.
È necessario monitorare regolarmente le CloudWatch metriche della tabella. Per una rapida panoramica nella console DynamoDB, scegli la tabella e seleziona la scheda **Parametri**. Da qui, è possibile visualizzare le unità di capacità di lettura e scrittura consumate e le richieste di lettura e scrittura che sono state limitate.
## Capacità di lettura
Per impostazione predefinita, Amazon EMR gestisce il carico di richieste sulla tabella DynamoDB, in base alle impostazioni di velocità effettiva assegnata della tabella. Tuttavia, se si nota un grande numero di messaggi `ProvisionedThroughputExceeded` nell'output del processo, è possibile regolare la velocità di lettura predefinita. A tale scopo, puoi modificare la variabile di configurazione `dynamodb.throughput.read.percent`. Puoi utilizzare il comando `SET` per impostare questa variabile al prompt dei comandi di Hive:
```
1. SET dynamodb.throughput.read.percent=1.0;
```
Questa variabile persiste nella sessione di Hive corrente. Se esci da Hive e torni in un secondo momento, `dynamodb.throughput.read.percent`tornerà al suo valore predefinito.
Il valore di `dynamodb.throughput.read.percent` può essere compreso tra `0.1` e `1.5`, estremi inclusi. `0.5` rappresenta la velocità di lettura predefinita, il che significa che Hive cercherà di consumare metà della capacità di lettura della tabella. Se si aumenta il valore sopra `0.5`, Hive aumenterà il tasso di richiesta; diminuendo il valore al di sotto di `0.5` riduce la frequenza di richiesta di lettura. La velocità di lettura effettiva varia in base a fattori come la presenza di una distribuzione uniforme delle chiavi nella tabella DynamoDB.
Se si nota che Hive spesso esaurisce la capacità di lettura sottoposta a provisioning della tabella o se le richieste di lettura sono troppo limitate, provare a ridurre `dynamodb.throughput.read.percent` al di sotto di `0.5`. Se si dispone di capacità di lettura sufficiente nella tabella e si desidera che le operazioni HiveQL siano più reattive, è possibile impostare il valore sopra `0.5`.
## Capacità di scrittura
Per impostazione predefinita, Amazon EMR gestisce il carico di richieste sulla tabella DynamoDB, in base alle impostazioni di velocità effettiva assegnata della tabella. Tuttavia, se si nota un grande numero di messaggi `ProvisionedThroughputExceeded`nell'output del processo, è possibile regolare la velocità di scrittura predefinita. A tale scopo, puoi modificare la variabile di configurazione `dynamodb.throughput.write.percent`. Puoi utilizzare il comando `SET` per impostare questa variabile al prompt dei comandi di Hive:
```
1. SET dynamodb.throughput.write.percent=1.0;
```
Questa variabile persiste nella sessione di Hive corrente. Se esci da Hive e torni in un secondo momento, `dynamodb.throughput.write.percent`tornerà al suo valore predefinito.
Il valore di `dynamodb.throughput.write.percent` può essere compreso tra `0.1` e `1.5`, estremi inclusi. `0.5` rappresenta la velocità di scrittura predefinita, il che significa che Hive cercherà di consumare metà della capacità di scrittura della tabella. Se si aumenta il valore sopra `0.5`, Hive aumenterà il tasso di richiesta; diminuendo il valore al di sotto di `0.5` riduce la frequenza di richiesta di scrittura. La velocità di scrittura effettiva varia in base a fattori come la presenza di una distribuzione uniforme delle chiavi nella tabella DynamoDB.
Se si nota che Hive spesso esaurisce la capacità di lettura sottoposta a provisioning della tabella o se le richieste di scrittura sono troppo limitate, provare a ridurre `dynamodb.throughput.write.percent` al di sotto di `0.5`. Se si dispone di capacità di scrittura sufficiente nella tabella e si desidera che le operazioni HiveQL siano più reattive, è possibile impostare il valore sopra `0.5`.
Quando scrivi dati in DynamoDB utilizzando Hive, assicurati che il numero delle unità di capacità di scrittura sia maggiore del numero di mappatori del cluster. Ad esempio, si consideri un cluster Amazon EMR composto da 10 nodi *m1.xlarge*. Il tipo di nodo *m1.xlarge* fornisce 8 attività di mappatura, quindi il cluster avrebbe un totale di 80 mappatori (10 × 8). Se la tabella DynamoDB ha meno di 80 unità di capacità di scrittura, un'operazione di scrittura Hive potrebbe consumare tutta la velocità effettiva di scrittura per tale tabella.
Per determinare il numero di mappatori per i tipi di nodi di Amazon EMR, consulta [Configurazione attività](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hadoop-task-config.html) nella *Guida per gli sviluppatori di Amazon EMR*.
Per ulteriori informazioni sui mappatori, consulta [Regolazione dei mappatori](EMRforDynamoDB.PerformanceTuning.Mappers.md).
# Regolazione dei mappatori
Quando Hive avvia un processo Hadoop, il processo viene elaborato da una o più attività di mappatura. Supponendo che la tabella DynamoDB disponga di capacità di throughput sufficiente, è possibile modificare il numero di mappatori nel cluster, migliorando potenzialmente le prestazioni.
**Nota**
Il numero di attività di mappatura utilizzate in un processo Hadoop è influenzato dalle *suddivisioni degli input*, dove Hadoop suddivide i dati in blocchi logici. Se Hadoop non esegue un numero sufficiente di suddivisioni di input, le operazioni di scrittura potrebbero non essere in grado di consumare tutta la velocità effettiva di scrittura disponibile nella tabella DynamoDB.
## Aumento del numero di mappatori
Ogni mappatore in un Amazon EMR ha una velocità massima di lettura di 1 MiB al secondo. Il numero di mappatori in un cluster dipende dalla dimensione dei nodi nel cluster. Per informazioni sulle dimensioni dei nodi e sul numero di mappatori per nodo, consulta [Configurazione attività](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hadoop-task-config.html) nella *Guida per gli sviluppatori di Amazon EMR*.
Se la tabella DynamoDB dispone di un'ampia capacità di throughput per le letture, è possibile provare ad aumentare il numero di mappatori completando una delle seguenti operazioni:
+ Aumentare la dimensione dei nodi nel cluster. Ad esempio, se il cluster utilizza i nodi *m1.large*(tre mappatori per nodo), puoi provare ad eseguire l'aggiornamento ai nodi *m1.xlarge* (otto mappatori per nodo).
+ Aumentare il numero di nodi del cluster. Ad esempio, se si dispone di un cluster a tre nodi di nodi *m1.xlarge*, disponi di un totale di 24 mappatori disponibili. Se si dovesse raddoppiare la dimensione del cluster, con lo stesso tipo di nodo, si avrebbero 48 mappatori.
È possibile utilizzare il Console di gestione AWS per gestire la dimensione o il numero di nodi nel cluster. Per rendere effettive le modifiche, potrebbe essere necessario riavviare il cluster.
In alternativa, puoi aumentare il numero di mappatori modificando il parametro di configurazione Hadoop `mapred.tasktracker.map.tasks.maximum`. Questo è un parametro Hadoop, non un parametro Hive. Non pertanto è possibile modificarlo in modo interattivo dal prompt dei comandi. Se si aumenta il valore di `mapred.tasktracker.map.tasks.maximum`, è possibile aumentare il numero di mappatori senza aumentare la dimensione o il numero di nodi. Tuttavia, se si imposta il valore troppo alto, è possibile che i nodi del cluster esauriscano la memoria.
È possibile impostare il valore per `mapred.tasktracker.map.tasks.maximum` come operazione di bootstrap quando si avvia per la prima volta il cluster Amazon EMR. Per ulteriori informazioni, consulta [(Facoltativo) Creazione di operazioni di bootstrap per l'installazione di software aggiuntivo](https://docs.aws.amazon.com/ElasticMapReduce/latest/ManagementGuide/emr-plan-bootstrap.html) nella *Guida alla gestione di Amazon EMR*.
## Diminuzione del numero di mappatori
Se si utilizza l'istruzione `SELECT` per selezionare i dati da una tabella Hive esterna mappata a DynamoDB, il processo Hadoop può utilizzare tutte le attività necessarie, fino al numero massimo di mappatori nel cluster. In questo scenario, è possibile che una query Hive a lunga esecuzione possa utilizzare tutta la capacità di lettura assegnata della tabella DynamoDB, con un impatto negativo su altri utenti.
È possibile utilizzare il parametro `dynamodb.max.map.tasks` per impostare un limite superiore per le attività della mappa:
```
SET dynamodb.max.map.tasks=1
```
Questo valore deve essere maggiore o uguale a 1. Quando Hive elabora la query, il processo Hadoop risultante utilizzerà non più di `dynamodb.max.map.tasks` durante la lettura dalla tabella DynamoDB.
# Argomenti aggiuntivi
Di seguito sono riportati alcuni altri modi per ottimizzare le applicazioni che utilizzano Hive per accedere a DynamoDB.
## Retry duration (Durata nuovi tentativi)
Per impostazione predefinita, Hive rieseguirà un processo Hadoop se non ha restituito alcun risultato da DynamoDB entro due minuti. È possibile regolare questo intervallo modificando il parametro `dynamodb.retry.duration`:
```
1. SET dynamodb.retry.duration=2;
```
Il valore deve essere un numero intero diverso da zero, che rappresenta il numero di minuti nell'intervallo di nuovi tentativi. Il valore predefinito per `dynamodb.retry.duration` è 2 (minuti).
## Richieste di dati in parallelo
Molteplici richieste di dati, sia da parte di più utenti sia da più applicazioni verso un'unica tabella, possono far esaurire il throughput di lettura assegnato e rallentare le prestazioni.
## Durata dei processi
La consistenza dei dati in DynamoDB dipende dall'ordine delle operazioni di lettura e scrittura di ciascun nodo. Quando una query Hive è in avanzamento, un'altra applicazione potrebbe caricare nuovi dati nella tabella DynamoDB oppure modificare o eliminare dati esistenti. In questo caso, i risultati della query Hive potrebbe non riflettere le modifiche effettuate ai dati durante l'esecuzione della query.
## Ora delle richieste
Le prestazioni possono essere migliorate pianificando query Hive che accedono a una tabella DynamoDB quando la richiesta nella tabella DynamoDB è minore. Ad esempio, se la maggior parte degli utenti della tua applicazione vive a San Francisco, potresti decidere di esportare i dati giornalieri alle 4:00 PST, quando la maggior parte degli utenti dorme e non aggiorna i record del database DynamoDB.