Что означает федеративный запрос, когда данные можно оставить в исходной системе и какие ограничения есть у такого подхода.
Данные остались в рабочей системе
У компании есть рабочая база заказов и отдельная среда для аналитики. Аналитику нужны сведения о нескольких последних заказах, но переносить всю базу ради одного вопроса неудобно. Один из вариантов — обратиться к источнику через соединение и получить нужный результат. Такой способ называют федеративным запросом: аналитическая система запрашивает данные в другой системе, где они продолжают храниться.
Это не волшебная общая база. Системы остаются разными, соединение требует разрешений, а часть результата всё равно передаётся между ними для ответа пользователю. В документации Google Cloud федеративный запрос описан именно как обращение к внешней операционной базе из аналитической среды. Для понимания, зачем иногда создают отдельное хранилище, полезна статья о базе данных и хранилище.
Как аналитика видит источник
Сначала владелец источника разрешает доступ к определённым сведениям. Аналитическая система использует настроенное соединение, направляет часть работы внешней базе и получает результат. Пользователю это может выглядеть как единый вопрос к данным, хотя ответ зависит от двух сред. Доступ к одной системе сам по себе не означает право читать любую таблицу в другой.
Федеративный запрос отличается от постоянного переноса данных. При переносе создают собственную копию и обновляют её по расписанию или событиям. При обращении к источнику ответ ближе к его текущему состоянию, но зависит от доступности и нагрузки источника именно в момент чтения. Есть и смежный механизм внешних таблиц: он тоже позволяет работать с данными вне аналитического хранилища, однако способ подключения и поддерживаемые источники различаются.
Условный пример
Условный отдел продаж ведёт заказы в рабочей базе, а аналитики готовят еженедельный отчёт. Для разового вопроса о последних обращениях они могут запросить только нужный период через соединение. Из миллиона исторических строк не требуется заранее делать отдельную полную копию только ради этой проверки. Но если такой отчёт одновременно открывают сотни сотрудников, повторные обращения способны перегрузить рабочую базу.
Поэтому важно согласовать с владельцем системы допустимую нагрузку, права и время обновления. Иногда для аналитики используют читающую копию рабочей базы. Так повседневная работа с заказами меньше зависит от тяжёлых аналитических вопросов. Конкретная архитектура всегда зависит от нагрузки и требований к свежести данных, а не от привлекательности самого слова «федерация».
Почему ответ может приходить дольше
Аналитическая среда ждёт, пока внешний источник выполнит свою часть работы и передаст результат. Сеть, расстояние между системами, скорость источника и объём ответа влияют на время. Документация Google Cloud прямо предупреждает: федеративные запросы могут быть медленнее чтения данных, уже размещённых в аналитическом хранилище. Внешние таблицы имеют похожее ограничение по скорости и могут зависеть от изменений исходных данных во время чтения.
Другой риск — разные определения полей и форматов в системах. Если отчёт соединяет сведения из нескольких мест, нужно проверить, одинаково ли они понимают дату, идентификатор клиента и статус заказа. Быстрый доступ к источнику не заменяет согласования смысла данных. Хранение больших наборов как отдельных объектов рассмотрено в статье об объектном хранилище.
Когда лучше перенести данные
Если отчёт нужен регулярно, затрагивает много строк и должен работать быстро без влияния на рабочую базу, перенос выбранных данных в аналитическое хранилище часто удобнее. Появляется собственный график обновления, контроль качества и предсказуемая нагрузка. Цена — дополнительная копия, её хранение и необходимость объяснить пользователю, насколько свежи сведения.
Для редкого вопроса по небольшому объёму федеративное чтение может быть разумным первым шагом. Сравнивайте варианты по четырём вопросам: какой объём нужен, насколько важна свежесть, какова нагрузка на источник и кто отвечает за доступ. Выстраивать такие решения учатся на программе «Архитектор данных», где выбор способа связи между системами рассматривают в контексте всей архитектуры.
