ЕГ
Так как это достаточно дорого получается на большом числе колонок
Size: a a a
2021 November 26
R
Имеешь в виду на большом числе строк?
R
И колонок наверное тоже
ЕГ
Не, rdd - это рядная структура, а dataframe - колоночная с пачками рядов, при вызове rdd требуется конвертация вроде как на текущий момент
ЕГ
Раньше не требовалась
R
Да. По сравнению с monotonically increasing id медленней, но все же конвертация происходит в параллель в разных тасках, поэтому скейлится норм. Я так понимаю ты в своем решении вычисляешь офсет в каждом партишене отдельно и прибавляешь? Не получится ли overflow при большом количестве загрузок?
ЕГ
Число партиций не может быть больше INT_MAX)
R
Я имею в виду представь что данные грузятся порциями и ты для каждой порции генеришь айдишки. В твоём варианте получаются огромные пробелы я так понимаю, не приведет ли это в итоге при складывании огромных офсетов, что ты из long диапазона вылезешь?
ЕГ
Не, иначе б монотоник сам не работал
ЕГ
Я вычитаю монотоники
ЕГ
Не складываю
R
А, это другое дело...надо будет глянуть поподробней... Ещё увидел что у тебя udf используется, не приведет ли это к десериализации всей строки как и в случае с rdd?
R
В принципе по времени, у нас на 200 миллионов строк вариант с rdd работал 2-3 минуты но колонок было поменьше
ЕГ
Да по идее не должно, udf над колонками работает вполне
ЕГ
Такими же пачками применяется
R
Думаешь он объект Row частично десереализует (одну колонку), применяет на нее udf и "всериализовывает" обратно?
R
Мне кажется всю строку фигачит
R
+ можно избавиться попробовать от udf если использовать spark_partition_id + .na.replace, но там конечно вопрос что случится при большом количестве партишенов
ИК
это вполне можно делать, я так делал с отдельными полями. И я при этом старался делать так же, как во встроенных функциях. Как в механизме вызова UDF сделано, не смотрел
R
+ мне кажется в твоём варианте будет две джобы из за коллекта, а zipWithUniqueId позволяет за одну сделать