Läs mer om designbesluten bakom HBases nya stöd för MOB.
Apache HBase är en distribuerad, skalbar, presterande, konsekvent nyckelvärdesdatabas som kan lagra en mängd olika binära datatyper. Den utmärker sig när det gäller att lagra många relativt små värden (<10K) och tillhandahålla läsning och skrivning med låg latens.
Det finns dock en växande efterfrågan på att lagra dokument, bilder och andra måttliga objekt (MOB) i HBase samtidigt som man bibehåller låg latens för läsning och skrivning. Ett sådant användningsfall är en bank som lagrar signerade och skannade kunddokument. Som ett annat exempel kan transportbyråer vilja lagra ögonblicksbilder av trafik och rörliga bilar. Dessa MOB:er skrivs vanligtvis en gång.
Tyvärr kan prestandan försämras i situationer där många medelstora värden (100K till 10MB) lagras på grund av det ständigt ökande I/O-trycket som skapas av packningar. Tänk på fallet där 1 TB foton från trafikkameror, varje 1 MB i storlek, lagras i HBase dagligen. Delar av de lagrade filerna komprimeras flera gånger via mindre komprimeringar och så småningom skrivs data om av större komprimeringar. Tillsammans med ackumulering av dessa MOB:er kommer I/O skapad av komprimeringar att sakta ner komprimeringarna, blockera spolning av memstore ytterligare och så småningom blockera uppdateringar. En stor MOB-butik kommer att utlösa täta regionuppdelningar, vilket minskar tillgängligheten för de drabbade regionerna.
För att åtgärda dessa nackdelar har Cloudera och Intels ingenjörer implementerat MOB-stöd i en HBase-gren (hbase-11339:HBase MOB). Den här grenen kommer att slås samman med mastern i HBase 1.1 eller 1.2 och finns redan och stöds även i CDH 5.4.x.
Operationer på MOB är vanligtvis skrivintensiva, med sällsynta uppdateringar eller raderingar och relativt sällsynta läsningar. MOB:er lagras vanligtvis tillsammans med sina metadata. Metadata relaterade till MOB kan till exempel inkludera bilnummer, hastighet och färg. Metadata är mycket små i förhållande till MOB. Metadata nås vanligtvis för analys, medan MOB vanligtvis endast nås slumpmässigt när de uttryckligen efterfrågas med radnycklar.
Användare vill läsa och skriva MOB i HBase med låg latens i samma API:er och vill ha stark konsekvens, säkerhet, ögonblicksbild och HBase-replikering mellan kluster och så vidare. För att uppfylla dessa mål flyttades MOB från HBases huvudsakliga I/O-bana och till en ny I/O-bana.
I det här inlägget kommer du att lära dig om denna designmetod och varför den valdes.
Möjliga tillvägagångssätt
Det fanns några möjliga tillvägagångssätt för detta problem. Det första tillvägagångssättet vi övervägde var att lagra MOB i HBase med en avstämd split- och komprimeringspolicy – en större önskad MaxFileSize minskar frekvensen av regiondelning, och färre eller inga komprimeringar kan undvika skrivförstärkningsstraffet. Det tillvägagångssättet skulle förbättra skrivlatensen och genomströmningen avsevärt. Men tillsammans med det ökande antalet lagrade filer skulle det finnas för många öppnade läsare i en enda butik, till och med fler än vad som tillåts av operativsystemet. Som ett resultat skulle mycket minne förbrukas och läsprestanda försämras.
Ett annat tillvägagångssätt var att använda en HBase + HDFS-modell för att lagra metadata och MOB separat. I denna modell är en enskild fil länkad av en post i HBase. Detta är en klientlösning och transaktionen kontrolleras av klienten – inga HBase-side-minnen konsumeras av MOB:s. Detta tillvägagångssätt skulle fungera för objekt större än 50 MB, men för MOB:er leder många små filer till ineffektiv HDFS-användning eftersom standardblockstorleken i HDFS är 128 MB.
Låt oss till exempel säga att en NameNode har 48 GB minne och varje fil är 100 KB med tre repliker. Varje fil tar mer än 300 byte i minnet, så en NameNode med 48 GB minne kan rymma cirka 160 miljoner filer, vilket skulle begränsa oss till att bara lagra 16 TB MOB-filer totalt.
Som en förbättring kunde vi ha satt ihop de små MOB-filerna till större – det vill säga en fil kunde ha flera MOB-poster – och lagra offset och längd i HBase-tabellen för snabb läsning. Det är dock svårt att upprätthålla datakonsistens och hantera borttagna MOB och små MOB-filer i komprimering.
Dessutom, om vi skulle använda detta tillvägagångssätt, skulle vi behöva överväga nya säkerhetspolicyer, förlora atomicitetsegenskaper för skrivningar och potentiellt förlora säkerhetskopieringen och katastrofåterställningen som tillhandahålls av replikering och ögonblicksbilder.
HBase MOB-design
I slutändan, eftersom de flesta problem kring lagring av MOB i HBase involverar I/O som skapats av komprimering, var nyckeln att flytta MOB ur förvaltning av normala regioner för att undvika regionuppdelningar och komprimering där.
HBase MOB-design liknar HBase + HDFS-metoden eftersom vi lagrar metadata och MOB separat. Skillnaden ligger dock i en design på serversidan:memstore cachar MOB:erna innan de töms till disken, MOB:erna skrivs in i en HF-fil som kallas "MOB-fil" i varje flush, och varje MOB-fil har flera poster istället för en enda fil i HDFS för varje MOB. Denna MOB-fil lagras i en speciell region. All läsning och skrivning kan användas av de nuvarande HBase API:erna.
Skriv och läs
Varje MOB har ett tröskelvärde:om värdelängden för en cell är större än denna tröskel, betraktas denna cell som en MOB-cell.
När MOB-cellerna uppdateras i regionerna skrivs de till WAL och memstore, precis som de vanliga cellerna. Vid spolning töms MOB-filerna till MOB-filer och metadata och sökvägar för MOB-filer töms för att lagra filer. Datakonsistensen och HBase-replikeringsfunktionerna är inbyggda i denna design.
MOB-redigeringarna är större än vanligt. I synkroniseringen är motsvarande I/O också större, vilket kan sakta ner synkroniseringsoperationerna för WAL. Om det finns andra regioner som delar samma WAL kan skrivlatensen för dessa regioner påverkas. Men om datakonsistensen och icke-volatiliteten behövs är WAL ett måste.
Cellerna tillåts att flytta mellan lagrade filer och MOB-filer i komprimeringarna genom att ändra tröskeln. Standardtröskeln är 100KB.
Som illustreras nedan kallas cellerna som innehåller sökvägarna till MOB-filer referensceller . Taggarna hålls kvar i cellerna, så vi kan fortsätta att lita på HBase-säkerhetsmekanismen.
Referenscellerna har referenstaggar som skiljer dem från normala celler. En referenstagg innebär en MOB-cell i en MOB-fil, och därför krävs ytterligare upplösning vid läsning.
Under läsning öppnar butiksskannern skannrar för att memstore och lagra filer. Om en referenscell uppfylls läser skannern filsökvägen från cellvärdet och söker samma radnyckel från den filen. Blockcachen kan aktiveras för MOB-filer i skanning, vilket kan påskynda sökningen.
Det är inte nödvändigt att öppna läsare för alla MOB-filer; endast en behövs vid behov. Denna slumpmässiga läsning påverkas inte av antalet MOB-filer. Så vi behöver inte komprimera MOB-filerna om och om igen när de är tillräckligt stora.
MOB-filnamnet är läsbart och består av tre delar:MD5 för startnyckeln, det senaste datumet för cellerna i denna MOB-fil och ett UUID. Den första delen är startnyckeln för regionen där denna MOB-fil rensas. Vanligtvis har MOB:erna en användardefinierad TTL, så du kan hitta och ta bort utgångna MOB-filer genom att jämföra den andra delen med TTL.
Ögonblicksbild
För att vara mer vänlig mot ögonblicksbilden lagras MOB-filerna i en speciell dummy-region, varvid ögonblicksbilden, tabellexporten/klonen och arkiveringen fungerar som förväntat.
När man lagrar en ögonblicksbild i en tabell, skapar man MOB-regionen i ögonblicksbilden och lägger till de befintliga MOB-filerna i manifestet. När du återställer ögonblicksbilden, skapa fillänkar i MOB-regionen.
Rengör och packar ihop
Det finns två situationer när MOB-filer bör raderas:när MOB-filen har löpt ut och när MOB-filen är för liten och bör slås samman till större för att förbättra HDFS-effektiviteten.
HBase MOB har en syssla i master:den skannar MOB-filerna, hittar de utgångna som bestäms av datumet i filnamnet och raderar dem. Sålunda återvinns diskutrymme med jämna mellanrum genom att förfallna MOB-filer åldras.
MOB-filer kan vara relativt små jämfört med ett HDFS-block om du skriver rader där endast ett fåtal poster kvalificerar sig som MOB; Det kan också finnas raderade celler. Du måste släppa de raderade cellerna och slå samman de små filerna till större för att förbättra HDFS-användningen. MOB-komprimeringarna komprimerar bara de små filerna och de stora filerna berörs inte, vilket undviker upprepad komprimering till stora filer.
Några andra saker att tänka på:
- Vet vilka celler som raderas. I varje större HBase-komprimering skrivs raderingsmarkörerna till en del-fil innan de släpps.
- I det första steget av MOB-komprimering slås dessa delfiler samman till större.
- Alla små MOB-filer är valda. Om antalet små filer är lika med antalet befintliga MOB-filer, betraktas denna komprimering som en större och kallas en ALL_FILES-komprimering.
- Dessa valda filerna är partitionerade med startnyckeln och datumet i filnamnet. De små filerna i varje partition komprimeras med del-filer så att raderade celler kan släppas; under tiden genereras en ny HF-fil med nya referensceller, komprimatorn commiterar den nya MOB-filen och sedan bulkläser den denna HF-fil i HBase.
- När komprimeringarna i alla partitioner är klara, om en ALL_FILES-komprimering är involverad, arkiveras delfilerna.
Livscykeln för MOB-filer illustreras nedan. I grund och botten skapas de när memstore töms, och raderas av HFileCleaner från filsystemet när de inte refereras av ögonblicksbilden eller förfaller i arkivet.
Slutsats
Sammanfattningsvis flyttar den nya HBase MOB-designen MOB:er bort från HBases huvudsakliga I/O-väg samtidigt som de behåller de flesta funktionerna för säkerhet, komprimering och ögonblicksbild. Den tillgodoser egenskaperna hos operationer i MOB, gör skrivförstärkningen av MOB mer förutsägbar och håller låga latenser i både läsning och skrivning.
Jincheng Du är en mjukvaruingenjör på Intel och en HBase-bidragsgivare.
Jon Hsieh är mjukvaruingenjör på Cloudera och HBase-kommitter/PMC-medlem. Han är också grundaren av Apache Flume, och en engagerad i Apache Sqoop.