Advisor apache HBase in Azure HDInsight
Questo articolo descrive diversi advisor per ottimizzare le prestazioni di Apache HBase in Azure HDInsight.
Ottimizzare HBase per leggere i dati scritti più di recente
Se il caso d'uso prevede la lettura dei dati scritti più di recente da HBase, questo avviso può essere utile. Per prestazioni elevate, è ottimale che le letture HBase vengano gestite da , anziché dall'archiviazione memstore
remota.
L'avviso di query indica che per una determinata famiglia di colonne in una tabella > del 75% vengono letti da memstore
. Questo indicatore suggerisce che anche se un flusso si verifica nel memstore
file recente deve essere accessibile e che deve essere nella cache. I dati sono prima scritti nel memstore
sistema accedono ai dati recenti. È possibile che i thread di scaricamento HBase interni rilevino che un'area specifica ha raggiunto le dimensioni predefinite di 128M e può attivare uno scaricamento. Questo scenario accade anche ai dati più recenti scritti quando la memstore
dimensione è di circa 128M. Pertanto, una lettura successiva di tali record recenti può richiedere una lettura di file anziché da memstore
. È quindi consigliabile ottimizzare che anche i dati recenti scaricati di recente possono risiedere nella cache.
Per ottimizzare i dati recenti nella cache, prendere in considerazione le impostazioni di configurazione seguenti:
Impostare
hbase.rs.cacheblocksonwrite
sutrue
. Questa configurazione predefinita in HDInsight HBase ètrue
, quindi verificare che non venga reimpostata sufalse
.Aumentare il
hbase.hstore.compactionThreshold
valore in modo da evitare che la compattazione venga avviata. Per impostazione predefinita, questo valore è impostato su3
. È possibile aumentarlo in un valore più alto, ad esempio10
.Se si segue il passaggio 2 e si imposta compattazioneThreshold, passare
hbase.hstore.compaction.max
a un valore superiore, ad esempio , e aumentare anche il valore per la configurazionehbase.hstore.blockingStoreFiles
in valore superiore, ad esempio100
300
.Se si è certi che sia necessario leggere solo i dati recenti, impostare
hbase.rs.cachecompactedblocksonwrite
la configurazione su ON. Questa configurazione indica al sistema che, anche se si verifica la compattazione, i dati rimangono nella cache. Le configurazioni possono essere impostate anche a livello di famiglia.In HBase Shell eseguire il comando seguente per impostare
hbase.rs.cachecompactedblocksonwrite
la configurazione:alter '<TableName>', {NAME => '<FamilyName>', CONFIGURATION => {'hbase.hstore.blockingStoreFiles' => '300'}}
La cache di blocchi può essere disattivata per una determinata famiglia in una tabella. Assicurarsi che sia attivato per le famiglie con letture dei dati più recenti. Per impostazione predefinita, la cache di blocchi viene attivata per tutte le famiglie in una tabella. Nel caso in cui sia stata disabilitata la cache dei blocchi per una famiglia ed è necessario attivarla, usare il comando alter dalla shell hbase.
Queste configurazioni consentono di assicurarsi che i dati siano disponibili nella cache e che i dati recenti non subisca la compattazione. Se è possibile un TTL nello scenario, è consigliabile usare la compattazione a livelli di data. Per altre informazioni, vedere Guida di riferimento di Apache HBase: Compattazione a livelli di data
Ottimizzare la coda di scaricamento
Questo avviso indica che gli scaricamenti HBase potrebbero richiedere l'ottimizzazione. La configurazione corrente per i gestori di scaricamento potrebbe non essere abbastanza elevata per gestire il traffico di scrittura che potrebbe causare un rallentamento degli scaricamenti.
Nell'interfaccia utente del server di area si noti se la coda di scaricamento aumenta oltre 100. Questa soglia indica che gli scaricamenti sono lenti e potrebbe essere necessario ottimizzare la hbase.hstore.flusher.count
configurazione. Per impostazione predefinita, il valore è 2. Assicurarsi che i thread max flusher non aumentino oltre 6.
Inoltre, vedere se si ha un consiglio per l'ottimizzazione del conteggio delle regioni. In caso affermativo, ti consigliamo di provare l'ottimizzazione dell'area per verificare se ciò consente di scaricare più velocemente. In caso contrario, l'ottimizzazione dei thread di scaricamento può essere utile.
Ottimizzazione del numero di aree
L'avviso di ottimizzazione del conteggio delle aree indica che HBase ha bloccato gli aggiornamenti e il numero di aree può essere maggiore delle dimensioni dell'heap supportate in modo ottimale. È possibile ottimizzare le dimensioni dell'heap, memstore
le dimensioni e il conteggio delle regioni.
Come scenario di esempio:
Si supponga che le dimensioni dell'heap per il server di area siano pari a 10 GB. Per impostazione predefinita, è
hbase.hregion.memstore.flush.size
128M
. Il valore predefinito per la proprietàhbase.regionserver.global.memstore.size
è0.4
. Ciò significa che al di fuori del 10 GB, 4 GB viene allocato permemstore
(a livello globale).Si supponga che sia presente una distribuzione uniforme del carico di scrittura in tutte le aree e presupponendo che ogni area cresca fino a 128 MB solo il numero massimo di aree in questa configurazione è
32
aree. Se un determinato server di area è configurato per avere 32 aree, il sistema evita meglio di bloccare gli aggiornamenti.Con queste impostazioni, il numero di aree è 100. Il 4 GB globale
memstore
è ora suddiviso in 100 aree. In modo efficace ogni area ottiene solo 40 MB permemstore
. Quando le scritture sono uniformi, il sistema esegue spesso scaricamenti e dimensioni inferiori dell'ordine < di 40 MB. La presenza di molti thread di scaricamento potrebbe aumentare la velocitàhbase.hstore.flusher.count
di scaricamento.
La consulenza significa che sarebbe consigliabile riconsiderare il numero di aree per server, le dimensioni dell'heap e la configurazione delle dimensioni globali memstore
insieme all'ottimizzazione dei thread di scarico per evitare che gli aggiornamenti vengano bloccati.
Ottimizzazione della coda di compattazione
Se la coda di compattazione HBase cresce a più di 2000 e si verifica periodicamente, è possibile aumentare i thread di compattazione a un valore maggiore.
Quando c'è un numero eccessivo di file per la compattazione, può causare un utilizzo più heap correlato al modo in cui i file interagiscono con il file system di Azure. Quindi è meglio completare la compattazione il più rapidamente possibile. Alcune volte nei cluster precedenti le configurazioni di compattazione correlate alla limitazione potrebbero causare una velocità di compattazione più lenta.
Controllare le configurazioni hbase.hstore.compaction.throughput.lower.bound
e hbase.hstore.compaction.throughput.higher.bound
. Se sono già impostati su 50M e 100M, lasciarli così come è. Tuttavia, se sono state configurate tali impostazioni in un valore inferiore (ovvero con i cluster meno recenti), modificare rispettivamente i limiti su 50M e 100M.
Le configurazioni sono e hbase.regionserver.thread.compaction.large
(le impostazioni predefinite sono hbase.regionserver.thread.compaction.small
1 ogni).
Limitare il valore massimo per questa configurazione a meno di 3.
Analisi completa tabella
L'avviso di analisi completa della tabella indica che oltre il 75% delle analisi rilasciate sono analisi complete di tabella/area. È possibile rivedere il modo in cui il codice chiama le analisi per migliorare le prestazioni delle query. Prendere in considerazione le procedure seguenti:
Impostare la riga iniziale e arrestata appropriata per ogni analisi.
Usare l'API MultiRowRangeFilter in modo che sia possibile eseguire query su intervalli diversi in una chiamata di analisi. Per altre informazioni, vedere Documentazione dell'API MultiRowRangeFilter.
Nei casi in cui è necessaria un'analisi completa di tabella o area, verificare se è possibile evitare l'utilizzo della cache per tali query, in modo che altre query che usano la cache potrebbero non rimuovere i blocchi che sono ad accesso frequente. Per assicurarsi che le analisi non usino la cache, usare l'API di analisi con l'opzione setCaching(false) nel codice:
scan#setCaching(false)