ИК
так ведь за это и борются)
Size: a a a
2021 October 21
OI
т.е. классической проблемы python_udf, когда мы берём строку, серриализуем в питон, обрабатываем, отдаём, серриализуем обратно и всё это последовательно, можно сказать, нет)
AZ
там есть еще довод от первичности колоночного хранения - в большинстве колоночных систем вы получаете данные на клиента в строковом виде, даже если никаких преобразований не было
нужен колоночно-нативный интерфейс для клиентов
нужен колоночно-нативный интерфейс для клиентов
ЕГ
Вроде как спарк учится с этим работать
ИК
Так получается, в пайплайне можно сканить и транформить сколько угодно паркетов с ограниченным выделением памяти? И почти zero copy на сер-десер?
GP
they say да
GP
И весь профит уже засчет того что все твои паркеты мемори мапед файлы
GP
Это все ещё копи просто ты сразу не копишь все и не двигаешь прочтённые байты никак
ИК
круто, чо))
GP
Ас ис лоадишь
GP
Но там ограничения есть
GP
GP
типо нанов незя в паркете
GP
Что-то ещё
GP
но даж с нанами там какой-то компат
GP
чето я хотел разобраться а потом время улетело и другим пришлось заниматься
GP
Там у них ещё плазма продукт есть интересный
t
Использовал в свое время - если в кратце, то эрроу батчики не нужно десереализовывать перед работой с ними - то есть принял по сети и у тебя готовые данные. Другое дело, что для максимальной эффективности все должны уметь его нативно использовать
t
там не построчно передается емнип
t
даже на обычных python udf