Il modello di compattazione sta cambiando drasticamente con CDH 5/HBase 0.96. Ecco cosa devi sapere.
Apache HBase è un archivio dati distribuito basato su un albero di unione strutturato in log, quindi prestazioni di lettura ottimali deriverebbero dall'avere un solo file per archivio (famiglia di colonne). Tuttavia, quell'ideale non è possibile durante i periodi di pesanti scritture in arrivo. Invece, HBase proverà a combinare HFiles per ridurre il numero massimo di ricerche su disco necessarie per una lettura. Questo processo è chiamato compattazione .
Le compattazioni scelgono alcuni file da un singolo archivio in una regione e li combinano. Questo processo prevede la lettura dei KeyValue nei file di input e la scrittura di tutti i KeyValue che non vengono eliminati, sono all'interno del time to live (TTL) e non violano il numero di versioni. Il file combinato appena creato sostituisce quindi i file di input nella regione.
Ora, ogni volta che un client richiede dati, HBase sa che i dati dei file di input sono conservati in un file contiguo su disco, quindi è necessaria solo una ricerca, mentre in precedenza poteva essere richiesta una per ogni file. Ma l'IO del disco non è gratuito e, senza un'attenta attenzione, la riscrittura dei dati più e più volte può portare a una seria sottoscrizione eccessiva della rete e del disco. In altre parole, la compattazione riguarda lo scambio di alcuni IO del disco ora per meno ricerche in seguito.
In questo post imparerai di più sull'uso e le implicazioni delle compattazioni in CDH 4, nonché sulle modifiche al modello di compattazione in CDH 5 (che sarà nuovamente basato su HBase 0.96).
Compattazione in CDH 4
La compattazione ideale sceglierebbe i file che ridurranno il maggior numero di ricerche nelle letture imminenti, scegliendo anche i file che richiederanno la minor quantità di I/O. Sfortunatamente, quel problema non è risolvibile senza la conoscenza del futuro. In quanto tale, è solo un ideale a cui HBase dovrebbe aspirare e non qualcosa che sia mai realmente raggiungibile.
Invece dell'ideale impossibile, HBase utilizza un'euristica per cercare di scegliere quali file in un negozio potrebbero essere buoni candidati. I file vengono scelti in base all'intuizione che i file simili dovrebbero essere combinati con file simili, il che significa che i file che hanno all'incirca le stesse dimensioni dovrebbero essere combinati.
La politica predefinita in HBase 0.94 (spedizione in CDH 4) esamina l'elenco di HFiles, cercando di trovare il primo file con una dimensione inferiore al totale di tutti i file moltiplicato per hbase.store.compaction.ratio. Una volta trovato quel file, il file H e tutti i file con ID sequenza più piccoli vengono scelti per essere compattati.
Per il caso predefinito in cui i file più grandi sono i più vecchi, questo approccio funziona bene:
Tuttavia, questa ipotesi sulla correlazione tra età e dimensione dei file è errata in alcuni casi, portando l'attuale algoritmo a scegliere in modo non ottimale. Piuttosto, i file caricati in blocco possono e talvolta lo fanno in modo molto diverso dai file Hfile più normalmente scaricati, quindi sono ottimi esempi:
Modifiche alla compattazione in CDH 5
Le compattazioni sono cambiate in modo significativo di recente. Per HBase 0.96 e CDH 5, l'algoritmo di selezione dei file è stato reso configurabile tramite HBASE-7516, quindi ora è possibile avere criteri di compattazione forniti dall'utente. Questa modifica consente agli utenti più esperti di testare e ripetere come vogliono eseguire le compattazioni.
Anche l'algoritmo di selezione della compattazione predefinito è stato modificato in ExploringCompactionPolicy. Questa politica è diversa dalla vecchia impostazione predefinita in quanto garantisce che ogni singolo file in una compattazione proposta rientri nel rapporto specificato. Inoltre, non si limita a scegliere il primo set di file con dimensioni all'interno del rapporto di compattazione; invece esamina tutti i possibili set che non violano alcuna regola, quindi sceglie qualcosa che sembra avere il maggiore impatto per la minor quantità di IO prevista. Per fare ciò, ExploringCompactionPolicy sceglie una compattazione che rimuoverà la maggior parte dei file all'interno del rapporto e, se c'è un pareggio, viene data la preferenza all'insieme di file di dimensioni inferiori:
Sono previste ulteriori modifiche per le versioni future, tra cui la compattazione a livelli, la compattazione a strisce e la compattazione basata sul livello.
Conclusione
Per alcuni casi d'uso, questo lavoro non avrà alcun impatto. Questa è una buona cosa, poiché le compattazioni erano già abbastanza ben studiate. Tuttavia, per gli utenti che hanno picchi di traffico elevati o che utilizzano carichi in blocco, questo lavoro può produrre grandi miglioramenti nei tempi di attesa IO e nella latenza delle richieste. Per uno specifico caso d'uso di caricamento in blocco, abbiamo riscontrato una riduzione del 90% dell'IO del disco a causa delle compattazioni.
Di seguito sono riportati i risultati di un test case in PerfTestCompactionPolicies di HBase:
Dai un'occhiata a questo lavoro in CDH 5 (in versione beta al momento della stesura di questo articolo) quando si tratta di un cluster vicino a te.
Ulteriori letture:
- Esplorazione della politica di compattazione
- https://hbase.apache.org/book/regions.arch.html#compaction.file.selection
- https://issues.apache.org/jira/browse/HBASE-7516
- https://issues.apache.org/jira/browse/HBASE-7678
- https://issues.apache.org/jira/browse/HBASE-7667
- https://issues.apache.org/jira/browse/HBASE-7055
- http://www.hbasecon.com/sessions/compaction-improvements-in-apache-hbase/
