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

Ну а дальше понятно - льём дифы, включаем морж он рид

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

если естественного ключа нет, то возможны варианты

Если нужно выбрать только новые и обновлённые записи из источника (а я так думаю, что именно с целой таблицей источником приходится сравнивать снепшот), то самый наивный способ - исключить существующие записи антиджоином по первичном ключу с обеих сторон
Source left anti join target on (primary, key, fields)
Union
Target left anti join source on (primary, key, fields)

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

если ключа нету, то проще всего хеш записи сравнивать

но эжто чудовищно неэффективно

Антиджоины можно заменить на union + groupBy primary, key, fields + having count(1)=1

Apache “чудовищно неэффективно” Spark

Чтобы сделать эффективнее, надо знать точнее, с чем нужно работать.
В идеале CDC должна приносить готовую дельту, только дедуплицировать, и чилить))

Можно просто MR

this

Обычно считалки дельты или снапшотов делаются полностью на метаданных один раз

Ребята, спасибо! Боюсь показаться профаном, но как поняла. Все это использование нативных Spark, Hive и то что расчет дельт это неэффективно. Однако, неужели эти новомодные фреймворки Delta Lake, Iceberg не спасают?

Дельта и друзья нужны для другой стороны, чтобы изменения можно было накатить и получить копию текущего состояния в источнике

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

Спасают, конечно. И кастомные фреймворки (как их ни назови), спасают. Но для такого их использования нужно разбираться, что менять, допиливать под свой use case. Скорее всего, проще и дешевле окажется пересмотреть архитектурное решение

если у вас привязка к спарку по требованиям, и нет иных вариантов, попробуйте как-то переформулировать задачу, чтобы подойти к ней с какой-то другой стороны

Мы пока на старте, поэтому рассматриваем все варианты. И тут либо  показываем, что построение дельт в виду архитектуры hadoop это дорого и больно и лучше пересмотреть архитектурное решение, либо ищем обходные пути