Не совсем такой же, все же с минимальными различиями

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

Например?

Можно юдф использовать в скл, для этого её надо зарегистрировать

Из последнего что помню, при записи разные права на чтение

Не очень понимаю о чем ты
Разные права на чтение для кого?

С трудом. Но дорабатывали 😅 а потом на промежуточные таблички нарезали. На оракле дело было.

Экстремистская тема какая-то

почему, на проекте витрины из 5000 строк, никто не выжил? 😂

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

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

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

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

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

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

Всем привет. Вот такой вопрос. В RDD есть понятие known partitioner. И в джойнах одинаковые известные партишенеры не приводят к пересылкам. Но я никак не помогу понять, работает ли эта терминология для датафреймов? Поэкспериментировав понимаю, что вроде бы нет, Exchange оператору как будто бы плевать на это дело и опять же неясно, как вообще можно сравнить партишенеры двух датафреймов

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

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

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

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

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

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

@pklemenkov
https://spark.apache.org/releases/spark-release-3-1-1.html

раздел Performance Enhancements