Как стать автором
Обновить

Комментарии 3

На самом деле попыток запускать Hadoop поверх СХД предпринималось уже довольно много, практически все вендоры СХД имеют своё решение для этого. В пику этому по сети гуляет множество статей вроде Never, ever do this to Hadoop, осуждающих такой дизайн. Даже я как-то написал одну.

На самом деле тут все довольно просто. Подобные системы имеют смысл только при сильном дизбалансе требований к объему хранимых данных и вычислительной мощности. Например, большой кластер Apache Spark для обработки пары десятков терабайт данных в MLlib, или же хранение нескольких петабайт данных и периодические запросы к ним в Hive.

Рациональная же составляющая тут следующая — не верьте маркетингу. Если у вас есть N процессоров и M жестких дисков, то добавив между ними сеть вы никак не получите +30% в производительности чтения (да и откуда, жестких дисков-то ровно столько же). Затем, при использовании приведенной архитектуры нужно не забывать про стоимость лицензий на софт, поставляемый HPE (те же СХД — это не просто кучка железа, это проприетарный софт на них). Масштабировать такой кластер в будущем можно будет только компонентами HP, то есть вендор lock-in гарантирован. К тому же требования к сети у таких решений по сравнению с традиционными кластерами Hadoop сильно выше — если на текущий момент множество кластеров Hadoop спокойно живет с 1GbE ввиду парадигмы вычислений MR, то тут без 10GbE не обойтись, а желательно еще и по нескольку кабелей к каждой из нод подвести (20 LFF дисков на вычислительную ноду смогут отдать ей около 1200MB/sec, а это уже больше возможностей одного 10GbE порта).

Как показывает практика, чаще всего подобные системы внедряются крупными банками и подобными им корпорациями, в которых нет своей экспертизы по Hadoop, но которые хотят показать всему миру что "мы тоже умеем Hadoop". Зачастую внедренные таким образом системы либо практически не используются, либо заменяются нормальными кластерами с ростом нагрузки на них и экспертизы на стороне заказчика.
Столько времени прошло, а самое ценное в этой статье — Ваш комментарий.
Спасибо за него!
Вычислительные узлы и узлы хранения данных BDRA связывает высокоскоростная сеть.

Было бы интересно почитать, почему выбрано такое решение. Много где рекомендуют обратное — использовать по возможности одинаковые воркер-узлы, не разбивать их на "хранение" и "обработку". При таком подходе сводится к минимуму использование сети (кластер пытается обрабатывать данные там, где они храняться; сеть не ложится при выходе из строя одного из серверов с данными, ...).
Зарегистрируйтесь на Хабре , чтобы оставить комментарий