Как можно автоматизировать выполнение запросов в Postgresql?

Как можно обеспечить аналитикам возможность запускать SQL-запросы на базе данных Prod без прямого доступа, сохраняя прозрачность и возможность отслеживания логов действий, исключая необходимость вмешательства администраторов?
  • 22 февраля 2024 г. 9:58
Ответы на вопрос 5
Для автоматизации выполнения запросов в PostgreSQL можно использовать различные инструменты и методы, включая:

1. Использование планировщика задач (например, cron) для запуска скриптов с SQL запросами по расписанию.

2. Написание хранимых процедур или функций на SQL или PL/pgSQL, которые можно запускать автоматически через триггеры или события.

3. Использование сторонних инструментов для автоматизации выполнения запросов, таких как pgagent или Apache Airflow.

Чтобы обеспечить аналитикам возможность запускать SQL запросы на базе данных Prod без прямого доступа, можно использовать следующие подходы:

1. Создание специальной роли в PostgreSQL, которая будет иметь только необходимые права на выполнение запросов, но не на изменение структуры данных или данных.

2. Реализация доступа через API или веб-интерфейс, который позволит аналитикам отправлять SQL запросы и получать результаты, не имея доступа к самой базе данных.

3. Логирование всех запросов, выполненных через этот механизм, для возможности отслеживания действий и аудита.

4. Создание специального механизма управления доступом, который позволит аналитикам запросить выполнение определенного SQL запроса, подтвердив свою идентичность и цель запроса, без необходимости вмешательства администраторов.
Prod закрыт по требованию отдела Безопасности.
Проблема в ваших бизнес процессах, переделайте их с учетом требований от аналитиков. Если аналитикам нужны данные с прода, то, например, можно выдать им доступ только на чтение, только определенных данных, надеюсь "надо внести изменения в Prod-Postgresql от аналитиков" это опечатка и нужно только чтение (а то если тут запись, то с этим условием будет всё сложнее)? Либо сделайте slave только с ограниченными данными. Решение сильно зависит от того, что именно хотят делать аналитики и с какими данными.
простая html страничка, которая будет дергать нужный bash скрипт...
Вообще, самое правильно решение в данном случае будет завести отдельную БД для аналитики/статистики и прочего и все данные этой категории класть туда. И соответственно поднять отдельный HTTP сервер, где вся эта статистика будет показываться - и вот туда запустить аналитиков и пускай они там занимаются своей аналитикой. Например можно использовать что-то типа графаны .
Современные аналитики обычно не работают с БД напрямую . Особенно с той БД, где ходят клиенты 
и активно работают короткие транзакции (OLTP).

В крупных конторах наподобие банков и торговых сетей обычно для аналитиков отгружаются
все-все исторические данные
, что проходили в БД. В денормализованном виде. Обычно
такие себе широкие таблицы по 100 - 500 колонок. И эти таблицы сливаются во всякие
аналитические системы (Databricks) в формате column-oriented tables (Delta-table). И аналитики
работают с этими данными на языках SQL/Python/R e.t.c. Строют всякие графики, краcивые
картинки и агрегации.

ОИБ здесь конечно при делах и не при делах . Рациональное зерно такого разделения
состоит в том что с БД транзакций снимается ненужная I/O нагрузка и БД работает легче
и аналитики не натворят бед с denial of service.
Похожие вопросы