Nedávno jsem přednášel na LA Hadoop User Group o Apache HBase Do's and Don'ts. Publikum bylo skvělé a mělo velmi informované a dobře formulované otázky. Jody ze Shopzilly byl vynikající hostitel a dlužím mu velké díky za to, že mi dal příležitost mluvit s více než 60 hadoopery z LA. Vzhledem k tomu, že ne každý žije v LA nebo by se na setkání mohl dostat, shrnul jsem zde některé důležité body. Pro ty z vás, kteří mají náročný den, je zde tl;dr:
- HBase je dobrý, ale nenahrazuje RDBMS nebo HDFS
- Dobrá konfigurace znamená dobrý provoz
- Monitor monitor monitor monitor monitor monitor
My v Cloudera jsme velkými fanoušky HBase. Milujeme technologii, milujeme komunitu a zjistili jsme, že se skvěle hodí pro mnoho aplikací. Úspěšné použití HBase bylo dobře zdokumentováno a v důsledku toho mnoho organizací zvažuje, zda se HBase hodí pro některé z jejich aplikací. Impulsem pro mou přednášku a tento navazující blogový příspěvek je objasnit některé dobré aplikace pro HBase, varovat před některými špatnými aplikacemi a zdůraznit důležité kroky k úspěšnému nasazení HBase.
Kdy použít HBase
Nejdůležitější při pohledu na HBase je to, že i když je skvělým řešením mnoha problémů, není to stříbrná kulka. HBase není optimalizován pro klasické transakční aplikace ani pro relační analytiku. Není to také úplná náhrada za HDFS při provádění velké dávky MapReduce. Podívejte se na některé z případů použití v tomto příspěvku, abyste získali představu o tom, které aplikace jsou vhodné pro HBase, a pokud máte dotazy, pokračujte a zveřejněte je na seznamech. Už jsem zmínil, že komunita je fantastická?
S tímto upozorněním – proč byste měli používat HBase? Pokud má vaše aplikace variabilní schéma, kde se každý řádek mírně liší, měli byste se podívat na HBase. Jako příklad provedení modelovacího cvičení pomocí standardního relačního schématu; Pokud nemůžete přidávat sloupce dostatečně rychle a většina z nich má v každém řádku hodnotu NULL, měli byste zvážit HBase. Pokud zjistíte, že jsou vaše data uložena v kolekcích, například některá metadata, data zpráv nebo binární data, která jsou všechna klíčovaná na stejné hodnotě, měli byste zvážit HBase. Pokud při ukládání nebo načítání potřebujete klíčový přístup k datům, měli byste zvážit HBase.
Podpůrné služby
Za předpokladu, že jste přesvědčeni, že HBase se pro vaši aplikaci hodí, zde je několik tipů, které je třeba vzít v úvahu při jeho nasazení. Existuje několik podpůrných služeb, které jsou důležité a jedna, která je vyžadována. Pokud jste se ještě nedívali na ZooKeeper, nyní je čas. HBase používá ZooKeeper pro různé distribuované koordinační služby, jako jsou hlavní volby. Jak se HBase vyvíjí a roste, nadále spoléhá na ZooKeeper pro další funkce, což z něj činí klíčovou součást systému. Kromě toho byste měli mít k dispozici správné síťové služby, jako je NTP a DNS. HBase závisí na tom, že všechny uzly v clusteru mají úzce synchronizované hodiny a vzájemně se konzistentně odkazují. Použití NTP a DNS zajišťuje, že nenarazíte na podivné chování, když si jeden uzel A myslí, že čas je zítra, a uzel B si myslí, že je včera. Předejdete také situacím, kdy hlavní uzel řekne uzlu C, aby obsluhoval oblast, ale uzel C nezná svůj vlastní název a neodpovídá. Použití NTP a DNS vám ušetří spoustu starostí, jakmile začnete.
Řekl jsem, že nejdůležitějším faktorem při výběru HBase je ujistit se, že máte vhodný případ použití. Nejdůležitější věcí při používání HBase je sledování systému. Monitorování je klíčem k úspěšným operacím HBase. Stejně jako v případě mnoha distribuovaných systémů je HBase náchylná ke kaskádovým poruchám. Pokud se jeden uzel začne přehazovat, může ztratit kontakt s masterem, což způsobí, že zátěž převezme jiný server a přetíží se. Tento druhý server selže a selhání bude kaskádové. Musíte sledovat paměť, CPU, I/O a síťovou latenci a šířku pásma na každém z vašich uzlů HBase, abyste se ujistili, že fungují v rámci zdravých parametrů. Monitorování je nejdůležitějším postupem pro provoz zdravého clusteru HBase.
Osvědčené postupy pro architekturu HBase
Rychle vpřed k vašemu dobře monitorovanému clusteru HBase s perfektním případem použití, zde jsou některé osvědčené postupy. Použijte předponu klíče, která se dobře distribuuje na základě vašeho případu použití. Pokud před klíčem uvedete časové razítko nebo jakoukoli podobnou hodnotu, která je po seřazení uložena nebo dotazována v dávce, pravděpodobně přetížíte každý server regionu místo rovnoměrného rozložení zátěže. Také byste měli udržovat počet regionů na rozumném počtu na základě velikosti paměťového úložiště a množství paměti RAM a RegionServer JVM by měl být omezen na 12 GB haldy java, aby se minimalizovaly dlouhé GC pauzy. Například počítač s 36 GB RAM, na kterém běží také démon DataNode, by mohl zpracovat přibližně 100 oblastí s aktivními zápisy a pamětí o velikosti 48 MB. To umožňuje dostatek prostoru pro paměťové požadavky DataNode a RegionServer, prostor pro vyrovnávací paměť pro soubory Linuxu a přiměřenou velikost zarovnání pro každý RegionServer.
Několik doporučení pro konfiguraci zahrnuje zakázání automatického zhutňování (ve výchozím nastavení k němu dochází každých 24 hodin od zahájení HBase) a naplánujte jej tak, aby se spouštěl každý den mimo špičku. Měli byste také nakonfigurovat kompresi (jako je LZO) a explicitně umístit správně nakonfigurovaný adresář HBase conf do vaší CLASSPATH.
HBase NEDĚLÁ
Pokryli jsme širokou škálu osvědčených postupů pro HBase. Existuje také několik vzorů použití, kterým je třeba se vyhnout. Neočekávejte například, že budete HBase používat jako velkoobchodní náhradu za každou z vašich relačních databází. HBase je skvělá v mnoha věcech, ale nenahrazuje relační databáze. Pro začátek nemluví o SQL, nemá optimalizátor, nepodporuje transakce mezi záznamy ani spojení. Pokud nic z toho ve své databázové aplikaci nepoužíváte, HBase by vám mohla velmi dobře vyhovovat.
Buďte opatrní při spouštění smíšených úloh na clusteru HBase. Pokud máte smlouvy SLA na přístup HBase nezávisle na jakýchkoli úlohách MapReduce (například transformace v Pig a poskytování dat z HBase), spusťte je na samostatných clusterech. HBase je náročný na CPU a paměť se sporadickým velkým sekvenčním I/O přístupem, zatímco úlohy MapReduce jsou primárně I/O svázány s pevnou pamětí a sporadickým CPU. Jejich kombinace může vést k nepředvídatelným latencím pro spory HBase a CPU mezi těmito dvěma. Sdílený cluster také vyžaduje méně úlohových slotů na uzel, aby vyhovoval požadavkům HBase CPU (obecně polovina slotů na každém uzlu, které byste alokovali bez HBase). Sledujte také swap paměti. Pokud HBase začne swapovat, je velká šance, že vynechá srdeční tep a vypadne z clusteru. Na zaneprázdněném clusteru to může přetížit jiný region, což způsobí jeho výměnu a kaskádu selhání.
Poslední myšlenky
Jedna poslední rada, než to shrneme. Při načítání HBase použijte HFileOuputFormat, pokud načítáte přes úlohu MapReduce nebo kolekci serverů pomocí dávkových vkládání. Načtení pomocí jednoho klienta bude pro tohoto klienta překážet a nebude využívat škálovatelnost, kterou poskytuje HBase.
Stručně řečeno, zvažte HBase, když načítáte data podle klíče, vyhledáváte data podle klíče (nebo rozsahu), poskytujete data podle klíče, dotazujete se na data podle klíče nebo když ukládáte data podle řádku, která dobře neodpovídají schématu.
Případy použití
- Apache HBase:Používá technologii HBase Wiki
- Mozilla:Přesun Socorra na HBase
- Facebook:Nový systém zasílání zpráv v reálném čase od Facebooku:HBase
- StumbleUpon:HBase na StumbleUpon