Zjistěte více o návrhových rozhodnutích, která stojí za novou podporou HBase pro MOB.
Apache HBase je distribuovaná, škálovatelná, výkonná a konzistentní databáze klíčových hodnot, která může ukládat různé typy binárních dat. Vyniká v ukládání mnoha relativně malých hodnot (<10K) a poskytuje čtení a zápis s nízkou latencí.
Roste však poptávka po ukládání dokumentů, obrázků a dalších středně náročných objektů (MOB) v HBase při zachování nízké latence pro čtení a zápis. Jedním z takových případů použití je banka, která uchovává podepsané a naskenované zákaznické dokumenty. Jako další příklad mohou dopravní agentury chtít ukládat snímky provozu a jedoucích aut. Tyto MOB jsou obecně jednorázové.
Bohužel se výkon může zhoršit v situacích, kdy je uloženo mnoho středně velkých hodnot (100 kB až 10 MB) kvůli neustále se zvyšujícímu I/O tlaku vytvářenému zhutňováním. Zvažte případ, kdy se do HBase denně ukládá 1 TB fotografií z dopravních kamer, každá o velikosti 1 MB. Části uložených souborů jsou vícenásobně komprimovány prostřednictvím menších komprimací a případně jsou data přepisována většími komprimacemi. Spolu s akumulací těchto MOB I/O vytvořené komprimací zpomalí komprimaci, dále zablokují proplachování paměti paměti a případně zablokují aktualizace. Velký obchod MOB způsobí časté rozdělení regionů, čímž se sníží dostupnost postižených regionů.
Aby se tyto nedostatky vyřešily, inženýři Cloudera a Intel implementovali podporu MOB ve větvi HBase (hbase-11339:HBase MOB). Tato větev bude sloučena s hlavní v HBase 1.1 nebo 1.2 a je již přítomna a podporována také v CDH 5.4.x.
Operace na MOBech jsou obvykle náročné na zápis, se vzácnými aktualizacemi nebo mazáními a relativně vzácným čtením. MOB jsou obvykle uloženy společně s jejich metadaty. Metadata týkající se MOB mohou zahrnovat například číslo vozu, rychlost a barvu. Metadata jsou ve srovnání s MOB velmi malá. K metadatům se obvykle přistupuje za účelem analýzy, zatímco k MOB se obvykle přistupuje náhodně pouze tehdy, když jsou výslovně požadovány pomocí klíčů řádků.
Uživatelé chtějí číst a zapisovat MOB v HBase s nízkou latencí ve stejných API a chtějí silnou konzistenci, zabezpečení, snapshot a replikaci HBase mezi clustery a tak dále. Pro splnění těchto cílů byly MOB přesunuty z hlavní I/O cesty HBase do nové I/O cesty.
V tomto příspěvku se dozvíte o tomto přístupu k návrhu a proč byl vybrán.
Možné přístupy
Bylo několik možných přístupů k tomuto problému. Prvním přístupem, který jsme zvažovali, bylo ukládání MOBů do HBase s vyladěnými zásadami rozdělení a komprimace – větší požadovaná MaxFileSize snižuje frekvenci dělení regionů a menší nebo žádné komprimace může zabránit penalizaci za zesílení zápisu. Tento přístup by výrazně zlepšil latenci zápisu a propustnost. Spolu s rostoucím počtem uložených souborů by však v jednom obchodě bylo příliš mnoho otevřených čteček, dokonce více, než povoluje OS. V důsledku toho by se spotřebovalo velké množství paměti a výkon čtení by se snížil.
Dalším přístupem bylo použití modelu HBase + HDFS k samostatnému ukládání metadat a MOB. V tomto modelu je jeden soubor propojen záznamem v HBase. Toto je klientské řešení a transakce je řízena klientem – MOB nespotřebovávají žádné paměti na straně HBase. Tento přístup by fungoval pro objekty větší než 50 MB, ale u MOB vede mnoho malých souborů k neefektivnímu využití HDFS, protože výchozí velikost bloku v HDFS je 128 MB.
Řekněme například, že NameNode má 48 GB paměti a každý soubor má 100 kB se třemi replikami. Každý soubor zabírá více než 300 bajtů v paměti, takže NameNode s 48GB pamětí pojme asi 160 milionů souborů, což by nás omezovalo na uložení pouze 16TB MOB souborů celkem.
Jako vylepšení jsme mohli malé soubory MOB sestavit do větších – to znamená, že soubor mohl mít více položek MOB – a uložit offset a délku do tabulky HBase pro rychlé čtení. Udržování konzistence dat a správa odstraněných MOBů a malých MOB souborů v komprimaci je však obtížné.
Kromě toho, pokud bychom použili tento přístup, museli bychom zvážit nové bezpečnostní zásady, ztratit vlastnosti atomicity zápisů a potenciálně ztratit zálohování a obnovu po havárii, kterou poskytuje replikace a snímky.
HBase MOB Design
Nakonec, protože většina starostí kolem ukládání MOBů v HBase zahrnuje I/O vytvořené komprimací, bylo klíčem přesunout MOB mimo správu normálních regionů, aby se předešlo rozdělení a zhutnění regionů tam.
Návrh HBase MOB je podobný přístupu HBase + HDFS, protože metadata a MOB ukládáme odděleně. Rozdíl však spočívá v návrhu na straně serveru:paměťové úložiště ukládá MOBy do mezipaměti před jejich vyprázdněním na disk, MOB se při každém vyprázdnění zapisují do HFsouboru zvaného „soubor MOB“ a každý soubor MOB má více záznamů namísto jednoho souboru. v HDFS pro každý MOB. Tento soubor MOB je uložen ve speciální oblasti. Veškeré čtení a zápis mohou využívat aktuální HBase API.
Psaní a čtení
Každý MOB má práh:pokud je hodnota délky buňky větší než tento práh, je tato buňka považována za buňku MOB.
Když jsou buňky MOB aktualizovány v oblastech, jsou zapsány do WAL a memstore, stejně jako normální buňky. Při vyprázdnění se MOB vyprázdní do souborů MOB a metadata a cesty souborů MOB se vyprázdní, aby se soubory uložily. Funkce konzistence dat a replikace HBase jsou pro tento návrh přirozené.
Úpravy MOB jsou větší než obvykle. Při synchronizaci je také odpovídající I/O větší, což může zpomalit synchronizační operace WAL. Pokud existují další oblasti, které sdílejí stejnou WAL, může být ovlivněna latence zápisu těchto oblastí. Pokud je však potřeba konzistence dat a nevolatilita, WAL je nutností.
Buňkám je povoleno pohybovat se mezi uloženými soubory a soubory MOB při komprimaci změnou prahové hodnoty. Výchozí prahová hodnota je 100 kB.
Jak je znázorněno níže, buňky, které obsahují cesty k souborům MOB, se nazývají referenční buňky . Tagy jsou zachovány v buňkách, takže se můžeme i nadále spolehnout na bezpečnostní mechanismus HBase.
Referenční buňky mají referenční značky, které je odlišují od normálních buněk. Značka reference implikuje buňku MOB v souboru MOB, a proto je při čtení potřeba další řešení.
Při čtení skener úložiště otevírá skenery pro ukládání a ukládání souborů. Pokud je splněna referenční buňka, skener přečte cestu k souboru z hodnoty buňky a vyhledá stejný klíč řádku z tohoto souboru. Bloková mezipaměť může být povolena pro soubory MOB při skenování, což může urychlit vyhledávání.
Není nutné otevírat čtečky všech souborů MOB; v případě potřeby je potřeba pouze jeden. Toto náhodné čtení není ovlivněno počtem souborů MOB. Takže soubory MOB nemusíme znovu a znovu komprimovat, když jsou dostatečně velké.
Název souboru MOB je čitelný a skládá se ze tří částí:MD5 spouštěcího klíče, nejnovějšího data buněk v tomto souboru MOB a UUID. První část je startovací klíč oblasti, odkud je tento MOB soubor vyprázdněn. Obvykle mají MOBy uživatelsky definované TTL, takže můžete najít a odstranit soubory MOB, jejichž platnost vypršela, porovnáním druhé části s TTL.
Snímek
Aby byly snímky šetrnější, jsou soubory MOB uloženy ve speciální fiktivní oblasti, přičemž snímek, export/klonování tabulky a archiv fungují podle očekávání.
Při ukládání snímku do tabulky se ve snímku vytvoří oblast MOB a do manifestu se přidá existující soubory MOB. Při obnově snímku vytvořte odkazy na soubory v oblasti MOB.
Čištění a zhutnění
Existují dvě situace, kdy by měly být soubory MOB smazány:když vyprší platnost souboru MOB a když je soubor MOB příliš malý a měl by být sloučen do větších, aby se zlepšila účinnost HDFS.
HBase MOB má v masteru práci:skenuje soubory MOB, najde ty, jejichž platnost vypršela, podle data v názvu souboru a odstraní je. Místo na disku se tak periodicky obnovuje stárnutím souborů MOB, jejichž platnost vypršela.
Soubory MOB mohou být relativně malé ve srovnání s blokem HDFS, pokud zapisujete řádky, kde se jako MOB kvalifikuje pouze několik položek; také mohou být odstraněny buňky. Chcete-li zlepšit využití HDFS, musíte odstranit odstraněné buňky a sloučit malé soubory do větších. Zhutnění MOB zhutní pouze malé soubory a velké soubory se nedotknou, což zabraňuje opakovanému zhutňování velkých souborů.
Některé další věci, které je třeba mít na paměti:
- Zjistěte, které buňky byly odstraněny. Při každé velké komprimaci HBase jsou značky odstranění zapsány do souboru del před jejich odstraněním.
- V prvním kroku komprimace MOB jsou tyto del soubory sloučeny do větších.
- Jsou vybrány všechny malé soubory MOB. Pokud se počet malých souborů rovná počtu existujících souborů MOB, je toto zhuštění považováno za hlavní a nazývá se zhutnění ALL_FILES.
- Tyto vybrané soubory jsou rozděleny podle startovacího klíče a data v názvu souboru. Malé soubory v každém oddílu jsou komprimovány pomocí souborů del, takže odstraněné buňky lze zahodit; mezitím se vygeneruje nový soubor HF s novými referenčními buňkami, kompaktor potvrdí nový soubor MOB a poté hromadně nahraje tento soubor HF do HBase.
- Po dokončení komprimace ve všech oddílech, pokud se jedná o komprimaci ALL_FILES, jsou soubory del archivovány.
Životní cyklus souborů MOB je znázorněn níže. V zásadě jsou vytvořeny, když je paměť memstore vyprázdněna, a odstraněna HFileCleaner ze souborového systému, když na ně neodkazuje snímek nebo pokud v archivu vypršela platnost.
Závěr
Stručně řečeno, nový design HBase MOB přesouvá MOB z hlavní I/O cesty HBase, přičemž zachovává většinu funkcí zabezpečení, zhutnění a pořizování snímků. Vyhovuje charakteristikám operací v MOB, činí zesílení zápisu MOB předvídatelnějším a udržuje nízké latence při čtení i zápisu.
Jincheng Du je softwarový inženýr ve společnosti Intel a přispěvatel HBase.
Jon Hsieh je softwarový inženýr ve společnosti Cloudera a člen HBase/PMC. Je také zakladatelem Apache Flume a autorem Apache Sqoop.