Komprimeringsmodellen förändras drastiskt med CDH 5/HBase 0.96. Här är vad du behöver veta.
Apache HBase är ett distribuerat datalager baserat på ett loggstrukturerat sammanslagningsträd, så optimal läsprestanda skulle komma från att bara ha en fil per butik (kolumnfamilj). Det idealet är dock inte möjligt under perioder med tunga inkommande skrivningar. Istället kommer HBase att försöka kombinera HFiles för att minska det maximala antalet disksökningar som behövs för en läsning. Denna process kallas komprimering .
Kompakteringar väljer några filer från en enda butik i en region och kombinerar dem. Den här processen innebär att man läser nyckelvärden i inmatningsfilerna och skriver ut alla nyckelvärden som inte raderas, som ligger inom tiden att leva (TTL) och som inte bryter mot antalet versioner. Den nyligen skapade kombinerade filen ersätter sedan indatafilerna i regionen.
Nu, närhelst en klient frågar efter data, vet HBase att data från indatafilerna finns i en sammanhängande fil på disken - därför behövs bara en sökning, medan tidigare en för varje fil kunde krävas. Men disk-IO är inte gratis, och utan noggrann uppmärksamhet kan omskrivning av data om och om igen leda till allvarliga nätverks- och disköverabonnemang. Med andra ord handlar komprimering om att handla med någon disk-IO nu för färre sökningar senare.
I det här inlägget kommer du att lära dig mer om användningen och implikationerna av komprimering i CDH 4, samt ändringar av komprimeringsmodellen i CDH 5 (som kommer att ombaseras på HBase 0.96).
Komprimering i CDH 4
Den idealiska komprimeringen skulle välja de filer som kommer att minska flest sökningar i kommande läsningar och samtidigt välja filer som behöver minst mängd IO. Tyvärr är det problemet inte lösbart utan kunskap om framtiden. Som sådan är det bara ett ideal som HBase bör sträva efter och inte något som någonsin verkligen är möjligt att uppnå.
Istället för det omöjliga idealet använder HBase en heuristik för att försöka välja vilka filer i en butik som sannolikt kommer att vara bra kandidater. Filerna väljs utifrån intuitionen att liknande filer ska kombineras med liknande filer – vilket innebär att filer som är ungefär lika stora ska kombineras.
Standardpolicyn i HBase 0.94 (levereras i CDH 4) tittar igenom listan med hFiles och försöker hitta den första filen som har en storlek som är mindre än summan av alla filer multiplicerat med hbase.store.compaction.ratio. När den filen har hittats väljs HF-filen och alla filer med mindre sekvens-ID för att komprimeras.
För standardfallet där de största filerna är de äldsta, fungerar detta tillvägagångssätt bra:
Detta antagande om korrelationen mellan ålder och storlek på filer är dock felaktig i vissa fall, vilket leder till att den nuvarande algoritmen väljer suboptimalt. Snarare kan och ibland sorteras bulkladdade filer väldigt annorlunda än de mer normalt tömda HFiles, så de är bra exempel:
Komprimeringsförändringar i CDH 5
Komprimeringarna har förändrats på betydande sätt nyligen. För HBase 0.96 och CDH 5 gjordes filvalsalgoritmen konfigurerbar via HBASE-7516 - så det är nu möjligt att ha användarlevererade komprimeringspolicyer. Denna förändring gör att mer erfarna användare kan testa och upprepa hur de vill köra komprimering.
Standardalgoritmen för val av komprimering ändrades också till ExploringCompactionPolicy. Denna policy skiljer sig från den gamla standarden genom att den säkerställer att varje enskild fil i en föreslagen komprimering är inom det givna förhållandet. Dessutom väljer den inte bara den första uppsättningen filer som har storlekar inom komprimeringsförhållandet; istället tittar den på alla möjliga uppsättningar som inte bryter mot några regler, och väljer sedan något som ser ut att ha mest effekt för den minsta förväntade mängden IO. För att göra det väljer ExploringCompactionPolicy en komprimering som tar bort flest filer inom förhållandet, och om det är oavgjort ges företräde åt uppsättningen filer som är mindre i storlek:
Fler förändringar planeras för framtida utgåvor, inklusive komprimering i nivå, komprimering med rand och nivåbaserad komprimering.
Slutsats
För vissa användningsfall kommer detta arbete inte att ha någon inverkan alls. Det är bra, eftersom packningar redan var ganska väl studerade. Men för användare som har stora trafikspikar eller som använder bulklaster, kan detta arbete ge stora förbättringar i IO-väntetider och förfrågningslatens. För ett specifikt bulkbelastningsfall har vi sett en 90 % minskning av disk-IO på grund av komprimering.
Här är resultat från ett testfall i HBases PerfTestCompactionPolicies:
Kolla in det här arbetet i CDH 5 (i beta när detta skrivs) när det gäller ett kluster nära dig.
Mer läsning:
- Utforska komprimeringspolicy
- 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/