— Нет времени объяснять, просто подключите хранилище напрямую к продовой базе. Есть какой-то ТУЗ не нужный?

Так обычно начинается повесть о созданном в рекордные сроки дашборде. А потом боль и унижение, и никто не хочет брать на себя ответственность, когда упал прод, потому что BI‑аналитик выгружал 90 миллионов строк join’ом без фильтра. А вашему бизнесу всё равно, кто виноват. Данные не пришли, отчёта нет, шеф злой.

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

Подходы к интеграции: от тяп-ляпа до архитектурно зрелого

1. Прямой доступ к базе через техническую учётку (он же «давай просто подключимся»)

Это когда из хранилища (или витрины, или BI‑инструмента) просто ставится прямое подключение к боевой базе, обычно через выделенного пользователя с правами SELECT. На жаргоне ТУЗ (техническая учётная запись).

Применяется, когда:

• нужно срочно что-то показать;

• ETL ещё не настроен;

• ресурсов мало;

• никто не хочет ждать формализацию требований три недели/месяца.

Основные проблемы:

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

• сложно контролировать, кто что тащит, когда и зачем;

• невозможно отследить lineage, или куда потом пошли эти данные;

• с точки зрения безопасности - это дырка;

• как правило, никто не следит за этой связью, пока она не упадёт.

Вывод: чистой воды технический долг. Годно для MVP или на пару недель, но жить с этим в проде довольно опасно. Использовать можно только с ограничениями: лимиты трафика, сетевая изоляция, мониторинг.

2. Batch ETL выгрузка по расписанию

Классика. По cron или через Airflow в определённое время запускается задание, которое тянет нужные данные из источника и складывает их в хранилище. Это может быть CSV, SQL-скрипт, Python-код или что-то посерьёзней. Из практики в большинстве случаев этого способа достаточно, чтобы закрыть 90% потребностей бизнеса в аналитике. Если вы так научились, дальше только перфекционизм.

Плюсы:

• просто;

• можно контролировать нагрузку (всё ночью или в окно активности);

• понятная точка восстановления (вчерашняя выгрузка упала, перезапустили);

• легко отлаживать.

Минусы:

• задержка по времени (ничего real-time);

• если схема источника изменилась, всё падает;

• если много источников, может быть бардак;

• нет встроенного lineage, если не настраивать вручную.

Где уместно:

• когда источники стабильны;

• если бизнес окей с лагом в 1–6 часов;

• нужно просто и надёжно.

3. CDC (Change Data Capture)

Продвинутый способ: забираем только то, что изменилось. Работает через логи транзакций (logical replication, Debezium и прочие инструменты) или триггеры в базе.

Почему круто:

• минимальная нагрузка на источник;

• почти real-time;

• можно восстанавливать историю изменений;

• отлично для витрин, витрин в ClickHouse, лейков и фичей для AI.

Почему больно:

• нужно уметь это настраивать;

• не все источники поддерживают нормальный CDC;

• при смене структуры есть шансы умереть;

• приходится следить за отставанием, партиционированием, конфликтами и очередями.

Где уместно:

• если источники нагруженные и важна производительность;

• если хочется real-time или хотя бы near real-time;

• если бизнес уже требует данные «сейчас», а не «завтра утром».

4. API-интеграции

Когда источник не даёт прямого подключения к базе, но есть REST, GraphQL, gRPC и прочее, можно работать через API. Тут нет доступа к таблицам, но есть эндпоинты, через которые можно забирать данные.

Плюсы:

• не лезем в базу = безопаснее;

• получаем данные в готовом виде (в идеале);

• можем делать это, как угодно, часто.

Минусы:

• API может быть медленным;

• могут быть ограничения (rate limit, pagination);

• часто API не предоставляет всей нужной информации;

• нестабильность и отсутствие логирования.

Где уместно:

• когда других способов нет;

• когда источник сам сервис (CRM, 1С, сторонние системы);

• когда важна «чистота» и независимость.

5. Событийная интеграция (Kafka, RabbitMQ, pub/sub)

Это уже взрослый уровень. Источник публикует события (например, "создан новый тикет", "обновлена карточка сотрудника"), и дальше потребители (в том числе DWH) подписываются на них. Такой способ позволяет строить потоковую обработку данных, при этом каждый потребитель может реагировать в своём темпе.

Плюсы:

• масштабируется;

• отлично для real-time;

• decoupling: источник не знает про потребителя;

• данные идут по мере появления.

Минусы:

• нужен зоопарк: брокер, хранение, потребители;

• дорого по инфраструктуре и поддержке;

• сложно отлаживать и мониторить;

• высокая цена за вход.

Где уместно:

• high-load системы;

• микросервисы, финансовые события, транзакции;

• там, где real-time критичен.

Подводные камни и грабли

• CDC без ретеншна. Вы проехали момент, логи стерлись, догнать нельзя.

• API с rate limit. Вроде всё тянется, но потом бах 429 Too Many Requests.

• Kafka без схемы. Прилетает событие с неожиданным полем, и твой консьюмер ломается.

• ETL без контроля схемы. Таблица в источнике поменялась, а ты об этом узнаешь от злого аналитика.

• Прямой доступ с JOIN’ом на всё. И прод лежит.

Как выбрать подход

Спроси себя:

• Насколько стабильный у тебя источник?

• Насколько быстро тебе нужны данные?

• Кто будет поддерживать этот процесс через 3 месяца?

• Сколько у тебя разработчиков и железа?

• Что критичнее: скорость или надёжность?

Универсального ответа нет. Но точно можно сказать, если ты в 2025 году подключаешь хранилище напрямую к продовой базе, то у тебя или всё очень плохо, или всё очень быстро, или всем на всё плевать.