M
главное имплиситов поменьше
Size: a a a
2020 May 28
ПФ
главное имплиситов поменьше
там нету имплиситов, поэтому их ровно 0 :)
2020 May 29
ПФ
@pomadchin я благодаря @ivrudnev имею теперь идеальный репродьюсер на скале
spark.conf.set("spark.sql.codegen.wholeStage", false)
Seq(1.asInstanceOf[Integer], null.asInstanceOf[Integer], 3.asInstanceOf[Integer]).toDS().map(v=>(v,v)).show()ПФ
интересно, а как часто используются Dataset, по моей практике, если наберется 5%, то уже хорошо, rdd чаще используется
Как только я понял, что я не могу нормально напистаь джойн на сырых датафреймах — я начал использовать датасеты.
И чтобы избежать моей ошибки при работе с джойнами в Kotlin API уже учтена наллабилити — что при leftJoin справа может быть null
И чтобы избежать моей ошибки при работе с джойнами в Kotlin API уже учтена наллабилити — что при leftJoin справа может быть null
AS
Как только я понял, что я не могу нормально напистаь джойн на сырых датафреймах — я начал использовать датасеты.
И чтобы избежать моей ошибки при работе с джойнами в Kotlin API уже учтена наллабилити — что при leftJoin справа может быть null
И чтобы избежать моей ошибки при работе с джойнами в Kotlin API уже учтена наллабилити — что при leftJoin справа может быть null
а что значит нормально, когда делаем join на датасетах мы получаем два тупла, когда делаем на датафреймах, это объединение информации, как в sql
ПФ
а что значит нормально, когда делаем join на датасетах мы получаем два тупла, когда делаем на датафреймах, это объединение информации, как в sql
На датасетах мы получаем тупл (когда используем joinWith), а вот на датафреймах мы получаем датафрейм )
И вот у тебя три подряд джойна и внутри никакого автодополнения, непонятно как обращаться к полям вообще, приходится экспериментально подбирать магические строки если какие-то датафреймы были неименованными… В общем много боли, которую я не смог превзойти.
И вот у тебя три подряд джойна и внутри никакого автодополнения, непонятно как обращаться к полям вообще, приходится экспериментально подбирать магические строки если какие-то датафреймы были неименованными… В общем много боли, которую я не смог превзойти.
AZ
На датасетах мы получаем тупл (когда используем joinWith), а вот на датафреймах мы получаем датафрейм )
И вот у тебя три подряд джойна и внутри никакого автодополнения, непонятно как обращаться к полям вообще, приходится экспериментально подбирать магические строки если какие-то датафреймы были неименованными… В общем много боли, которую я не смог превзойти.
И вот у тебя три подряд джойна и внутри никакого автодополнения, непонятно как обращаться к полям вообще, приходится экспериментально подбирать магические строки если какие-то датафреймы были неименованными… В общем много боли, которую я не смог превзойти.
Тут основной вопрос насколько работа с данными в Spark декларативное и насколько императивное программирование. Грубо говоря все, что ты пишешь это боль, но правда и то, что люди научились её не замечать годами, работая на sql и падая в рантайм
ПФ
Тут основной вопрос насколько работа с данными в Spark декларативное и насколько императивное программирование. Грубо говоря все, что ты пишешь это боль, но правда и то, что люди научились её не замечать годами, работая на sql и падая в рантайм
С моей точки зрения непонятно зачем писать на детефреймах потому что есть же SQL для которого тоже есть автодополнение хотя бы табличек внутри запроса и при этом его знают типа все и грамматика у него суперпредсказуемая и можно делать интересные штуки типа
В спарковой грамматике это не очень тривиально пишется, а на SQL это хоть дерево напишет
FROM A a JOIN B b ON b.id=a.user_id JOIN C c ON a.id=c.some_id AND b.id=c.author_id. В спарковой грамматике это не очень тривиально пишется, а на SQL это хоть дерево напишет
M
ну иногда вопрос в том что предпочтительнее - удобство написания без магии или чтобы оно быстро работало
ПФ
Причём SQL ещё и читается проще
ПФ
ну иногда вопрос в том что предпочтительнее - удобство написания без магии или чтобы оно быстро работало
Кстати, а есть какие-то бенчмарки, которые показывают что датасеты быстрее? Я такое слышал, но сам построить бенчмарк не могу потому что не понимаю как
M
не думаю что бенчмарки будут в пользу датасетов
M
хотя если под тангстеном
ПФ
Да не очень понятно. У тебя весь маппинг по сути на нативных UDF'ках же.
N
с чего вдруг они должны быть как-то заметно быстрее.
D
типа больше магии в sql навернуть при оптимизации можно)
D
но лично мне на датасетах интефейс приятнее, чем сикуль
AZ
Причём SQL ещё и читается проще
Есть люди с sql дислексией
N
про магию это общие слова. магии больше можно навернуть как раз в SQL
D
да именно в нем больше