Механизм выполнения MERGE

В данном разделе описана логика обновления данных при репликации данных в Google BigQuery посредством Renta ELT.

Требования к схеме данных

1. Уникальный ключ (обязательно).
   Требуется для идентификации и обновления записей. Поле ключа зависит от источника (например, Primary Key для PostgreSQL CDC или Lead ID для Salesforce). Спецификации уникальных ключей для каждого коннектора доступны в документации раздела Sources.
2. Ключ партицирования (опционально).
   Поле, по которому будет производиться физическое разделение данных (партицирование) в целевой таблице BigQuery.

Алгоритм репликации

Процесс слияния данных состоит из трех этапов:

1. Staging.
   Новые и измененные данные загружаются во временную таблицу BigQuery (формат нейминга: target_table_name_renta_temp).
2. Дедупликация.
   Внутри временной таблицы производится выборка актуальных состояний. Записи группируются по уникальному ключу и сортируются по timestamp (или иному системному параметру источника). В целевую таблицу передается только последняя версия строки.
3. Merge.
   Отфильтрованные данные из временной таблицы переносятся в целевую таблицу.

Влияние партицирования на производительность MERGE

Наличие ключа партицирования критически влияет на объем обрабатываемых данных и стоимость запроса:

1. С партицированием (рекомендуется).
   Операция MERGE затрагивает только те партиции целевой таблицы, данные для которых присутствуют во временной таблице. Это исключает лишнее чтение данных.
2. Без партицирования.
   BigQuery выполняет полное сканирование целевой таблицы. Для таблиц большого объема это приводит к снижению производительности и росту затрат.

Обработка удалений (deletes)

При удалении записей в источнике физическое удаление строк в BigQuery не производится. Renta применяет метод логического удаления (soft delete): для удаленной записи системное поле is_delete переводится в значение True.