сделать ей внутри какую-то параллельность не выйдет, можно не стараться

как это решит проблему того что

3-20млн за 20 мин пишется
600млн за 2 часа 10мин

то есть если проводить параллели 600млн даже больше 2часов должна писаться

Ну вот я сейчас понял что похоже 600млн действительно не влезают в память, и начинается спил на диск, от этого деградация. Вот и думаю, что может как то нарезать ТОЛЬКО эти 600млн, может репартишн какой то сделать. И спускать быстрее.

нельзя сделать репартишен одной партиции
лучше с самого начала избавляться от skew

пока это невозможно)
Либо я не вижу как.
Очень простая витрина данных.
Товар*магазин*цена*дата старта*дата окончания.

И вот там где дата окончания 5999-01-01, (текущая активная цена). Идет сильный перекос.

А если партицию делать по дате старта. То получается более ровные партиции. Но витрина почти фулл перезаписывается каждый день. Потому что регулярно прилетают изменения цен, с датой старта от 2015года. На какой нить 1 коробок спичек... и все. Партицию переписывать.

значит солить дату при партицианировании и уже по ней делать партишининг

Типичный случай перекоса. Значение известно. Добавляем поле, которое будет functions.rand(30) для актуальных записей, 0 для всех остальных. Включаем его в repartition. Дропаем после репартишена. Это и есть «солить»

Интересное решение.

но можно на шафл нарваться, тк партиционирование поедет

ну можно ещё использовать 3.2 (тут adaptive включен по умолчанию) или 3.0/3.1 и включить adaptive переменной (он смержен был, но по дефолту не включен)

вроде как unskew там научились делать, но это не точно

Ваще наивное. Можно не добавлять поле, главное, чтобы это выражение было в репартишене. И само выражение может быть, например, датой старта для активных цен, датой окончания для прочих. Вариантов полно

ну, тут выбирать, или шафл или страглер. Я, обычно, за шафл. Да и образовался этот перекос, скорее всего, после какого-то шафла, так что чего уж тут бояться

Я не разработчик и не спарковод (хоть и понимаю о чем речь в целом). Просто данный перекос кажется мне +\- частым явлением. И интересен опыт как это порешать.

А в понедельник пойду уже разраба мучать. Тыкать его в ваши сообщения. И просить "сделать все как надо")

обычно все начинают солить

в случае databricks платформы у них было внутреннее расширение которое skew находит и делает автоматом разделение (по крайней мере они так заявляли, я не тестил)

Да, с интересом читал обсуждение тут выше. Жду, когда на 3 спарк будем переходить, и боюсь, что придётся переписывать движок, в котором и так уже много было сделано, чтобы не было перекосов и все файлики примерно одинаковые. С другой стороны, адаптив может стать намного более сильным средством, если его взять под контроль и научить использовать собранные статистики. В теории любой DAG можно сделать непадающим, было бы здорово!

в adaptive оптимизатор уже и его заявляет что умеет, но тоже пока не тестил, вскоре может скажу как он в деле, пока у нас вагон обвязки вокруг для этого