но работает быстрее, чем udf в питоне

ну то есть самое быстрое scala/java udf, потом pandas_udf, потом pyspark udf?

Не совсем - самое быстрое это org.apache.spark.sql.functions._ и SQL builtin functions, потом уже остальное

Ну и вот это тоже должно работать быстро:
https://databricks.com/session_eu20/optimizing-apache-spark-udfs

Народ, а кто в кишки лазил, вот помогите понять - происходит вот у нас шаффл. По идее, есть у нас буфер в execution memory, там происходит некий сортинг входной партиции. Далее, по достижении определенного лимита, данные спилятся на диск spill writer-ом в отдельный файл. Допустим, это произошло ещё несколько раз, после чего все прокрутилось, и файлы опять поднимаются в буфер, окончательно сортируются и мерджатся в один файл. Дальше эта шаффлд партиция отправляется на читку spill reader-у, который опять тащит блоки из нее в буфер и проводит похожую с spill writer-ом манипуляцию. Эта каша у меня в голове образовалась после прочтения нескольких разных источников и попытки немного полазить по сырцам. Помогите, пожалуйста, устранить кашу в голове:
1. Если говорить просто про шаффл - он вообще в состоянии произойти только в оперативной памяти, даже если данные входящей партиции помещаются в буфер, или же в любом случае будет промежуточные результаты  скидывать на диск?
2.  Если будет скидывать на диск все равно - то в чем вообще отличие шаффла со спиллом и без него?
3. Зачем spill reader ещё раз колбасит данные после spill wtiter-а?
4. Куда вообще сохраняет свои промежуточные результаты spill writer и spill reader (и shuffle writer ещё)? На датаноду локально, или в распределенное хранилище?

> 1. Если говорить просто про шаффл - он вообще в состоянии произойти только в оперативной памяти, даже если данные входящей партиции помещаются в буфер, или же в любом случае будет промежуточные результаты  скидывать на диск?
По идее если у тебя нет spill в описании стейджа, то шафл произошел в памяти и потом уехал на диски

попробуй какой нибудь маленький шафл сделать - там spill'а не будет

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

> 4. Куда вообще сохраняет свои промежуточные результаты spill writer и spill reader (и shuffle writer ещё)? На датаноду локально, или в распределенное хранилище?
локально, ведь спарк и без хдфс будет работать

Логично, да

>Я просто встречал точку зрения, что спарк в любом случае промежуточные бакеты куда-то на диск складывает и держит на протяжении существования джобы, чтобы рекомпьют не делать лишний раз, если что.
ты имеешь ввиду рекомпьют после репартишена?

если это - то данные шафла всегда на диск улетают в итоге

и это позволяет репартишен использовать типа как кеш в данном случае

Т.е. после каждой широкой трансформации весь шаффл сбрасывается на диск и продолжает там валяться, подгружаясь в ореративку по мере необходимости? И пока джоба не отбежит, так и будет там валяться, так? И, следовательно, шаффл со спиллом и без отличается только тем, что первый, т.к. не умещается в буфер, делает больше IO операций и больше грузит сеть, так?

>Т.е. после каждой широкой трансформации весь шаффл сбрасывается на диск и продолжает там валяться
да, и новый экшн над этим дф уже возьмет данные из файлов шафла

> И пока джоба не отбежит, так и будет там валяться, так?
да

> И, следовательно, шаффл со спиллом и без отличается только тем, что первый
шафл со спиллом это когда в процессе подготвки файла  шафла все настолько большое, что не влезает в память воркера и он спиллит данные на диск. В итоге да, оверхед на I/O в диск получается многократный

> больше грузит сеть, так?
а вот сеть по идее тут не аффектит

Но в этом случае все равно падает по памяти воркера

Почему-то