Знаю, что udf зло, но можно ли вообще как либо расширить функционал объявленый в spark sql?

А что с производительностью SQL vs DF ?

500, ха. В моей жизни была витрина из порядка 5к строк 😅 вот там реально пздц был.

вроде как тот же сиквел побыстрее не?

вроде как тот же сиквел побыстрее не?

как дорабатывать, как дебажить?

Не зло, если на скале)

Когда ты пишешь на датафреймах, Спарк конвертит это в Спарк сиквел
Оне не становится быстрее, он такой же

Spark SQL имеет только одну нишу, когда вам нужно написать код для тех людей, которые не смогут потом его поддерживать в виде датафреймов)

Ключевое слово "привычки" :))

Мой кейс:
под задачи BI в компании накатал за пару дней витринку, ничего сложного: простые агрегации, конвертация валют и с десяток простых бизнесовых метрик.

Тема настолько зашла, что в течение следующих 1.5 месяцев ко мне почти каждый день приходили и просили добавить "всего лишь ещё один" расчётный показатель. В итоге sql-код стал простынкой из >500 строк, и не смотря на то, что я старался соблюдать принципы модульности с кучей with () as, никто кроме меня и ребят из моей команды, которые приложили руку, разобраться в нём, не то чтобы не может, а просто не хочет.

Пример: понадобилось добавить расчёт кумулятивной суммы метрики. В df это можно сделать просто поменяв sum на cumsum. В sql не так, нужно извращаться. Попробовав наиболее распространённый рецепт - получили падение производительности на 2 порядка. План запроса для такой простыни, как вы понимаете отдаёт другую нечитаемую простыню. На просьбу к нашему dba-щику помочь, он посмотрел на нашу простыню, перекрестился и теперь просто обходит нас стороной.

Каждая новая мелкая доработка стала очень дорогой и стрёмной, почти всегда ломающей, то что уже работало. Продебажить классическими средствами нельзя. Юнит-тестов нет, потому что нет юнитов, короче кошмар.

В итоге застопил все тикеты на доработку и медитативно переписываем всё на df

либо когда вы предоставляете конфигуряемые джобы

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

Удивился, поразился. Пошел перепроверять себя.


Вот данные актуальные на ноябрь 2019 года:

Normally to manipulate the data present a SQL database with Spark it is possible to exploit a custom UDF. However, as Adi Polak reminds us, use the higher-level standard column-based functions with dataset operators whenever possible before reverting to using your own custom UDF functions since UDFs are a blackbox for Spark and so it does not even try to optimise them.

Удивился, поразился. Пошел перепроверять себя.


Вот данные актуальные на ноябрь 2019 года:

Normally to manipulate the data present a SQL database with Spark it is possible to exploit a custom UDF. However, as Adi Polak reminds us, use the higher-level standard column-based functions with dataset operators whenever possible before reverting to using your own custom UDF functions since UDFs are a blackbox for Spark and so it does not even try to optimise them.

Когда ты пишешь на датафреймах, Спарк конвертит это в Спарк сиквел
Оне не становится быстрее, он такой же

udf зло в любом случае и на питоне и на скале
Просто на питоне намного больнее)