— Мы получаем более миллиона твитов в день, и наш сервер просто не успевает их обрабатывать.
Поэтому мы хотим установить Hadoop в кластере и распределить обработку.
Речь шла о вычислительно тяжелых сентиментальный анализ , поэтому я мог поверить, что одному серверу действительно не хватает процессора для обработки большого потока твитов.
— Что вы собираетесь делать с уже обработанными данными? — Скорее всего, поместим их в MySQL, как делали раньше, или вообще удалим.
— Тогда Hadoop вам точно не нужен.
Мой бывший коллега был далеко не первым, кто рассказал о распределенных вычислениях на Hadoop. И каждый раз я видел полное непонимание того, зачем была придумана и разработана эта платформа.
Вообще говоря, при обработке данных существует несколько типичных ситуаций, и в каждой из них есть свои подходы и инструменты.
Давайте рассмотрим основные из них.
Точечная обработка активных данных
Самый распространенный сценарий, с которым нам всем приходится сталкиваться, — это хранение «активных» данных — информации о пользователях, списков продуктов, комментариев к статьям и т. д. — всего того, что может часто меняться.В данном случае мы хотим иметь возможность обрабатывать данные по точкам — извлекать нужный объект по индексу, обрабатывать его и загружать обратно.
Это именно та функциональность, которую предоставляет большинство.
СУБД (как реляционный, так и NoSQL).
При масштабировании здесь возникает основная проблема с максимальным объемом данных, хранящихся в базе данных.
Однако даже если используемая СУБД не поддерживает распределенную структуру, проблема легко решается путем секционирования на уровне приложения.
Потоковая обработка в реальном времени
Однако иногда упор делается на обработку данных, а не на их хранение.Именно с такой ситуацией столкнулся мой бывший коллега, занимающийся анализом настроений.
Ему нужно было получать твиты в режиме реального времени, анализировать их и отображать результат на динамически генерируемом графике.
Миллион ежедневных твитов не был проблемой — в конце концов, это не более 140 миллионов символов или 280 МБ при использовании кодировки UTF16. Задача заключалась в анализе этих твитов в режиме реального времени.
К счастью, большинство потоковых алгоритмов (будь то сентиментальный анализ твитов, сбор совокупной статистики или машинное обучение онлайн ) использует для своей работы маленький , независимый фрагменты данных друг от друга.
Это упрощает распараллеливание обработки, просто добавляя больше вычислительных узлов и помещая их перед балансировщик нагрузки .
В простейшем случае брокер сообщений (например, КроликMQ или НулевойMQ ), в более сложных можно использовать готовые фреймворки для потоковой обработки, например Буря .
При этом основной код, непосредственно выполняющий обработку данных, остается практически неизменным по сравнению с односерверной версией.
Пакетная обработка исторических данных
Помимо активных и потоковых, существует еще один важный тип данных — исторические, т.е.те, которые когда-то были сгенерированы и вряд ли когда-либо изменятся.
Сюда входят журналы событий, финансовые показатели, индексы документов за определенный день и вообще любые данные, привязанные к какому-то моменту в прошлом.
Чаще всего такие данные накапливаются в больших объемах и затем используются аналитиками для решения бизнес-задач.
Отличительной особенностью здесь является то, что на момент обработки необходимые данные уже собраны и распределены по множеству серверов (если данные умещаются на одном сервере, то это просто не такой уж большой ).
Представим, что у нас есть данные обо всех покупках в крупной сети супермаркетов за последние шесть месяцев.
Мы хотим проанализировать эти данные: посчитать среднюю эффективность каждого супермаркета, эффект от промоакций, корреляцию между купленными товарами и многие другие показатели.
Как организовать работу с данными так, чтобы расчет этих параметров занимал разумное количество времени? Мы можем загрузить все данные в распределенную базу данных Oracle и работать с ней так же, как и с активными данными.
Но в этом случае сервер приложений будет последовательно извлекать данные из базы данных и последовательно обрабатывать каждую запись, что крайне неэффективно.
Также мы можем настроить конвейер потоковой обработки, распределяя нагрузку между серверами приложений.
Но рано или поздно мы столкнемся с каналом связи между узлами обработки и узлами данных.
Единственный способ распределить нагрузку и не перегрузить канал связи – это минимизировать перемещение данных между узлами.
А для этого необходимо провести максимальные расчеты локально на тех машинах, где находятся обрабатываемые данные.
Точно принцип локальности данных лежит в основе парадигмы MapReduce и всего Hadoop.
Узнайте больше о MapReduce
Принято считать, что каждое задание MapReduce состоит из двух фаз — фазы сопоставления и фазы сокращения.На самом деле все несколько сложнее: сначала данные разбиваются на сплиты, затем над каждым из них выполняется функция карты, затем результаты сортируются, затем объединяются, затем снова сортируются и, наконец, передаются в функцию сокращения.
Однако именно Map и Reduc описывают основную идею парадигмы.
Фаза карты выполняет всю работу, которую можно выполнить локально.
Например, локально можно посчитать количество слов в строке, или посчитать метрику одной записи в CSV-файле, или проанализировать твит и т. д. Карта обеспечивает прозрачное распараллеливание и минимальную нагрузку на канал связи.
Но одной локальной карты для большинства задач недостаточно: чтобы подсчитать количество слов во всем тексте, нужно сложить их количество в каждой строке, а для расчета среднего значения метрики нужно собрать воедино результаты по каждой запись из файла CSV. Именно в этом и состоит цель функции сокращения.
При этом объем передаваемых по сети данных существенно сокращается (в этом также очень помогает функция объединения, выполняющая роль локального сокращения).
Так почему же мой коллега ошибся, использовав Hadoop для анализа настроений твитов? Ведь, как уже говорилось выше, на этапе карты вы можете анализировать каждый твит отдельно, полностью игнорируя этап сокращения! Все дело в инфраструктуре.
Во-первых, твиты по-прежнему придется сначала переносить на вычислительные узлы, а это означает потерю преимущества локальности данных.
Во-вторых, Hadoop плохо подходит для онлайн-обработки: работа ведется с пакетами данных, а значит, сначала придется собрать твиты, а уже потом запускать задание MapReduce. Даже если вы настроите задачу карты на постоянное и бесконечное чтение твитов из источника, Hadoop через некоторое время уничтожит всю задачу как неудавшуюся.
И в-третьих, если вы услышите, что Hadoop быстр, помните, что производительность достигается за счет минимизации перемещения данных, а сами задания MapReduce, особенно на небольших объемах данных, могут выполняться довольно долго из-за накладных расходов (запуск JVM, запуск заданий резервного копирования, запись промежуточных результатов на диск и т. д.).
Так что используйте правильные инструменты для правильных задач и будет вам счастье! Теги: #Hadoop #MapReduce #Высокая производительность #Большие данные #Hadoop
-
Продажа Книг
19 Oct, 24 -
Intel Ларраби Непрактичен
19 Oct, 24 -
Выпущена Bulldoc 0.31
19 Oct, 24 -
«Пыль» Flac
19 Oct, 24
