e
Предположу, что на sql стриминг ты никак не завернешь., в то время как в рамках спарка пожалуйста. Да и вообще здесь разговор о двух разных подходах ETL и ELT
про стримминг , да занес в мемо , спасибо )
Size: a a a
2021 April 01
A
Предположу, что на sql стриминг ты никак не завернешь., в то время как в рамках спарка пожалуйста. Да и вообще здесь разговор о двух разных подходах ETL и ELT
почему нет?
флинк в стриминг на sql умеет
спарк в стриминг на sql умеет
флинк в стриминг на sql умеет
спарк в стриминг на sql умеет
АА
почему нет?
флинк в стриминг на sql умеет
спарк в стриминг на sql умеет
флинк в стриминг на sql умеет
спарк в стриминг на sql умеет
Я так понял мы обсуждаем голый sql и использование спарка с df. Или здесь про подход low code?
A
Нет, чем лучше df vs sql
В пределах спарка
В пределах спарка
VS
@essbase а у тебя щас sql код где?
VS
spark sql или голый?
AK
Только удобочитабельный код. Гораздо удобнее прочитать 200 строк датафреймов, чем сиквела
Если начинается множество преобразований, высчитывание всяких математических вещей, то в сиквеле можно состариться
Если начинается множество преобразований, высчитывание всяких математических вещей, то в сиквеле можно состариться
Гораздо удобнее прочитать 200 строк sql, чем датафреймов. Вопрос привычки)
С
Гораздо удобнее прочитать 200 строк sql, чем датафреймов. Вопрос привычки)
И эти 200 строк sql кода будут равны 20 строкам датафрейма
AK
Сюткин
И эти 200 строк sql кода будут равны 20 строкам датафрейма
Ты диск экономишь?..
IS
Гораздо удобнее прочитать 200 строк sql, чем датафреймов. Вопрос привычки)
Если это селекты - может удобнее, а если преобразования, джоины, то сомневаюсь)
С
Ты диск экономишь?..
20 строк прочитать удобнее чем 200
AK
Вопрос привычки.
АА
Ну в таком случае можно сказать, что ты полностью отказываешься и от привилегий ООП и ФП, а ограничиваешься только тем, что дает тебе синтаксис spark sql. И тут еще вопрос, мало использовал spark sql, в рамках него можно вызвать udf?
AK
Сюткин
20 строк прочитать удобнее чем 200
И ваще, давай пруфы такого sql, который из 200 строк превращается в 20)
С
И ваще, давай пруфы такого sql, который из 200 строк превращается в 20)
АА
Знаю, что udf зло, но можно ли вообще как либо расширить функционал объявленый в spark sql?
AK
Знаю, что udf зло, но можно ли вообще как либо расширить функционал объявленый в spark sql?
Не зло, если на скале)
С
И ваще, давай пруфы такого sql, который из 200 строк превращается в 20)
Я тут cnum как-то год назад переписывал, с sql, ужался код раза в 2.5
С
Но это не показатель
VS
Гораздо удобнее прочитать 200 строк sql, чем датафреймов. Вопрос привычки)
Ключевое слово "привычки" :))
Мой кейс:
под задачи BI в компании накатал за пару дней витринку, ничего сложного: простые агрегации, конвертация валют и с десяток простых бизнесовых метрик.
Тема настолько зашла, что в течение следующих 1.5 месяцев ко мне почти каждый день приходили и просили добавить "всего лишь ещё один" расчётный показатель. В итоге sql-код стал простынкой из >500 строк, и не смотря на то, что я старался соблюдать принципы модульности с кучей with () as, никто кроме меня и ребят из моей команды, которые приложили руку, разобраться в нём, не то чтобы не может, а просто не хочет.
Пример: понадобилось добавить расчёт кумулятивной суммы метрики. В df это можно сделать просто поменяв sum на cumsum. В sql не так, нужно извращаться. Попробовав наиболее распространённый рецепт - получили падение производительности на 2 порядка. План запроса для такой простыни, как вы понимаете отдаёт другую нечитаемую простыню. На просьбу к нашему dba-щику помочь, он посмотрел на нашу простыню, перекрестился и теперь просто обходит нас стороной.
Каждая новая мелкая доработка стала очень дорогой и стрёмной, почти всегда ломающей, то что уже работало. Продебажить классическими средствами нельзя. Юнит-тестов нет, потому что нет юнитов, короче кошмар.
В итоге застопил все тикеты на доработку и медитативно переписываем всё на df
Мой кейс:
под задачи BI в компании накатал за пару дней витринку, ничего сложного: простые агрегации, конвертация валют и с десяток простых бизнесовых метрик.
Тема настолько зашла, что в течение следующих 1.5 месяцев ко мне почти каждый день приходили и просили добавить "всего лишь ещё один" расчётный показатель. В итоге sql-код стал простынкой из >500 строк, и не смотря на то, что я старался соблюдать принципы модульности с кучей with () as, никто кроме меня и ребят из моей команды, которые приложили руку, разобраться в нём, не то чтобы не может, а просто не хочет.
Пример: понадобилось добавить расчёт кумулятивной суммы метрики. В df это можно сделать просто поменяв sum на cumsum. В sql не так, нужно извращаться. Попробовав наиболее распространённый рецепт - получили падение производительности на 2 порядка. План запроса для такой простыни, как вы понимаете отдаёт другую нечитаемую простыню. На просьбу к нашему dba-щику помочь, он посмотрел на нашу простыню, перекрестился и теперь просто обходит нас стороной.
Каждая новая мелкая доработка стала очень дорогой и стрёмной, почти всегда ломающей, то что уже работало. Продебажить классическими средствами нельзя. Юнит-тестов нет, потому что нет юнитов, короче кошмар.
В итоге застопил все тикеты на доработку и медитативно переписываем всё на df