LINUX.ORG.RU

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

 


2

2

9 сентября 2015 года стала доступна новая версия высокопроизводительной системы распределенной обработки данных.

Apache Spark — это высокопроизводительная система для распределенной обработки данных, основанная на модели вычислений в памяти.

Spark предназначен для запуска в окружении Hadoop-кластера через использование механизма YARN или в одиночном режиме. В качестве уровня хранения данных могут быть использованы HDFS, HBase, Cassandra, Hive или любой Hadoop input format. Поддерживается работа в пакетном режиме (подобно map-reduce), а также режимы потоковой обработки, интерактивных запросов и машинного обучения. Spark предоставляет программные интерфейсы для работы с языками Python, Java и Scala.

Является проектом верхнего уровня Apache Software Foundation (ссылка).

Основные изменения:

  1. API (RDD, DataFrame & SQL)
    • новый экспериментальный механизм пользовательских функций-агрегатов (user-defined aggregate function, UDAF), раньше поддержка была только для Hive
    • улучшенная поддержка значений NaN (функции isnan, nanvl, поддержка группировки и т.д.)
    • добавлен тип данных CalendarIntervalType для временных интервалов
    • добавлена поддержка упорядочивания для типа данных StructType
    • добавлены боле 100 функций date/time, string, math, etc.
    • добавлена поддержка вывода типов и сообщений об ошибках во время фазы анализа (т.о. большая часть ошибок выявляется во время анализа, а не во время исполнения)
  2. Бэкенд (DataFrame & SQL)
    • генерация кода включена по-умолчанию для практически всех DataFrame/SQL функций
    • улучшен механизм выполнения агрегаций (aggregation)
    • улучшен механизм выполнения слияний (join)
    • улучшен механизм выполнения сортировки (sort)
    • улучшена поддержка прямой работы с памятью
    • улучшены средства отладки и генерации отчетов
  3. Интеграция
    • улучшения работы с источниками данных: Hive, Hadoop, Mesos, а также системы управления кластером
  4. Машинное обучение и аналитика
    • добавлены преобразователи признаков (feature transformers): CountVectorizer, Discrete Cosine transformation, MinMaxScaler, NGram, PCA, RFormula, StopWordsRemover и VectorSlicer
    • добавлены новые алгоритмы: многоуровневый персептрон, PrefixSpan для выявления последовательных последовательностей, генерация правил объединения, критерий согласия Колмогорова-Смирнова и т.д.
    • улучшения в существующих алгоритмах
  5. Потоковый режим
    • добавлен Python API для потоковых источников (Kafka, Kinesis, Flume, MQTT)
    • добавлен Python API для алгоритмов машинного обучения на потоковых данных
    • добвлен механизм адаптивной подстройки под уровень поступления данных и вычислительной загрузки
    • улучшены механизмы балансировки нагрузки и планировщик для приемников данных кластера

Также релиз содержит также множество других изменений.

>>> Подробности

★★★★★

Проверено: maxcom ()
Последнее исправление: JB (всего исправлений: 3)

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

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

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

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

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

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

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

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

d-strip
()

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

foror ★★★★★
()
Ответ на: комментарий от d-strip

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

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

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

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

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

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

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

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 и подобного треша юзать такие поделия.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

shty ★★★★★
() автор топика
Ответ на: комментарий от foror

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

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

shty ★★★★★
() автор топика
Ответ на: комментарий от foror

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

shty ★★★★★
() автор топика
Ответ на: комментарий от foror

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

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

shty ★★★★★
() автор топика
Ответ на: комментарий от foror

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

foror ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.