LINUX.ORG.RU

MapReduce без Hadoop

 ,


0

1

Вопрос пока что для меня дискусионного характера. Нужен MapReduce, но весь мой опыт контактирования с продуктами из стека Hadoop говорит мне о том, что если ты хоть чуточку в здравом уме, бежать от этой штуки нужно сломя голову и как можно дальше. Собственно загуглив я обнаружил что реализаций MapReduce довольно много. Но вот вопрос, а что собственно говоря выбрать? Может ли кто-то посоветовать в какую сторону смотреть?


Ответ на: комментарий от in_dance

Ну мне видится две причины создающих такое впечатление.

  • Очень большой вес инфраструктуры, она вся написана под jvm с явной расточительностю на ресурсы. Поскольку в моем понимании cloud native решения опираются на массу машин с даеко не самым топовым железом, а иногда даже и весьма посредственным, развертывание элементов hadoop является просто тратой денег на вычислительные ресурсы. Как пример такого софта могу привести Apache Cassandra, которая для гарантированного холодного старта требует минимум гиг озу. В масштабе одного инстанса не очень много, а в масштабе кластера выглядит ужасающим расточительством памяти.
  • Повязанность инрфраструктуры на общие зависимости. Не могу тут масштабно рассуждать, был опыт только с kafka, которая не работает без zookeeper, и как я понял из того что я читал, это самый безобидный пример, зависимости на вещи вроде zookeeper, hdfs и т п подобно там повсеместны.

Из всего этого возникает некий диссонанс - теоретически MapReduce это очень простая вещь, но вот предлагаемая реализация требует сотен гигабай озу и ядер cpu, что вызывает некоторое непонимание этой ресурсоемкости.

Serbis ()

но вот предлагаемая реализация требует сотен гигабай озу и ядер cpu

мне кажется это необходимость для тех задач, где используется map reduce, а не что-либо иное

in_dance ()
Последнее исправление: in_dance (всего исправлений: 1)
Ответ на: комментарий от Serbis

Объём данных, которые (по задумке) призван прожевать хадуп требуют во много раз более толстой инфраструктуры чем сам хадуп. Из этого мораль, если затраты на сам хадуп для тебя заметны то возможно тебе ни хадуп, ни другая распределенная обработка не нужна.

ya-betmen ★★★★★ ()
Ответ на: комментарий от ya-betmen

Получается какой-то технологический провал. Потому что данных столько что их уже нельзя обрабатвывать обычными средставми, а до хадупа исходя из вашего утверждения они и не вырастут никогда. Получается остается только изобретение велосипедов?

Объём данных, которые (по задумке) призван прожевать хадуп требуют во много раз более толстой инфраструктуры чем сам хадуп

Только вот парадокс в том, что по признаниям известных крупных компаний, количество данных которые у них в реальности жует хадуп, могут без затруднений прожуют несколько реплик микросервиса. Потому что средний пакет данных сгружаемых туда составляет 10-100гб. Спрашивается - на кой черт там хадуп развернут?

Serbis ()
Последнее исправление: Serbis (всего исправлений: 1)
Ответ на: комментарий от Serbis

Спрашивается - на кой черт там хадуп развернут?

Потому что удобно и просто работает. Не надо следить за этими «микросервисами», чтобы они не падали, балансились, etc.

pekmop1024 ★★★★★ ()

Критерии для выбора-то какие?

Мапредьюсов «попроще» хватает - монга, спарк.

Да почти любой современный яп с ложкой функциональщины можно брать и делать на коленке мапредьюс.

anonymous ()

А задача какова?

Просто мало у кого есть задачи размера гугла. Обычно на практике, если забыть про map-reduce, то всё вдруг прекрасно считается на одной машине и вдесятеро быстрее.

anonymous ()
Ответ на: комментарий от anonymous

Когда только появлялись все эти докеры-кибернеты-хадупы, ещё были люди, которые пытались образумить вебмакак, мол, вы не Гугл и не Амазон.
Но им только подавай клауд-нейтив, веб-скейл решения - которые имеют смысл только для огромного количества данных и огромного количества машин. Ведь когда построим посадочную полосу и сделаем там то же, что делали могучие господа - они к нам обязательно прилетят.

anonymous ()
Ответ на: комментарий от Serbis

средний пакет данных сгружаемых туда составляет 10-100гб.

И это не может прожевать например постгре?

Да и например кассандра съест менее 5гигов под инфраструктуру, так что не понимаю чего ты жалуешься.

ya-betmen ★★★★★ ()

чтобы лорчик понимал, насколько ТС странный, скажу что юзал хадуп в виртуалке на машине с 8 гигами оперативки из которых только 4 было выделено под виртуалку. Ясно, что ничего серьёзного (хотя что считать серьёзным тоже вопрос) там не посчитать, это было чисто чтобы хадуп потыкать и на мапредюс поглядеть. И потыкалось и погляделось, да ещё через биндинг к тормознутому и жручему питону, вроде такого https://www.michael-noll.com/tutorials/writing-an-hadoop-mapreduce-program-in....

peregrine ★★★★★ ()
Последнее исправление: peregrine (всего исправлений: 1)

Ну вообще джава не такая уж и медленная, и бывает что от нативного кода не отличается, и я думаю что память там уйдет на сами данные а не на jvm. Тюнинг может конечно потребовать некоторого опыта.

Я бы выбрал то у чего есть поддержка, стековерфлоу, комьюнити. И провел бы тесты производительности на своем железк, сравнил удобство и посмотрел как оно под мою задачу ложится.

Вот какая у вас задача? Как она в мап редюс парадигму ложится?

OxiD ★★★★ ()
Ответ на: комментарий от Serbis

Кассандре нужен гиг памяти вовсе не из-за жавы, а из-за того, как она с диском работает. И думаю ей нужно 4. Это значение не изменилось бы если все написать на плюсах. Насколько помню там lsm дерево, и чем больше озу тем больше шансов что не будет чтений с диска. А чтения могут быть случайными и не быстрыми.

OxiD ★★★★ ()
Последнее исправление: OxiD (всего исправлений: 1)

Могу сказать про Hadoop. Столько времени пытался его настроить на максимальную производительность для Apache Nutch, безуспешно. Внешняя сортировка, которую фреймворк выполняет между map и reduce медленнее возможной раз в 10-100. В результате выбрасывания hadoop’a осталась только краулерная логика, я смог занять имеющуюся память сервера под структуры данных и снизить максимально работу с диском, а та, что осталась, была последовательными чтением/записью.

anymouse ()
Ответ на: комментарий от anymouse

Дело в том, что такие вещи как хадуп используются в структурах типа банков. У меня есть опыт работы с таких местах, там потратить пару миллиардов на резервный ЦОД вполне нормальная ситуация. У нас типовые сервера, которые выдавали всем подразделениям без спецзапросов по повышенным ресурсам имели на борту 128 гигов озу и 32 ядра цпу. И это считались самые дохлые машины. В таких условиях, внедрение да и разработка самого хадупа идет с пристрелкой на потенциально безлимитные как вычислительные так и финансовые русурсы. В таких местах никого не волнуют лишние 200-300 гигов памяти. Совсем другое дело это небольшая компания или даже стартап как в моем случае, где эти же 200-300 гигов это довольно заметная стока в финансовм отчете. Поэтому и приходится задавать такие вот дурацкие вопросы о хадупе без хадупа.

Serbis ()
Последнее исправление: Serbis (всего исправлений: 2)
Ответ на: комментарий от in_dance

Спарк точно так же жрёт ресурсы и создаёт 300% оверхеда на ровном месте. Если выкинуть спарк, обычно всё прекрасно работает на одной машине.

Единственное, для чего он бывает полезен - им могут пользоваться «дата-сатанисты», не представляющие, как работают алгоритмы, и что делать с данными, которые целиком не влезают в память. Спарк для них создаёт иллюзию, что данные в память влезают. Ценой огромного оверхеда и диких задержек. Типичный воркфлоу: запустил запрос и ушёл на полчаса пить кофе и трепаться с коллегами. Кто-то из яндекса говорил, что после замены спарка на кликхаус продуктивность труда аналитиков выросла на порядок, потому что запросы теперь занимают не минуты, а секунды, и пить кофе каждый раз не обязательно.

anonymous ()
Ответ на: комментарий от anonymous

Ваши предложения? Нужно провести поиск и аггрегацию по 3.5 Пб событийных данных на 100 нодах (это требование по предельным параметрам, в реальности конечно будет скорее всего около 500Тб, но сути вопроса это не меняет). Что можете предложить без разработки велосипедов?

Serbis ()
Ответ на: комментарий от Serbis

в реальности конечно будет скорее всего около 500Тб

Предлагаю для начала вернуться в реальность, лол. Алсо ClickHouse.

Хотя, на самом деле, для человечества будет лучше, если ваша контора будет страдать и работать неэффективно. Честно. Фонд Apache поистине выполняет кармическую миссию по кормлению говнокомпаний отборным неюзабельным жабоговном. Иначе бы они совсем поработили мир, и пришлось бы нам взорвать вашу планету нахрен. Предварительно эвакуировав всех котиков.

anonymous ()