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. I thread del flusher interno di HBase possono rilevare che una determinata regione ha raggiunto la dimensione di 128M (predefinita) e possono attivare uno svuotamento. 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. Aumenta il valore di hbase.hstore.compactionThreshold per evitare che la compattazione si attivi. 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 livelli temporali. Per ulteriori informazioni, vedere Guida di riferimento di Apache HBase: compattazione gerarchica dei dati

Ottimizzare la coda di svuotamento

Questo avviso indica che i flush di HBase potrebbero richiedere una regolazione. La configurazione corrente dei gestori di flush potrebbe non essere sufficientemente alta per gestire il traffico di scrittura, il che potrebbe causare un rallentamento dei flush.

Nell'interfaccia utente del server di regione, 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. Assicurati che i thread di flusher 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 flusher 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 la dimensione dell'heap, la dimensione memstore e il conteggio delle regioni.

Scenario di esempio:

• Supponiamo che la dimensione dell'heap per il server di regione sia di 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. Effettivamente, ogni regione ha solo 40 MB per memstore. Quando le scritture sono uniformi, il sistema esegue spesso flush ed effettua operazioni di dimensioni inferiori dell'ordine di grandezza 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 cresce oltre 2000 ed è un fenomeno che si verifica periodicamente, puoi aumentare il numero di thread di compattazione a un valore più alto.

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 effettuate sono scansioni complete di tabelle/regioni. È 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, così che altre query che usano la cache non scartino i blocchi frequentemente utilizzati. 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