MapReduce без Hadoop

Забавно, исследовав вопрос остановился именно на hadoop.

бежать от этой штуки нужно сломя голову и как можно дальше

Почему сделали такой вывод?

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

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

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

4,2

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

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

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

Dask.
Из преимуществ - работает поверх pandas
Недостаток - индексы должны помещаться в RAM, иначе не работает.

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

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

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

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

тебе он вряд-ли нужен.

если вопрос хранения огромного количества данных не стоит остро, а нужна только прожарка — посмотри на spark.

Amazon EMR

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

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

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

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

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

Недостаток - индексы должны помещаться в RAM, иначе не работает.

Можно файл подкачки на NVMe выделить

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

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

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

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

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

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

Кот-то упомянул Кассандру… может, вам просто Кликхаус нужен?

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

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

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

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

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

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

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

Так звучит, как будто сама технология гарантирует тормоза. Вот это не очевидно.

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

В общем перебрав варианты остановились пока на Standalone Spark, будем читать и размышлять как развиваться дальше и не потратить все деньги на память :)

Spark

Это называется «из лужи в болото».

Это почему?

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

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

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

и что делать с данными, которые целиком не влезают в память

а что делать с теми, которые не влезают в память максималки на амазоне?

Нужно провести поиск и аггрегацию по 3.5 Пб

вот именно, отличный пример

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

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

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