Comments 4
Спасибо за описанный опыт посещения саммита. Я бы еще отдельно отметил демо сессию в рамках доклада Apache Spark 2.0, которая начинается на видео примерно с 17:45 минуты.
а теперь пару других слов:
streaming — как пилили микробатчи, так и будем пилить, ожидать честного стриминга не стоит и «он вам не нужен»
sql — как пилили кастомный Catalyst, так и будем пилить, плевать мы хотели на другие уже существующие и отлаженные инструменты (для примера https://calcite.apache.org/ )
rdd — забили на развитие, используйте dataframe
dataframe — пока юзайте, но учтите, что основные изменения у нас в sql, так что может и вам что от планировщика перепадет, но вообще лучше тоже двигайте в sql, там все оптимизации
и да, dataframe уже в разы быстрее чем rdd для питона, так как имеет схему и гонит данные в лямбды достаточно хорошо, поэтому arrow больше для общения между любыми системами интересно
я не спорю, что спарк развивается, но зачастую шумихи больше чем достижений
streaming — как пилили микробатчи, так и будем пилить, ожидать честного стриминга не стоит и «он вам не нужен»
sql — как пилили кастомный Catalyst, так и будем пилить, плевать мы хотели на другие уже существующие и отлаженные инструменты (для примера https://calcite.apache.org/ )
rdd — забили на развитие, используйте dataframe
dataframe — пока юзайте, но учтите, что основные изменения у нас в sql, так что может и вам что от планировщика перепадет, но вообще лучше тоже двигайте в sql, там все оптимизации
и да, dataframe уже в разы быстрее чем rdd для питона, так как имеет схему и гонит данные в лямбды достаточно хорошо, поэтому arrow больше для общения между любыми системами интересно
я не спорю, что спарк развивается, но зачастую шумихи больше чем достижений
«streaming — как пилили микробатчи, так и будем пилить, ожидать честного стриминга не стоит и «он вам не нужен»»
Очевидно от микробатчей никуда сейчас не деться, но раньше даже с микробатчами работать было не удобно, теперь же у нас появился удобный API (насколько удобный еще только предстоит выяснить), который позволит применять эту технологию чаще.
«rdd — забили на развитие, используйте dataframe»
У вас есть какие-то предложения по их развитию? Кажется, что кроме багофиксов, доп-оптимизаций и небольших изменений в api-для основных языков там больше ничего глобального не сделать.
«dataframe — пока юзайте, но учтите, что основные изменения у нас в sql, так что может и вам что от планировщика перепадет, но вообще лучше тоже двигайте в sql, там все оптимизации»
Хм, в презентациях посвящённых Catalyst использовался, вполне себе dataframe-api и не было sql. Ну и потом, они же взаимозаменяемы и оптимизация будет одинаковой, если посмотреть доклад про внутреннее устройство оптимизатора тут, то становится понятно что нет разницы между SparkSql, DataFrame-api, ну и DataSet-там тоже перепадёт.
Очевидно от микробатчей никуда сейчас не деться, но раньше даже с микробатчами работать было не удобно, теперь же у нас появился удобный API (насколько удобный еще только предстоит выяснить), который позволит применять эту технологию чаще.
«rdd — забили на развитие, используйте dataframe»
У вас есть какие-то предложения по их развитию? Кажется, что кроме багофиксов, доп-оптимизаций и небольших изменений в api-для основных языков там больше ничего глобального не сделать.
«dataframe — пока юзайте, но учтите, что основные изменения у нас в sql, так что может и вам что от планировщика перепадет, но вообще лучше тоже двигайте в sql, там все оптимизации»
Хм, в презентациях посвящённых Catalyst использовался, вполне себе dataframe-api и не было sql. Ну и потом, они же взаимозаменяемы и оптимизация будет одинаковой, если посмотреть доклад про внутреннее устройство оптимизатора тут, то становится понятно что нет разницы между SparkSql, DataFrame-api, ну и DataSet-там тоже перепадёт.
>> Очевидно от микробатчей никуда сейчас не деться
да, немного улучшили, но главная позиция именно в «вам честный стриминг не нужен» и как результат мы имеем
http://beam.incubator.apache.org/capability-matrix/
причем для 2.0 спарка почти ничего не меняется
>> У вас есть какие-то предложения по их развитию
как минимум были предложения по https://github.com/amplab/spark-indexedrdd и которые местами мне интересны, в качестве быстрого распределенного хранилища, без необходимости тянуть сбоку imdb + получаем и локальность вычислений
>> Хм, в презентациях посвящённых Catalyst использовался, вполне себе dataframe-api и не было sql. Ну и потом, они же взаимозаменяемы и оптимизация будет одинаковой
не могут быть они полностью взаимозаменяемые, так как в dataframe как и у rdd хватает терминальных операций, а sql может состоять из нескольких слоев и проще выполнять push down для предикатов. с sql у нас на руках весь план запросов имеется. хотя для простых запросов действительно функционально одинаковы sql vs dataframe.
p.s. и самый простой вопрос который мне нравится к спарку: данные у меня приходят пускай и условно равномерно, но бывают всплески, как мне гарантировать что в какой-то момент я не захлебнусь? у того же beam/dataflow для окна есть тригеры по объему, что мне делать в этом случае со спарком, который не позволяет управлять размером очередного батча
да, немного улучшили, но главная позиция именно в «вам честный стриминг не нужен» и как результат мы имеем
http://beam.incubator.apache.org/capability-matrix/
причем для 2.0 спарка почти ничего не меняется
>> У вас есть какие-то предложения по их развитию
как минимум были предложения по https://github.com/amplab/spark-indexedrdd и которые местами мне интересны, в качестве быстрого распределенного хранилища, без необходимости тянуть сбоку imdb + получаем и локальность вычислений
>> Хм, в презентациях посвящённых Catalyst использовался, вполне себе dataframe-api и не было sql. Ну и потом, они же взаимозаменяемы и оптимизация будет одинаковой
не могут быть они полностью взаимозаменяемые, так как в dataframe как и у rdd хватает терминальных операций, а sql может состоять из нескольких слоев и проще выполнять push down для предикатов. с sql у нас на руках весь план запросов имеется. хотя для простых запросов действительно функционально одинаковы sql vs dataframe.
p.s. и самый простой вопрос который мне нравится к спарку: данные у меня приходят пускай и условно равномерно, но бывают всплески, как мне гарантировать что в какой-то момент я не захлебнусь? у того же beam/dataflow для окна есть тригеры по объему, что мне делать в этом случае со спарком, который не позволяет управлять размером очередного батча
Sign up to leave a comment.
Spark Summit 2016: обзор и впечатления