Tento blogový příspěvek byl publikován na Hortonworks.com před sloučením s Cloudera. Některé odkazy, zdroje nebo reference již nemusí být přesné.
Pro tento příspěvek se podíváme na technický hluboký ponor do jedné ze základních oblastí HBase. Konkrétně se podíváme na to, jak Apache HBase rozděluje zátěž mezi regiony a spravuje rozdělení regionů. HBase ukládá řádky dat do tabulek. Tabulky jsou rozděleny do částí řádků nazývaných „regiony“. Tyto oblasti jsou distribuovány v rámci clusteru, hostovány a zpřístupněny klientským procesům prostřednictvím procesu RegionServer. Oblast je souvislý rozsah v prostoru klíčů, což znamená, že všechny řádky v tabulce, které se řadí mezi počáteční a koncový klíč oblasti, jsou uloženy ve stejné oblasti. Oblasti se nepřekrývají, tj. klíč jednoho řádku patří v libovolném okamžiku přesně jedné oblasti. Oblast je v každém okamžiku obsluhována pouze serverem jedné oblasti, což je způsob, jakým HBase zaručuje silnou konzistenci v rámci jednoho řádku#. Spolu s -ROOT- a .META. regiony, regiony tabulky efektivně tvoří 3-úrovňový B-strom pro účely umístění řádku v tabulce.
Region se zase skládá z mnoha „obchodů“, které odpovídají rodinám sloupců. Úložiště obsahuje jedno úložiště paměti a žádný nebo více souborů úložiště. Data pro každou rodinu sloupců jsou uložena a přistupována samostatně.
Tabulka se obvykle skládá z mnoha oblastí, které jsou zase hostovány mnoha servery oblastí. Regiony jsou tedy fyzickým mechanismem používaným k distribuci zatížení zápisu a dotazů mezi servery regionů. Při prvním vytvoření tabulky HBase ve výchozím nastavení přidělí tabulce pouze jednu oblast. To znamená, že zpočátku budou všechny požadavky směřovat na server jedné oblasti, bez ohledu na počet serverů oblasti. To je hlavní důvod, proč počáteční fáze načítání dat do prázdné tabulky nemohou využít celou kapacitu clusteru.
Předdělení
Důvod, proč HBase vytváří pro tabulku pouze jednu oblast, je ten, že nemůže vědět, jak vytvořit dělicí body v prostoru klíčů řádků. Provádění takových rozhodnutí je vysoce založeno na distribuci klíčů ve vašich datech. Namísto hádání a ponechání vás, abyste se vypořádali s důsledky, vám HBase poskytuje nástroje pro správu od klienta. Pomocí procesu zvaného předběžné rozdělení můžete vytvořit tabulku s mnoha oblastmi tím, že dodáte body rozdělení v době vytvoření tabulky. Vzhledem k tomu, že předběžné rozdělení zajistí rovnoměrnější rozložení počátečního zatížení v celém clusteru, měli byste jeho použití vždy zvážit, pokud předem znáte své rozložení klíčů. Předrozdělení však také představuje riziko vytvoření oblastí, které skutečně nerozdělují zatížení rovnoměrně kvůli zkreslení dat nebo v přítomnosti velmi horkých nebo velkých řádků. Pokud je počáteční sada bodů rozdělení oblastí vybrána špatně, můžete skončit s heterogenním rozložením zátěže, což zase omezí výkon vašich clusterů.
Neexistuje žádná krátká odpověď na optimální počet regionů pro dané zatížení, ale můžete začít s nižším násobkem počtu serverů regionů jako počtu rozdělení a poté nechat automatické rozdělení, aby se postaralo o zbytek.
Jedním z problémů s předrozdělováním je výpočet dělicích bodů pro tabulku. Můžete použít nástroj RegionSplitter. RegionSplitter vytváří dělicí body pomocí zásuvného algoritmu SplitAlgorithm. HexStringSplit a UniformSplit jsou dva předdefinované algoritmy. První z nich lze použít, pokud mají klíče řádku předponu pro hexadecimální řetězce (jako když jako předpony používáte hash). Ten rozděluje klíčový prostor rovnoměrně za předpokladu, že se jedná o náhodná bajtová pole. Můžete také implementovat svůj vlastní SplitAlgorithm a použít jej z nástroje RegionSplitter.
$ hbase org.apache.hadoop.hbase.util.RegionSplitter test_table HexStringSplit -c 10 -f f1
kde -c 10 určuje požadovaný počet oblastí jako 10 a -f určuje rodiny sloupců, které chcete v tabulce, oddělené „:“. Nástroj vytvoří tabulku s názvem „test_table“ s 10 oblastmi:
13/01/18 18:49:32 DEBUG hbase.HRegionInfo: Current INFO from scan results = {NAME => 'test_table,,1358563771069.acc1ad1b7962564fc3a43e5907e8db33.', STARTKEY => '', ENDKEY => '19999999', ENCODED => acc1ad1b7962564fc3a43e5907e8db33,}
13/01/18 18:49:32 DEBUG hbase.HRegionInfo: Current INFO from scan results = {NAME => 'test_table,19999999,1358563771096.37ec12df6bd0078f5573565af415c91b.', STARTKEY => '19999999', ENDKEY => '33333332', ENCODED => 37ec12df6bd0078f5573565af415c91b,}
... Pokud máte po ruce dělicí body, můžete také použít shell HBase k vytvoření tabulky s požadovanými dělicími body.
hbase(main):015:0> create 'test_table', 'f1', SPLITS=> ['a', 'b', 'c']
nebo
$ echo -e "anbnc" >/tmp/splits hbase(main):015:0> create 'test_table', 'f1', SPLITSFILE=>'/tmp/splits'
Pro optimální rozložení zátěže byste se měli zamyslet nad svým datovým modelem a rozložením klíčů pro výběr správného algoritmu rozdělení nebo bodů rozdělení. Bez ohledu na metodu, kterou jste zvolili k vytvoření tabulky s předem určeným počtem oblastí, můžete nyní začít načítat data do tabulky a zjistit, že zatížení je distribuováno v celém clusteru. Jakmile začne zpracování dat, můžete nechat převzít automatické rozdělování a průběžně sledovat celkový počet oblastí pro tabulku.
Automatické rozdělení
Bez ohledu na to, zda je použito předběžné dělení nebo ne, jakmile se region dostane na určitý limit, automaticky se rozdělí na dva regiony. Pokud používáte HBase 0.94 (který je dodáván s HDP-1.2), můžete nakonfigurovat, kdy se HBase rozhodne rozdělit oblast a jak vypočítá body rozdělení pomocí připojitelného rozhraní RegionSplitPolicy API. Existuje několik předdefinovaných zásad rozdělení regionů:ConstantSizeRegionSplitPolicy, IncreasingToUpperBoundRegionSplitPolicy a KeyPrefixRegionSplitPolicy.
První z nich je výchozí a pouze rozdělená politika pro verze HBase před 0.94. Rozdělí oblasti, když se celková velikost dat pro jeden z úložišť (odpovídající rodině sloupců) v oblasti zvětší než nakonfigurovaná „hbase.hregion.max.filesize“, která má výchozí hodnotu 10 GB. Tato politika rozdělení je ideální v případech, kdy jste provedli předběžné rozdělení a máte zájem o nižší počet regionů na server regionu.
Výchozí zásada rozdělení pro HBase 0.94 a trunk je IncreasingToUpperBoundRegionSplitPolicy, která provádí agresivnější rozdělení na základě počtu regionů hostovaných na serveru stejné oblasti. Zásada rozdělení používá maximální velikost souboru úložiště na základě Min (R^2 * „hbase.hregion.memstore.flush.size“, „hbase.hregion.max.filesize“), kde R je počet stejných oblastí stůl hostovaný na stejném regionálním serveru. Takže například s výchozí velikostí vyprázdnění memstore 128 MB a výchozí maximální velikostí úložiště 10 GB bude první oblast na serveru regionu rozdělena hned po prvním vyprázdnění na 128 MB. S rostoucím počtem regionů hostovaných na serveru regionu bude server používat rostoucí velikosti rozdělení:512 MB, 1152 MB, 2 GB, 3,2 GB, 4,6 GB, 6,2 GB atd. Po dosažení 9 regionů bude velikost rozdělení přesahovat nakonfigurovanou „hbase“. .hregion.max.filesize“, v tomto okamžiku bude od té doby používána velikost rozdělení 10 GB. Pro oba tyto algoritmy, bez ohledu na to, kdy dojde k rozdělení, je použitým bodem rozdělení klíč řádku, který odpovídá středu v „indexu bloku“ pro největší soubor úložiště v největším obchodě.
KeyPrefixRegionSplitPolicy je zvláštním doplňkem arzenálu HBase. Můžete nakonfigurovat délku předpony pro klíče řádků pro jejich seskupení a tato zásada rozdělení zajišťuje, že oblasti nebudou rozděleny uprostřed skupiny řádků se stejnou předponou. Pokud jste pro své klíče nastavili předpony, můžete pomocí této zásady rozdělení zajistit, že řádky se stejnou předponou klíče řádku vždy skončí ve stejné oblasti. Toto seskupení záznamů se někdy nazývá „skupiny entit“ nebo „skupiny řádků“. Toto je klíčová funkce při zvažování použití funkce „místní transakce“ (alternativní odkaz) v návrhu vaší aplikace.
Výchozí zásadu rozdělení, která se má použít, můžete nakonfigurovat nastavením konfigurace „hbase.regionserver.region.split.policy“ nebo konfigurací deskriptoru tabulky. Pro vás odvážné duše můžete také implementovat své vlastní zásady rozdělení a zapojit je při vytváření stolu nebo úpravou existující tabulky:
HTableDescriptor tableDesc = new HTableDescriptor("example-table");
tableDesc.setValue(HTableDescriptor.SPLIT_POLICY, AwesomeSplitPolicy.class.getName());
//add columns etc
admin.createTable(tableDesc); Pokud provádíte předběžné rozdělení a chcete rozdělení oblastí spravovat ručně, můžete rozdělení oblastí také zakázat nastavením „hbase.hregion.max.filesize“ na vysoké číslo a nastavením zásady rozdělení na ConstantSizeRegionSplitPolicy. Měli byste však použít hodnotu zabezpečení například 100 GB, aby regiony nepřesáhly možnosti regionálního serveru. Můžete zvážit deaktivaci automatického rozdělování a spolehnout se na počáteční sadu oblastí z předběžného dělení, například pokud používáte jednotné hodnoty hash pro vaše předpony klíčů, a můžete zajistit, že zatížení pro čtení/zápis do každé oblasti a také její velikost je jednotný napříč regiony v tabulce.
Vynucená rozdělení
HBase také umožňuje klientům vynutit rozdělení online tabulky ze strany klienta. Shell HBase lze například použít k rozdělení všech oblastí tabulky nebo k rozdělení oblasti, volitelně poskytnutím bodu rozdělení.
hbase(main):024:0> split 'b07d0034cbe72cb040ae9cf66300a10c', 'b' 0 row(s) in 0.1620 seconds
Při pečlivém sledování rozložení zátěže HBase, pokud zjistíte, že některé oblasti jsou zatěžovány nerovnoměrně, můžete zvážit ruční rozdělení těchto oblastí, abyste vyrovnali zatížení a zlepšili propustnost. Dalším důvodem, proč byste mohli chtít provést manuální rozdělení, je situace, kdy zjistíte, že počáteční rozdělení pro region není optimální a automatické rozdělení jste zakázali. K tomu může dojít například v případě, že se distribuce dat v průběhu času mění.
Jak se implementují rozdělení regionů
Jak požadavky na zápis zpracovává regionální server, hromadí se v úložném systému v paměti zvaném „memstore“. Jakmile se paměťové úložiště zaplní, jeho obsah se zapíše na disk jako další soubory úložiště. Tato událost se nazývá „vyprázdnění paměti“. Jak se hromadí soubory úložiště, RegionServer je „kompaktuje“ do kombinovaných větších souborů. Po dokončení každého vyprázdnění nebo zhutnění se zařadí požadavek na rozdělení regionu, pokud RegionSplitPolicy rozhodne, že region by měl být rozdělen na dva. Protože všechny datové soubory v HBase jsou neměnné, když dojde k rozdělení, nově vytvořené dceřiné oblasti nepřepíší všechna data do nových souborů. Místo toho vytvoří malé soubory podobné symbolickým odkazům, nazvané Referenční soubory, které směřují buď na horní nebo spodní část nadřazeného souboru úložiště podle bodu rozdělení. Referenční soubor bude použit stejně jako běžný datový soubor, ale pouze polovina záznamů. Oblast lze rozdělit pouze v případě, že již neexistují žádné odkazy na neměnné datové soubory nadřazené oblasti. Tyto referenční soubory jsou postupně vyčištěny komprimací, takže region přestane odkazovat na své rodičovské soubory a může být dále rozdělen.
Ačkoli rozdělení regionu je místní rozhodnutí učiněné na RegionServeru, samotný proces rozdělení musí být koordinován s mnoha aktéry. RegionServer upozorní Mastera před a po rozdělení, aktualizuje .META. tabulky, aby klienti mohli objevovat nové dceřiné oblasti, a přeuspořádá adresářovou strukturu a datové soubory v HDFS. Split je víceúkolový proces. Pro povolení vrácení v případě chyby uchovává RegionServer v paměti deník o stavu provádění. Kroky provedené RegionServerem k provedení rozdělení jsou znázorněny na obrázku 1. Každý krok je označen svým číslem kroku. Akce z RegionServers nebo Master jsou zobrazeny červeně, zatímco akce z klientů jsou zobrazeny zeleně.
1. RegionServer lokálně rozhodne o rozdělení regionu a připraví rozdělení. Jako první krok vytvoří znode v zookeeper pod /hbase/region-in-transition/region-name ve stavu SPLITTING.
2. Master se o tomto uzlu dozví, protože má hlídač pro nadřazený uzel v přechodové oblasti.
3. RegionServer vytvoří podadresář s názvem „.splits“ v adresáři nadřazené oblasti v HDFS.
4. RegionServer zavře nadřazenou oblast, vynutí vyprázdnění mezipaměti a označí oblast jako offline ve svých místních datových strukturách. V tomto okamžiku požadavky klientů přicházející do nadřazené oblasti způsobí výjimku NotServingRegionException. Klient to zkusí znovu s určitým odstupem.
5. RegionServer vytvoří adresáře regionů v adresáři .splits pro dceřiné regiony A a B a vytvoří potřebné datové struktury. Poté rozdělí soubory úložiště v tom smyslu, že vytvoří dva referenční soubory na soubor úložiště v nadřazené oblasti. Tyto referenční soubory budou ukazovat na soubory nadřazených oblastí.
6. RegionServer vytvoří skutečný adresář regionu v HDFS a přesune referenční soubory pro každou dceřinou společnost.
7. RegionServer odešle požadavek Put do .META. a nastaví nadřazený objekt jako offline v souboru .META. a přidává informace o dceřiných regionech. V tomto okamžiku nebudou v .META jednotlivé položky. pro dcery. Klienti uvidí, že nadřazená oblast je rozdělena, pokud naskenují .META., ale nebudou vědět o dceřiných položkách, dokud se neobjeví v .META.. Také, pokud toto Vložit do .META. uspěje, bude rodič efektivně rozdělen. Pokud RegionServer selže dříve, než toto RPC uspěje, hlavní server a server další oblasti otevírající oblast vyčistí špinavý stav rozdělení oblasti. Po .META. aktualizace však bude rozdělení regionů převedeno vpřed pomocí Master.
8. RegionServer otevírá dceřiné společnosti paralelně pro přijímání zápisů.
9. RegionServer přidá dceřiné A a B do .META. spolu s informacemi o tom, že hostí regiony. Po tomto okamžiku mohou klienti objevovat nové regiony a zadávat požadavky do nového regionu. Klienti mezipaměť .META. záznamy lokálně, ale když zadají požadavky na server regionu nebo .META., jejich mezipaměti budou zneplatněny a o nových regionech se dozvědí z .META..
10. RegionServer aktualizuje znode /hbase/region-in-transition/region-name v zookeeper na stav SPLIT, aby se o tom velitel mohl dozvědět. Balancér může libovolně znovu přiřadit dceřiné regiony serverům jiných regionů, pokud se tak rozhodne.
11. Po rozdělení budou meta a HDFS stále obsahovat odkazy na nadřazený region. Tyto odkazy budou odstraněny, když komprimace v dceřiných oblastech přepíše datové soubory. Úlohy garbage collection v hlavním serveru pravidelně kontrolují, zda dceřiné oblasti stále odkazují na nadřazené soubory. Pokud ne, nadřazená oblast bude odstraněna.
Sloučení oblastí
Na rozdíl od rozdělení regionů HBase v tomto bodě neposkytuje použitelné nástroje pro slučování regionů. Ačkoli existují nástroje HMerge a Merge, nejsou příliš vhodné pro obecné použití. V současné době neexistuje žádná podpora pro online tabulky a funkce automatického slučování. Nicméně s problémy, jako je OnlineMerge, Master iniciované automatické slučování regionů, zámky čtení/zápisu založené na ZK pro operace s tabulkami, pracujeme na stabilizaci rozdělení regionů a umožnění lepší podpory pro slučování regionů. Zůstaňte naladěni!
Závěr
Jak můžete vidět, pod kapotou HBase provádí spoustu úklidu, aby spravovala rozdělení regionů a provádí automatizované sdílení regionů. HBase však také poskytuje potřebné nástroje pro správu regionů, abyste mohli řídit proces rozdělení. Pomocí RegionSplitPolicy můžete také přesně řídit, kdy a jak k rozdělení regionů dochází.
Počet oblastí v tabulce a způsob rozdělení těchto oblastí jsou zásadní faktory pro pochopení a vyladění zatížení clusteru HBase. Pokud dokážete odhadnout rozložení klíčů, měli byste vytvořit tabulku s předrozdělením, abyste dosáhli optimálního výkonu počátečního zatížení. Můžete začít s nižším násobkem počtu serverů oblastí jako výchozím bodem pro počáteční počet oblastí a nechat převzít automatické rozdělení. Pokud nemůžete správně odhadnout počáteční body rozdělení, je lepší vytvořit tabulku s jedním regionem a spustit nějaké počáteční zatížení s automatickým rozdělením a použít IncresingToUpperBoundRegionSplitPolicy. Mějte však na paměti, že celkový počet regionů se časem ustálí a aktuální sada bodů rozdělení regionů bude určena z údajů, které tabulka dosud získala. Možná budete chtít neustále sledovat rozložení zátěže mezi regiony, a pokud se rozložení zátěže v průběhu času mění, použijte ruční rozdělení nebo nastavte agresivnější velikosti rozdělení regionů. Nakonec můžete vyzkoušet nadcházející funkci online sloučení a přispět svým případem použití.