Компроміси між штормом та Hadoop (MapReduce)

Чи може хтось люб’язно розказати мені про компроміси, які брали участь у виборі між Storm та MapReduce у кластері Hadoop для обробки даних? Звичайно, окрім очевидного, що Hadoop (обробка через MapReduce в кладоні Hadoop) є системою пакетної обробки, а Storm - системою обробки в режимі реального часу.

Я трохи працював з Hadoop Eco System, але я не працював із Storm. Переглянувши безліч презентацій та статей, я все ще не зміг знайти задовільну та всебічну відповідь.

Примітка: Термін компроміс тут не означає порівнювати з подібними речами. Він призначений для відображення наслідків отримання результатів у режимі реального часу, відсутніх у системі пакетної обробки.

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

Завдання MapReduce приймає файл (або деякий сховище даних) як вхід і записує файл результатів. Якщо ви хочете, щоб ці результати були доступні для програми, ви несете відповідальність за розміщення цих даних у доступному місці. Це, ймовірно, повільно, і буде спостерігатися відставання між значеннями, які ви можете відображати, і значеннями, які представляють вашу систему в її поточному стані.

Важливою відмінністю, яку слід враховувати при використанні MapReduce для побудови систем реального часу, є навчання вашої моделі та застосування вашої моделі. Якщо ви думаєте, що параметри вашої моделі не змінюються швидко, ви можете встановити їх з MapReduce, а потім мати механізм доступу до цих попередньо встановлених параметрів, коли ви хочете застосувати свою модель.

Буря : обчислювальна система в режимі реального часу. Storm - це онлайн-система, що означає, в цьому сенсі, послугу, яка взаємодіє із запущеною програмою. На відміну від MapReduce, він отримує невеликі фрагменти даних (не цілий файл), оскільки вони обробляються у вашій програмі. Ви визначаєте DAG операцій, які потрібно виконати над даними. Поширений і простий випадок використання Storm - це відстеження лічильників та використання цієї інформації для заповнення інформаційної панелі в реальному часі.

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

Якщо ви хочете дізнатися більше ... Якщо ви хочете дізнатися більше про системи в режимі реального часу, які відповідають параметрам MR та застосовують моделі по-різному, ось слайди для бесіди, яку я розповів про створення рекомендаційних двигунів у реальному часі на HBase.

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

Ще один цікавий шлюб MR та Storm - SummingBird . Summingbird дозволяє визначити операції аналізу даних, які можна застосувати за допомогою Storm або MR.

Це схоже на запитання про компроміси між сковородою та вашим ящиком срібного посуду. Вони порівнюють не дві речі. Ви можете використовувати їх разом у рамках більшого проекту.

Сам Hadoop - це не одне, а назва федерації служб, таких як HDFS, Hive, HBase, MapReduce тощо. Шторм - це те, що ви використовуєте з деякими з цих служб, як HDFS або HBase. Це структура потокової обробки. Є інші розширені екосистеми Hadoop, наприклад, Spark Streaming.

Коли ви вибрали б структуру потокової обробки? коли вам потрібно реагувати на нові дані майже в реальному часі. Якщо вам потрібен такий інструмент, ви також розгортаєте цей інструмент.