7-те най-често срещани Hadoop и Spark проекти

Има стара аксиома, която гласи нещо подобно: Ако предложите на някого пълната си подкрепа и финансова подкрепа, за да направи нещо различно и иновативно, той в крайна сметка ще направи това, което правят всички останали.

Така става с Hadoop, Spark и Storm. Всеки си мисли, че прави нещо специално с тези нови технологии за големи данни, но не отнема много време, за да срещнете едни и същи модели отново и отново. Конкретните реализации могат да се различават до известна степен, но въз основа на моя опит, ето седемте най-често срещани проекта.

Проект № 1: Консолидиране на данни

Наречете го „корпоративен център за данни“ или „езеро за данни“. Идеята е, че имате различни източници на данни и искате да извършите анализ в тях. Този тип проекти се състоят от получаване на емисии от всички източници (или в реално време, или като партида) и пускането им в Hadoop. Понякога това е първа стъпка към превръщането в „компания, управлявана от данни“; понякога просто искате красиви отчети. Езерата на данни обикновено се материализират като файлове на HDFS и таблици в Hive или Impala. Има смел, нов свят, в който голяма част от това се появява в HBase - и във Финикс, в бъдеще, защото Hive е бавен.

Продавачите обичат да казват неща като „схема при четене“, но в действителност, за да успеете, трябва да имате добра представа за това какви ще бъдат вашите случаи на използване (тази схема на Hive няма да изглежда ужасно различно от това, което бихте направили в корпоративно хранилище за данни). Истинската причина за езерото за данни е хоризонталната мащабируемост и много по-ниска цена от Teradata или Netezza. За „анализ“ много хора настроиха Tableau и Excel отпред. По-сложните компании с „истински учени за данни“ (математици, които пишат лош Python) използват Zeppelin или iPython бележник като преден край.

Проект № 2: Специализиран анализ

Много проекти за консолидация на данни всъщност започват тук, където имате специална нужда и въвеждате един набор от данни за система, която извършва един вид анализ. Те обикновено са невероятно специфични за дадена област, като риск от ликвидност / симулации на Монте Карло в банка. В миналото такива специализирани анализи зависеха от остарели, патентовани пакети, които не можеха да се мащабират както данните и често страдаха от ограничен набор от функции (отчасти защото доставчикът на софтуер не можеше да знае толкова много за домейна, колкото институцията потопен в него).

В света на Hadoop и Spark тези системи изглеждат приблизително същите като системите за консолидация на данни, но често имат повече HBase, персонализиран не-SQL код и по-малко източници на данни (ако не само един). Все по-често те са базирани на Spark.

Проект № 3: Hadoop като услуга

Във всяка голяма организация с проекти за „специализиран анализ“ (и по ирония на съдбата един или два проекта за „консолидиране на данни“) те неизбежно ще започнат да изпитват „радостта“ (т.е. болката) от управлението на няколко по-различно конфигурирани клъстера Hadoop, понякога от различни доставчици. След това те ще кажат: „Може би трябва да консолидираме това и да обединим ресурси“, вместо половината от техните възли да стоят без работа половината време. Те биха могли да отидат в облака, но много компании или не могат, или не, често от съображения за сигурност (прочетете: вътрешна политика и защита на работните места). Това обикновено означава много рецепти за готвачи и сега пакети за контейнери на Docker.

Все още не съм го използвал, но изглежда, че Blue Data има най-близкото нещо до нестандартното решение тук, което ще се хареса и на по-малки организации, които нямат достатъчно възможности да внедрят Hadoop като услуга.

Проект № 4: Потокова аналитика

Много хора биха нарекли това „стрийминг“, но поточният анализ е доста различен от стрийминга от устройства. Често стрийминг анализът е по-версия в реално време на това, което една организация правеше на партиди. Вземете противодействие на изпирането на пари или измамата: Защо да не направите това на базата на транзакцията и да го хванете, както се случва, а не в края на цикъл? Същото важи и за управлението на запасите или нещо друго.

В някои случаи това е нов тип транзакционна система, която анализира данни бит по бит, докато паралелно ги шунтирате в аналитична система. Такива системи се проявяват като Spark или Storm с HBase като обичайното хранилище на данни. Имайте предвид, че стрийминг анализът не замества всички форми на анализ; все пак ще искате да извадите на показ исторически тенденции или да погледнете минали данни за нещо, което никога не сте обмисляли.

Проект № 5: Сложна обработка на събития

Тук говорим за обработка на събития в реално време, където подсекундите имат значение. Въпреки че все още не е достатъчно бърз за приложения с ултра ниска латентност (пикосекунда или наносекунда), като системи за търговия от висок клас, можете да очаквате милисекунди време за реакция. Примерите включват рейтинг в реално време на записи на данни за обаждания за телекомуникации или обработка на събития в Интернет на нещата. Понякога ще видите, че такива системи използват Spark и HBase - но обикновено те падат по лицата си и трябва да бъдат преобразувани в Storm, който се основава на модела Disruptor, разработен от борсата LMAX.

В миналото такива системи се основаваха на персонализиран софтуер за съобщения - или на високопроизводителни, готови продукти за съобщения клиент-сървър, но днешните обеми данни са твърде много и за двете. Обемите на търговия и броят на хората с мобилни телефони са нараснали, откакто са създадени тези стари системи, а медицинските и индустриалните сензори изпомпват твърде много битове. Все още не съм го използвал, но проектът Apex изглежда обещаващ и твърди, че е по-бърз от Storm.

Проект № 6: Стрийминг като ETL

Понякога искате да заснемете поточни данни и да ги съхраните някъде. Тези проекти обикновено съвпадат с № 1 или № 2, но добавят свой обхват и характеристики. (Някои хора си мислят, че правят номер 4 или номер 5, но всъщност изхвърлят на диск и анализират данните по-късно.) Почти винаги това са проектите на Kafka и Storm. Също така се използва Spark, но без обосновка, тъй като всъщност не се нуждаете от анализ в паметта.

Проект № 7: Замяна или увеличаване на SAS

SAS е добре; SAS е хубаво. SAS също е скъпо и не купуваме кутии за всички вас, учени и анализатори на данни, за да можете да си „играете“ с данните. Освен това искате да направите нещо различно от това, което SAS може да направи или да генерирате по-красива графика. Ето вашето хубаво езеро с данни. Тук е iPython Notebook (сега) или Zeppelin (по-късно). Ще подадем резултатите в SAS и ще съхраним резултатите от SAS тук.

Докато съм виждал други проекти на Hadoop, Spark или Storm, това са „нормалните“ ежедневни типове. Ако използвате Hadoop, вероятно ги разпознавате. Някои от случаите на използване на тези системи съм внедрил години преди това, работещ с други технологии.

Ако сте старомоден, твърде много се страхувате от „голямото“ в големите данни или „правите“ в Hadoop, не се притеснявайте. Колкото повече неща се променят, толкова повече остават същите. Ще откриете много паралели между нещата, които сте използвали за разгръщане, и хипстерските технологии, които се вихрят около Хадопосферата.