@AskarKazTeleRadio

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

У нас есть три среды Dev/Stage/Prod, соответственно у каждой среды своя база данных Postgresql.
Аналитики имеют доступ только к двум из них, это Dev/Stage. Prod закрыт по требованию отдела Безопасности.
Очень часто бывает так что надо внести изменения в Prod-Postgresql от аналитиков, но так как доступов у них нет они просят Админов прогнать их SQL запрос на Проде. Это дико неудобно и создает ненужную работу Админам.
Прошу подсказать, существует ли какой-то инструмент который позволяет запускать SQL-запросы от аналитиков и чтобы это было прозрачно и с логами?
Рассматривали вариант репозиторий с CI/CD куда аналитик кладет свой SQL-запрос.
  • Вопрос задан
  • 291 просмотр
Решения вопроса 1
@Vitsliputsli

существует ли какой-то инструмент который позволяет запускать SQL-запросы от аналитиков и чтобы это было прозрачно и с логами?
Рассматривали вариант репозиторий с CI/CD куда аналитик кладет свой SQL-запрос.


Да хоть сами такой напишите, это просто.
Но, проблема не в этом, работать от принципа "сломали прод - щас по логам найдем кто" это очень хреновый вариант. Я к тому, что подобные запросы, должны верифицироваться, и желательно не только админами, но и техническим руководителем проекта. Да это долго, да тяжко для всех участников, но это лучше, чем положить прод.
Только так, если дорожите стабильностью.
Если какието запросы делаете слишком часто - очевидна необходимость автоматизации, добавления функционала в админку, т.к. при большом кол-ве, фактор человеческой ошибки вырастет. А само наличие таких запросов, если их мало, нормально для большинства систем.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 5
@Everything_is_bad
Prod закрыт по требованию отдела Безопасности.
Проблема в ваших бизнес процессах, переделайте их с учетом требований от аналитиков. Если аналитикам нужны данные с прода, то, например, можно выдать им доступ только на чтение, только определенных данных, надеюсь "надо внести изменения в Prod-Postgresql от аналитиков" это опечатка и нужно только чтение (а то если тут запись, то с этим условием будет всё сложнее)? Либо сделайте slave только с ограниченными данными. Решение сильно зависит от того, что именно хотят делать аналитики и с какими данными.
Ответ написан
saboteur_kiev
@saboteur_kiev
software engineer
Рассматривали вариант репозиторий с CI/CD куда аналитик кладет свой SQL-запрос.


Ну это нормальная ситуация. Но нужно понимать, что прогонять что-либо на проде, особенно внося изменения, нельзя без тестирования и возможности отката. Еще и без согласования по времени.

Конечно, можно настроить CD таким образом, чтобы пайплайн проверял был ли он запущен на тесте до того как запускать на проде, и при запуске на проде, чтобы выполнялся бэкап.

Но риски, если что-то пойдет на продакшене не так кто берет на себя?
Это нужно заранее обговорить с владельцем проекта.
То есть у вас перед принятием технического решения, нужно решить организационный.

P.S. Для обычных то есть рид-онли запросах, обычно просто пишется маленькое веб-приложение прямо для аналитиков, в котором шаблонизируются необходимые запросы и выдается результат в удобном для аналитике виде (html/csv/excel...), как часть обычного процесса разработки, интегрируется с вашей же системой авторизации и раздаются права какой репорт (запрос) кто может выполнять и смотреть результат.
Ответ написан
Комментировать
mayton2019
@mayton2019
Bigdata Engineer
Современные аналитики обычно не работают с БД напрямую. Особенно с той БД, где ходят клиенты
и активно работают короткие транзакции (OLTP).

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

ОИБ здесь конечно при делах и не при делах. Рациональное зерно такого разделения
состоит в том что с БД транзакций снимается ненужная I/O нагрузка и БД работает легче
и аналитики не натворят бед с denial of service.
Ответ написан
Комментировать
@Drno
простая html страничка, которая будет дергать нужный bash скрипт...
Ответ написан
VoidVolker
@VoidVolker
Dark side eye. А у нас печеньки! А у вас?
Вообще, самое правильно решение в данном случае будет завести отдельную БД для аналитики/статистики и прочего и все данные этой категории класть туда. И соответственно поднять отдельный HTTP сервер, где вся эта статистика будет показываться - и вот туда запустить аналитиков и пускай они там занимаются своей аналитикой. Например можно использовать что-то типа графаны.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы