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

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:

  1. Impostare hbase.rs.cacheblocksonwrite su true. Questa configurazione predefinita in HDInsight HBase è true, quindi verificare che non venga reimpostata su false.

  2. Aumentare il hbase.hstore.compactionThreshold valore in modo da evitare che la compattazione venga avviata. Per impostazione predefinita, questo valore è impostato su 3. È possibile aumentarlo in un valore più alto, ad esempio 10.

  3. 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 configurazione hbase.hstore.blockingStoreFiles in valore superiore, ad esempio 100300.

  4. 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'}}
    
  5. 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.size128M. 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 per memstore (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 per memstore. 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.countdi 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)
    

Passaggi successivi

Ottimizzare Apache HBase con Ambari