Komprimeringsmodellen ændrer sig drastisk med CDH 5/HBase 0.96. Her er, hvad du behøver at vide.
Apache HBase er et distribueret datalager baseret på et log-struktureret flettetræ, så optimal læseydeevne ville komme fra kun at have én fil pr. butik (kolonnefamilie). Dette ideal er dog ikke muligt i perioder med tunge indkommende skriverier. I stedet vil HBase forsøge at kombinere HFiles for at reducere det maksimale antal disksøgninger, der er nødvendige for en læsning. Denne proces kaldes komprimering .
Komprimeringer vælger nogle filer fra en enkelt butik i en region og kombinerer dem. Denne proces involverer læsning af KeyValues i inputfilerne og udskrivning af eventuelle KeyValues, der ikke er slettet, er inde i time to live (TTL), og som ikke overtræder antallet af versioner. Den nyligt oprettede kombinerede fil erstatter derefter inputfilerne i området.
Nu, når en klient beder om data, ved HBase, at dataene fra inputfilerne opbevares i én sammenhængende fil på disken - derfor er der kun behov for én søgning, hvorimod der tidligere kunne kræves en for hver fil. Men disk IO er ikke gratis, og uden omhyggelig opmærksomhed kan omskrivning af data igen og igen føre til noget alvorligt netværks- og diskoverabonnement. Med andre ord handler komprimering om at handle noget disk-IO nu for færre søgninger senere.
I dette indlæg vil du lære mere om brugen og implikationerne af komprimeringer i CDH 4, samt ændringer af komprimeringsmodellen i CDH 5 (som vil blive re-baseret på HBase 0.96).
Komprimering i CDH 4
Den ideelle komprimering ville vælge de filer, der vil reducere flest søgninger i kommende læsninger, mens du også vælger filer, der har brug for den mindste mængde IO. Desværre kan det problem ikke løses uden viden om fremtiden. Som sådan er det bare et ideal, som HBase bør stræbe efter og ikke noget, der nogensinde virkelig er opnåeligt.
I stedet for det umulige ideal, bruger HBase en heuristik til at prøve at vælge, hvilke filer i en butik der sandsynligvis vil være gode kandidater. Filerne er valgt ud fra den intuition, at lignende filer skal kombineres med lignende filer - hvilket betyder, at filer, der har omtrent samme størrelse, skal kombineres.
Standardpolitikken i HBase 0.94 (forsendelse i CDH 4) kigger gennem listen over HFiles og prøver at finde den første fil, der har en størrelse mindre end summen af alle filer ganget med hbase.store.compaction.ratio. Når den fil er fundet, vælges HF-filen og alle filer med mindre sekvens-id'er til at blive komprimeret.
For standardtilfældet, hvor de største filer er de ældste, fungerer denne fremgangsmåde godt:
Denne antagelse om sammenhængen mellem alder og størrelse af filer er imidlertid i nogle tilfælde defekt, hvilket får den nuværende algoritme til at vælge suboptimalt. Tværtimod kan masseindlæste filer og nogle gange sortere meget anderledes end de mere normalt flushede HFiles, så de er gode eksempler:
Komprimeringsændringer i CDH 5
Komprimeringer har ændret sig betydeligt for nylig. For HBase 0.96 og CDH 5 blev filvalgsalgoritmen gjort konfigurerbar via HBASE-7516 - så det er nu muligt at have brugerleverede komprimeringspolitikker. Denne ændring giver mere erfarne brugere mulighed for at teste og gentage, hvordan de vil køre komprimeringer.
Standardkomprimeringsvalgalgoritmen blev også ændret til ExploringCompactionPolicy. Denne politik er forskellig fra den gamle standard, idet den sikrer, at hver enkelt fil i en foreslået komprimering er inden for det givne forhold. Den vælger heller ikke kun det første sæt filer, der har størrelser inden for komprimeringsforholdet; i stedet ser den på alle de mulige sæt, der ikke overtræder nogen regler, og vælger derefter noget, der ser ud til at være mest virkningsfuldt for den mindste mængde IO, der forventes. For at gøre det vælger ExploringCompactionPolicy en komprimering, der fjerner flest filer inden for forholdet, og hvis der er uafgjort, foretrækkes det sæt filer, der er mindre i størrelse:
Der er planlagt flere ændringer for fremtidige udgivelser, herunder trindelt komprimering, stribet komprimering og niveaubaseret komprimering.
Konklusion
I nogle tilfælde vil dette arbejde slet ikke have nogen indflydelse. Det er en god ting, da komprimeringer allerede var ret godt undersøgt. For brugere, der har store trafikstigninger, eller som bruger massebelastninger, kan dette arbejde dog give store forbedringer i IO-ventetider og i anmodningsforsinkelse. For et specifikt tilfælde af bulk-load har vi set en 90 % reduktion i disk IO på grund af komprimeringer.
Her er resultater fra en testcase i HBases PerfTestCompactionPolicies:
Tjek dette arbejde i CDH 5 (i beta på tidspunktet for skrivningen), når det kommer til en klynge nær dig.
Yderligere læsning:
- Udforsker komprimeringspolitikken
- 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/