Кто-то должен начать)

Вы просто пессимисты. Я на спарке решаю задачу так. Приходит большой кусок данных. Я знаю что там немного изменений. Так же я знаю pk. Я беру хеш от pk  и разбиваю по партициям и полям с условием репартишн

Далее делаю hash inner join  where col<>col2 так получаю измененные хеши

Никто не говорил, что эта задача в хадупе и/или спарке не решается, scd2 накрутить достаточно просто. Речь о том, что там такие техники использовать дорого.

стоп, а где Тс спрашивал про цену?
в чем плюс спарка, это  один микроскоп на все шурупы.
когда приходит задача, я  ее просто делаю и получаю результат.
Если нужно быстрее, я просто говорю, сколько это будет стоить и бизнес уже решает, так ли ему надо  данные обновлять каждые 5 минут)

Перечитайте сообщения ТС, и увидите, что ее заботит стоимость решения, исходя из этого и дискуссия строилась.

Возможно я не прав, но  посыл был "использование нативных Spark, Hive и то что расчет дельт это неэффективно"
и мой ответ был, очень эффективно , главное железа побольше.
вот в кубер уйду , там вообще будут прерываемые машины ) поднял. посчитал. потушил )))

Ну смотря в сравнении с чем. С ничем-да, очень эффективно всё прочитать, поменять 2% и записать обратно. Но можно же и по-другому. Вот в лучшей в мире субд например можно написать merge into и она сама там внутри подбегает по цилиндрам с индексами и найдёт те 2% и их обновит, а остальные 98% не будет даже нюхать.

или провалится в фулскан индекса, и дай бог если это будет кластерный)
или дедлок поймает на параллельном апдейте

Зависит от объема этих 2%)

и вообще, можно сходить в соседние кликхаус, грунплам каналы, у них там тоже не медом намазано  😤

тут понимаешь какая история, индексы специально так делают, чтобы их можно было рендж-сканить, а даже если фуллсканить, то это все равно на порядки дешевле, чем читать с диска то, что они индексируют и писать его обратно.

А можно подробнее?
pk уникален, соот-но зачем по нему считать хеши? Чтобы на основе них разложить в бакеты? (но тогда нужно подбирать хеш, который генерирует максимум коллизий, получатся?)

Но потом речь идет про хеш джойн, а какой в нем смысл, если просто джойн по pk должен быть быстрее, так как он и уже индексирован (он же уникален) ?)  + у нас получается каскад из джойнов на каждую колонку в таблице? Т.е. col<>col2, потом col3<>col4 и т.д?

Или pk это не primary key и я не правильно вас понял?

В спарке особо нет понятия индексов

Спарк делает джойн, считая хэш по модулю числа тасков, чтоб раскидать данные с одним ключом на одну ноду

Можно руками это сделать, и потом быстрее джойнить

Т.е. речь о том, чтобы бакет из таблицы A, содержащий ключи в рейндже n до n+x, в идеале, оказался  на той же ноде, что и бакет из таблицы Б, содержащий те же ключи в рейндже от n до n+x? И внутри одной ноды эти 2 бакета отработать (Т.е. уже поколоночно сравнить)?

Рэнж бакет плохо, может быть неравномерное распределение данных

Хотя в спарке есть рэнж партишенер, но это так себе тема

Проще разбить по хэшу по модулю, это точно равномерно будет