DZ
паковать джарку с спарком то еще удовольствие
Size: a a a
2021 November 26
SI
Наверное, assembly вообще удалю. В нашем проекте мы делаем assembly, потому что часто для сторонних спарк пакетов мы пакуем прямо в джарник его
SI
ну и без стратегии оно упадет
DZ
как я провел лето
A
Основное замечание было что стратегия куцая и неправильная
SI
Да, интро про то, зачем это вообще не помешает — спасибо
SI
Я могу честно признаться что
1. Я не шарю в sbt глубоко
2. Стратегия работает, если спарк паковать в сам джарник
3. Тот кусок я вообще уберу, видимо
1. Я не шарю в sbt глубоко
2. Стратегия работает, если спарк паковать в сам джарник
3. Тот кусок я вообще уберу, видимо
A
2. вы счастливчик и видимо у вас мало либ
DZ
2. вы скорее всего не запускаете свой код
SI
немало, просто в градле запаковкой занимается shadowJar, там оно по-другому описывается
SI
спасибо!
A
точно так же провайдеры для json/hadoop FileSystem и вагона всего описывается
и ваш discard/first поломает всё
и ваш discard/first поломает всё
A
поэтому services всегда своя стратегия
maven по дефолту делает concat
сбт умеет и дедупликацию строк после concat делать
maven по дефолту делает concat
сбт умеет и дедупликацию строк после concat делать
A
@ivanychev в грейдле это тоже нужно описывать, правда чуть по дргому, но там логика тоже понятна
https://github.com/johnrengelman/shadow/blob/master/src/docs/configuration/merging/README.md#merging-service-descriptor-files
https://github.com/johnrengelman/shadow/blob/master/src/main/groovy/com/github/jengelman/gradle/plugins/shadow/transformers/ServiceFileTransformer.groovy#L33-L40
https://github.com/johnrengelman/shadow/blob/master/src/docs/configuration/merging/README.md#merging-service-descriptor-files
https://github.com/johnrengelman/shadow/blob/master/src/main/groovy/com/github/jengelman/gradle/plugins/shadow/transformers/ServiceFileTransformer.groovy#L33-L40
РП
Господа Спарководы.
Спрошу вашего опыта.
Есть вот такие вводные данные. По записи данных Спарком в HIVE.
"1млрд в 150 партиций залился за 20 минут
600млн в одну партицию - 2 часа 10 минут"
Для меня это несколько странно. Но что можно придумать. Чтобы 1 единственную перекошенную партицию в 600млн записывать быстрее? (остальные партиции по 3-20млн строк)
Спрошу вашего опыта.
Есть вот такие вводные данные. По записи данных Спарком в HIVE.
"1млрд в 150 партиций залился за 20 минут
600млн в одну партицию - 2 часа 10 минут"
Для меня это несколько странно. Но что можно придумать. Чтобы 1 единственную перекошенную партицию в 600млн записывать быстрее? (остальные партиции по 3-20млн строк)
A
а что именно смущает?
паркет тот же самый порядочно памяти/cpu может жрать на записи
особенно если некоторые части не влазят в буфер в памяти и он начинает их спилить на диск
паркет тот же самый порядочно памяти/cpu может жрать на записи
особенно если некоторые части не влазят в буфер в памяти и он начинает их спилить на диск
РП
Ну может как то можно ее в процессе спуска нарезать?
ИК
надо сделать ей unskew)) Она не просто так образовалась, и надо локализовать этот этап и порубить партицию на несколько