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

Question

[AskarKazTeleRadio]

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

Comments

[Сергей Горностаев]

Вы сначала у безопасников выясните разрешат ли они исключить админов из процесса. Заодно неплохо бы понять, почему вообще аналитики вносят какие-либо изменения на проде, притом часто - это выглядит противоестественным.

[AskarKazTeleRadio]

Сергей Горностаев, согласен изменения на проде БД аналитиками это плохой процесс, но в условиях быстрых процессов разработки Разрабы не успевают делать примелимые админ-панели для своих сервисов, поэтому у нас частая практика внесения изменений в бд (с безами договоримся).

[shurshur]

AskarKazTeleRadio, какого рода "изменения" им нужны? Обычно в аналитических целях нужно делать только select.

[AskarKazTeleRadio]

shurshur, INSERT

[shurshur]

AskarKazTeleRadio, зачем аналитикам insert?

В конце концов, создать им рядом базу / схему с доступом для их юзеров и на продовые данные сильно зарезать доступ. Но лучше сразу реплику с пофильтрованными данными.

Answer 1

[Vitsliputsli]

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

Да хоть сами такой напишите, это просто.
Но, проблема не в этом, работать от принципа "сломали прод - щас по логам найдем кто" это очень хреновый вариант. Я к тому, что подобные запросы, должны верифицироваться, и желательно не только админами, но и техническим руководителем проекта. Да это долго, да тяжко для всех участников, но это лучше, чем положить прод.
Только так, если дорожите стабильностью.
Если какието запросы делаете слишком часто - очевидна необходимость автоматизации, добавления функционала в админку, т.к. при большом кол-ве, фактор человеческой ошибки вырастет. А само наличие таких запросов, если их мало, нормально для большинства систем.

Answer 2

[Everything_is_bad]

Prod закрыт по требованию отдела Безопасности.

Проблема в ваших бизнес процессах, переделайте их с учетом требований от аналитиков. Если аналитикам нужны данные с прода, то, например, можно выдать им доступ только на чтение, только определенных данных, надеюсь "надо внести изменения в Prod-Postgresql от аналитиков" это опечатка и нужно только чтение (а то если тут запись, то с этим условием будет всё сложнее)? Либо сделайте slave только с ограниченными данными. Решение сильно зависит от того, что именно хотят делать аналитики и с какими данными.

Comments

[AskarKazTeleRadio]

С чтением БД проблем нет

"внести изменения в Prod-Postgresql от аналитиков" это не опечатка, а наш плохой процесс, отписал в коментах почему у нас так

[Everything_is_bad]

AskarKazTeleRadio, ну тогда все изменения должны быть оформлены в виде миграции (а так же по возможности обратной), это как раз и будет обычный процесс CI/CD, он же у вас используется для деплоя на прод?

[AskarKazTeleRadio]

Everything_is_bad, так и есть, все изменения идут как миграции через CI/CD.

Но бывают случай когда надо просто изменить статус заказа (потому-то сервис наш плохо написан и не сделал этого, залогал) или удалить заказ (из той же оперы). Согласен это не наши проблемы,

по-хорошему надо сказать что пишите нормально сервис, мы не будем заниматься таким колхозом,

но пока не исправят надо с этим жить и как то упростить себе работу)

[Everything_is_bad]

AskarKazTeleRadio,

Но бывают случай когда надо просто изменить статус заказа (потому-то сервис наш плохо написан и не сделал этого, залогал) или удалить заказ (из той же оперы).

для такого по идеи вообще писать админку и подобное делать в ней.

Answer 3

[Saboteur]

Рассматривали вариант репозиторий с CI/CD куда аналитик кладет свой SQL-запрос.

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

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

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

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

Answer 4

[mayton2019]

Современные аналитики обычно не работают с БД напрямую. Особенно с той БД, где ходят клиенты
и активно работают короткие транзакции (OLTP).

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

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

Answer 5

[Drno]

простая html страничка, которая будет дергать нужный bash скрипт...

Comments

[AskarKazTeleRadio]

Впринципе башануть можно всегда))

Я в вопросе имел ввиду есть ли бест практисы в решений данной траблы?)

[Drno]

AskarKazTeleRadio, а что может быть проще...
запросили лог пасс - авторизовали - показали строку для запуска sql - передали в bash - записали логи...)

Answer 6

[VoidVolker]

Вообще, самое правильно решение в данном случае будет завести отдельную БД для аналитики/статистики и прочего и все данные этой категории класть туда. И соответственно поднять отдельный HTTP сервер, где вся эта статистика будет показываться - и вот туда запустить аналитиков и пускай они там занимаются своей аналитикой. Например можно использовать что-то типа графаны.

Comments

[AskarKazTeleRadio]

С чтением БД проблем нет

Проблема в внесений изменений в прод БД, чтобы было прозрачно и с логами

Почему аналитики вносят какие-либо изменения на проде? Отписал в коментах к вопросу

[VoidVolker]

Внесение изменений в продакшен БД означает, что у вас проблемы с организацией процесса разработки и его разворачивания, а не автоматизацией запросов в БД. В правильно организованном процессе разработки нет необходимости вносить изменения в продакшен БД напрямую.