Сообщение Re[6]: Оптимизация работы с sql от 04.01.2024 3:56
Изменено 04.01.2024 4:20 MaximVK
Re[6]: Оптимизация работы с sql
Здравствуйте, Gt_, Вы писали:
Мда, апломба много, а знаний ноль.
Ну поехали...
Gt_>именно тут спарк идеален, ты просто совсем нулевый как я погляжу.
Боюсь, что нулевый у нас тут ты, судя по тому что ты пишешь.
Одна вот эта фраза выдает полную неграмотность в вопросе: "как бонус сумасшедшая параллельность, которую клик думаю любит". Ты понимаешь, что у тебя полная бредятина написана?
Или нужно объяснить?
Gt_>а зрение давно проверял ? ты явно не на спарк смотрел.
спишем хамство на твою невоспитанность
Gt_>спарк ничего не транслиует,
Да ладно?!
Открываем документацию и внимательно читаем про то как работают push downs и pruning
Также внимательно изучаем спецификацию DataSource V2
Также открываем для себя df.explain() и с изумлением смотрим на pushedFilters, pushedAggregates и даже pushedJoins
Gt_>спарк вычитывает в свой датафрейм
Еще одна глупость. Спарк как раз и был построен, чтобы можно было загрузку данных абстрагировать от логики расчетов.
1) Задумчиво читаем про RDD. Dataframe — это абстракция более высокого уровня построенная поверх RDD. С более-менее боевыми задачами на одних датафреймах не уедешь.
2) Ознакомившись с RDD внимательно читаем про то, что такое dataframe и в качестве продвинутого топика про catalyst.
Если на пальцах то пайплайн такой:
1. строиться логический план
2. план оптимизируется
3. строится физический план (тут как раз появляются push downs)
4. генерация кода
5. запуск
6. сбор результатов
Датафрейм — это не контейнер для данных.
При создании датафрейма и описания трансформаций никакой загрузки данных не происходит.
Gt_>и вся магия происходит в его jvm.
Чего?! какой еще "его jvm"? у спарка нет никакого "своего jvm".
Можно говорить, что для спарка будет лучше — грааль или хотспот — и в каких случаях.
Ну и с магией — это в Хогвартс. В спарке инженерно все понятно.
Gt_>клик для спарка просто тупой сторидж, мало чем отличающийся от S3.
Ну это же полная ахинея. Я даже не понимаю, с какого конца начать, чтобы объяснить.
Это как сказать, что для спарка Oracle — это как HDD
Ну еще можно было бы сказать Спарку все равно, что parquet файл на S3 или Clickhouse. Это, конечно, тоже бред, но намного меньший.
В этом случае можно просто открыть доку по различным коннекторам и обнаружить, что они, внезапно, предоставляют разные возможности и спарк с ними будет работать по разному. Опять таки, отсылаю к чтению спеки по DataSource V2
Gt_>scala умирает уже достаточно давно, может даже уже и не живая.
Держите меня семеро. А ничего, что сам спарк написан на скале и скала рекомендованный язык для спарка?
Для простых задач можно выжить с pyspark-ом, но на более-менее серьезном процессинге альтернативы Scala уже не будет. Можно, конечно, на java, но это прямо скажем так себе язык для работы с data. Ну и почитай еще что Захария пишет.
Gt_>вобщем почитай концепции, попробуй вникнуть, где происходит магия и 100 раз подумай, прежде чем запихивать логику в тормозные udf
Ты сейчас комментируешь какие-то свои иллюзии, а не то, что я писал. У меня логика не живет в udf, но лишь по той причине, что спарком я пользуюсь на скале.
А вот в питоне есть pandas udf, которые построены поверх apache arrow и если udf можно векторизировать, то будет работать очень шустро.
Поэтому и тут ты тоже плаваешь.
Суммируя:
Так громко и с размаху сесть в лужу — это надо постараться.
Поэтому иди и тренируйся на заднем дворе. Буду вопросы — приходи.
Не благодари
Мда, апломба много, а знаний ноль.
Ну поехали...
Gt_>именно тут спарк идеален, ты просто совсем нулевый как я погляжу.
Боюсь, что нулевый у нас тут ты, судя по тому что ты пишешь.
Одна вот эта фраза выдает полную неграмотность в вопросе: "как бонус сумасшедшая параллельность, которую клик думаю любит". Ты понимаешь, что у тебя полная бредятина написана?
Или нужно объяснить?
Gt_>а зрение давно проверял ? ты явно не на спарк смотрел.
спишем хамство на твою невоспитанность
Gt_>спарк ничего не транслиует,
Да ладно?!
Открываем документацию и внимательно читаем про то как работают push downs и pruning
Также внимательно изучаем спецификацию DataSource V2
Также открываем для себя df.explain() и с изумлением смотрим на pushedFilters, pushedAggregates и даже pushedJoins
Gt_>спарк вычитывает в свой датафрейм
Еще одна глупость. Спарк как раз и был построен, чтобы можно было загрузку данных абстрагировать от логики расчетов.
1) Задумчиво читаем про RDD. Dataframe — это абстракция более высокого уровня построенная поверх RDD. С более-менее боевыми задачами на одних датафреймах не уедешь.
2) Ознакомившись с RDD внимательно читаем про то, что такое dataframe и в качестве продвинутого топика про catalyst.
Если на пальцах то пайплайн такой:
1. строиться логический план
2. план оптимизируется
3. строится физический план (тут как раз появляются push downs)
4. генерация кода
5. запуск
6. сбор результатов
Датафрейм — это не контейнер для данных.
При создании датафрейма и описания трансформаций никакой загрузки данных не происходит.
Gt_>и вся магия происходит в его jvm.
Чего?! какой еще "его jvm"? у спарка нет никакого "своего jvm".
Можно говорить, что для спарка будет лучше — грааль или хотспот — и в каких случаях.
Ну и с магией — это в Хогвартс. В спарке инженерно все понятно.
Gt_>клик для спарка просто тупой сторидж, мало чем отличающийся от S3.
Ну это же полная ахинея. Я даже не понимаю, с какого конца начать, чтобы объяснить.
Это как сказать, что для спарка Oracle — это как HDD
Ну еще можно было бы сказать Спарку все равно, что parquet файл на S3 или Clickhouse. Это, конечно, тоже бред, но намного меньший.
В этом случае можно просто открыть доку по различным коннекторам и обнаружить, что они, внезапно, предоставляют разные возможности и спарк с ними будет работать по разному. Опять таки, отсылаю к чтению спеки по DataSource V2
Gt_>scala умирает уже достаточно давно, может даже уже и не живая.
Держите меня семеро. А ничего, что сам спарк написан на скале и скала рекомендованный язык для спарка?
Для простых задач можно выжить с pyspark-ом, но на более-менее серьезном процессинге альтернативы Scala уже не будет. Можно, конечно, на java, но это прямо скажем так себе язык для работы с data. Ну и почитай еще что Захария пишет.
Gt_>вобщем почитай концепции, попробуй вникнуть, где происходит магия и 100 раз подумай, прежде чем запихивать логику в тормозные udf
Ты сейчас комментируешь какие-то свои иллюзии, а не то, что я писал. У меня логика не живет в udf, но лишь по той причине, что спарком я пользуюсь на скале.
А вот в питоне есть pandas udf, которые построены поверх apache arrow и если udf можно векторизировать, то будет работать очень шустро.
Поэтому и тут ты тоже плаваешь.
Суммируя:
Так громко и с размаху сесть в лужу — это надо постараться.
Поэтому иди и тренируйся на заднем дворе. Буду вопросы — приходи.
Не благодари
Re[6]: Оптимизация работы с sql
Здравствуйте, Gt_, Вы писали:
Мда, апломба много, а знаний ноль.
Ну поехали...
Gt_>именно тут спарк идеален, ты просто совсем нулевый как я погляжу.
Боюсь, что нулевый у нас тут ты, судя по тому что ты пишешь.
Одна вот эта фраза выдает полную неграмотность в вопросе: "как бонус сумасшедшая параллельность, которую клик думаю любит". Ты понимаешь, что у тебя полная бредятина написана?
Или нужно объяснить?
Gt_>а зрение давно проверял ? ты явно не на спарк смотрел.
спишем хамство на твою невоспитанность
Gt_>спарк ничего не транслиует,
Да ладно?!
Открываем документацию и внимательно читаем про то как работают push downs и pruning
Также внимательно изучаем спецификацию DataSource V2
Также открываем для себя df.explain() и с изумлением смотрим на pushedFilters, pushedAggregates и даже pushedJoins
Gt_>спарк вычитывает в свой датафрейм
Еще одна глупость. Спарк как раз и был построен, чтобы можно было загрузку данных абстрагировать от логики расчетов.
1) Задумчиво читаем про RDD. Dataframe — это абстракция более высокого уровня построенная поверх RDD. С более-менее боевыми задачами на одних датафреймах не уедешь.
2) Ознакомившись с RDD внимательно читаем про то, что такое dataframe и в качестве продвинутого топика про catalyst.
Если на пальцах то пайплайн такой:
1. строиться логический план
2. план оптимизируется
3. строится физический план (тут как раз появляются push downs)
4. генерация кода
5. запуск
6. сбор результатов
Датафрейм — это не контейнер для данных.
При создании датафрейма и описания трансформаций никакой загрузки данных не происходит.
Gt_>и вся магия происходит в его jvm.
Чего?! какой еще "его jvm"? у спарка нет никакого "своего jvm".
Можно говорить, что для спарка будет лучше — грааль или хотспот — и в каких случаях.
Ну и с магией — это в Хогвартс. В спарке инженерно все понятно.
Gt_>клик для спарка просто тупой сторидж, мало чем отличающийся от S3.
Ну это же полная ахинея. Я даже не понимаю, с какого конца начать, чтобы объяснить.
Это как сказать, что для спарка Oracle — это как HDD
Ну еще можно было бы сказать для спарк не делает разницы между, скажем, parquet файлом на S3 и Clickhouse. Это, конечно, тоже бред, но намного меньший.
В этом случае можно просто открыть доку по различным коннекторам и обнаружить, что они, внезапно, предоставляют разные возможности и спарк с ними будет работать по разному. Опять таки, отсылаю к чтению спеки по DataSource V2
Gt_>scala умирает уже достаточно давно, может даже уже и не живая.
Держите меня семеро. А ничего, что сам спарк написан на скале и скала рекомендованный язык для спарка?
Для простых задач можно выжить с pyspark-ом, но на более-менее серьезном процессинге альтернативы Scala уже не будет. Можно, конечно, на java, но это прямо скажем так себе язык для работы с data. Ну и почитай еще что Захария пишет.
Gt_>вобщем почитай концепции, попробуй вникнуть, где происходит магия и 100 раз подумай, прежде чем запихивать логику в тормозные udf
Ты сейчас комментируешь какие-то свои иллюзии, а не то, что я писал. У меня логика не живет в udf, но лишь по той причине, что спарком я пользуюсь на скале.
А вот в питоне есть pandas udf, которые построены поверх apache arrow и если udf можно векторизировать, то будет работать очень шустро.
Поэтому и тут ты тоже плаваешь.
Суммируя:
Так громко и с размаху сесть в лужу — это надо постараться.
Поэтому иди и тренируйся на заднем дворе. Буду вопросы — приходи.
Не благодари
Мда, апломба много, а знаний ноль.
Ну поехали...
Gt_>именно тут спарк идеален, ты просто совсем нулевый как я погляжу.
Боюсь, что нулевый у нас тут ты, судя по тому что ты пишешь.
Одна вот эта фраза выдает полную неграмотность в вопросе: "как бонус сумасшедшая параллельность, которую клик думаю любит". Ты понимаешь, что у тебя полная бредятина написана?
Или нужно объяснить?
Gt_>а зрение давно проверял ? ты явно не на спарк смотрел.
спишем хамство на твою невоспитанность
Gt_>спарк ничего не транслиует,
Да ладно?!
Открываем документацию и внимательно читаем про то как работают push downs и pruning
Также внимательно изучаем спецификацию DataSource V2
Также открываем для себя df.explain() и с изумлением смотрим на pushedFilters, pushedAggregates и даже pushedJoins
Gt_>спарк вычитывает в свой датафрейм
Еще одна глупость. Спарк как раз и был построен, чтобы можно было загрузку данных абстрагировать от логики расчетов.
1) Задумчиво читаем про RDD. Dataframe — это абстракция более высокого уровня построенная поверх RDD. С более-менее боевыми задачами на одних датафреймах не уедешь.
2) Ознакомившись с RDD внимательно читаем про то, что такое dataframe и в качестве продвинутого топика про catalyst.
Если на пальцах то пайплайн такой:
1. строиться логический план
2. план оптимизируется
3. строится физический план (тут как раз появляются push downs)
4. генерация кода
5. запуск
6. сбор результатов
Датафрейм — это не контейнер для данных.
При создании датафрейма и описания трансформаций никакой загрузки данных не происходит.
Gt_>и вся магия происходит в его jvm.
Чего?! какой еще "его jvm"? у спарка нет никакого "своего jvm".
Можно говорить, что для спарка будет лучше — грааль или хотспот — и в каких случаях.
Ну и с магией — это в Хогвартс. В спарке инженерно все понятно.
Gt_>клик для спарка просто тупой сторидж, мало чем отличающийся от S3.
Ну это же полная ахинея. Я даже не понимаю, с какого конца начать, чтобы объяснить.
Это как сказать, что для спарка Oracle — это как HDD
Ну еще можно было бы сказать для спарк не делает разницы между, скажем, parquet файлом на S3 и Clickhouse. Это, конечно, тоже бред, но намного меньший.
В этом случае можно просто открыть доку по различным коннекторам и обнаружить, что они, внезапно, предоставляют разные возможности и спарк с ними будет работать по разному. Опять таки, отсылаю к чтению спеки по DataSource V2
Gt_>scala умирает уже достаточно давно, может даже уже и не живая.
Держите меня семеро. А ничего, что сам спарк написан на скале и скала рекомендованный язык для спарка?
Для простых задач можно выжить с pyspark-ом, но на более-менее серьезном процессинге альтернативы Scala уже не будет. Можно, конечно, на java, но это прямо скажем так себе язык для работы с data. Ну и почитай еще что Захария пишет.
Gt_>вобщем почитай концепции, попробуй вникнуть, где происходит магия и 100 раз подумай, прежде чем запихивать логику в тормозные udf
Ты сейчас комментируешь какие-то свои иллюзии, а не то, что я писал. У меня логика не живет в udf, но лишь по той причине, что спарком я пользуюсь на скале.
А вот в питоне есть pandas udf, которые построены поверх apache arrow и если udf можно векторизировать, то будет работать очень шустро.
Поэтому и тут ты тоже плаваешь.
Суммируя:
Так громко и с размаху сесть в лужу — это надо постараться.
Поэтому иди и тренируйся на заднем дворе. Буду вопросы — приходи.
Не благодари