Компания использует PostgreSQL как оперативную базу, ClickHouse для аналитики событий и BigQuery для части внешних данных. Как решить, где должны выполняться тяжёлые JOIN между этими источниками — на этапе ETL или на этапе запроса?

Короткий ответ

Сравните два плана по свежести, повторяемости, стоимости передачи, доступности и владельцу результата. Запрос, который выполняется для каждого открытия дашборда, не должен регулярно сканировать удалённую OLTP-базу.

Как это работает подробнее

ETL переносит нужный срез по watermark или CDC и соединяет данные рядом с местом аналитического вычисления. Это добавляет задержку и поддержку пайплайна, но делает нагрузку предсказуемой и защищает PostgreSQL.

Федеративный движок не всегда проталкивает фильтр и агрегацию в источник. Изучите план выполнения и метрики: удалённые строки, байты сети, время блокировок и повторное использование результата.

Пример кода

incremental_customer_extract.sqlКопировать

SELECT customer_id, account_tier, updated_at
FROM public.customers
WHERE updated_at > :last_successful_watermark
  AND updated_at <= :current_watermark
ORDER BY updated_at, customer_id;

Что использовать на практике

• Материализуйте стабильные связи. Часто используемые dimensions и bridges загружайте в целевое хранилище.
• Минимизируйте перенос. Выбирайте только нужные столбцы и изменившиеся строки.
• Определите владельца. Пайплайн должен иметь SLA, проверки полноты и процедуру backfill.

Подводные камни

• Живой JOIN в дашборде. Он создаёт непредсказуемую зависимость от сети и OLTP.
• Копирование всего. Репликация ненужных полей увеличивает стоимость и зону доступа к данным.
• Нет согласованного среза. Источники, прочитанные в разное время, дают логически несовместимый результат.