Тогда, наверное, проще всего смотреть на количество партиций (это партиции спарк джоба, а не таблицы) в хранилище (df.rdd.getNumPartitions()) и сделать repartition обоих наборов данных по ключам join по этому количеству партиций

Но решение догружать инкремент с join'ом на всё хранилище мне не нравится. Каждый следующий запуск будет дольше предыдущего. Может быть грузить всё (raw), а после выполнить дедубликацию в хранилище (ods)?

@pomadchin @krivdathetriewe

Коллеги, а подскажите, кто в России читает хорошие Advanced курсы по Spakу,  для корпоративного обучения (интересует именно Advanced, а не вводный курс)?

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

Яцека выпишите )

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

Он на smartdata будет как раз, идеальный момент чтобы за него зацепиться

Спасибо, расмотрим, хорошее предложение!

А когда Смартдата?

С 9 по 12 декабря. 4 дня, 4 трека по два доклада

Согласен, но для корпоративного обучения надо бы курсы.

Ага, понял, сенкс.

Драфт программы опубликован уже, кстати

Там ещё будет @tenKe, тоже про Спарк, например.

Ага, спасибо, я знаю.

Сейчас, чувствую, хорошо будет

Выделить инкремент через join-очень дорогая операция, даже если, как по учебнику, это две бакетированые и сортированные таблицы.

Я советую пойти более дешёвым путем, а именно, найти поле, которое монотонно возрастает. Сохранить его максимальное полученное значение. И сделать фильтр по условию {поле > последнее наибольшее значение}. Это проверенная, можно сказать, классическая техника выделения инкремента, имеющая линейное время выполнения на любом наборе данных.

Если персистить последнее значение невозможно, то находите max({поле из снепшота}) и кидайте в условие фильтра. Все равно быстрее, чем join

Так и делаем