Blog fulltextového týmu

V minulém díle jsme si Hadoop představili a nyní se podíváme víc pod kapotu.
Prakticky o všem v Hadoopu se dá říct, že to není žádný převratný vynález nebo
něco naprosto nepochopitelného. Vše je logickým vyústěním potřeby ukládat velká
data a nad nimi provádět distribuované výpočty.

Z toho můžeme odvodit i základ Hadoopu:

•  HDFS – distribuovaný souborový systém
•  Map/Reduce framework – distribuované výpočty

To samotné by však pro každého nebylo dostačující, a tak nad Hadoopem je dnes už
postavena kupa dalších aplikací, která buď zjednoduše práci s ním, daty v něm
uloženými nebo poskytuje úplně nové funkce. Je možné, že Vás Hadoop zatím příliš nezaujal, je šance, že tyto další aplikace by mohly. Vyjmenujme tedy aspoň některé:

• Hive – datový sklad, který umožňuje nad uloženými daty spouštět HQL dotazy (podobné SQL)
• Mahout – knihovna pro strojové učení a data mining
• Pig – jazyk pro práci s uloženými daty bez nutnosti psaní Map/Reduce jobů
• Cascading – jazyk pro práci s uloženými daty bez nutnosti psaní Map/Reduce jobů
• HBase – NoSQL databáze

V tomto článku se podíváme podrobněji na souborový systém.

HDFS

HDFS je distribuovaný souborový systém napsaný v Javě (nechytejte se za hlavu,
je to rychlé) přímo pro potřeby spouštění Map/Reduce aplikací, určený k nasazení
na levném HW. Z toho plynou určité požadavky a omezení tohoto filesystému v
rámci co nejjednodušší implementace:

1. odolnost proti chybám HW - můžeme se stavět na hlavu, ale počítače stejně
   budou padat, přehřívat se, bude jim docházet paměť či místo na disku, disky
   budou odcházet do křemíkového nebe či pekla a čím víc strojů ve svazku budeme
   mít, tím větší bude pravděpodobnost, že k tomu dojde. HDFS je proto chytře
   replikované, umí detekovat různé chyby a zotavit se z nich
2. streamování souborů – důraz je kladen především na propustnost a ne na
   přístupové doby
3. orientace na velké soubory – velká data jsou uložená v rozumném množství
   velkých souborů a ne v kupě maličkých
4. co se jednou zapíše, už nelze změnit – aneb write-once-read-many, tj. jednou
   zapsaný soubor už není možné měnit ani přidávat data na jeho konec (určitá
   podpora pro append už sice existuje – HDFS-265, ale není to zdaleka tak jednoduché jako v normálním souborovém systému a používá se
   jen ve speciálních případech)
5. „Moving Computation is Cheaper than Moving Data“ – výpočet je efektivnější
   spustit přímo u dat a ne tahat data po síti

HDFS si představte jako klasický souborový systém s adresáři, soubory a
oprávněními. Se soubory je možné provádět tradiční operace s výjimkou změny
souboru. Zajímavostí je trochu nezvyklý atribut souboru, a to počet požadovaných
replik. Soubory se dělí na bloky, velikost jednoho bloku je standardně 64MB.

hadice:~# hadoop fs -ls /user/michel
 Found 2 items
 -rw-r--r-- 2 michel grp 193 2011-12-29 14:54 /user/michel/fi10
 drwxr-xr-x - michel grp 0 2011-12-29 15:20 /user/michel/fi10.wcl

Architektura

Architektura systému je tvořena především dvěma komponentami typu master/slave,
kde NameNode je master starající se o metadata – v podstatě seznam souborů a
adresářů, jejich mapování na bloky a umístění daných bloků. DataNode je slave,
který neví vůbec nic o souborech, slouží jako úložiště bloků, ty je na něj možné
zapisovat a pochopitelně z něj zase číst. DataNode reportuje NameNodu seznam
svých bloků a NameNode mu může nařídit blok někam dodatečně zreplikovat či smazat.

Klient může provádět operace se souborovým systémem, v tom případě se o vše
postará NameNode. Při čtení souboru si klient nejdříve na NameNode zjistí umístění
bloků daného souboru a pak již přímo komunikuje s patřičným DataNode. Data tak
proudí po síti přímo bez prostředníka. Zápis probíhá analogicky, klient nejdříve
založí soubor pomocí NameNode a ten mu řekne, jaký DataNode má použít.

Replikace

A jak je to s tou replikací? Data jsou replikována tak, aby na jednom stroji
ležela vždy jedna replika, tedy při stupni replikace 2 leží blok na 2 různých
strojích. Systém tak není odolný pouze před výpadkem jednoho disku jako u
diskových polí, ale je odolný před výpadkem celého stroje. Je na místě
zdůraznit, že v tom případě není nutné disková pole používat, ono je to totiž
dokonce nevhodné! Zajímavý je ještě samotný průběh replikace, při zápisu nového
bloku s replikací 3 klient provádí zápis pouze jednou, DataNody replikují data
ihned pomocí „replikačního vláčku“, první DN pošle data na druhý a druhý pak dál
na třetí.

Jak je vidět návrh HDFS není nějak zvlášť složitý, bylo by samozřejmě možné se
pustit ještě mnohem víc do hloubky, ale pro základní představu by nám to mělo
stačit. A jak to u nás používáme? Máme ve svazku 76 strojů s celkovou kapacitou
510 TB, což při replikaci 3 dává zhruba 170 TB, aktuálně máme asi poloviční
zaplnění a 9 miliónů souborů. Příště se podíváme na samotný Map/Reduce.

Už pár let se v odborných periodicích, na IT serverech i různých blozích pravidelně objevují termíny cloud, big data, NoSQL databáze a všichni zasvěceně přikyvujeme. Člověk se sice moc nedočte, k čemu jsou dobré, ale jsou tu s námi a nechávají nás klidnými. Až do doby, kdy začneme řešit tu otázku, kam s nimi, s těmi velkými daty.

Pokud nejste úplně v obraze, ukažme si to nejdřív na nějakém příkladě. Představme si, že provozujeme velký zpravodajský server, máme k dispozici access logy pár let dozadu a dostaneme úkol zjistit čtenost jednotlivých rubrik a najít nejčtenější články. Logy jsou pochopitelně obrovské, gzipované, rozložené přes několik strojů, v horším případě zálohované na pásce. A potřebujeme to zjistit do zítra, protože to vedení potřebuje k dalšímu rozhodování nebo má zrovna vyjít PR článek, kde se tím máme pochlubit. Nemožné? Jistě, na jednom stroji by to šlo obtížně, na více strojích by to sice šlo, ale data budou chtít ručně zagregovat. Pro jednou to tedy nějak zbastlíme, ručně spojíme výsledky z jednotlivých strojů v tabulkovým kalkulátoru a při vhodné konstelaci hvězd se to třeba i stihne. Druhý den za námi přijde někdo z vedení, že by je zajímala statistika pro pracovní dny a víkendy zvlášť. Zatneme zuby a odpovíme: „Proč by ne?“….

Většina z nás je nejspíš zvyklá takové výpočty provádět na jednom stroji a vystačí si s různými „standardizovanými“ nástroji jako je grep, sed, awk, nebo data nahraje do SQL databáze a dotazuje se přímo nad nimi. Jednoduchost je jasným přínosem a nelze ji popírat. Od určitého objemu dat a požadovaného množství výpočtů nutně narazíme a budeme nuceni změnit svůj přístup. Ve chvíli, kdy nám přestane pro výpočty stačit současný jeden stroj, můžeme koupit větší a lepší a data přesunout na něj. Časem to však může být příliš finančně nákladné nebo dokonce už takový stroj taky nemusí existovat. Můžeme si říct, že ty výpočty vlastně nepotřebujeme a data dál jen syslit. Není ale škoda mít k dispozici krásná data a nemít možnost s nimi pracovat?

Dobře, rozložíme data na více strojů a začneme řešit různé související problémy:

1. kam a jak uložit vstupní data?
2. jak spustit na všech strojích stejný výpočet?
3. jak mezi více stroji přenášet mezivýsledky?
4. jak spojit a kam uložit výsledky?

Naštěstí nejsme první, kdo si podobné otázky položil a tak už takové systémy existují. A přejdeme tedy rovnou k tomu z nejpopulárnějších a ještě k tomu zdarma – Hadoop. Tohle heslo za sebou dnes už skrývá pořádnou kupu firem a dalších projektů s ním spojených, nutno dodat, že situace není právě přehledná a než se ponoříte do hlubšího studia, doporučuji se pořádně nadechnout. Hadoop ekosystém je už teď tak velký, že v podstatě není v silách jednoho člověka pochopit a naučit se správně používat všechny v něm dostupné nástroje, zvlášť když vývoj probíhá tak překotně. Nechci Vás však odradit, naučit se alespoň část používat opravdu stojí za to, jen je nutné si na začátku dle popisů či zkušeností dalších lidí zvolit ty správné nástroje.

Vraťme se tedy k řešení námi položených otázek:

1. data bude zřejmě nejlepší uložit do distribuovaného souborového systému, co třeba HDFS (Hadoop Distributed File System)?
2. na všech strojích spustíme výpočet jako tzv. Map
3. spojení mezivýsledků provedeme pomocí Reduce… a máme tu Hadoop MapReduce, ten pochopitelně zajistí i přenos mezivýsledků mezi stroji
4. výsledky by se nám nemusely vejít na jeden stroj, takže je uložíme opět do HDFS

Prima, to bychom měli, vynalezli jsme základní stavební kameny Hadoopu a už víme, k čemu jsou dobré. Prozatím můžeme prohlásit vše ostatní za třešničky na dortu, které nám zpříjemňují či jinak zjednodušují práci s Hadoopem.

Hadoop je tedy framework pro distribuované zpracování velkých dat pomocí jednoduchého programovacího modelu. Celý systém velmi dobře škáluje, pokud chcete počítat s většími daty či výpočet urychlit, v podstatě stačí přidat do svazku další stroje. Základní myšlenkou je nespoléhat na spolehlivost použitého HW, ale zajistit vysokou dostupnost softwarově, tj. je možné použít levnější, ne příliš spolehlivé stroje, systém v případě selhání stroje tento odstaví a svazek pokračuje dál.

Je třeba zmínit, že základ Hadoopu je napsán v Javě, což s sebou nese určitá pozitiva i negativa tohoto jazyka. Vývoj jde rychle od ruky, na druhou stranu si člověk užije perné chvilky s použitou pamětí a garbage collectorem, zvláště v případech, kdy dopředu přesně nevíme, jak zpracovávaná data přesně vypadají, což je v případě dat získaných z internetu a z chování uživatelů častý jev. Pro psaní úloh je možné použít i jiné jazyky jako např. Python nebo C++, ale jsou zde určitá omezení a ve většině případů bude kód v Javě rychlejší nebo Vám nabídne více možností řešení určitého problému.

K čemu se Hadoop hodí:

• různé statistiky a histogramy z logů
• strojové učení
• analýza webových stránek
• vytvoření invertovaného indexu pro vyhledávání
• výroba jazykových korpusů

Příště se s Hadoopem seznámíme podrobněji.