Nejběžnější projekty pro Hadoop a Spark

Existuje jeden starý axiom, který zní asi takto: Pokud někomu nabídnete svou plnou podporu a finanční zajištění, aby udělal něco inovativního a jiného, skončí to nakonec tím, že udělá to, co dělají všichni ostatní.

To samé platí i pro technologie Hadoop, Spark či Storm. Všichni si myslí, že s těmito novými řešeními pro big data dělají něco výjimečného, ale netrvá to dlouho, než si všimnete stále se opakujících vzorů.

Konkrétní implementace se sice mohou do jisté míry lišit, ale na základě již existujících zkušeností zde uvádíme sedm nejběžnější projektů, se kterými se lze v této souvislosti setkat.

Projekt č. 1:Konsolidace dat

Můžeme to nazvat jakkoli, třeba „podnikové centrum dat“ nebo „datové jezero“. Myšlenkou je, že můžete mít různorodé zdroje dat a potřebujete pro ně dělat komplexní analýzy.

Tento typ projektu zahrnuje přebírání dat ze všech zdrojů (v reálném čase nebo v podobě dávek) a jejich načítání do Hadoopu.

Někdy je to první krok k proměně ve „společnost řízenou daty“ a někdy je třeba mít hezké reporty. Datová jezera mají obvykle podobu souborů (technologie HDFS) a tabulek (technologie Hive nebo Impala). Existují odvážná řešení, která pro většinu z toho používají HBase – a v budoucnu Phoenix, protože technologie Hive je relativně pomalá.

Prodejci rádi zmiňují vlastnosti jako „schéma při čtení,“ ale ve skutečnosti je k úspěchu nutná dobrá představa o tom, jak se budou data používat (toto schéma Hive se nebude výrazně lišit od toho, co byste dělali v rámci podnikového datového skladu).

Skutečným důvodem pro použití datového jezera jsou horizontální škálovatelnost a mnohem nižší náklady, než nabízejí řešení od firem jako Teradata či Netezza. Pro účely „analýzy“ mnoho lidí použije jako rozhraní technologie Tableau a Excel.

Náročnější společnosti se „skutečnými datovými vědci“ (matematici, obvykle s omezenými znalostmi jazyka Python) použijí jako rozhraní technologie Zeppelin nebo iPython.

Projekt č. 2: Specializovaná analýza

Mnoho projektů týkajících se konsolidace dat ve skutečnosti začíná tím, že vznikne specifický požadavek, v jehož rámci se zpracovává jedna datová množina systémem, který vykonává jen jeden druh analýzy.

Tendencí je specializace na konkrétní oblast, jako jsou například simulace rizik likvidity nebo využití metody Monte Carlo. V minulosti takové specializované analýzy závisely na zastaralých, proprietárních balíčcích, které neumožňovaly škálovatelnost podle rozsahu dat a často trpěly i omezenou sadou funkcí (částečně proto, že dodavatel softwaru nemohl dostatečně znát oblast, na kterou se zákazník hloubkově zaměřil).

Ve světě technologií Hadoop a Spark tyto systémy vypadají přibližně stejně jako tradiční systémy pro konsolidaci dat, ale často se využívá technologie HBase, vlastní ne-SQL kód a méně datových zdrojů (ne-li dokonce jen jeden). Využití technologie Spark právě pro tyto účely roste.

Projekt č. 3:Hadoop jako služba

V každé velké organizaci nevyhnutelně začnou s projekty „specializované analýzy“ (a ironicky s jedním až dvěma projekty „konsolidace dat“) vznikat problémy se správou několika různě nakonfigurovaných clusterů Hadoop, nezřídka dokonce pocházejících od různých dodavatelů.

Dalším krokem bývá pochopení nutnosti konsolidace včetně využití poolu zdrojů namísto toho, že je polovina současných uzlů velkou část doby nevyužitá.

Mohl by se využít cloud, ale mnoho společností tuto cestu použít nemůže nebo nechce, často z bezpečnostních důvodů (interní zásady a ochrana pracovních míst). To ale obvykle znamená mít balíčky kontejnerů typu Docker apod.

Vypadá to, že společnost Blue Data nabízí rozumné řešení tohoto typu, které lze přímo použít, což bude velmi zajímavé pro menší organizace, jež obvykle nemají  tolik prostředků pro nasazení technologie Hadoop v podobě služby.

Projekt č. 4: Kontinuální (streamingová) analytika

Mnoho lidí pro tyto účely používá pojem streamování, ale streamingová analytika se od toho, co si pod pojmem streaming ze zařízení obvykle můžeme představit,  liší.

Jde v podstatě o verzi analýzy vykonávané v reálném čase pro činnosti, které by organizace jinak dělala formou dávkového zpracování.

Vezměme si například boj s praním špinavých peněz a odhalování podvodů: Proč to nedělat transakčním způsobem a nezachytit to již v průběhu, namísto zpracování až po události na konci cyklu? Totéž lze říci o řízení zásob a čemkoliv dalším.

V některých případech jde o nový typ transakčního systému, který souběžně analyzuje data po částech, jak přibývají do systému.

Takové systémy zahrnují Spark nebo Storm, přičemž obvyklým úložištěm dat je HBase. Je ale jasné, že kontinuální analytika nenahrazuje všechny druhy analýz. Stále můžete potřebovat analýzu historických trendů nebo prozkoumat historická data z pohledu, který vás předtím nenapadl.

Projekt č. 5: Komplexní zpracování událostí

Zde se mluví o zpracování událostí v reálném čase, kde záleží na zlomcích sekundy. Přestože rychlost není dostatečná pro aplikace s ultranízkou latencí (pikosekundy nebo nanosekundy),  jako mají třeba špičkové obchodovací systémy, můžete očekávat rychlost odezvy v řádu milisekund.

Příkladem může být vyhodnocení záznamů o hovorech v reálném čase pro telekomunikační společnosti a zpracování událostí internetu věcí.

V některých případech uvidíte, že se u takových systémů používají Spark a HBase, ale obvykle potom není výkon dostatečný a je nutná konverze na technologii Storm, která se zakládá na vzoru Disruptor vyvinutém organizací LMAX Exchange.

V minulosti takové systémy vycházely ze zakázkově vytvořeného softwaru pro předávání zpráv nebo na vysoce výkonných standardních produktech klient-server pro předávání zpráv, současné objemy dat jsou ale pro oba tyto typy řešení už příliš velké.

Objemy obchodů a počet lidí s mobilními telefony od doby vzniku těchto historických systémů raketově vzrostly a zdravotnické i průmyslové senzory produkují příliš mnoho bitů. Slibně vypadá projekt Apex, který má být podle tvůrců ještě rychlejší než Storm.

Projekt č. 6: Streamování jako ETL

Někdy je potřebné zachytit streamovaná data a někde je uskladnit...

Tento příspěvek vyšel v Computerworldu 9/2015.Oproti této on-line verzi je výrazně obsáhlejší a přináší další poznatky a tipy, které lze využít při praktické implementaci u vás ve firmě.

Časopis (starší čísla i předplatné těch nadcházejících) si můžete objednat na adrese našeho vydavatelství.