но только я не знаю, где он реализован, а где нет)

в любом случае это доступ из 2х процессов в одну память, никто на такое не пойдёт

насколько помню только в fork норм это сделано (CoW памяти)

на чтение точно есть такая тема

но не факт, что udf не имеет права на запись в данные массивы

https://www.alibabacloud.com/blog/use-apache-arrow-to-assist-pyspark-in-data-processing_595299

по поводу магии передачи

ссылка класс👍

спасибо

в такие тонкости не углублялся, потому что фичи надо пилить)

Клустер опять "тормозит"

https://www2.cs.duke.edu/ari/trapeze/freenix/node6.html
а вот всё-таки и такое где-то есть)

сокеты с copy-on-write)

просто многие от спарка ожидают магии

сразу было tungsten решит наши проблемы так как будет кодогенерация, обещания были вплоть до нативного кода и запуска на gpu
закончилось генерацией java классов на лету, компиляцией их janino (для проверки что все ок), отправкой исходного кода на воркеры, там повторной компиляции, установки в класспас и выполнения

был pyspark, медленный как …., так как каждый объект сериализовался
потом ввели датафреймы которые на графиках показывали что чуть ли не быстрее скаловских датафреймов
НО это были тесты когда из питона вызывали агрегирующие функции и как таковое все выполнение в спарк рантайме было, как только нужно перегонять данные в питон процесс, то конечно со схемой уже чуть лучше, не нужно каждый объект отдельно сериализовать, но все равно данные гонять

появился arrow
опять обещания что вот уж на этот раз zero copy
закончилось как всегда …… чуть лучше с форматом, но данные так же гоняются

как исследовательский проект?
таких проектов вагон и маленькая тележка …. проблемы когда их в прод пытаются затянуть

ну, вот есть прод, надо отскорить 100млн абонентов

есть 30 дсов

которые гоняют бустец, нейросетки, применяют либы готовые

можно выкатить то, что получилось напилить, за несколько дней, с падением производительности в 2 раза

из-за копирования в сокете