Existuje starý axiom, který zní asi takto: Pokud někomu nabídnete plnou podporu a finanční podporu, aby udělal něco jiného a inovativního, skončí s tím, co dělají všichni ostatní.
Tak to jde s Hadoopem, Sparkem a Stormem. Každý si myslí, že s těmito novými technologiemi velkých dat dělá něco zvláštního, ale netrvá dlouho, než se setkáte se stejnými vzory znovu a znovu. Konkrétní implementace se mohou poněkud lišit, ale na základě mých zkušeností je zde sedm nejčastějších projektů.
Projekt č. 1: Konsolidace dat
Říkejte tomu „podnikové datové centrum“ nebo „datové jezero“. Myšlenka je, že máte různorodé zdroje dat a chcete v nich provést analýzu. Tento typ projektu spočívá v získávání zdrojů ze všech zdrojů (buď v reálném čase nebo v dávce) a jejich vložení do Hadoopu. Někdy je to první krok k tomu, abyste se stali „společností založenou na datech“; někdy prostě chcete hezké zprávy. Datová jezera se obvykle zhmotňují jako soubory na HDFS a tabulkách v Hive nebo Impala. Existuje odvážný nový svět, kde se většina z toho objeví v HBase - a ve Phoenixu v budoucnu, protože Hive je pomalý.
Prodejci rádi říkají věci jako „schéma při čtení“, ale ve skutečnosti, abyste byli úspěšní, musíte mít dobrou představu o tom, jaké budou vaše případy použití (toto schéma Úlu nebude vypadat strašně odlišně od toho, co byste dělali v podnikový datový sklad). Skutečným důvodem pro datové jezero je horizontální škálovatelnost a mnohem nižší náklady než Teradata nebo Netezza. Pro „analýzu“ mnoho lidí nastavilo na předním panelu Tableau a Excel. Sofistikovanější společnosti s „skutečnými datovými vědci“ (matematici, kteří píší špatný Python) používají jako front-end notebook Zeppelin nebo iPython.
Projekt č. 2: Specializovaná analýza
Mnoho projektů konsolidace dat ve skutečnosti začíná tady, kde máte zvláštní potřebu a vložíte jednu datovou sadu pro systém, který provádí jeden druh analýzy. Ty mají tendenci být neuvěřitelně specifické pro danou doménu, jako je riziko likvidity / simulace Monte Carlo v bance. V minulosti takové specializované analýzy závisely na zastaralých proprietárních balíčcích, které se nedokázaly zvětšit jako data a často trpěly omezenou sadou funkcí (částečně proto, že prodejce softwaru nemohl vědět o doméně tolik jako instituce ponořen do ní).
Ve světech Hadoop a Spark vypadají tyto systémy zhruba stejně jako systémy konsolidace dat, ale často mají více HBase, vlastní kód mimo SQL a méně zdrojů dat (ne-li jen jeden). Stále více jsou založeny na Sparku.
Projekt č. 3: Hadoop jako služba
V jakékoli velké organizaci s projekty „specializované analýzy“ (a ironicky jednoho nebo dvou projektů „konsolidace dat“) začnou nevyhnutelně pociťovat „radost“ (tj. Bolest) ze správy několika různě konfigurovaných klastrů Hadoop, někdy z různých prodejci. Dále řeknou: „Možná bychom to měli konsolidovat a shromáždit zdroje,“ místo aby polovinu jejich uzlů polovinu času nečinně používaly. Mohli by jít do cloudu, ale mnoho společností buď nemůže, nebo nebude, často z bezpečnostních důvodů (čtěte: vnitřní politika a ochrana pracovních míst). To obecně znamená spoustu receptů kuchařů a nyní balíčky kontejnerů Docker.
Ještě jsem to nepoužil, ale zdá se, že Blue Data má nejblíže k out-of-the-box řešení zde, což také osloví menší organizace, kterým chybí možnosti nasadit Hadoop jako službu.
Projekt č. 4: Streamovací analytika
Mnoho lidí by tomu říkalo „streamování“, ale analytika streamování se liší od streamování ze zařízení. Streamovací analytika je často verzí toho, co organizace dělala v dávkách, v reálném čase. Vezměte si praní špinavých peněz nebo detekci podvodů: Proč to neudělat na základě transakce a nezachytit to tak, jak se to stane, spíše než na konci cyklu? Totéž platí pro správu zásob nebo cokoli jiného.
V některých případech se jedná o nový typ transakčního systému, který analyzuje data kousek po kousku, když je paralelně shuntujete do analytického systému. Takové systémy se projevují jako Spark nebo Storm s HBase jako obvyklým úložištěm dat. Upozorňujeme, že streamovací analytika nenahrazuje všechny formy analytiky; stále budete chtít zobrazit historické trendy nebo se podívat na minulá data a najít něco, o čem jste nikdy neuvažovali.
Projekt č. 5: Složité zpracování událostí
Tady mluvíme o zpracování událostí v reálném čase, kde záleží na sekundách. I když stále nejste dostatečně rychlí pro aplikace s extrémně nízkou latencí (pikosekunda nebo nanosekunda), jako jsou špičkové obchodní systémy, můžete očekávat dobu odezvy milisekund. Mezi příklady patří hodnocení záznamů o hovorech v reálném čase pro telekomunikační společnosti nebo zpracování událostí internetu věcí. Někdy uvidíte, že takové systémy používají Spark a HBase - ale obecně jim padnou do tváře a musí být převedeny na Storm, který je založen na vzoru Disruptor vyvinutém burzou LMAX.
V minulosti byly takové systémy založeny na přizpůsobeném softwaru pro zasílání zpráv - nebo na vysoce výkonných, běžných produktech pro zasílání zpráv mezi klientem a serverem - ale dnešní objemy dat jsou příliš mnoho. Od vytvoření těchto starších systémů vzrostly objemy obchodování a počet lidí s mobilními telefony a lékařské a průmyslové senzory vyčerpaly příliš mnoho bitů. Ještě jsem to nepoužil, ale projekt Apex vypadá slibně a tvrdí, že je rychlejší než Storm.
Projekt č. 6: Streamování jako ETL
Někdy chcete zachytit streamovaná data a někde je uskladnit. Tyto projekty se obvykle shodují s č. 1 nebo č. 2, ale přidávají svůj vlastní rozsah a vlastnosti. (Někteří lidé si myslí, že dělají č. 4 nebo č. 5, ale ve skutečnosti se ukládají na disk a data analyzují později.) Jedná se téměř vždy o projekty Kafka a Storm. Používá se také Spark, ale bez odůvodnění, protože opravdu nepotřebujete analýzu v paměti.
Projekt č. 7: Výměna nebo rozšíření SAS
SAS je v pořádku; SAS je fajn. SAS je také drahý a nekupujeme boxy pro všechny datové vědce a analytiky, abyste si s daty mohli „hrát“. Kromě toho jste chtěli udělat něco jiného, než dokáže SAS, nebo vygenerovat hezčí graf. Tady je vaše pěkné datové jezero. Tady je iPython Notebook (nyní) nebo Zeppelin (později). Výsledky vložíme do SAS a zde uložíme výsledky ze SAS.
I když jsem viděl další projekty Hadoop, Spark nebo Storm, jedná se o „normální“ každodenní typy. Pokud používáte Hadoop, pravděpodobně je poznáte. Některé případy použití těchto systémů, které jsem implementoval před lety a pracoval s jinými technologiemi.
Pokud jste staromódem, který se příliš bojí „velkého“ ve velkých datech nebo „dělat“ v Hadoopu, nedělejte to. Čím více věcí se mění, tím více zůstávají stejné. Najdete spoustu paralel mezi věcmi, které jste použili k nasazení, a hipsterskými technologiemi vířícími kolem Hadooposféry.
