Хеши MD5 или SHA, вычисляется по бизнес-ключам. Это когда данные грузятся из Staging в DV. В витринах - используются те же хеши или суррогатные ключи, создаваемые при переносе данных в витрины.

Меняются. Поэтому в DV загружаем как есть, и дальше - со знанием что на что поменялось - связываем два объекта в интегрированной части DV. Все равно что было два каталога продуктов в двух разных системах, их дедуплицировали.

Вы правы. Он короткий и уязвимый как криптографичный, поэтому и будет deprecated.
Коллеги использовали google CityHash и FarmHash, понравилось - быстро и мало коллизий.

Генерация последовательности суррогатных ключей - это однопоточная операция. Следовательно, схема ETL\ELT подстравиватеся под эту парадигму - грузим данные объекта строго в один поток, обеспечиваем синхронизации и блокировки. Загрузки - делаем в порядке графа зависимостей (не обязательно, но технику early arriving data почему-то не любят), hubs -> satellites links или anchors -> ties. Сложно в исполнении, долго работает, нужно делать поиск по справочнику bus key -> id.
Или - используем хеши. Единственное усложнение - проверяем в процессе загрузки на возможную коллизию, если она случилась - генерируем хеш еще раз и снова проверяем, пока хеш не станет уникальным. Факты коллизий и их решений записываем в специальные таблицы рядом. По опыту - в таких таблицах не было более 5 записей на 10^10 оригинальных.