Почему не работать напрямую с исходной базой

Что проверяют

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

Как отвечать

Перечислить причины, начиная с самой ощутимой.

• Нагрузка: скан по всей таблице конкурирует с транзакциями, вытесняет кэш, а в PostgreSQL долгая читающая транзакция ещё и мешает автовакууму убирать мёртвые версии строк. Падает продукт, а не ваш отчёт.
• Контракт: разработчики меняют колонки, когда им удобно, и пайплайн ломается молча. Витрина с фиксированной схемой это договорённость, которую нельзя нарушить случайно.
• Модель: схема нормализована под запись. Считать по ней метрики дорого, а ещё легко посчитать неверно из-за мягких удалений, технических дублей и обновлений на месте.
• История: строка обновилась, прежнее значение исчезло. Для обучения нужно состояние на момент события, иначе в признаки утекают данные из будущего и метрика на валидации выходит фантастической.
• Доступ: в витрине персональные поля маскируются и права выдаются на нужный срез, в боевой базе доступ обычно всё или ничего.

Что предлагать взамен: реплика на чтение для разовых задач, регулярная выгрузка в хранилище, слой витрин с проверками качества. Если ходить в бой всё же нужно, то отдельной ролью только на чтение и с ограничением времени запроса (statement_timeout).

Где спотыкаются

Сводят всё к нагрузке и предлагают реплику. Реплика снимает нагрузку, но не даёт ни истории, ни устойчивой схемы, ни маскирования. Это разные проблемы и разные решения.

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

Путают базу приложения и сырой слой хранилища. Сырой слой это уже копия, ходить в него нормально, а запрет касается базы работающего сервиса. Ответ «с сырыми данными работать нельзя» подменяет тему.