Big Data головного мозку

Напевно, у світі немає даних подібного феномена настільки неоднозначного розуміння того, що ж таке Hadoop. Ні один подібний продукт не оповитий такою великою кількістю міфів, легенд, а головне нерозуміння з боку користувачів. Не менш загадковим і суперечливим є термін "Big Data", який іноді хочеться писати жовтим шрифтом(спасибі маркетологам), а вимовляти з особливим пафосом. Про цих двох поняттях — Hadoop і Big Data я б хотів поділитися з співтовариством, а можливо і розвести невеликою холівар.
Можливо стаття когось образить, кого-то посміхнеться, але я сподіваюся, що не залишить нікого байдужим.
image
Демонстрація Hadoop користувачам

Почнемо з витоків.

Перша половина 2000х, Google: ми зробили відмінний інструмент — молоток, він добре забиває цвяхи. Цей молоток складається з ручки і бойка, але тільки ми з вами їм не поділимося.
2006 рік, Дуг Кайтинг: привіт, народ, я тут зробив такий же молоток, як у Google і він дійсно добре забиває цвяхи, до слова сказати, я тут спробував забивати їм невеликі шурупи і ви не повірите, він більш-менш впорався з цим.
2010 рік, Підлогу 30 років: Хлопці, молоток працює, навіть більше, він відмінно забиває болти. Звичайно, отвір треба трохи підготувати, але інструмент дуже перспективний.
2012 рік, Підлогу 32 роки: Виявляється молотком можна рубати дерева, звичайно, це трохи довше, ніж сокирою, але він, мати його, працює! І за все це ми не заплатили ні копійки Так само ми хочемо побудувати за допомогою молотка невеликий будинок. Побажайте нам удачі.
2013 рік, Дуг: Ми оснастили молоток лазерним прицілом — тепер його можна метати, вбудований ніж дозволить вам більш ефективно рубати дерева. Все безкоштовно, все заради людей.
2015 рік, Ден, 25 років: я кошу траву молотком… кожен день. Це трохи складно, але мені, чорт візьми, подобається, мені подобається працювати руками!
Якщо дійсно розібратися і копнути трохи глибше, то Google, а потім і Дуг зробили інструмент(і далеко не ідеальний, як зізналося Google, через кілька років), для вирішення певного класу завдань — побудова пошукового індексу.
Інструмент вийшов непоганим, але є одна проблема, втім, про все по порядку.
На початку 2012 року розпочався агресивний тренд — "епоха big data".
image
Саме з цього моменту почали з'являтися даремні статті і навіть книги в стилі "Як стати big data company" або "Великі дані вирішують все". Жодна з конференцій більше не обходилася без міркувань про те, "з якого терабайта починалася big data" і повторюваних історій про те, як "одна компанія була майже на межі дефолту, але таки перейшла на великі дані і вона просто порвала ринок". Вся це порожня балаканина підтримувала грамотним маркетингом від компаній, які продавали підтримку на все це — спонсорувалися хакатони, семінари та багато-багато всього.
В кінцевому підсумку у великої кількості людей склалася конкретна картина світу, в якій традиційні рішення — це повільно, це дорого, та й як мінімум, це більше не модно.
Минуло вже багато років, але досі я бачу обговорення та статті з заголовками "Map Reduce: first steps" або "Big Data: What Does it Really Mean?" на професійних ресурсах.

Hadoop як засіб для індексування

І так, що ж все-таки таке Hadoop? У загальних словах це файлова система HDFS і набір інструментів для обробки даних.
Все ж цей блог технічний, дозволю собі ось таку картинку:
image
Компоненти Hadoop 2
Все це розмазане по кластеру з "дешевого заліза" і на думку маркетологів має в помах ока завалити вас грошима, які будуть приносити "великі дані".
Великі інтернет-компанії, наприклад Yahoo, в свій час, оцінили Hadoop, як засіб обробки великих обсягів інформації. Використовуючи MapReduce, вони могли будувати пошукові індекси на кластерах з тисяч машин.
Треба сказати, що тоді це було дійсно проривом — Open Source продукт уміє розв'язувати задачі такого класу і все це безкоштовно. Yahoo зробило ставку на те, що можливо в майбутньому їм би не довелося вирощувати фахівців, а набирати з боку вже готових.
Але я не знаю коли перша мавпа спустилася з дерева, взяла палицю і почала використовувати MapReduce для аналізу даних, але факт залишається фактом, MapReduce почав реально з'являтися там, де це зовсім не потрібно.

Hadoop MapReduce як засіб для аналітики

Якщо у вас одна велика таблиця, наприклад, логи користувачів, то MR з натяжкою міг би згодитися для підрахунку кількості рядків або унікальних записів. Але у цього фреймворку були фундаментальні недоліки:
Кожен крок MapReduce породжує велике навантаження на диски, що уповільнює загальну роботу. Результати роботи кожного етапу скидаються на диск.
Ініціалізація "воркеров" займає відносно великий час, що призводить до великих затримок, навіть для простих запитів.
Число "маперов" і "редьюсеров" постійно під час виконання, ресурси діляться між цими групами процесів і якщо, наприклад, маперы вже припинили свою роботу, то ресурси редьюсерам вже не звільняться.
Все це більш-менш ефективно працює на простих запитах. Операції JOIN великих таблиць будуть працювати вкрай не ефективно — навантаження на мережу.
Не дивлячись на весь цей комплекс проблем, MapReduce заслужив велику популярність в області аналізу даних. Коли новачки починають своє знайомство з Hadoop, перше, що вони бачать — MapReduce, "ну ок" — говорять вони, — "треба вивчати". За фактом інструмент для аналітики марний, але маркетинг зіграв злий жарт з MR. Інтерес користувачів не тільки не згасає, але і підживлюється новачками(я пишу цю статтю в червні 2016).
Для аналізу зацікавленості в технології з боку бізнесу я вирішив використовувати HeadHunter.ru як основну площадку пошуку пропозицій по роботі.
І ще можна зустріти такі цікаві вакансії на HH.ru за ключовими словами MapReduce:
image
На момент написання статті було 30 вакансій тільки в Москві, і це від шанованих і успішних фірм. Відразу скажу, що я не аналізував глибоко ці пропозиції, але позитивна динаміка все ж є, близько року тому подібних пропозицій було більше.
Звичайно, люди розміщували вакансію могли просто написати, що попало і, можливо, HeadHunter це не найкращий засіб для подібної аналіткі, але більш підходящих інструментів вимірювання зацікавленості бізнесу я знайти не зміг.

Spark як засіб для аналітики

Звичайно, розумні люди відразу зрозуміли, що c MR ловити нічого і придумали Spark, який, до речі, так само живе під крилом ASF. Spark — це MR на стероїдах і як кажуть розробники швидше MapReduce в більш ніж у 100 разів.
image
Сферичний Spark у вакуумі швидше MapReduce
Spark хороший тим, що позбавлений перерахованих недоліків MR.
Але ми вже виходимо на інший рівень і недоліки знову з'являються:
Хардкод і старанна код на Java перетворює прості запити в місиво, яке неможливо буде читати в майбутньому. Підтримка SQL поки слабка.
Немає вартісної оптимізації. З цією проблемою можна зіткнутися при з'єднанні таблиць.
Spark не розуміє, як дані лежать в HDFS. Це хоч і MPP-система, але при з'єднанні великих таблиць виникає ситуація, коли з'єднуються дані знаходяться на різних вузлах, що призводить до навантаження на мережу.
Хоча в цілому Spark штука годна, але можливо його вб'є ринок праці, так як шукати дорогих фахівців на Java або Scala, які будуть хардкодить вам аналітику дуже і дуже важко, особливо якщо ви no-name-company(вимовляти з особливим пафосом, якщо працюєте у такий).
Так само разом з Spark зародилося цікаве рішення — Spark Streaming і, можливо, це буде дійсно таким "довгограючим" рішенням.
Spark штука проста, надійна і його можна розгорнути без Hadoop.
Поживемо побачимо.
Пропозиція з вакансіями трохи краще ніж по MapReduce, вони більш зрілі і схоже їх писали плюс-мінус розуміючі люди
image
Кількість подібних пропозицій — 56 штук.
image

А тепер кілька міфів про Hadoop і BigData

Міф 1. Hadoop — це безкоштовно
В наші дні ми використовує дуже багато OpenSource продуктів і навіть не замислюємося про те, чому ми за них не платимо. Звичайно, безкоштовний сир буває тільки в мишоловці і платити, врешті-решт, доводиться, особливо за Hadoop.
Hadoop і все що з ним пов'язано, активно позиціонується маркетологами під прапорами безкоштовності, миру і братерства. Але в дійсності, використовувати власну збірку Hadoop ризикнуть не багато — продукт досить сирий і досі багатьма незрозумілий.
Компанії доведеться наймати дорогих фахівців, при цьому завдання вони будуть вирішувати довше і наполегливіше. Зрештою, замість того, щоб вирішувати завдання обробки даних, співробітники будуть вирішувати проблеми латання дірок в сирому софті і побудови милиць.
Звичайно, мова не стосується інших зрілих OpenSource продуктів, типу MySQL, Postgres і т. п., які активно використовуються в бойових системах, але навіть тут, безліч компаній користується платній професійною підтримкою.
Перш ніж вирішувати, чи потрібен вам безкоштовний продукт, порахуйте, так він безкоштовний. Можливо, з вашими завданнями по збору зерна з полів, з однаковим успіхом впорається і вчорашній студент на сучасному комбайні і група дорогих Java-кодерів, з безкоштовними молотками-серпами.
Ок, Hadoop, це не безкоштовно, припустимо, але Hadoop працює на дешевому залозі! І знову повз. Hadoop хоч і працює на дешевому залозі, для швидкого і надійного рішення завдань вам все одно будуть потрібні нормальні сервера — на "десктопах" це працювати не буде. Для придатної роботи Hadoop потрібно залізо такого ж класу, як і для будь-яких інших аналітичних MPP-систем. За рекомендацією Cloudera в
залежно від завдань необхідно:
  1. 2 CPU c 4-8-16 Ядрами
  2. 12-24 JBOD дисків
  3. 64-512GB of RAM
  4. 10 Gbit Net
Прошу зауважити, що RAID відсутня, але надмірність Hadoop на рівні софта вимагає приблизно такої ж кількості дисків.
Міф 2. Hadoop для обробки неструктурованої інформації.
Інший не менш примітний міф говорить нам про те, що "Hadoop необхідний для обробки неструктурованої інформації", а такий неструктурованою інформацією як раз і є Big Data :-). Але давайте спочатку розберемося, що ж таке неструктурована інформація.
Таблиці — це точно структурована інформація, це безперечно.
А ось JSON, XML, YAM — називають напів-структурованою інформацією.
Але і такі формати мають структуру, тільки не таку явну як структура таблиць.
Інша актуальна тема — логи, на думку популяризаторів BigData — не мають структури.

насправді структура є, логи цілком собі нормально записуються у таблиці й обробляються без MapReduce
Твіттер:

насправді, структура є майже у всіх даних, які можуть нам стати в нагоді. Вона може бути розрізнена, не зручна для обробки, але вона є.
Навіть такі дані, наприклад, відео або аудіо інформація можуть бути представлені у вигляді вигляді структури, яку можна розподілити на велику кількість серверів і обробляти.
Відео-файли:

Швидше за все, там, де ви працюєте, немає неструктурованої інформації. І ваша інформація може бути розрізненої і "брудної", але якась структура у неї все одно є. В такому разі, у вас дійсно проблеми й потрібно вирішувати в першу чергу їх.
Звичайно, є інформація, яку можна ефективно "розмазати" за великим кластера, наприклад генетична інформація або величезний файловий архів, але таких кейсів надзвичайно мало і для "бізнес-аналітики" вони не цікаві, такі завдання вирішуються іншими засобами зовсім на іншому рівні(якщо знаєте, розкажіть).
Якщо ви знаєте якісь дійсно неструктуровані джерела інформації, які не можна просто так обробити в розподіленому кластері, будь-ласка, пишіть в коментарях.
Міф 3. Будь-яка проблема вирішується через технології Big Data
Ще один цікавий термін нав'язаний суспільству — "технології Big Data". Звичайно, ніякого логічного визначення того, що таке Big Data звичайно, ні, тим більше немає визначення "технологій Big Data".
Прийнято вважати, що все, що пов'язано з Hadoop — це "технології Big Data"
image
Але Hadoop і все що з ним пов'язано, дуже добре замаскований, акуратний суперфункциональный швейцарський ніж-молоток. Їм можна рубати дерева, косити траву, забивати болти. Він справляється з усіма завданнями, але от коли справа доходить до вирішення конкретного завдання, особливо коли потрібно зробити це якісно, такий швейцарський ніж-молоток тільки ускладнить вам життя.

Impala, Dill, Kudu — нові гравці

Звичайно, ще більш розумні люди, ніж всі інші, подивилися на весь цей бардак і вирішили створити свій лунапарк.
Три звірка Impala, Drill і Kudu з'явилися приблизно одночасно і не зовсім давно.
Це такі ж МРР-движки поверх HDFS як Spark і MR, але різниця між ними така ж, як між їжею і закускою — величезна. Продукти так само знаходяться під крилом, вельмишановного ASF. В принципі, усіма трьома проектами можна користуватися вже зараз, не дивлячись, що вони на стадії так званої "інкубації".
До речі, Impala і Kudu знаходяться під крилом Cloudera, а Drill вийшов з компанії Dremio.
З усього звіринця я б виділив Apache Kudu як самий цікавий інструмент з представлених з чітким і зрілим roadmap.
Переваги Kudu наступні:
Kudu розуміє, як лежать дані в HDFS, подимает як їх правильно класти в HDFS, щоб оптимізувати майбутні запити. Директива distributed by.
Тільки SQL і ніякого хардкода.
З явних недоліків можна виділити відсутність Cost-based оптимізатора, але це лікується і можливо в майбутніх релізах ми Kudu постане у всій красі. Всі ці 3 продукту плюс-мінус приблизно однакові, з цього, розглянемо архітектуру на прикладі Apache Impala:
image
Як ми бачимо, є примірники СУБД — Impala, які вже працює з даними на своїй конкретній ноде. При підключенні клієнта до одного з вузлів він стає управляючим. Архітектура досить схожа на Vertica, Teradata(верхнеуровнево і дуже приблизно). Основне завдання при роботі з такими системами зводиться до того, що б правильно "розмазати" дані по кластеру, щоб в подальшому ефективно з ними працювати.
При всіх своїх перевагах, розробники піарять свої системи як "федеравтивные", тобто: беремо таблицю Kuda, пов'язуємо її з плоским файлом, все це змішуємо з Postgres і приправляємо MySQL. Тобто у нас з'являється можливість працювати з гетерогенними джерелами як із звичайними таблицями або нереляційними структурами(JSON) з таблицями. Але у такого підходу є своя ціна — оптимізатор не розуміє статистику зовнішніх джерел, так само такі зовнішні таблиці стають вузьким горлом при виконанні запитів, так як, по суті, працюють в "один потік".
Інший важливий момент — необхідність HDFS. HDFS в такій архітектурі перетворюється в даремний апендикс, який тільки ускладнює роботу системи — зайвий шар абстракції, який має свої накладні витрати. Так само, HDFS може бути розгорнута поверх не зовсім ефективних чи не правильно налаштованих файлових систем, що може призвести до фрагментації файлів даних і втрати продуктивності.
Звичайно, HDFS можна використовувати як смітник всього і вся, скидаючи в неї все потрібне і непотрібне. Такий підхід останнім часом називається "Data Lake", але не варто забувати, що аналізувати непідготовлені дані буде складніше у майбутньому. Послідовники такого підходу аргументують переваги тим, що дані, можливо, і не доведеться аналізувати, отже, немає необхідності витрачати часу на їх підготовку. Загалом, вирішувати яким шляхом йти все-таки вам.
Ніяких пропозицій по роботі та інтересів компаній в бік Kudu-подібних продуктів немає, а даремно.

Трохи маркетингу

Ви напевно помітили явний тренд у бік того, що весь цей цирк в області аналітики даних рухається в бік традиційних аналітичних MPP-систем (Teradata, Vertica, GPDB тощо).
Всі аналітичні MPP-системи розвиваються в одному напрямку, тільки при цьому дві різні групи йдуть до цього з різних сторін.
Перша група — йде по шляху "шардирования" традиційних SQL СУБД.
Друга група — йде за родоводом від MR і HDFS.
image
Користувачі виявляють інтерес до слова Hadoop
Лавиноподібне зростання Hadoop звичайно обумовлений дуже грамотним маркетингом з боку компаній, що продають ці рішення.
Компанії змогли виростити в умах людей ідею того, що Hadoop безкоштовний, він простий і швидкий і легкий, а ще… немає бога крім Hadoop.
Натиск був такий сильний, що навіть Teradata не змогла впоратися з собою і замість того, що б самій формувати ринок, почала продавати рішення на базі Hadoop і наймати фахівців. Не кажучи вже про інших гравців ринку, які дружно народили поделия під назвою "AnyDumbSoft Big Data Edition", в більшості випадках використовують стандартні конектори до HDFS.
Тренду піддався навіть Oracle, випустив "Big data products" або "Golden Gate for Big data". Перший продукт — це просто готова залізка з "золотим" CDH від Cloudera, а в продукт номер два просто додано Java-коннектори для Kafka(брокер повідомлень), HBase і решти зоопарку. Зробити це міг будь-який користувач самостійно.
image
Big Data хворої людини
На жаль, це тренд, це мейнстрім, який змете будь-яку стабільну компанію, якщо вона ризикне піти проти течії. До речі, я почасти теж ризикую бути закиданным помідорами, висвітлюю цю тему.

Apache HAWQ (Pivotal HDB).

Pivotal пішов далі за всіх. Вони взяли традиційний Greenplum і натягнули його на HDFS. Весь движок обробки даних залишився за Postgres, але самі файли даних зберігаються в HDFS. Якийсь практичної доцільності в цьому мало.
Ви отримуєте в розпорядження такою ж Greenplum, з більш складним адмініструванням, але продають його і рекламують як Hadoop.
Apache HAWQ дуже схожий на Apache Kudu.

Cloudera Distributed Hadoop

Cloudera одна з перших компаній почали монетизувати Hadoop і саме там працює Дуг, який винайшов Hadoop.
Cloudera на відміну від інших гравців, не підлаштовується під ринок, а сама робить його. Грамотний піар і маркетинг дозволили їй завоювати досить ласий шматочок ринку — зараз у списку клієнтів більш 100 великих і відомих компаній.
На відміну від інших подібних компаній, Cloudera не просто продає зоопарк з вже готових компонентів, але і сама бере активну участь у їх розробці.
За ціною CDH виходить трохи дешевше Vertica/Greenplum.
Але не дивлячись на велику кількість історій успіху на сайті Cloudera, є одна маленька проблема — Kuda, Impala — трохи сирі продукти на стадії інкубації. Навіть коли вони дозріють, цим системам потрібно буде пройти довгий шлях, що б обрости всім необхідним функціоналом Vertica або хоча б Greenplum, а це не рік і не два, поки ж, CDH можна залишити для хіпстерів.
Так само треба віддати належне маркетологам Cloudera, зумів струснути ринок.

Майбутнє Hadoop

Дозволю собі пованговать і уявити, що буде зі стеком Hadoop через 5 років.
MapReduce буде використовуватися тільки в дуже обмеженій кількості завдань, що проект швидше за все выпилят із загального стека, або про нього забудуть.
З'являться перші дистрибутиви CDH вже з частковим відмовою від використання HDFS. В такому випадку, файли таблиць будуть зберігатися на звичайній файловій системі, але у нас буде невелика смітник для зберігання сирих даних.
Можна провести аналогію з Flex Zone Vertica — звалище, в яку можна кидати все що завгодно і обробляти далі по мірі необхідності або забувати.
Насправді мати таку смітник не тільки зручно, але ми просто змушені будемо мати її. Обсяги дискового простору зростають непропорційно швидко в порівнянні з продуктивністю процесорів. Коли кількість вузлів в кластері збільшують в цілях продуктивності ми збільшуємо і обсяг дискового простору(більше необхідного). В наслідок чого, завжди буде велика кількість незайнятого дискового простору, в якому зручно зберігати дані до яких звернення буде або дуже рідкісне, або ми до них не звернемося ніколи.
Зоопарк імені Hadoop навряд чи виправдає кредит довіри, який надали йому користувачі, але сподіваюся, що не піде з ринку.
Хоча б, з інтересів конкуренції.
image
Будуть у Hadoop проблеми через 5 років?
Що буде з Spark? Можливо, багато хто буде використовувати його як движок для розподіленої попередньої обробки та підготовки даних в реальному часі — Spark Streaming, але і ця ніша теж активно займається іншими гравцями (Storm, виробники ETL)

Майбутнє Vertica, Greenplum.

Vertica буде полірувати свою інтеграцію з HDFS, нарощувати функціонал і Vertica швидше за все не піде в OpenSource — зараз продукт і так добре продається.
Greenpum зробить свій аналог Flex Zone, шляхом злиття коду з HAWQ, або сам стане non-HDFS частиною HAWQ, зрештою, кого-то ми втратимо.
Якихось нових гравців на ринку аналітичних MPP-систем швидше за все, очікувати не доведеться. Відкриття вихідного Greenplum ставить доцільність використання таких СУБД як Postgres-XL, як мінімум, під сумнів.
Принципових змін архітектури в цих продуктах ми навряд чи побачимо, зміни будуть поліпшення наявного функціоналу.

Майбутнє Postgres-XL та подібних

Postgres-XL могла б бути прекрасним MPP інструментом для аналізу великих обсягів даних, якби трохи відійшла від того, що дав їй Postgres. На жаль СУБД не вміє працювати з Column Store-таблицями, в ній немає нормального синтаксису для управління партициями, а так само вона має стандартний оптимізатор Postgres з усіма витікаючими.
Наприклад, в Greenplum є cost-based оптимізатор, заточений для аналітичних запитів. Це та штука, без якої життя аналітика і розробника дуже сильно ускладниться.
Але ставити хрест на такому чудовому продукті теж не варто, Postgres розвивається, 9.6 вже з'явилася багатопоточність і можливо умільці прикрутять Column Store і GPORCA в Postgres-XL.

Майбутнє Teradata, Netezza, SAP і подібних

У будь-якому випадку, ринок аналітичних систем буде зростати і, в будь-якому випадку, клієнти на ці продукти будуть. Будуть ці рішення продавати на полях для гольфу або на конференціях "Big Data — технологія майбутнього" я не знаю.
Але швидше за все, цим гравцям доведеться піти від поточної бізнес-моделі програмно-апаратних засобів і поглянути у бік Only-Software-продуктів.
Застрибнути в примарний поїзд "Big Data" у них не вийде, але це і не потрібно, бо поїзд уявний і вони почасти самі його і придумали.

Майбутнє: Redshift, BigQuery і хмарних сервісів для аналітики

На перший погляд хмарні сервіси виглядають дуже привабливо: не потрібно перейматися купівлею обладнання та ліцензіями. Мається на увазі, що при бажанні можна буде з легкістю відмовитися від сервісу, або перейти до іншого.
З іншого боку, аналітика — проект довгостроковий, а розробляти аналітичне сховище, абстрагуючись від конкретної технології дуже і дуже складно. За цього в майбутньому безболісно перейти з одного хмарного сховища в інше буде складно.
Клієнти в таких гравців точно будуть, але дуже специфічні — стартапи і невеликі компанії.
Резюме: Я не торкнулася великої кількості продуктів з звіринця ASF, які продають під соусом Big Data (Storm, Sqoop тощо), так як поки до них мало інтересу як з мого боку, так і ринку в цілому. Тому, буду радий будь-яким коментарям, що стосуються цих продуктів.
Так само я не торкнувся теми кликстрим-аналітики, яка набирає обертів. Сподіваюся, опишу це в наступних статтях.
Друге резюме: Складно не піти на поводу у "творців" ринку при виборі рішень в області обробки та аналізу даних. Досі не осіла пил і ми ще будемо стикатися з компаніями, які продають "щастя" і ми будемо стикатися з продуктами, позиціонуються як "універсальні ліки" від Big Data головного мозку.
Я постарався показати, куди розвивається Hadoop, так і вся індустрія обробки даних. Спробував розвіяти кілька міфів прод Big Data і постарався представити в якому напрямку буде розвиватися вся область. Сподіваюся, вийшло — дізнаємося про це вже через кілька років.
Зрештою, ринок розвивається і стає більш доступним для споживача, з'являються нові продукти, з'являються нові або змінюються старі технології.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.