Spark 1.5 — распределенная система обработки данных

Все время вспоминаю эту статью, когда читаю про очередные распределенные кластера: http://aadrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-clu...

1) статья правильная, про то что не надо все подряд обзывать big data, а разные инструменты подходят для разных случаев, не надо все подряд заколачивать, и тем более микроскопом
2) в статье использовался Hadoop, у которого все промежуточные результаты идут через диск, ибо Hadoop - это не про быстрые вычисления, а про обработку больших объемов данных
3) 7 машин - это ну совсем мелкий кластер

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

не понимаю что Вы хотели сказать свои комментарием

Хотел сказать что всегда вспоминаю эту статью..

Хорошо обул )

По ссылке лень хидить, там рассматривают одинаковый петабайтовый объём?

Там заголовок просто желтый.
Автор говорит о том, что очень часто встречается с тем, что Hadoop используют там, где дешевле и проще будет обойтись без него.
Он не отрицает того, что при обработке действительно больших данных, одной нодой и comand-line-tools-chain не обойтись.

Насколько оправдано это жирное поделие? Тот кому оно реально может помочь (google, amazon, lhc) обладает ресурсами запилить кастомное оптимизированное решение. Или это для компаний типа mailru, yahoo и подобный треш?

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

Насколько оправдано это жирное поделие?

твои жирные каменты - вот что неоправдано

такой факт не свидетельствует о Вашем уме, дорогой товарищ шланг

твои жирные каменты - вот что неоправдано

Окей, иду читать документацию и что я вижу:

By default, Java objects are fast to access, but can easily consume a factor of 2-5x more space than the “raw” data inside their fields. This is due to several reasons:

Нахрена мне такие тапочки, когда у меня огромное кол-во данных, а мне это жирнота дает еще 2-5x оверхеда? Вот я и говорю, что это удел mailru, yahoo и подобного треша юзать такие поделия.

Я написал то что хотел сказать, не надо искать скрытых мотивов и смыслов везде.

Кому пришло в голову назвать это Spark?

Нахрена мне такие тапочки, когда у меня огромное кол-во данных, а мне это жирнота дает еще 2-5x оверхеда?

1) Огромное количество данных - это сколько? Больше, чем у Yahoo?
2) Опиши свой use case. Как ты решаешь задачи обработки данных?

1) Вы написали «очередные распределенные кластера», такая формулировка несет негативный момент
2) почему-то у многих людей которые занимаются обработкой больших данных, и с которыми я знаком лично, таких ассоциаций не возникает, может быть потому что они представляют зачем это нужно и как это правильно использовать?

Кому пришло в голову назвать это Spark?

ну да, покусились на святое, на газету Ильича

Тот кому оно реально может помочь (google, amazon, lhc) обладает ресурсами запилить кастомное оптимизированное решение.

Дефективное совковое образование detected. На каждый чих запиливать кастомное решение, похожие одно на другое? Это путь тех кто считает «Бабы еще нарожают». Буржуи считают деньги

Нахрена мне такие тапочки, когда у меня огромное кол-во данных, а мне это жирнота дает еще 2-5x оверхеда?

Потому что Java objects are fast to access

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

Т.е. нормально переплачивать за серваки кучу бабла? Когда на крестах хватит двух серваков по $10K каждый, со Spark надо 6 серваков за $10K ибо оверхед по памяти от 2-5, берем по среднему. Когда надо 10 серваков, со Spark - 30 и переплата $200K. Когда - 10 000 серваков, со Spark переплачиваем $200 000 000 баксов.

Может все таки запилить кастомное решение, которое сэкономит эти баксы?

Буржуи считают деньги

Ну да, расскажи еще сказок, про атлантов и идеальных людей пандоры.

Огромное количество данных - это сколько? Больше, чем у Yahoo?

Без разницы. Когда мне хватило бы одного сервака со Spark мне нужно покупать 3 сервака. Когда мне хватило бы 2 двух серваков и простого алгоритма мержа, со Spark мне нужно думать об аренде стойки в датацентре.

И наоборот, когда мне надо 1000 серваков, со Spark я переплачиваю $20 000 000. С оверхедом по памяти в 2-5 раз, я переплачу еще за 2000 серваков, не говорю уже о том, сколько нужно еще переплатить за инфраструктуру для них.

Опиши свой use case. Как ты решаешь задачи обработки данных?

Я не решаю этих задач, но начав решать я бы определенно отбросил Spark и поискал другие решения. Или сел и посчитал, что проще выделить $300K небольшой команде профи, которые напишут кастомное решение под мою задачу, чем чуть позже переплачивать за масштабирование огромные деньги.

Потому что Java objects are fast to access

Зачем мне fast to access, когда мне в памяти нужно размещать куеву тучу данных? И иметь оверхед 2-5 раз?

Когда на крестах хватит двух серваков [..], со Spark надо 6 серваков

обоснование цифр будет?

Я не решаю этих задач

боюсь что все ваши фантазии происходят из этого печального факта

Зачем мне fast to access, когда мне в памяти нужно размещать куеву тучу данных?

а зачем тебе куча данных в памяти?

обоснование цифр будет?

Вот это я и срашивал в самом начале. И хотел бы увидеть эти цифры на офиц. сайте Spark. А пока я знаю, что для хранения большего объема данных в RAM на JVM требуется x3 оверхеда, чем хранить тот же объем данных на Си.

Простые вычисления говорят мне, что для выгрузки в RAM котировок (как пример) потребует 16 байт данных на запись. Тем самым я смогу разместить на 128 Gb памяти котировки 5000 компаний за 60 дней с разрешением в 1 сек. И все это на одном сервере.

На JVM для размещения эти данных потребуется 3 сервера. Я уж не говорю о том, что я дополнительно получу оверхед от GC. Если данные вне jvm heap, то я получу охренительный оверхед по копированию данных из external heap в jvm heap с сопровождающейся сериализацией/десериализацией объектов.

Так что в итоге интуиция мне подсказывает, что Си реализация (а в будущем Rust реализация) будет в 3 раза дешевле по оборудованию, чем JVM реализация. Даже для простейших ситуаций можно будет экономить десятки тысяч долларов. А для сложных это сотни и миллионы долларов.

а зачем тебе куча данных в памяти?

Чтобы делать их анализ и расчеты с максимальной скоростью, удивлены? Правда, мне сейчас это не нужно, но один из возможных проектов может вырасти.

И я точно не буду юзать для этого Spark, а скорее запилю собственное решение на Rust. Если к тому времени не будет на нем чего-то подобного Spark.

Зачем мне fast to access, когда мне в памяти нужно размещать куеву тучу данных?

«память больше не ресурс» (C)

Если к тому времени не будет на нем чего-то подобного Spark

Вообще удивляет конечно, всё давно есть на Java, даже тем же апплетам 15 лет, но нет, переизобретают .NET, Silverlight, DHTML & HTML 5, все что угодно лишь бы не взять готовую жабу. Ресурсы человечества тратятся на NIH. При этом вирусни несмотря на всякие javascript и dhtmlы не стало меньше хотя казалось бы должно было, тому подтверждение врубленный по умолчанию Microsoft Defender, который в 10ке вообще сделали неотключаемым

Когда - 10 000 серваков, со Spark переплачиваем $200 000 000 баксов.

Может все таки запилить кастомное решение, которое сэкономит эти баксы?

Рассуждения уровня семиклассников или министров, «Да нахрена мы платим миллионы за этот Oracle и какой-то ACID?!? Да неужели наши хакеры не напишут замену этой SQL DB на простых файлах? Ведь наши хакеры не индусы какие, паимаишь, у нас учёные»

Как оно там, написали уже процессинг Национальной Платежной Системы?

Простые вычисления говорят мне, что для выгрузки в RAM котировок (как пример) потребует 16 байт данных на запись. Тем самым я смогу разместить на 128 Gb памяти котировки 5000 компаний за 60 дней с разрешением в 1 сек. И все это на одном сервере.

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

PS и вот нафига котировки финансовых инструментов за 60 дней в оперативном доступе - ума не приложу, но это так - мысли в сторону

Так что в итоге интуиция мне подсказывает, что Си реализация (а в будущем Rust реализация) будет в 3 раза дешевле по оборудованию, чем JVM реализация.

погодите считать прибыли, что с данными то делать собираетесь?

И я точно не буду юзать для этого Spark, а скорее запилю собственное решение [..]

да никто и не заставлят Вас ничего использовать против Вашей воли

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

запилю собственное решение на Rust

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

а зачем тебе куча данных в памяти?

Чтобы делать их анализ и расчеты с максимальной скоростью, удивлены?

да не то чтобы, но Вы будете удивлены, когда узнаете что просто нахождение данных в памяти на скорость счета влияет далеко не всегда так положительно как Вам кажется ))

но нет, переизобретают .NET, Silverlight, DHTML & HTML 5, все что угодно лишь бы не взять готовую жабу

ну это тоже полезный процесс, ибо больше инструментов хороших и разных

А почему какой проект ни возьми из Apache, тот на жабе?

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

2 ксеона по 12 ядер с HT, т.е. в итоге 24 с ddr4 по два канала на проц.

и вот нафига котировки финансовых инструментов за 60 дней в оперативном доступе - ума не приложу, но это так - мысли в сторону

Для прогнозирования временных рядов. Т.е. нужно в реальном времени делать последовательный поиск определенных паттернов в старых данных для каждого из 5000 графиков. И делать это нужно очень быстро, т.к. ситуация на рынке меняется в реальном времени.

И 60 дней это еще мало, по хорошему нужно за год, т.е. раз в 6 больше данных.

легким прогулочным шагом в одно лицо собираетесь всех вокруг забороть за полгода

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

И начну я не для 1000 раб. станция. А с 1-2 серверов. А не так, что у нас уже 50 серверов и нужно срочно новое решение, ибо Spark жрет бабло на железе, а нужно срочно масштабироваться дальше.

Кстати, по поводу «скорости счета», делать это на JVM - потерять по скорости раза в два. Но это конечно не критично, можно сделать внешнию либу через JNI. Но обычно для таких вещей расчеты делаются на GPU и тут опять теряешь в перформансе, т.к. нужно сериализовать/десериолизовать объекты, а затем копировать из одного хипа в другой.

Так что тут тоже будет проседание, как минимум в два раза. Я не знаю зачем такие вещи пилят на JVM. Поэтому изначально задал простой вопрос: Насколько оправдана это жирнота? Хотел увидеть простой ответ, мол очень популярно среди «индусов» мейлру, яху и прочего треша. Или какой-то другой ответ.

https://news.ycombinator.com/item?id=9249913

Первый ответ.

Хотел увидеть простой ответ, мол очень популярно среди «индусов» мейлру, яху и прочего треша.

https://cwiki.apache.org/confluence/display/SPARK/Powered By Spark

Подходит под запрос?

Подходит под запрос?

Не убедительно, куча нонеймов, а там где вписывают мировые бренды, например, Baidu, толком нет информации для чего или какие-то размытые данные: Ebay «Using Spark core for log transaction aggregation and analytics».