[Перевод] Hadoop: быть или не быть?
Здравствуйте, уважаемые читатели! Некоторое время назад у нас вышел перевод фундаментальной орейлевской книги о фреймворке Hadoop:
В настоящее время редакция оказалась перед непростым выбором, перевести ли новое 4-е издание этой книги, либо допечатать уже имеющееся.
Поэтому мы решили опубликовать перевод статьи Ананда Кришнасвами, появившейся в блоге Thoughtworks еще в 2013 году, где автор пытается проанализировать, в каких случаях уместно использовать Hadoop, а в каких — излишне.
Надеемся, что материал покажется интересным, вызовет полемику, а Вы поделитесь Вашими впечатлениями о работе с Hadoop и поучаствуете в опросе.
Система Hadoop зачастую позиционируется как универсальный фреймворк, который поможет вашей организации справиться решительно с любыми проблемами. Стоит лишь упомянуть «большие данные» или «аналитику» — и сразу находится подходящий ответ: «Hadoop!». Однако фреймворк Hadoop разрабатывался для решения совершенно конкретного класса задач; в иных случаях он, мягко говоря, неидеален, а иногда задействовать Hadoop — очевидная ошибка. Притом, что преобразование данных (в более широком смысле — операции ETL — «извлечение, преобразование, загрузка») значительно оптимизируются при помощи Hadoop, однако если ваш бизнес обладает хотя бы одним из пяти нижеперечисленных свойств, то, вероятно, вам лучше обойтись без Hadoop.
1. Жажда больших данных
Многие компании склонны считать, что имеющиеся в их распоряжении данные тянут на статус «больших», но, к сожалению, в большинстве случаев такая оценка оказывается завышенной. Исследовательская статья «Nobody Ever Got Fired For Buying a Cluster» позволяет оценить, какие объемы данных по всеобщему убеждению считаются «большими». Авторы приходят к выводу, что система Hadoop создавалась для обработки тера- и петабайтных объемов данных, тогда как при решении большинства практических задач объем вводимых данных не превышает 100 Гб (медианный размер задания в Microsoft & Yahoo составляет менее 14 Гб, а 90% заданий в Facebook оказываются гораздо меньше 100 Гб). Соответственно, авторы статьи считают целесообразным выделить отдельный сервер для эпизодических «увеличений» инфраструктуры, нежели при необходимости «уменьшать» инфраструктуру, в которой работает Hadoop.
Спросите себя:
• У нас есть несколько терабайт данных или более? • Есть ли у меня стабильный и очень объемный приток данных? • Каким количеством данных я собираюсь оперировать?
2. В очереди
При отправке заданий минимальная задержка Hadoop составляет около минуты. Таким образом, системе требуется минута или более для отклика на заказ клиента и предоставление рекомендаций. Только очень лояльный и терпеливый клиент станет глядеть на экран 60+ секунд, ожидая ответа. Как вариант, можно предварительно вычислять родственные элементы для каждого элемента, уже имеющегося в списке (априори с использованием Hadoop) и обеспечивать на сайте или в мобильном приложении мгновенный (секундный) доступ к сохраненному результату. Hadoop — отличный движок для таких предварительных вычислений, упрощающий работу с большими данными. Разумеется, чем сложнее становится типичный отклик такого рода, тем менее эффективным оказывается и полное предвычисление результатов.
Спросите себя:
• Каковы пользовательские ожидания относительно скорости отклика программы? • Какие из заданий можно объединить в пакеты?
3. Ответ на ваш звонок поступит через…
Hadoop не предназначен для применения в случаях, требующих отклика на запросы в реальном времени. Задания, проходящие через цикл map-reduce, также проводят какое-то время в цикле перетасовки (shuffle cycle). Длительность обоих этих циклов не ограничена, в результате чего разработка приложений реального времени на базе Hadoop серьезно осложняется. Трейдинг с учетом взвешенной по объему средней цены — практический пример, в котором для совершения сделок требуется оперативный отклик системы.
Аналитикам не обойтись без SQL. Hadoop не слишком хорош для произвольного доступа к множествам данных (даже с применением Hive, который фактически формирует задания MapReduce из вашего запроса). Архитектура Dremel от Google (и, разумеется, BigQuery) разработана специально для поддержки спонтанных запросов к гигантским наборам строк за периоды, не превышающие нескольких секунд. SQL же позволяет делать связи между таблицами. Другие многообещающие альтернативы — разработка Shark из Калифорнийского университета, AmpLab из университета Беркли, а также инициатива Stinger, реализуемая Hortonworks.
Спросите себя:
• Насколько плотно пользователи/аналитики должны взаимодействовать с моими данными? • Требуется ли обеспечить интерактивность с терабайтами данных, либо лишь с небольшим подмножеством информации?
Итак: Hadoop работает в пакетном режиме. Это означает, что при добавлении новой информации задание должно вновь просеять все множество данных. Следовательно, длительность анализа увеличивается. Фрагменты данных — просто обновления или небольшие изменения — могут поступать в реальном времени. Зачастую бизнес должен принимать решения на основании этих событий. Как бы ни стремительно закачивались в систему новые данные, Hadoop все равно будет обрабатывать их в пакетном режиме. Возможно, в будущем эту проблему удастся решить при помощи YARN. Решение Storm от Twitter уже является популярной и доступной альтернативой. Комбинация Storm с распределенной системой обмена сообщениями, такой как Kafka, открывает ряд возможностей для потоковой агрегации и обработки данных. Однако в Storm остро не хватает балансировки нагрузки, тогда как в S4 от Yahoo такая возможность имеется.
Спросите себя:
• Каков «срок годности» моих данных? • Насколько быстро мой бизнес должен обеспечивать прибыль от поступающих данных? • Насколько важно для моего бизнеса реагировать на изменения или обновления в реальном времени?
Реклама в реальном времени или отслеживание данных, поступающих от сенсоров, требуют обработки потокового ввода в реальном времени. Но Hadoop или реализованные на его основе инструменты — не единственные альтернативы. Так, база данных HANA от SAP, хранимая в оперативной памяти, использовалась в аналитическом инструментарии ATLAS команды McLaren в ходе недавней гонки Indy 500 вместе с MATLAB для запуска моделей и реагирования на телеметрию в ходе гонки. Многие аналитики считают, что будущее Hadoop связано с интерактивностью и работой в реальном времени.
4. Только что закрыл аккаунт в любимой социальной сети
Hadoop и в особенности MapReduce лучше всего подходят для работы с данными, которые можно разложить на пары ключ-значение, не рискуя при этом потерей контекста или каких-либо неявных взаимосвязей. Неявные взаимосвязи есть в графах (ребра, поддеревья, дочерние и родительские отношения, веса и т.п.), причем далеко не все такие взаимосвязи могут существовать на конкретном узле. Поэтому большинство алгоритмов для работы с графами требуют полной или частичной обработки графа при каждой итерации. В MapReduce это зачастую невозможно или очень сложно сделать. Кроме того, возникает проблема с выбором стратегии сегментирования данных по узлам. Если ваша основная структура данных — это граф или сеть, то, вероятно, вам лучше воспользоваться базой данных для работы с графами, например, Neo4J или Dex. Можете познакомиться и с более новыми разработками, такими, как Pregel от Google или Giraph от Apache.
Спросите себя:
• Можно ли сказать, что базовая структура моих данных не менее важна, чем сами данные? • Связана ли искомая информация со структурой данных не менее или даже более, чем с сами данными?
5. Модель MapReduce
Некоторые задачи/задания/алгоритмы просто не вписываются в модель программирования MapReduce. Один из подобных классов проблем уже был рассмотрен выше. Задачи, в которых для вычисления результатов требуется знать итоги выполнения промежуточных этапов работы — другая категория таких проблем (академический пример — вычисление рядов Фибоначчи). Некоторые алгоритмы машинного обучения (например, на основе градиентного спуска или максимизации ожидания) также не вполне вписываются в парадигму MapReduce. Существуют определенные стратегии/варианты оптимизации (глобальное состояние, передача структур данных для справки и т.д.), предлагавшиеся различными исследователями для решения каждой из этих проблем, но их реализация по-прежнему остается более сложной и неинтуитивной, чем хотелось бы.
Спросите себя:
• Уделяет ли компания серьезное внимание высокоспецифичным алгоритмам или предметно-ориентированным процессам? • Будет ли технический отдел справляться с аналитикой лучше, если применяемые алгоритмы будут адаптированы под MapReduce — или нет?
Вдобавок следует рассмотреть такие практические случаи, в которых множество данных не слишком велико, либо общее количество данных велико, но это множество состоит из миллиардов мелких файлов (например, требуется просмотреть массу файлов изображений и выбрать из них те, где содержится определенная фигура), не поддающихся конкатенации. Как уже было указано выше, если задания не укладываются в парадигму MapReduce «разделить и агрегировать», то использование Hadoop для решения таких задач — сомнительная затея.
Итак, изучив, когда Hadoop может оказаться не лучшим решением, давайте обсудим, когда же его целесообразно использовать.
Спросите себя:
Собирается ли ваша организация…1. Извлекать информацию из колоссальных объемов текстовых логов?2. Преобразовывать в основном неструктурированные или плохо структурированные данные в удобный организованный формат?3. Решать задачи, связанные с обработкой всего множества данных, выполнять операции по ночам (подобно тому, как обрабатываются дневные операции по карточкам в кредитных компаниях)?4. Опираться на выводы, сделанные после однократной обработки данных, валидными вплоть до следующей намеченной обработки данных (что неприменимо, например, к значениям биржевых котировок, которые меняются гораздо чаще, чем при закрытии торгового дня)?
В таких случаях вам практически наверняка стоит обратить внимание на Hadoop.
Существует целый ряд бизнес-задач, которые хорошо вписываются в модель Hadoop (правда, практика показывает, что решение даже таких задач является довольно нетривиальным делом). Как правило, такие задания сводятся к обработке огромных объемов неструктурированных или полуструктурированных данных и заключаются либо в обобщении содержимого, либо в преобразовании выполненных наблюдений в структурированную форму для последующего использования другими компонентами системы. В таких случаях модель Hadoop оказывается весьма кстати. Если в собранных вами данных есть элементы, которые легко могут выступать в качестве идентификаторов соответствующих значений (в Hadoop такие пары называются «ключ-значение»), то подобную простую ассоциацию можно использовать сразу для нескольких вариантов агрегации.
Итак, важнее всего четко представлять, какие бизнес-ресурсы имеются в наличии и понимать ту проблему, которую вы собираетесь решать. Надеюсь, что эти соображения, а также изложенные выше рекомендации помогут вам подобрать именно такой инструментарий, который идеально подходит для вашего бизнеса.
Вполне вероятно, что это будет именно Hadoop.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
