Condividi tramite

Risolvere i problemi di prestazioni di Apache HBase in Azure HDInsight

  • Articolo

Questo articolo descrive varie linee guida per l'ottimizzazione delle prestazioni di Apache HBase e suggerimenti per ottenere prestazioni ottimali in Azure HDInsight. Molti di questi suggerimenti dipendono dal carico di lavoro specifico e dal modello di lettura/scrittura/analisi. Prima di applicare le modifiche di configurazione in un ambiente di produzione, testarle accuratamente.

Informazioni dettagliate sulle prestazioni di HBase

Il collo di bottiglia principale nella maggior parte dei carichi di lavoro HBase è il log WAL (Write Ahead Log), che influisce gravemente sulle prestazioni di scrittura. HBase di HDInsight ha un modello di calcolo di archiviazione separato. I dati vengono archiviati in remoto in Archiviazione di Azure, anche se le macchine virtuali ospitano i server di area. Fino a poco tempo fa, anche i file WAL venivano scritti nell’Archiviazione di Azure. In HDInsight questo comportamento amplifica questo collo di bottiglia. La funzionalità Scritture accelerate è progettata per risolvere questo problema. Scrive il file WAL nei dischi gestiti da SSD Premium di Azure. Ciò offre enormi vantaggi per le prestazioni di scrittura e consente di risolvere molti problemi riscontrati da alcuni dei carichi di lavoro a elevato utilizzo di scrittura.

Per ottenere un miglioramento significativo delle operazioni di lettura usare l'account di archiviazione BLOB in blocchi Premium come archiviazione remota. Questa opzione è possibile solo se è abilitata la funzionalità WAL.

Compattazione

Fondamentalmente la comunità concorda nel ritenere che la compattazione rappresenta un altro potenziale collo di bottiglia. Per impostazione predefinita, la compattazione principale è disabilitata nei cluster HBase di HDInsight. La compattazione è disabilitata perché, anche se si tratta di un processo a elevato utilizzo di risorse, i clienti hanno la massima flessibilità per pianificarla in base ai carichi di lavoro. Ad esempio, è possibile pianificarla durante le ore di minore attività. Inoltre, la località dei dati non è un problema perché l'archiviazione è remota (supportata da Archiviazione di Azure), anziché in un HDFS locale (Hadoop Distributed File System).

I clienti devono pianificare la compattazione principale in base alle loro esigenze. Se non viene eseguita questa manutenzione, la compattazione influirà negativamente sulle prestazioni di lettura a lungo termine.

Nelle operazioni di analisi, latenze medie molto superiori a 100 millisecondi sono motivo di preoccupazione. Controllare se la compattazione principale è stata pianificata in modo accurato.

Carico di lavoro Apache Phoenix

Rispondere alle domande seguenti consente di comprendere meglio il carico di lavoro Apache Phoenix:

  • Tutte le "letture" vengono sottoposte alle analisi?
    • In caso affermativo, quali sono le caratteristiche di queste analisi?
    • Lo schema della tabella Phoenix è stato ottimizzato per queste analisi, inclusa un'indicizzazione appropriata?
  • È stata usata l'istruzione EXPLAIN per comprendere i piani di query generati dalle "letture"?
  • Le scritture sono "upsert-selects"?
    • In caso affermativo, eseguono anche le analisi? La latenza prevista per le analisi ha una media di circa 100 millisecondi, rispetto ai 10 millisecondi impiegati dal punto in HBase.

Metodologia di test e monitoraggio delle metriche

Se si usano benchmark come quelli di Yahoo! Usare i Benchmark di Cloud Serving, JMeter o Pherf per testare e ottimizzare le prestazioni e verificare che:

  • I computer client non diventano un collo di bottiglia. A tale scopo, controllare l'utilizzo della CPU nei computer client.

  • Le configurazioni lato client, come il numero di thread, vengono ottimizzate in modo appropriato per saturare la larghezza di banda del client.

  • I risultati dei test vengono registrati in modo accurato e sistematico.

Se le query improvvisamente iniziano a comportarsi peggio di prima, verificare la presenza di potenziali bug nel codice dell'applicazione. Improvvisamente vengono generati grandi quantità di dati non validi? In caso affermativo, è possibile aumentare le latenze di lettura.

Problemi di migrazione

Se si esegue la migrazione ad Azure HDInsight, assicurarsi che la migrazione venga eseguita in modo sistematico e accurato, preferibilmente tramite automazione. Evitare la migrazione manuale. Assicurati che:

  • Gli attributi della tabella vengono migrati in modo accurato. Gli attributi possono includere come compressione anche i filtri bloom.

  • Le impostazioni di salting nelle tabelle Phoenix vengono mappate in modo appropriato nelle nuove dimensioni del cluster. Ad esempio, il numero di bucket salt deve essere un multiplo del numero di nodi di lavoro nel cluster. Ed è necessario usare un multiplo che è un fattore della quantità di aree sensibili.

Ottimizzazioni della configurazione lato server

In HBase di HDInsight, gli HFiles vengono archiviati nell'archiviazione remota. Quando si verifica un mancato riscontro nella cache, il costo delle letture è superiore a quello dei sistemi locali perché i dati nei sistemi locali sono supportati da HDFS locale. Nella maggior parte degli scenari, l'uso intelligente delle cache HBase (cache in blocchi e cache bucket) è progettato per aggirare questo problema. Nei casi in cui il problema permane, l'uso di un account BLOB in blocchi Premium può aiutare ad aggirare questo problema. Il driver del BLOB del servizio di archiviazione di Microsoft Azure si basa su determinate proprietà, ad esempio fs.azure.read.request.size per recuperare i dati in blocchi in base alla modalità di lettura (sequenziale e casuale) impostata, quindi possono ancora essere presenti istanze di lettura con latenze elevate. Tramite esperimenti empirici, è stato rilevato che impostando le dimensioni del blocco di richieste di lettura (fs.azure.read.request.size) su 512 KB e impostando le sesse le dimensioni del blocco delle tabelle HBase, si producono risultati migliori nella pratica.

Per la maggior parte dei cluster di nodi di grandi dimensioni, HBase di HDInsight fornisce bucketcache come file in un'unità SSD Premium locale collegata alla macchina virtuale, che esegue regionservers. Invece l’utilizzo della cache off-heap può offrire dei miglioramenti. La limitazione di questa soluzione alternativa è l'utilizzo della memoria disponibile che potenzialmente è di dimensioni inferiori rispetto alla cache basata su file, di conseguenza non sempre è la scelta migliore.

Di seguito sono riportati alcuni degli altri parametri specifici che sono stati ottimizzati e che consentono di variare i gradi:

  • Aumentare le dimensioni di memstore dai predefiniti 128 MB a 256 MB. In genere, questa impostazione è consigliata per scenari di scrittura pesanti.

  • Aumentare il numero di thread dedicati per la compattazione dall'impostazione predefinita da 1 a 4. Questa impostazione è rilevante se si osservano frequenti compattazioni secondarie.

  • Evitare di bloccare lo scaricamento di memstore a causa del limite di archiviazione. Per fornire questo buffer, aumentare l'impostazione di Hbase.hstore.blockingStoreFiles a 100.

  • Per controllare gli scaricamenti, usare le impostazioni seguenti:

    • Hbase.regionserver.maxlogs: 140 (evita lo scaricamento a causa dei limiti di WAL)

    • Hbase.regionserver.global.memstore.lowerLimit: 0.55

    • Hbase.regionserver.global.memstore.upperLimit: 0.60

  • Configurazioni specifiche di Phoenix per l'ottimizzazione del pool di thread:

    • Phoenix.query.queuesize: 10000

    • Phoenix.query.threadpoolsize: 512

  • Altre configurazioni specifiche di Phoenix:

    • Phoenix.rpc.index.handler.count: 50 (se sono presenti molte ricerche di indici o indici di grandi dimensioni)

    • Phoenix.stats.updateFrequency: 1 ora

    • Phoenix.coprocessor.maxmetadatacachetimetolivems: 1 ora

    • Phoenix.coprocessor.maxmetadatacachesize: 50 MB

  • Timeout RPC: 3 minuti

    • In timeout RPC sono inclusi i timeout RPC HBase, i timeout dello scanner client HBase e i timeout delle query Phoenix.
    • Assicurarsi di impostare il parametro hbase.client.scanner.caching sullo stesso valore sia lato server che lato client. Se i parametri non sono uguali, ciò comporta errori lato client correlati a OutOfOrderScannerException. Questo parametro deve essere impostato su un valore basso per le analisi di grandi dimensioni. Questo valore viene impostato su 100.

Altre considerazioni

Di seguito sono riportati altri parametri da considerare per l'ottimizzazione:

  • Hbase.rs.cacheblocksonwrite - per impostazione predefinita in HDI, questo parametro è impostata su vero.

  • Impostazioni che consentono di rinviare la compattazione secondaria in un secondo momento.

  • Impostazioni sperimentali, ad esempio la regolazione delle percentuali di code riservate per le richieste di lettura e scrittura.

Passaggi successivi

Se il problema resta irrisolto, visitare uno dei canali seguenti per maggiore supporto:

  • Ricevere risposte dagli esperti di Azure tramite la pagina Supporto della community per Azure.

  • Contattare @AzureSupport. Questo è l'account ufficiale Microsoft Azure per migliorare l'esperienza del cliente. Connette la community di Azure con le risorse giuste: risposte, supporto ed esperti.

  • Se serve ulteriore assistenza, è possibile inviare una richiesta di supporto dal portale di Azure. Selezionare Supporto nella barra dei menu o aprire l'hub Guida e supporto. Per informazioni più dettagliate, vedere Come creare una richiesta di supporto in Azure. La sottoscrizione di Microsoft Azure include l'accesso alla gestione delle sottoscrizioni e al supporto alla fatturazione, mentre il supporto tecnico viene fornito tramite uno dei Piani di supporto di Azure.