Avvisi di Apache HBase in Azure HDInsight

Questo articolo descrive diversi avvisi che consentono di ottimizzare le prestazioni di Apache HBase in Azure HDInsight.

Ottimizzare HBase per leggere i dati scritti più recentemente

Se il caso di utilizzo prevede la lettura dei dati scritti più recentemente da HBase, questo avviso può essere utile. Per prestazioni elevate, è ottimale che le letture HBase vengano gestite da memstore, anziché dall'archiviazione remota.

L'avviso di query indica che per una determinata famiglia di colonne in una tabella > il 75% delle letture vengono servite da memstore. Questo indicatore suggerisce che, anche se viene eseguito un flush nel memstore, è necessario accedere al file recente e tale file deve trovarsi nella cache. I dati sono prima scritti nel memstore il sistema accede ai dati recenti. È possibile che i thread del flusher di HBase interni rilevino che una determinata area abbia raggiunto le dimensioni (predefinite) di 128 M e può iniziare a scaricare. Questo scenario si verifica anche con i dati più recenti scritti quando la dimensione di memstore era di circa 128 M. Pertanto, una lettura successiva di tali record recenti può richiedere una lettura di file anziché da memstore. È quindi consigliabile ottimizzare il fatto che anche i dati recenti scaricati di recente possano 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 valore di hbase.hstore.compactionThreshold in modo da evitare la compattazione dall'inizio. Per impostazione predefinita, questo valore è 3. È possibile aumentarlo a un valore superiore, ad esempio 10.

  3. Se si segue il passaggio 2 e si imposta compactionThreshold, cambiare hbase.hstore.compaction.max in un valore superiore, ad esempio 100, e aumentare anche il valore per la configurazione hbase.hstore.blockingStoreFiles, ad esempio 300.

  4. Se si è certi che sarà necessario leggere solo i dati recenti, impostare la configurazione hbase.rs.cachecompactedblocksonwrite su ON. Questa configurazione indica al sistema che, anche se si verifica una compattazione, i dati rimangono nella cache. Le configurazioni possono essere impostate anche a livello di famiglia.

    Nella shell HBase eseguire il comando seguente per impostare la configurazione hbase.rs.cachecompactedblocksonwrite:

    alter '<TableName>', {NAME => '<FamilyName>', CONFIGURATION => {'hbase.hstore.blockingStoreFiles' => '300'}}
    
  5. La cache dei blocchi può essere disattivata per una determinata famiglia in una tabella. Assicurarsi che sia impostata su ON per le famiglie con letture di dati più recenti. Per impostazione predefinita, la cache dei blocchi è attivata per tutte le famiglie in una tabella. Se la cache dei blocchi è stata disabilitata per una famiglia ed è necessario attivarla, usare il comando alter dalla shell HBase.

    Queste configurazioni consentono di garantire che i dati siano disponibili nella cache e che i dati recenti non vengano sottoposti a compattazione. Se è possibile usare una TTL nello scenario, è consigliabile usare la compattazione a livello di data. Per altre informazioni, vedere Guida di riferimento di Apache HBase: compattazione a livello di data

Ottimizzare la coda di flush

Questo avviso indica che i flush di HBase potrebbero richiedere l'ottimizzazione. La configurazione corrente per i gestori di flush potrebbe non essere sufficientemente elevata per essere gestita con il traffico di scrittura che potrebbe causare un rallentamento dei flush.

Nell'interfaccia utente del server di area, notare se la coda di flush aumenta oltre 100. Questa soglia indica che i flush sono lenti e potrebbe essere necessario ottimizzare la configurazione hbase.hstore.flusher.count. Per impostazione predefinita, il valore è 2. Assicurarsi che i thread di svuotamento massimi non aumentino oltre 6.

Vedere anche se si dispone di una raccomandazione per l'ottimizzazione del conteggio delle regioni. In caso affermativo, è consigliabile provare l'ottimizzazione dell'area per verificare se ciò consente flush più rapidi. In caso contrario, l'ottimizzazione dei thread di svuotamento può essere utile.

Ottimizzazione del numero di aree

L'avviso di ottimizzazione del conteggio delle aree indica che HBase ha bloccato gli aggiornamenti e che il conteggio delle aree può essere superiore alle dimensioni dell'heap supportate in modo ottimale. È possibile ottimizzare le dimensioni dell'heap, le dimensioni memstore e il conteggio delle aree dell'heap.

Scenario di esempio:

  • Si supponga che le dimensioni dell'heap per il server di area siano 10 GB. Per impostazione predefinita, hbase.hregion.memstore.flush.size è 128M. Il valore predefinito per hbase.regionserver.global.memstore.size è 0.4. Ciò significa che, su 10 GB, vengono allocati 4 GB 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 in quel caso il numero massimo di aree in questa configurazione è di 32. Se un determinato server di area è configurato per avere 32 aree, il sistema evita di bloccare gli aggiornamenti.

  • Con queste impostazioni applicate, il numero di aree è 100. memstore globale di 4 GB è 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 flush e dimensioni inferiori dell'ordine < di 40 MB. La presenza di molti thread di flush potrebbe aumentare la velocità di flush di hbase.hstore.flusher.count.

L'avviso significa che sarebbe opportuno riconsiderare il numero di aree per server, le dimensioni dell'heap e la configurazione delle dimensioni memstore globali insieme all'ottimizzazione dei thread di flush, per evitare che gli aggiornamenti vengano bloccati.

Ottimizzazione della coda di compattazione

Se la coda di compattazione HBase aumenta fino a più di 2000 e si verifica periodicamente, è possibile aumentare i thread di compattazione a un valore maggiore.

Quando è presente un numero eccessivo di file per la compattazione, ciò può comportare un maggiore utilizzo dell'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 meno recenti le configurazioni di compattazione correlate alla limitazione potrebbero causare una riduzione della velocità di compattazione.

Controllare le configurazioni hbase.hstore.compaction.throughput.lower.bound e hbase.hstore.compaction.throughput.higher.bound. Se sono già impostate su 50 M e 100 M, lasciarle invariate. Tuttavia, se queste impostazioni sono state configurate con un valore inferiore (nel caso dei cluster meno recenti), modificare i limiti rispettivamente a 50 M e 100 M.

Le configurazioni sono hbase.regionserver.thread.compaction.small e hbase.regionserver.thread.compaction.large (le impostazioni predefinite sono di 1 ciascuna). Limitare il valore massimo per questa configurazione in modo che sia minore di 3.

Scansione completa della tabella

L'avviso di scansione completa della tabella indica che oltre il 75% delle scansioni rilasciate sono analisi complete di tabelle/aree. È possibile rivedere il modo in cui il codice chiama le scansioni per migliorare le prestazioni delle query. Considerare le procedure seguenti:

  • Impostare la riga di avvio e arresto appropriata per ogni scansione.

  • Usare l'API MultiRowRangeFilter in modo che sia possibile eseguire query su intervalli diversi in una chiamata di scansione. Per altre informazioni, vedere la documentazione sull’API MultiRowRangeFilter.

  • Nei casi in cui è necessaria una scansione completa di tabelle o aree, verificare se è possibile evitare l'utilizzo della cache per tali query, in modo che altre query che usano la cache evitino di rimuovere i blocchi a caldo. Per fare in modo che le scansioni non usino la cache, usare l'API scansione con l'opzione setCaching(false) nel codice:

    scan#setCaching(false)
    

Passaggi successivi

Ottimizzare Apache HBase con Ambari