Рынок распределенных вычислений и больших данных, если верить статистике, растет на 18-19% в год. Значит, вопрос выбора софта для этих целей остается актуальным. В этом посте мы начнем с того, зачем нужны распределенные вычисления, подробней остановимся на выборе ПО, расскажем о применении Hadoop с помощью Cloudera, а напоследок поговорим о выборе железа и о том, как оно разными способами влияет на производительность.
Зачем нужны распределенные вычисления в обычном бизнесе? Тут все просто и сложно одновременно. Просто — потому что в большинстве случаев мы выполняем относительно несложные расчеты на единицу информации. Сложно — потому что такой информации много. Очень много. Как следствие, приходится обрабатывать терабайты данных в 1000 потоков. Таким образом сценарии использования довольно универсальны: расчеты могут применяться везде, где требуется учесть большое количество метрик на еще большем массиве данных.
Один из недавних примеров: сеть пиццерий Додо Пицца определила на основании анализа базы заказов клиентов, что при выборе пиццы с произвольной начинкой пользователи обычно оперируют лишь шестью базовыми наборами ингредиентов плюс парой случайных. В соответствии с этим пиццерия подстроила закупки. Кроме того, у нее получилось лучше рекомендовать пользователям дополнительные товары, предлагаемые на этапе заказа, что позволило повысить прибыль.
Еще один пример: анализ товарных позиций позволил магазину H&M сократить ассортимент в отдельных магазинах на 40%, сохранив при этом уровень продаж. Этого удалось достичь, исключив плохо продающиеся позиции, причем в расчетах учитывалась сезонность.
Отраслевым стандартом вычислений такого рода является Hadoop. Почему? Потому что Hadoop — это отличный, хорошо документированный фреймворк (тот же Хабр выдает множество подробных статей на эту тему), который сопровождается целым набором утилит и библиотек. Вы можете подавать на вход огромные наборы как структурированных, так и неструктурированных данных, а система сама будет их распределять между вычислительными мощностями. Причем эти самые мощности можно в любой момент нарастить или отключить — та самая горизонтальная масштабируемость в действиии.
В 2017 году влиятельная консалтинговая компания Gartner заключила, что Hadoop скоро изживет себя. Причина довольно банальна: аналитики считают, что компании станут массово мигрировать в облако, так как там они смогут платить по факту использования вычислительных мощностей. Второй важный фактор, якобы способный «похоронить» Hadoop — это скорость работы. Потому что варианты вроде Apache Spark или Google Cloud DataFlow работают быстрее, чем MapReduce, лежащий в основе Hadoop.
Hadoop покоится на нескольких китах, самыми заметными из которых являются технологии MapReduce (система распределения данных для расчетов между серверами) и файловая система HDFS. Последняя специально предназначена для хранения распределенной между узлами кластера информации: каждый блок фиксированной величины может быть размещен на нескольких узлах, а благодаря репликации обеспечивается устойчивость системы к отказам отдельных узлов. Вместо таблицы файлов используется специальный сервер, именуемый NameNode.
На иллюстрации ниже приведена схема работы MapReduce. На первом этапе данные разделяются по определенному признаку, на втором — распределяются по вычислительным мощностям, на третьем — происходит расчет.
Изначально MapReduce создавалась Google для нужд своего поиска. Затем MapReduce ушла в свободный код, и проектом занялся Apache. Ну а Google постепенно мигрировал на другие решения. Интересный нюанс: в настоящий момент у Google есть проект, называемый Google Cloud Dataflow, позиционируемый как следующий шаг после Hadoop, как быстрая его замена.
При ближайшем рассмотрении видно, что Google Cloud Dataflow базируется на разновидности Apache Beam, при этом в Apache Beam входит хорошо документированный фреймворк Apache Spark, что позволяет говорить о практически одинаковой скорости выполнения решений. Ну а Apache Spark отлично работает на файловой системе HDFS, что позволяет разворачивать его на серверах Hadoop.
Добавим сюда объем документации и готовых решений по Hadoop и Spark против Google Cloud Dataflow, и выбор инструмента становится очевидным. Более того, инженеры могут сами решать, какой код — под Hadoop или Spark — им выполнять, ориентируясь на задачу, опыт и квалификацию.
Тенденция к всеобщему переходу в облако породила даже такой интересный термин как Hadoop-as-a-service. В таком сценарии очень важным стало администрирование подключаемых серверов. Потому что, увы, несмотря на свою популярность, чистый Hadoop является довольно сложным для настройки инструментом, так как очень многое приходится делать руками. К примеру, по отдельности конфигурировать серверы, следить за их показателями, аккуратно настраивать множество параметров. В общем, работа на любителя и есть большой шанс где-то напортачить или что-то проворонить.
Поэтому большую популярность получили различные дистрибутивы, которые изначально комплектуются удобными средствами развертывания и администрирования. Один из наиболее популярных дистрибутивов, которые поддерживают Spark и все упрощают, — это Cloudera. У него есть и платная, и бесплатная версии — и в последней доступна вся основная функциональность, причем без ограничения числа нод.
Во время настройки Cloudera Manager будет подключаться по SSH к вашим серверам. Интересный момент: при установке лучше указать, чтобы она велась так называемыми парселами: специальными пакетами, в каждом из которых содержатся все нужные компоненты, настроенные на работу друг с другом. По сути это такая улучшенная версия пакетного менеджера.
После инсталляции мы получаем консоль управления кластером, на которой можно увидеть телеметрию по кластерам, установленные сервисы, плюс вы сможете добавлять/удалять ресурсы и редактировать конфигурацию кластера.
В результате перед вами появляется рубка той ракеты, которая унесет вас в светлое будущее BigData. Но прежде чем сказать «поехали», давайте перенесемся под капот.
На своем сайте Cloudera упоминает разные возможные конфигурации. Общие принципы, по которым они строятся, приведены на иллюстрации:
Смазать эту оптимистичную картину может MapReduce. Если еще раз посмотреть на схему из предыдущего раздела, становится очевидно, что почти во всех случаях задание MapReduce может столкнуться с «бутылочным горлышком» при чтении данных с диска или из сети. Это также отмечается в блоге Сloudera. В результате для любых быстрых вычислений, в том числе и через Spark, который часто используется для расчетов в реальном времени, очень важна скорость ввода/вывода. Поэтому при использовании Hadoop очень важно, чтобы в кластер попадали сбалансированные и быстрые машины, что, мягко говоря, не всегда обеспечивается в облачной инфраструктуре.
Сбалансированность в распределении нагрузок достигается за счет использования виртуализации Openstack на серверах с мощными многоядерными ЦПУ. Дата-нодам выделены свои процессорные ресурсы и определенные диски. В нашем решении Atos Codex Data Lake Engine достигается широкая виртуализация, отчего мы выигрываем как по производительности (минимизируется влияние сетевой инфраструктуры), так и по TCO (исключаются лишние физические сервера).
В случае использования серверов BullSequana S200 мы получаем весьма равномерную загрузку, лишенную части узких мест. В минимальную конфигурацию включается 3 сервера BullSequana S200, каждый с двумя JBOD, плюс опционально подключаются дополнительные S200, содержащие по четыре дата-ноды. Вот пример нагрузки в тесте TeraGen:
Тесты с различными объемами данных и значениями репликации показывают одинаковые результаты с точки зрения распределения нагрузки между узлами кластера. Ниже приведен график распределения доступа к диску по тестам производительности.
Расчеты выполнены на базе минимальной конфигурации из 3 серверов BullSequana S200. Она включает в себя 9 узлов данных и 3 главных узла, а также зарезервированные виртуальные машины на случай развертывания защиты на базе OpenStack Virtualization. Результат теста TeraSort: размер блока 512 МБ коэффициента реплицирования равном трем с шифрованием составляет 23,1 мин.
Как можно расширить систему? Для Data Lake Engine доступны различные виды расширений:
В состав комплекса Atos Codex Data Lake Engine входят как сами сервера, так и предварительно установленное программное обеспечение, включающее комплект Cloudera с лицензией; сам Hadoop, OpenStack с виртуальными машинами на основе ядра RedHat Enterprise Linux, системы репликации данных и бэкапа (в том числе с помощью ноды резервного копирования и Cloudera BDR — Backup and Disaster Recovery). Atos Codex Data Lake Engine стал первым решением с применением виртуализации, которое было сертифицировано Cloudera.
Если вам интересны подробности, мы будем рады ответить на наши вопросы в комментариях.
Зачем нужны распределенные вычисления в обычном бизнесе? Тут все просто и сложно одновременно. Просто — потому что в большинстве случаев мы выполняем относительно несложные расчеты на единицу информации. Сложно — потому что такой информации много. Очень много. Как следствие, приходится обрабатывать терабайты данных в 1000 потоков. Таким образом сценарии использования довольно универсальны: расчеты могут применяться везде, где требуется учесть большое количество метрик на еще большем массиве данных.
Один из недавних примеров: сеть пиццерий Додо Пицца определила на основании анализа базы заказов клиентов, что при выборе пиццы с произвольной начинкой пользователи обычно оперируют лишь шестью базовыми наборами ингредиентов плюс парой случайных. В соответствии с этим пиццерия подстроила закупки. Кроме того, у нее получилось лучше рекомендовать пользователям дополнительные товары, предлагаемые на этапе заказа, что позволило повысить прибыль.
Еще один пример: анализ товарных позиций позволил магазину H&M сократить ассортимент в отдельных магазинах на 40%, сохранив при этом уровень продаж. Этого удалось достичь, исключив плохо продающиеся позиции, причем в расчетах учитывалась сезонность.
Выбор инструмента
Отраслевым стандартом вычислений такого рода является Hadoop. Почему? Потому что Hadoop — это отличный, хорошо документированный фреймворк (тот же Хабр выдает множество подробных статей на эту тему), который сопровождается целым набором утилит и библиотек. Вы можете подавать на вход огромные наборы как структурированных, так и неструктурированных данных, а система сама будет их распределять между вычислительными мощностями. Причем эти самые мощности можно в любой момент нарастить или отключить — та самая горизонтальная масштабируемость в действиии.
В 2017 году влиятельная консалтинговая компания Gartner заключила, что Hadoop скоро изживет себя. Причина довольно банальна: аналитики считают, что компании станут массово мигрировать в облако, так как там они смогут платить по факту использования вычислительных мощностей. Второй важный фактор, якобы способный «похоронить» Hadoop — это скорость работы. Потому что варианты вроде Apache Spark или Google Cloud DataFlow работают быстрее, чем MapReduce, лежащий в основе Hadoop.
Hadoop покоится на нескольких китах, самыми заметными из которых являются технологии MapReduce (система распределения данных для расчетов между серверами) и файловая система HDFS. Последняя специально предназначена для хранения распределенной между узлами кластера информации: каждый блок фиксированной величины может быть размещен на нескольких узлах, а благодаря репликации обеспечивается устойчивость системы к отказам отдельных узлов. Вместо таблицы файлов используется специальный сервер, именуемый NameNode.
На иллюстрации ниже приведена схема работы MapReduce. На первом этапе данные разделяются по определенному признаку, на втором — распределяются по вычислительным мощностям, на третьем — происходит расчет.
Изначально MapReduce создавалась Google для нужд своего поиска. Затем MapReduce ушла в свободный код, и проектом занялся Apache. Ну а Google постепенно мигрировал на другие решения. Интересный нюанс: в настоящий момент у Google есть проект, называемый Google Cloud Dataflow, позиционируемый как следующий шаг после Hadoop, как быстрая его замена.
При ближайшем рассмотрении видно, что Google Cloud Dataflow базируется на разновидности Apache Beam, при этом в Apache Beam входит хорошо документированный фреймворк Apache Spark, что позволяет говорить о практически одинаковой скорости выполнения решений. Ну а Apache Spark отлично работает на файловой системе HDFS, что позволяет разворачивать его на серверах Hadoop.
Добавим сюда объем документации и готовых решений по Hadoop и Spark против Google Cloud Dataflow, и выбор инструмента становится очевидным. Более того, инженеры могут сами решать, какой код — под Hadoop или Spark — им выполнять, ориентируясь на задачу, опыт и квалификацию.
Облако или локальный сервер
Тенденция к всеобщему переходу в облако породила даже такой интересный термин как Hadoop-as-a-service. В таком сценарии очень важным стало администрирование подключаемых серверов. Потому что, увы, несмотря на свою популярность, чистый Hadoop является довольно сложным для настройки инструментом, так как очень многое приходится делать руками. К примеру, по отдельности конфигурировать серверы, следить за их показателями, аккуратно настраивать множество параметров. В общем, работа на любителя и есть большой шанс где-то напортачить или что-то проворонить.
Поэтому большую популярность получили различные дистрибутивы, которые изначально комплектуются удобными средствами развертывания и администрирования. Один из наиболее популярных дистрибутивов, которые поддерживают Spark и все упрощают, — это Cloudera. У него есть и платная, и бесплатная версии — и в последней доступна вся основная функциональность, причем без ограничения числа нод.
Во время настройки Cloudera Manager будет подключаться по SSH к вашим серверам. Интересный момент: при установке лучше указать, чтобы она велась так называемыми парселами: специальными пакетами, в каждом из которых содержатся все нужные компоненты, настроенные на работу друг с другом. По сути это такая улучшенная версия пакетного менеджера.
После инсталляции мы получаем консоль управления кластером, на которой можно увидеть телеметрию по кластерам, установленные сервисы, плюс вы сможете добавлять/удалять ресурсы и редактировать конфигурацию кластера.
В результате перед вами появляется рубка той ракеты, которая унесет вас в светлое будущее BigData. Но прежде чем сказать «поехали», давайте перенесемся под капот.
Требования к железу
На своем сайте Cloudera упоминает разные возможные конфигурации. Общие принципы, по которым они строятся, приведены на иллюстрации:
Смазать эту оптимистичную картину может MapReduce. Если еще раз посмотреть на схему из предыдущего раздела, становится очевидно, что почти во всех случаях задание MapReduce может столкнуться с «бутылочным горлышком» при чтении данных с диска или из сети. Это также отмечается в блоге Сloudera. В результате для любых быстрых вычислений, в том числе и через Spark, который часто используется для расчетов в реальном времени, очень важна скорость ввода/вывода. Поэтому при использовании Hadoop очень важно, чтобы в кластер попадали сбалансированные и быстрые машины, что, мягко говоря, не всегда обеспечивается в облачной инфраструктуре.
Сбалансированность в распределении нагрузок достигается за счет использования виртуализации Openstack на серверах с мощными многоядерными ЦПУ. Дата-нодам выделены свои процессорные ресурсы и определенные диски. В нашем решении Atos Codex Data Lake Engine достигается широкая виртуализация, отчего мы выигрываем как по производительности (минимизируется влияние сетевой инфраструктуры), так и по TCO (исключаются лишние физические сервера).
В случае использования серверов BullSequana S200 мы получаем весьма равномерную загрузку, лишенную части узких мест. В минимальную конфигурацию включается 3 сервера BullSequana S200, каждый с двумя JBOD, плюс опционально подключаются дополнительные S200, содержащие по четыре дата-ноды. Вот пример нагрузки в тесте TeraGen:
Тесты с различными объемами данных и значениями репликации показывают одинаковые результаты с точки зрения распределения нагрузки между узлами кластера. Ниже приведен график распределения доступа к диску по тестам производительности.
Расчеты выполнены на базе минимальной конфигурации из 3 серверов BullSequana S200. Она включает в себя 9 узлов данных и 3 главных узла, а также зарезервированные виртуальные машины на случай развертывания защиты на базе OpenStack Virtualization. Результат теста TeraSort: размер блока 512 МБ коэффициента реплицирования равном трем с шифрованием составляет 23,1 мин.
Как можно расширить систему? Для Data Lake Engine доступны различные виды расширений:
- Узлы передачи данных: для каждых 40 ТБ полезного пространства
- Аналитические узлы с возможностью установки графического процессора
- Другие варианты в зависимости от потребностей бизнеса (например, если нужна Kafka и тому подобное)
В состав комплекса Atos Codex Data Lake Engine входят как сами сервера, так и предварительно установленное программное обеспечение, включающее комплект Cloudera с лицензией; сам Hadoop, OpenStack с виртуальными машинами на основе ядра RedHat Enterprise Linux, системы репликации данных и бэкапа (в том числе с помощью ноды резервного копирования и Cloudera BDR — Backup and Disaster Recovery). Atos Codex Data Lake Engine стал первым решением с применением виртуализации, которое было сертифицировано Cloudera.
Если вам интересны подробности, мы будем рады ответить на наши вопросы в комментариях.
sshikov
>При ближайшем рассмотрении видно, что Google Cloud Dataflow базируется на разновидности Apache Beam, при этом в Apache Beam входит хорошо документированный фреймворк Apache Spark
Простите, а вы в этом уверены? Насколько я знаю, у Beam есть SparkRunner, который позволяет запускать задачи Beam под управлением Spark — и это не совсем тоже самое, что входящий в состав спарк. Я бы сказал, что совсем не тоже. Запускаться под управлением спарка еще Crunch умел — и тоже самого спарка в его составе никогда не было.
И что самое главное — в Beam вроде не входит ничего похожего на HDFS, поэтому говорить что Beam это быстрая замена хадуп — ну это как-то так себе формулировочка. Быстрая замена MapReduce — ну да, может быть. Но это ни разу не отменяет того факта, что MapReduce в чистом виде и так уже мало используется, в том числе и на хадупе.
dmt_chkg Автор
Очевидно, что от MapReduce постепенно отказываются в пользу того же самого Spark как минимум из-за нагрузок на сеть и ради щадящей работы с хранилищем во время выполнения задачи. Наличие в дистрибутиве одного проекта не означает, что нужно отказываться от другого схожего и сбрасывать его со счета, лучше — пользоваться различными платформами исходя из задач и ресурсов.
Более того, в Atos Codex Datalake Engine датаноды изолированы друг от друга посредством OpenStack, что положительно сказалось на производительности в реальных задачах.
sshikov
Не все понял из вашего ответа, честно говоря.
Поясню — мне просто не понравилась формулировка, что в Beam якобы входит спарк. Мне кажется (я смотрел на Beam год назад, но вряд ли что-то могло сильно поменяться) что ничего такого нет — просто Beam может использовать спарк (или несколько других движков) для запуска своих задач. В том числе и без хадупа, это чистая правда. Я бы, кстати, даже не рассматривал Beam как замену спарку — они конечно похожи, но далеко не идентичны по возможностям. Переход в обе стороны будет стоит многих усилий.
А второе то, что спарк не может заменить хадуп, потому что в нем нет хранилища (hdfs). Ну т.е. в качестве замены всему хадупу он не годится. Ну то есть некоторые формулировки слегка нечеткие.
В целом же то утверждение, что у хадупа есть альтернативы в облаке, вопросов не вызывает. В зависимости скажем от масштаба они вполне могут быть лучше.