I když je Hadoop stále poměrně mladou technologií v porovnání s ustálenými produkty v oblasti datových skladů, našel si za poslední roky cestu do mnoha společností, kde plní nezastupitelnou roli při zpracování a analýze masivních objemů dat. Apache Hadoop je otevřená platforma s aktivní komunitou vývojářů, která kromě údržby a optimalizace stávajících komponent přináší pořád nové funkce. Ty si postupně hledají cestu do známých distribucí, ať už jde o Clouderu, nyní již příbuzné Hortonworks nebo alternativně MapR. Abychom mohli na projektech přinášet zákazníkům moderní řešení, je nezbytné tyto trendy sledovat a znát jejich výhody i nevýhody. Jaké jsou dvě velké novinky v komponentách HDFS a Hive?
HDFS Erasure coding
HDFS neboli Hadoop Distributed File Systém představuje klíčový prvek většiny instalací Hadoopu. Slouží jako vysoce robustní uložiště, v němž je disková kapacita distribuovaná na mnoho vzájemně propojených strojů tvořících výpočetní cluster. Uložené soubory jsou rozděleny do bloků o stejné velikosti, které jsou ve výchozím nastavení třikrát replikovány na různé servery. To jednak zaručuje uchování dat při selhání až dvou serverů a navíc přispívá k realizaci jedné z centrálních myšlenek Hadoopu, tedy přesouvat výpočet za daty. Při třech replikách si systém může vybrat, na kterém uzlu bude optimální provést výpočet, navíc může jeden soubor po blocích zpracovávat paralelně.
Stinnou stránkou tohoto konceptu je, že efektivně využijeme pouze 33 % skutečné kapacity clusteru. Zvláště u dat, se kterými nepotřebujeme provádět výpočty, spíše je pouze archivovat, se dá hovořit o plýtvání místem. Hadoop proto ve verzi 3 přichází s implementací Erasure Coding. Jde o efektivní kódování, při kterém je každý blok dále rozdělen na menší buňky. Ty jsou v určitém počtu rozřazeny do skupin a ke každé skupině jsou dopočítány paritní buňky. Pokud ztratíme některé buňky ve skupině, paritní informace je postačující k rekonstrukci ztracených dat. Místo prostého duplikování tak dostáváme nástroj, jenž stále garantuje bezpečné uložení dat a při zachování stejné diskové kapacity HDFS umožňuje uložení většího množství dat. Reálné využití tak může růst až přes 70 % skutečné kapacity.
HDFS umožňuje zapnout Erasure Coding selektivně pouze na některá data. V jednom systému se tak mohou nacházet jak data, která aktivně transformujeme a analyzujeme, tak i data, která chceme archivovat.
Transakce v Hive
S další zajímavou funkcí přichází Hive 3. Apache Hive je systém pro správu velkých objemů dat v HDFS, nad kterými umožňuje spouštět SQL dotazy. Novinkou je podpora transakcí na úrovni jednotlivých řádků. Jinak vyjádřeno, v nové verzi Hive můžeme kromě SELECTů a INSERTů používat také UPDATE a DELETE. To je velká změna hlavně z toho důvodu, že jedním ze základních principů Hadoopu bylo „write once, read many“, tedy jednorázově zapsat data, a poté nad nimi spouštět dotazy, případně je transformovat do nové sady dat.
Když se podíváme do historie, tak předchozí verze Hive podporovala transakce na úrovni jednotlivých partition, což je konstrukt, který umožňuje data organizovat podle určitého klíče. Například data z jednotlivých dnů tak mohou být ukládána do zvláštních složek. Transakce na této úrovni ale v praxi vedly k tomu, že pro změnu jedné hodnoty bylo potřeba přepsat celou partition.
Proč se vývojáři Hivu rozhodli zavést tuto změnu? Jde zejména o podporu několika důležitých případů. Prvním je oprava existujících záznamů. Když se staráme o kvalitu dat, dřív nebo později nastane situace, kdy je potřeba v tabulce část záznamů opravit. Podobně, například v souvislosti s GDPR, nastávají situace, kdy potřebujeme z databáze vymazat data o některém uživateli. V neposlední řadě jde o lepší podporu streamingových aplikací, ve kterých často z povahy dat dochází k potřebě aktualizovat stávající záznamy. S možností upravovat jednotlivé řádky odpadá nutnost přepisovat zbytečně velké množství dat.
Při praktickém použití této funkce je nutné brát ohledy na způsob, kterým Hive transakce provádí. Klíčovou komponentou celého systému je Transaction Manager. Ten přiděluje jednotlivým transakcím sekvenční čísla. Při zápisu jsou data ukládána do dvou typů souborů. Základem tabulky je takzvaný base file, který obsahuje poslední zkonsolidovanou verzi dat. Při zápisu nových řádek, jejich aktualizaci nebo mazání se zapisuje delta file, který nese informaci o tom, jak byla data v base souboru od poslední konsolidace modifikována. Když uživatel čte data, Transaction Manager poskytne informaci, které delta soubory je nutné přečíst, aby uživateli byla navrácena aktuální hodnota.
Popsaná architektura s sebou nese problém v podobě klesajícího výkonu čtení při rostoucím množství delta souborů. Hive proto podle nastavitelných parametrů spouští kompaktace, které delta soubory sloučí zpět do jediného base file. To je poměrně drahá operace. Navíc v rámci updatů dat roste velikost tabulky, i když počet řádků zůstává stejný. Rovněž je nutné zmínit, že transakční zpracování v Hive obsahuje jenom podmnožinu vlastností, které chápeme jako běžnou součást transakcí v tradičních relačních databázích. Nejsou například podporovány příkazy COMMIT a ROLLBACK, rovněž nemůžeme nastavovat stupeň izolace. Podpora transakcí je taktéž omezena pouze na tabulky, které uchovávají data ve formátu ORC.
V článku jsme popsali možnost efektivního uložení v HDFS a podporu transakcí v Hivu. Nejde však o jediné novinky v nové verzi Hadoopu. Technologie ve světě velkých dat stále prochází rychlým vývojem. Pamatujte ale, že každá nová funkce má své nesporné případy využití, stejně jako úskalí, na které je třeba myslet. Každému použití novinky na projektu tak musí předcházet analýza a ověření, zda aplikace povede ke kýženému výsledku.
Autor: Tomáš Duda
Big Data Engineer